2. Classify the work

Every item should end up in one of these states:

3. Decide whether Linear is warranted

Create or update Linear only if:

• execution is actively planned
• multiple repos or workstreams are involved
• the work needs internal ownership or sequencing
• the issue is part of a larger program lane

Do not mirror everything mechanically.

4. Keep the two systems consistent

When work is active:

• GitHub issue/PR should say what is happening publicly
• Linear should track owner, priority, and execution lane internally

When work ships or is rejected:

• post the public resolution back to GitHub
• mark the Linear task accordingly

Review Rules

• Never merge from title, summary, or trust alone; use the full diff
• External-source features should be rebuilt inside ECC when they are valuable but not self-contained
• CI red means classify and fix or block; do not pretend it is merge-ready
• If the real blocker is product direction, say so instead of hiding behind tooling

Output Format

Return:

PUBLIC STATUS
- issue / PR state
- CI / review state

CLASSIFICATION
- merge / port-rebuild / close / park
- one-paragraph rationale

LINEAR ACTION
- create / update / no Linear item needed
- project / lane if applicable

NEXT OPERATOR ACTION
- exact next move

Good Use Cases

• "Audit the open PR backlog and tell me what to merge vs rebuild"
• "Map GitHub issues into our ECC 1.x and ECC 2.0 program lanes"
• "Check whether this needs a Linear issue or should stay GitHub-only"

santa-method

通过双评审智能体对结果进行对抗式校验，提升输出发布前的可靠性

github-ops

帮助你执行 GitHub 操作、自动化流程并集成 API 与 CI/CD 工作流。