plan-ci（计划 ci）

[IMPORTANT] Use TaskCreate to break ALL work into small tasks BEFORE starting — including tasks for each file read. This prevents context loss from long files. For simple tasks, AI MUST ATTENTION ask user whether to skip.

Understand Code First — HARD-GATE: Do NOT write, plan, or fix until you READ existing code. 1. Search 3+ similar patterns (grep/glob) — cite file:line evidence 2. Read existing files in target area — understand structure, base classes, conventions 3. Run python.claude/scripts/code_graph trace <file> --direction both --json when .code-graph/graph.db exists 4. Map dependencies via connections or callers_of — know what depends on your target 5. Write investigation to .ai/workspace/analysis/ for non-trivial tasks (3+ files) 6. Re-read analysis file before implementing — never work from memory alone 7. NEVER invent new patterns when existing ones work — match exactly or document deviation BLOCKED until: - [] Read target files - [] Grep 3+ patterns - [] Graph trace (if graph.db exists) - [] Assumptions verified with evidence

Evidence-Based Reasoning — Speculation is FORBIDDEN. Every claim needs proof. 1. Cite file:line, grep results, or framework docs for EVERY claim 2. Declare confidence: >80% act freely, 60-80% verify first, <60% DO NOT recommend 3. Cross-service validation required for architectural changes 4. "I don't have enough evidence" is valid and expected output BLOCKED until: - [] Evidence file path (file:line) - [] Grep search performed - [] 3+ similar patterns found - [] Confidence level stated Forbidden without proof: "obviously", "I think", "should be", "probably", "this is because" If incomplete → output: "Insufficient evidence. Verified: [...]. Not verified: [...]."

Estimation — Modified Fibonacci: 1(trivial) → 2(small) → 3(medium) → 5(large) → 8(very large) → 13(epic, SHOULD split) → 21(MUST ATTENTION split). Output story_points and complexity in plan frontmatter. Complexity auto-derived: 1-2=Low, 3-5=Medium, 8=High, 13+=Critical.

• docs/test-specs/ — Test specifications by module (read existing TCs to include test strategy in plan)

Plan Quality — Every plan phase MUST ATTENTION include test specifications. 1. Add ## Test Specifications section with TC-{FEAT}-{NNN} IDs to every phase file 2. Map every functional requirement to ≥1 TC (or explicit TBD with rationale) 3. TC IDs follow TC-{FEATURE}-{NNN} format — reference by ID, never embed full content 4. Before any new workflow step: call TaskList and re-read the phase file 5. On context compaction: call TaskList FIRST — never create duplicate tasks 6. Verify TC satisfaction per phase before marking complete (evidence must be file:line, not TBD) Mode: TDD-first → reference existing TCs with Evidence: TBD. Implement-first → use TBD → /tdd-spec fills after.

Iterative Phase Quality — Score complexity BEFORE planning. Complexity signals: >5 files +2, cross-service +3, new pattern +2, DB migration +2 Score >=6 → MUST ATTENTION decompose into phases. Each phase: - ≤5 files modified - ≤3h effort - Follows cycle: plan → implement → review → fix → verify - Do NOT start Phase N+1 until Phase N passes VERIFY Phase success = all TCs pass + code-reviewer agent approves + no CRITICAL findings.

Skill Variant: Variant of /plan — specialized for CI/GitHub Actions failure analysis.

Quick Summary

Goal: Analyze GitHub Actions CI logs and create a plan to fix the identified issues.

Workflow:

1. Fetch — Download CI logs from GitHub Actions
2. Analyze — Identify root causes from build/test failures
3. Plan — Create implementation plan to fix CI issues

Key Rules:

• PLANNING-ONLY: do not implement, only create fix plan
• Focus on CI-specific issues (build, test, env, Docker, dependencies)
• Always offer /plan-review after plan creation

Be skeptical. Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence percentages (Idea should be more than 80%).

Activate planning skill.

PLANNING-ONLY — Collaboration Required

DO NOT use the EnterPlanMode tool — you are ALREADY in a planning workflow. DO NOT implement or execute any code changes. COLLABORATE with the user: ask decision questions, present options with recommendations. After plan creation, ALWAYS run /plan-review to validate the plan. ASK user to confirm the plan before any next step.

Github Actions URL

$ARGUMENTS

Use the planner subagent to read the github actions logs, analyze and find the root causes of the issues, then provide a detailed plan for implementing the fixes.

Plan File Specification:

• Every plan.md MUST ATTENTION start with YAML frontmatter: --- title: '{Brief title}' description: '{One sentence for card preview}' status: pending priority: P1 effort: {estimated fix time} branch: {current git branch} tags: [ci, bugfix] created: {YYYY-MM-DD} ---

Output: Provide at least 2 implementation approaches with clear trade-offs, and explain the pros and cons of each approach, and provide a recommended approach.

IMPORTANT Task Planning Notes (MUST ATTENTION FOLLOW)

• Always plan and break work into many small todo tasks using TaskCreate
• Always add a final review todo task to verify work quality and identify fixes/enhancements
• MANDATORY FINAL TASKS: After creating all planning todo tasks, ALWAYS add these three final tasks:

1. Task: "Write test specifications for each phase" — Add ## Test Specifications with TC-{FEAT}-{NNN} IDs to every phase file. Use /tdd-spec if feature docs exist. Use Evidence: TBD for TDD-first mode. 2. Task: "Run /plan-validate" — Trigger /plan-validate skill to interview the user with critical questions and validate plan assumptions 3. Task: "Run /plan-review" — Trigger /plan-review skill to auto-review plan for validity, correctness, and best practices

Important Notes

IMPORTANT: Analyze the skills catalog and activate the skills that are needed for the task during the process. IMPORTANT: Sacrifice grammar for the sake of concision when writing outputs.

REMINDER — Planning-Only Command

DO NOT use EnterPlanMode tool. DO NOT start implementing. ALWAYS validate with /plan-review after plan creation. ASK user to confirm the plan before any implementation begins. ASK user decision questions with your recommendations when multiple approaches exist.

Closing Reminders

• MANDATORY IMPORTANT MUST ATTENTION break work into small todo tasks using TaskCreate BEFORE starting
• MANDATORY IMPORTANT MUST ATTENTION search codebase for 3+ similar patterns before creating new code
• MANDATORY IMPORTANT MUST ATTENTION cite file:line evidence for every claim (confidence >80% to act)
• MANDATORY IMPORTANT MUST ATTENTION add a final review todo task to verify work quality
• MANDATORY IMPORTANT MUST ATTENTION include Test Specifications section and story_points in plan frontmatter
• MANDATORY IMPORTANT MUST ATTENTION include ## Test Specifications with TC IDs per phase. Call TaskList before creating new tasks.
• MANDATORY IMPORTANT MUST ATTENTION cite file:line evidence for every claim. Confidence >80% to act, <60% = do NOT recommend.
• MANDATORY IMPORTANT MUST ATTENTION include story_points and complexity in plan frontmatter. SP > 8 = split.
• MANDATORY IMPORTANT MUST ATTENTION score complexity first. Score >=6 → decompose. Each phase: plan → implement → review → fix → verify. No skipping.