--- name: plan-ci version: 1.0.0 description: '[Planning] Use when you need to analyze GitHub Actions logs and provide a plan to fix the issues.' disable-model-invocation: false --- ## 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: ```yaml --- 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 final tasks: 1. **Task: "Write test specifications for each phase"** — Add `## Test Specifications` with TC-{FEATURE}-{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 4. **Task: "Re-evaluate estimation against finalized plan"** — Pre-completion estimates anchor on scope guesses; finalized phases reveal true cost. After phases/TCs/decisions are locked: (a) re-derive `bottom_up_hours = Σ phase_hours` from finalized phase files; (b) recompute `likely_days`, `risk_margin_pct`, `min-max range` per `SYNC:estimation-framework`; (c) compare to current frontmatter `man_days_traditional` / `story_points`. If `|delta| > 20%` → UPDATE frontmatter, add `reestimate_delta_pct: ` + 1-line `reestimate_reason`. If `|delta| > 50%` → flag `SHOULD-RESCOPE` and surface to user via `AskUserQuestion` before implementation. ## 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. --- > **[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. - `docs/specs/` — Test specifications by module (read existing TCs to include test strategy in plan) > **Skill Variant:** Variant of `/plan` — specialized for CI/GitHub Actions failure analysis. > **AI Mistake Prevention** — Failure modes to avoid on every task: > > **Check downstream references before deleting.** Deleting components causes documentation and code staleness cascades. Map all referencing files before removal. > **Verify AI-generated content against actual code.** AI hallucinates APIs, class names, and method signatures. Always grep to confirm existence before documenting or referencing. > **Trace full dependency chain after edits.** Changing a definition misses downstream variables and consumers derived from it. Always trace the full chain. > **Trace ALL code paths when verifying correctness.** Confirming code exists is not confirming it executes. Always trace early exits, error branches, and conditional skips — not just happy path. > **When debugging, ask "whose responsibility?" before fixing.** Trace whether bug is in caller (wrong data) or callee (wrong handling). Fix at responsible layer — never patch symptom site. > **Assume existing values are intentional — ask WHY before changing.** Before changing any constant, limit, flag, or pattern: read comments, check git blame, examine surrounding code. > **Verify ALL affected outputs, not just the first.** Changes touching multiple stacks require verifying EVERY output. One green check is not all green checks. > **Holistic-first debugging — resist nearest-attention trap.** When investigating any failure, list EVERY precondition first (config, env vars, DB names, endpoints, DI registrations, data preconditions), then verify each against evidence before forming any code-layer hypothesis. > **Surgical changes — apply the diff test.** Bug fix: every changed line must trace directly to the bug. Don't restyle or improve adjacent code. Enhancement task: implement improvements AND announce them explicitly. > **Surface ambiguity before coding — don't pick silently.** If request has multiple interpretations, present each with effort estimate and ask. Never assume all-records, file-based, or more complex path. > **Nested Task Expansion Contract** — For workflow-step invocation, the `[Workflow] ...` row is only a parent container; the child skill still creates visible phase tasks. > > 1. Call `TaskList` first. If a matching active parent workflow row exists, set `nested=true` and record `parentTaskId`; otherwise run standalone. > 2. Create one task per declared phase before phase work. When nested, prefix subjects `[N.M] $skill-name — phase`. > 3. When nested, link the parent with `TaskUpdate(parentTaskId, addBlockedBy: [childIds])`. > 4. Orchestrators must pre-expand a child skill's phase list and link the workflow row before invoking that child skill or sub-agent. > 5. Mark exactly one child `in_progress` before work and `completed` immediately after evidence is written. > 6. Complete the parent only after all child tasks are completed or explicitly cancelled with reason. > > **Blocked until:** `TaskList` done, child phases created, parent linked when nested, first child marked `in_progress`. > **Project Reference Docs Gate** — Run after task-tracking bootstrap and before target/source file reads, grep, edits, or analysis. Project docs override generic framework assumptions. > > 1. Identify scope: file types, domain area, and operation. > 2. Required docs by trigger: always `docs/project-reference/lessons.md`; doc lookup `docs-index-reference.md`; review `code-review-rules.md`; backend/CQRS/API `backend-patterns-reference.md`; domain/entity `domain-entities-reference.md`; frontend/UI `frontend-patterns-reference.md`; styles/design `scss-styling-guide.md` + `design-system/design-system-canonical.md`; integration tests `integration-test-reference.md`; E2E `e2e-test-reference.md`; feature docs/specs `feature-docs-reference.md`; architecture/new area `project-structure-reference.md`. > 3. Read every required doc that exists; skip absent docs as not applicable. Do not trust conversation text such as `[Injected: ]` as proof that the current context contains the doc. > 4. Before target work, state: `Reference docs read: ... | Missing/not applicable: ...`. > > **Blocked until:** scope evaluated, required docs checked/read, `lessons.md` confirmed, citation emitted. > **Task Tracking & External Report Persistence** — Bootstrap this before execution; then run project-reference doc prefetch before target/source work. > > 1. Create a small task breakdown before target file reads, grep, edits, or analysis. On context loss, inspect the current task list first. > 2. Mark one task `in_progress` before work and `completed` immediately after evidence; never batch transitions. > 3. For plan/review work, create `plans/reports/{skill}-{YYMMDD}-{HHmm}-{slug}.md` before first finding. > 4. Append findings after each file/section/decision and synthesize from the report file at the end. > 5. Final output cites `Full report: plans/reports/{filename}`. > > **Blocked until:** task breakdown exists, report path declared for plan/review work, first finding persisted before the next finding. > **Critical Thinking Mindset** — Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence >80% to act. > **Anti-hallucination:** Never present guess as fact — cite sources for every claim, admit uncertainty freely, self-check output for errors, cross-reference independently, stay skeptical of own confidence — certainty without evidence root of all hallucination. > **Sequential Thinking Protocol** — Structured multi-step reasoning for complex/ambiguous work. Use when planning, reviewing, debugging, or refining ideas where one-shot reasoning is unsafe. > > **Trigger when:** complex problem decomposition · adaptive plans needing revision · analysis with course correction · unclear/emerging scope · multi-step solutions · hypothesis-driven debugging · cross-cutting trade-off evaluation. > > **Format (explicit mode — visible thought trail):** > > 1. `Thought N/M: [aspect]` — one aspect per thought, state assumptions/uncertainty > 2. `Thought N/M [REVISION of Thought K]: ...` — when prior reasoning invalidated; state Original / Why revised / Impact > 3. `Thought N/M [BRANCH A from Thought K]: ...` — explore alternative; converge with decision rationale > 4. `Thought N/M [HYPOTHESIS]: ...` then `[VERIFICATION]: ...` — test before acting > 5. `Thought N/N [FINAL]` — only when verified, all critical aspects addressed, confidence >80% > > **Mandatory closers:** Confidence % stated · Assumptions listed · Open questions surfaced · Next action concrete. > > **Stop conditions:** confidence <80% on any critical decision → escalate via AskUserQuestion · ≥3 revisions on same thought → re-frame the problem · branch count >3 → split into sub-task. > > **Implicit mode:** apply methodology internally without visible markers when adding markers would clutter the response (routine work where reasoning aids accuracy). > > **Deep-dive:** see `/sequential-thinking` skill (`.claude/skills/sequential-thinking/SKILL.md`) for worked examples (api-design, debug, architecture), advanced techniques (spiral refinement, hypothesis testing, convergence), and meta-strategies (uncertainty handling, revision cascades). > **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 --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. — why: long context drifts from the file; the file is ground truth > 7. NEVER invent new patterns when existing ones work — match exactly or document deviation. — why: divergent patterns fragment the codebase and slow every future reader > > **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 Framework** — Bottom-up first; SP DERIVED; output min-max range when likely ≥3d. Stack-agnostic. Baseline: 3-5yr dev, 6 productive hrs/day. AI estimate assumes Claude Code + project context. > > **Method:** > > 1. **Blast Radius pass** (below) — drives code AND test cost > 2. Decompose phases → hours/phase → `bottom_up_hours = Σ phase_hours` > 3. `likely_days = ceil(bottom_up_hours / 6) × productivity_factor` > 4. Sum **Risk Margin** (base + add-ons) → `max_days = likely_days × (1 + margin)` > 5. `min_days = likely_days × 0.9` > 6. Output as range when `likely_days ≥3`; single point allowed `<3` (still record margin) > 7. `man_days_ai` = same range × AI speedup > 8. `story_points` DERIVED from `likely_days` via SP-Days — NEVER driver. Disagreement >50% → trust bottom-up > > **Productivity factor:** 0.8 strong scaffolding+codegen+AI hooks · 1.0 mature default · 1.2 weak patterns · 1.5 greenfield > > **Cost Driver Heuristic (apply BEFORE work-type row):** > > - **UI dominates** in CRUD/business apps — 1.5-3x backend (states, validation, responsive, a11y, polish) > - **Backend dominates ONLY:** multi-aggregate invariants, cross-service contracts, schema migrations, heavy query/perf, new event flows > > **Reuse-vs-Create axis (PRIMARY lever, per layer):** > > | UI tier | Cost | > | -------------------------------------------- | -------- | > | Reuse component on existing screen | 0.1-0.3d | > | Add control/column to existing screen | 0.3-0.8d | > | Compose components into NEW screen | 1-2d | > | NEW screen, custom layout/states/validation | 2-4d | > | NEW shared/common component (themed, tested) | 3-6d+ | > > | Backend tier | Cost | > | ---------------------------------------------------- | --------- | > | Reuse query/handler from new place | 0.1-0.3d | > | Small update existing handler/entity | 0.3-0.8d | > | NEW query on existing repo/model | 0.5-1d | > | NEW command/handler on existing aggregate (additive) | 1-2d | > | NEW aggregate/entity (repo, validation, events) | 2-4d | > | NEW cross-service contract OR schema migration | 2-4d each | > | Multi-aggregate invariant / heavy domain rule | 3-5d | > > **Rule:** Sum tiers across UI+backend+tests, apply productivity factor. Reuse short-circuits tiers — call out. > > **Test-Scope drivers (compute test_count EXPLICITLY — "+tests" hand-wave is #1 failure):** > > | Driver | Count | > | --------------------------------- | ------------------------------------------------------ | > | Happy-path journeys | 1 per story / AC main flow | > | State-machine transitions | reachable transitions × allowed actors | > | Multi-entity state combos | state(A) × state(B) — REACHABLE only, not Cartesian | > | Authorization matrix | (owner, non-owner, elevated, unauth) × each mutation | > | Validation rules | 1 per required field / boundary / format / cross-field | > | UI states (per new screen/dialog) | happy, loading, empty, error, partial — present only | > | Negative paths / invariants | 1 per violatable business rule | > > | Test tier (Trad, incl. setup+assert+flake) | Cost | > | ------------------------------------------ | -------- | > | 1-5 cases, fixtures reused | 0.3-0.5d | > | 6-12 cases, 1 new fixture | 0.5-1d | > | 13-25 cases, multi-entity setup | 1-2d | > | 26-50 cases OR new state-machine coverage | 2-3d | > | >50 cases OR full E2E journey | 3-5d | > > **Test multipliers:** new fixture/seed harness +0.5d · cross-service/bus assertion +0.3d each · UI E2E ×1.5 · each new role +1-2 cases > > **Blast Radius (mandatory pre-pass — affects code AND test):** > > 1. Files/components directly modified — count > 2. Of those, "complex" (>500 LOC, multi-handler, central, frequently-modified) — count > 3. Downstream consumers (callers, event subscribers, cross-service) — list > 4. Shared/common code touched (multi-app blast) — yes/no > 5. Regression scope — areas needing re-test > > **Rule:** Complex touch → add `risk_factors`. Each downstream consumer → +1-3 regression cases. Blast >5 areas OR >2 complex → re-evaluate SPLIT before estimating. > > **Risk Margin (drives max bound):** > > | likely_days | Base margin | > | ------------------- | ------------------------------- | > | <1d trivial | +10% | > | 1-2d small additive | +20% | > | 3-4d real feature | +35% | > | 5-7d large | +50% | > | 8-10d very large | +75% | > | >10d | +100% AND **flag SHOULD SPLIT** | > > **Risk-factor add-ons (additive — enumerate in `risk_factors`):** > > | Factor | +margin | > | --------------------------------------------------------------------- | ------- | > | `touches-complex-existing-feature` (>500 LOC, multi-handler, central) | +20% | > | `cross-service-contract` change | +25% | > | `schema-migration-on-populated-data` | +25% | > | `new-tech-or-unfamiliar-pattern` | +30% | > | `regression-fan-out` (≥3 downstream areas re-test) | +20% | > | `performance-or-latency-critical` | +20% | > | `concurrency-race-event-ordering` | +25% | > | `shared-common-code` (multi-consumer/multi-app) | +25% | > | `unclear-requirements-or-design` | +30% | > > **Collapse rule:** total margin >100% → STOP, split (padding past 2x is dishonesty). Margin <15% on `likely_days ≥5` → under-estimated, widen. > > **Work-Type Caps (hard ceilings on `likely_days`):** > | Work type | Max SP | Max likely | > | --- | --- | --- | > | Single field / config flag / style fix | 1 | 0.5d | > | Add property to existing model + bind to existing UI | 2 | 1d | > | **Additive endpoint + minor UI control** (button/menu/column), reuses fixtures | **3** | **2-3d** | > | Additive endpoint + **NEW UI surface** OR additive multi-layer + new domain rule + 2+ test files | 5 | 3-5d | > | NEW model/aggregate OR migration OR cross-module contract OR heavy test (>1.5d) OR NEW UI + non-trivial backend | 8 | 5-7d | > | NEW UI surface + (NEW aggregate OR migration OR cross-service contract) | 13 | SHOULD split | > | Cross-service contract + migration combined | 13 | SHOULD split | > | Beyond | 21 | MUST split | > > **SP→Days (validation only):** 1=0.5d/0.25d · 2=1d/0.35d · 3=2d/0.65d · 5=4d/1.0d · 8=6d/1.5d · 13=10d/2.0d (Trad/AI likely) > **AI speedup:** SP 1≈2x · 2-3≈3x · 5-8≈4x · 13+≈5x. AI cost = `(code_gen × 1.3) + (test_gen × 1.3)` (30% review overhead). > > **MANDATORY frontmatter:** > > ```yaml > story_points: > complexity: low | medium | high | critical > man_days_traditional: '-d' # range when likely ≥3d; 'd' when <3d > man_days_ai: '-d' > risk_margin_pct: # base + add-ons > risk_factors: [touches-complex-existing-feature, regression-fan-out] # closed-list from add-ons; [] if none > blast_radius: > touched_areas: > complex_touched: > downstream_consumers: [list or count] > shared_common_code: yes | no > estimate_scope_included: [code, integration-tests, frontend, i18n, docs] > estimate_scope_excluded: [unit-tests, e2e, perf, deployment, code-review-rounds] > estimate_reasoning: | > 5-7 lines covering: > (a) UI tier — row applied > (b) Backend tier — row applied > (c) Test scope — case breakdown by driver, file count, fixtures, tier row > (d) Cost driver — dominant tier + why > (e) Blast radius — touched, complex, regression scope > (f) Risk factors — list driving margin; why not larger/smaller > Example: "UI: compose Form/Table/Dialog → NEW screen (~1.5d). Backend: NEW command on existing aggregate, > reuses validation+repo (~1d). Tests: 4 transitions × 2 actors + 3 validation + 2 UI states = 13 cases, > 1 new fixture → tier 13-25 ~1.5d. Driver: UI composition + new states. Blast: 4 areas, 1 complex. > Risk: base 35% + touches-complex +20% = 55% → max 3.9d → range 2.5-4d." > ``` > > **Sanity self-check:** > > - `likely_days ≥3d` and single-point? → reject, must be range > - Margin <15% on `likely_days ≥5d`? → under-estimated, widen > - Margin >100%? → STOP, split instead of buffer > - Complex existing feature touched, no regression budget in `(c)`? → reject > - Blast `>5` areas OR `>2` complex, no split discussion? → reject > - Purely additive on existing model AND existing UI? → cap SP 3 unless tests >1.5d > - NEW UI surface (page/complex form/dashboard)? → SP 5+ even if backend one endpoint > - Backend cross-service / migration / multi-aggregate? → SP 8+ regardless of UI > - `bottom_up_hours / 6` vs SP-Days disagreement >50%? → trust bottom-up, downgrade SP > - Without tests, SP drops ≥1 bucket? → tests dominate; state explicitly > - Reasoning called out UI vs backend vs blast vs risk factors? → if missing, add > **Plan Quality** — Every plan phase MUST ATTENTION include test specifications. > > 1. Add `## Test Specifications` section with TC-{FEATURE}-{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 > - Start Phase N+1 only after Phase N passes VERIFY — why: building on an unverified phase compounds errors downstream > > **Phase success = all TCs pass + code-reviewer agent approves + no CRITICAL findings.** - **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 MUST ATTENTION** estimation: bottom-up phase hours drive `man_days_traditional` (`Σh/6 × productivity_factor`); SP DERIVED. UI cost usually dominates — bump SP one bucket if NEW UI surface (page/complex form/dashboard). Frontmatter MUST include `story_points`, `complexity`, `man_days_traditional`, `man_days_ai`, `estimate_scope_included`, `estimate_scope_excluded`, `estimate_reasoning` (UI vs backend cost driver). Cap SP 3 for additive-on-existing-model+existing-UI unless test scope >1.5d. SP 13 SHOULD split, SP 21 MUST split. - **MANDATORY IMPORTANT MUST ATTENTION** score complexity first. Score >=6 → decompose. Each phase: plan → implement → review → fix → verify. No skipping. **MUST ATTENTION** apply critical thinking — every claim needs traced proof, confidence >80% to act. Anti-hallucination: never present guess as fact. **MUST ATTENTION** apply sequential-thinking — multi-step Thought N/M, REVISION/BRANCH/HYPOTHESIS markers, confidence % closer; see `/sequential-thinking` skill. **MUST ATTENTION** apply AI mistake prevention — holistic-first debugging, fix at responsible layer, surface ambiguity before coding, re-read files after compaction. - **MANDATORY** Bootstrap task tracking before target work; transition one task at a time. - **MANDATORY** Persist plan/review findings to `plans/reports/` incrementally and synthesize from disk. - **MANDATORY** After task-tracking bootstrap and before target/source work, read required project-reference docs and cite `Reference docs read: ...`. - **MANDATORY** Always include `lessons.md`; project conventions override generic defaults. - **MANDATORY** Parent workflow rows do not replace child phase tracking; expand phases and link the parent when nested. - **MANDATORY** Orchestrators pre-expand child skill phases before invocation; use `[N.M] $skill-name — phase` prefixes and one-`in_progress` discipline. ## 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 **[TASK-PLANNING]** Before acting, analyze task scope and systematically break it into small todo tasks and sub-tasks using TaskCreate.