plan-flow

Plan Flow

Overview

Use this skill when the user needs:

• A complete analysis of duplicated/redundant design in a codebase.
• A detailed TODO plan with explicit file-level steps.
• Strict execution evidence: change one step, test it, then update plan status.

This skill is repository-agnostic. It defines how to analyze and plan, not only what was done in one specific repo.

Core Workflow (Analyze -> Plan -> Execute)

1. Establish scope and constraints.
2. Confirm target directories/modules and out-of-scope areas.
3. Capture compatibility requirement, risk tolerance, and testing expectations.
4. Record baseline (git status --short, current branch, known blockers).

1. Run structured redundancy analysis first.
2. Build an inventory of architecture anchors:
3. Domain models and schemas
4. Factory/registry entry points
5. HTTP/storage/cache/logging abstractions
6. Route/service/provider adapters
7. Identify duplicate/redundant candidates with evidence:
8. Same concept, multiple conflicting definitions
9. Same responsibility, parallel implementations
10. Exported but unconnected modules
11. Dead/legacy paths still affecting readability
12. For each finding, record:
13. Exact files and symbols
14. Call path or usage evidence
15. Risk if changed
16. See references/analysis-playbook.md.

1. Prioritize and convert analysis into executable plan.
2. Score each finding by impact/effort/risk/confidence.
3. Group into phases (P0, P1, P2) and sequence low-risk/high-signal steps first.
4. Create or update plan/<task>.md from references/plan-template.md.
5. Keep exactly one step in in_progress.
6. Use statuses: pending / in_progress / completed / blocked.
7. See references/risk-impact-scoring.md.

1. Execute with strict step-test-update loop.
2. Implement only the current step and only in listed files.
3. Run step-level tests immediately, then project health checks.
4. Update plan status and execution log before touching next step.
5. On failure, record root cause and run fix loop before continuing.

1. Close with phase/final verification.
2. Run phase matrix checks and final regression set.
3. Report residual risks, deferred work, and explicit coverage gaps.

Quality Gates

• No finding enters the plan without file-level evidence.
• No step is completed without test command evidence.
• No next step starts before plan status/log update is written.
• If full regression is unavailable, record exact reason and nearest fallback checks.

Reference Map

• references/analysis-playbook.md
• How to detect duplicate/redundant design with reproducible evidence.
• references/risk-impact-scoring.md
• How to prioritize findings into phases and step order.
• references/plan-template.md
• Reusable plan skeleton including analysis table, step template, and log format.
• references/plan-accomplishments.md
• One completed real example (for style and granularity only, not as mandatory scope).

Scripts

• scripts/redundancy_scan.sh <target_dir>
• Fast first-pass scan for duplicate symbol names, parallel factory/builders, and legacy/dead-code hints.
• scripts/findings_to_plan.py --target-dir src --output plan/<name>.md
• Convert scan findings into a draft execution plan with scoring and phased order (P0/P1/P2).
• scripts/plan_lint.py <plan/file.md>
• Validate plan state machine, test evidence, and execution-log completeness for completed steps.

Trigger Cues

Trigger this skill when user asks for:

• "分析这个库有哪些重复设计/冗余设计"
• "做一个非常完整详细的 todolist/执行计划"
• "每改一处就测试并更新计划状态"
• "按步骤推进并可追踪"

Execution Rules

• Prefer small, reversible steps over large refactors.
• Keep plan language specific to file paths, symbols, and commands.
• Avoid mixing analysis conclusions with unverified assumptions.
• If new evidence contradicts earlier assumptions, revise plan before coding.