<!-- SYNC:understand-code-first -->[IMPORTANT] Use
TaskCreateto 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.
<!-- /SYNC:understand-code-first --> <!-- SYNC:evidence-based-reasoning -->Understand Code First — HARD-GATE: Do NOT write, plan, or fix until you READ existing code.
- Search 3+ similar patterns (
grep/glob) — citefile:lineevidence- Read existing files in target area — understand structure, base classes, conventions
- Run
python .claude/scripts/code_graph trace <file> --direction both --jsonwhen.code-graph/graph.dbexists- Map dependencies via
connectionsorcallers_of— know what depends on your target- Write investigation to
.ai/workspace/analysis/for non-trivial tasks (3+ files)- Re-read analysis file before implementing — never work from memory alone
- 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
<!-- /SYNC:evidence-based-reasoning --> <!-- SYNC:estimation-framework -->Evidence-Based Reasoning — Speculation is FORBIDDEN. Every claim needs proof.
- Cite
file:line, grep results, or framework docs for EVERY claim- Declare confidence: >80% act freely, 60-80% verify first, <60% DO NOT recommend
- Cross-service validation required for architectural changes
- "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 statedForbidden without proof: "obviously", "I think", "should be", "probably", "this is because" If incomplete → output:
"Insufficient evidence. Verified: [...]. Not verified: [...]."
<!-- /SYNC:estimation-framework -->Estimation — Modified Fibonacci: 1(trivial) → 2(small) → 3(medium) → 5(large) → 8(very large) → 13(epic, SHOULD split) → 21(MUST ATTENTION split). Output
story_pointsandcomplexityin 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)
<!-- /SYNC:plan-quality --> <!-- SYNC:iterative-phase-quality -->Plan Quality — Every plan phase MUST ATTENTION include test specifications.
- Add
## Test Specificationssection with TC-{FEAT}-{NNN} IDs to every phase file- Map every functional requirement to ≥1 TC (or explicit
TBDwith rationale)- TC IDs follow
TC-{FEATURE}-{NNN}format — reference by ID, never embed full content- Before any new workflow step: call
TaskListand re-read the phase file- On context compaction: call
TaskListFIRST — never create duplicate tasks- 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-specfills after.
<!-- /SYNC:iterative-phase-quality -->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:
- Fetch — Download CI logs from GitHub Actions
- Analyze — Identify root causes from build/test failures
- 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-reviewafter 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
EnterPlanModetool — 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-reviewto 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.mdMUST 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:
- Task: "Write test specifications for each phase" — Add
## Test Specificationswith TC-{FEAT}-{NNN} IDs to every phase file. Use/tdd-specif feature docs exist. UseEvidence: TBDfor TDD-first mode. - Task: "Run /plan-validate" — Trigger
/plan-validateskill to interview the user with critical questions and validate plan assumptions - Task: "Run /plan-review" — Trigger
/plan-reviewskill to auto-review plan for validity, correctness, and best practices
- Task: "Write test specifications for each phase" — Add
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
EnterPlanModetool. DO NOT start implementing. ALWAYS validate with/plan-reviewafter 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
TaskCreateBEFORE starting - MANDATORY IMPORTANT MUST ATTENTION search codebase for 3+ similar patterns before creating new code
- MANDATORY IMPORTANT MUST ATTENTION cite
file:lineevidence 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 <!-- SYNC:plan-quality:reminder -->
- MANDATORY IMPORTANT MUST ATTENTION include
## Test Specificationswith TC IDs per phase. CallTaskListbefore creating new tasks. <!-- /SYNC:plan-quality:reminder --> <!-- SYNC:evidence-based-reasoning:reminder --> - MANDATORY IMPORTANT MUST ATTENTION cite
file:lineevidence for every claim. Confidence >80% to act, <60% = do NOT recommend. <!-- /SYNC:evidence-based-reasoning:reminder --> <!-- SYNC:estimation-framework:reminder --> - MANDATORY IMPORTANT MUST ATTENTION include
story_pointsandcomplexityin plan frontmatter. SP > 8 = split. <!-- /SYNC:estimation-framework:reminder --> <!-- SYNC:iterative-phase-quality:reminder --> - MANDATORY IMPORTANT MUST ATTENTION score complexity first. Score >=6 → decompose. Each phase: plan → implement → review → fix → verify. No skipping. <!-- /SYNC:iterative-phase-quality:reminder -->