菜单
[Planning] Use when the user provides an implementation plan file and asks to analyze it, assess impact, update specifications, or verify planned changes.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/duc01226/EasyPlatform --skill plan-analysis命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
[Architecture] Use when designing solution architecture across backend, frontend, deployment, monitoring, testing, and code quality.
[Utilities] Use when you need to answer technical and architectural questions.
[Content] Use when you need to brainstorm as a PO/BA — structured ideation for problem-solving, new product creation, or feature enhancement.
正在显示 SKILL.md
基于 SOC 职业分类
| name | plan-analysis |
| version | 1.0.1 |
| description | [Planning] Use when the user provides an implementation plan file and asks to analyze it, assess impact, update specifications, or verify planned changes. |
Goal: Analyze an implementation plan, assess its impact on the codebase, and update specification documents accordingly.
Workflow:
Key Rules:
Be skeptical. Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence percentages (Idea should be more than 80%).
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 analysis, validate findings with user approval. user to confirm the analysis before any next steps.
You are to operate as an expert full-stack principal developer, software architect, and technical analyst to analyze a detailed implementation plan, perform comprehensive impact analysis, and update specification documents using the configured repository stack.
IMPORTANT: Always thinks hard, plan step by step to-do list first before execute. Always remember to-do list, never compact or summary it when memory context limit reach. Always preserve and carry your to-do list through every operation.
Prerequisites:
Build a structured knowledge model in .ai/workspace/analysis/[plan-name].analysis.md.
IMPLEMENTATION_PLAN_DEEP_ANALYSIS: Thorough analysis of the implementation plan file:
Plan Structure Analysis:
## Implementation Plan OverviewRequirements Extraction:
## Extracted RequirementsPlanned Changes Analysis:
## Planned Changes AnalysisArchitecture Impact Assessment:
## Architecture Impact AssessmentExisting Specification Analysis:
## Current Specification AnalysisAFFECTED_COMPONENTS_DISCOVERY: For each planned change, discover:
Save to ## Comprehensive File List with:
filePath, changeType, relationshipType, impactLevelserviceContext, planContext, specificationRelevanceIMPORTANT: MUST ATTENTION DO WITH TODO LIST
For each file, document in ## Knowledge Graph:
currentContent: Existing functionality (if file exists)plannedChanges: Specific changes plannedchangeImpactAnalysis: How changes affect other componentstestingRequirements: New test cases neededspecificationMapping: How component maps to spec sectionstestCaseImpact: Existing test cases needing modificationWrite comprehensive summary showing:
Generate detailed analysis under these headings:
Implementation Impact Analysis: Component impact, integration points, data flow changes, architectural-pattern compliance
Business Logic Analysis: New business rules, modified workflows, validation requirements
Testing Strategy Analysis: Test coverage requirements, new test scenarios, regression testing needs
Specification Update Strategy: How to integrate new requirements, maintain traceability, preserve existing coverage
Rollback and Safety Strategy: Backup procedures, rollback plan, validation checkpoints
CRITICAL: Present comprehensive analysis for explicit approval. DO NOT proceed without it.
Once approved, execute with MANDATORY steps:
Verify under ## Specification Validation:
plan
workflow-feature
MANDATORY FINAL TASKS: After creating all planning todo tasks, ALWAYS add these three final tasks:
## Test Specifications with TC-{FEATURE}-{NNN} IDs to every phase file. Use /spec [mode=tests] if feature docs exist. Use Evidence: TBD for TDD-first mode./plan-validate skill to interview the user with critical questions and validate plan assumptions/plan-review skill to auto-review plan for validity, correctness, and best practicesDO NOT use
EnterPlanModetool. DO NOT start implementing. ALWAYS validate with user approval after analysis. ASK user to confirm findings before any execution begins. ASK user for clarification when multiple approaches exist.
[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.
Prerequisites:
docs/specs/ — Test specifications by module (read existing TCs to include test strategy in plan)AI Mistake Prevention — Failure modes to avoid on every task:
Re-read files after context changes. Context compaction, resume, or long-running work can make memory stale; verify current files before acting. Verify generated content against source evidence. AI hallucinates APIs, names, claims, and document facts. Check the relevant source before documenting or referencing. Check downstream references before deleting or renaming. Removing an artifact can stale docs, generated mirrors, configs, and callers; map references first. Trace the full impact chain after edits. Changing a definition can miss derived outputs and consumers. Follow the affected chain before declaring done. Verify ALL affected outputs, not just the first. One green check is not all green checks; validate every output surface the change can affect. Assume existing values are intentional — ask WHY before changing. Before changing a constant, limit, flag, wording, or pattern, read nearby context and history. Surface ambiguity before acting — don't pick silently. Multiple valid interpretations require an explicit question or stated assumption with risk. Keep shared guidance role-relevant. Universal guidance must help every receiving skill or agent; code-specific obligations belong only in code-specific protocols.
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. — why: long context drifts from the file; the file is ground truth
- 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.
- 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: [...]."
Nested Task Expansion Contract — For workflow-step invocation, the
[Workflow] ...row is only a parent container; the child skill still creates visible phase tasks.
- Call
TaskListfirst. If a matching active parent workflow row exists, setnested=trueand recordparentTaskId; otherwise run standalone.- Create one task per declared phase before phase work. When nested, prefix subjects
[N.M] $skill-name — phase.- When nested, link the parent with
TaskUpdate(parentTaskId, addBlockedBy: [childIds]).- Orchestrators must pre-expand a child skill's phase list and link the workflow row before invoking that child skill or sub-agent.
- Mark exactly one child
in_progressbefore work andcompletedimmediately after evidence is written.- Complete the parent only after all child tasks are completed or explicitly cancelled with reason.
Blocked until:
TaskListdone, child phases created, parent linked when nested, first child markedin_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.
- Identify scope: file types, domain area, and operation.
- Required docs by trigger: always
docs/project-reference/lessons.md; doc lookupdocs-index-reference.md; reviewcode-review-rules.md; backend/CQRS/APIbackend-patterns-reference.md; domain/entitydomain-entities-reference.md; frontend/UIfrontend-patterns-reference.md; styles/designscss-styling-guide.md+design-system/design-system-canonical.md; integration testsintegration-test-reference.md; E2Ee2e-test-reference.md; feature docs/specsfeature-spec-reference.md+spec-system-reference.md+spec-principles.md; behavior/public-contract/spec-test-code syncworkflow-spec-test-code-cycle-reference.md; derived spec index/ERD/reimplementation guidesspec-system-reference.md+ source Feature Specs underdocs/specs/; architecture/new areaproject-structure-reference.md.- Read every required doc. If
docs/project-config.json, the docs index,lessons.md,CLAUDE.md,AGENTS.md, or any task-required reference doc is missing or stale, auto-run/project-initor the narrow lower-level route (/project-config,/docs-init,/scan-all,/scan --target=<key>,/claude-md-init) before ordinary project-specific work. If Codex mirrors orAGENTS.mdare missing/stale, ask the user to run/sync-codex; do not auto-run it.- Before target work, state:
Reference docs read: ... | Not applicable: ....Ready when: scope evaluated, required docs checked/read or setup route completed,
lessons.mdconfirmed, citation emitted.
Task Tracking & External Report Persistence — Bootstrap this before execution; then run project-reference doc prefetch before target/source work.
- Create a small task breakdown before target file reads, grep, edits, or analysis. On context loss, inspect the current task list first.
- Mark one task
in_progressbefore work andcompletedimmediately after evidence; never batch transitions.- For plan/review work, create
plans/reports/{skill}-{YYMMDD}-{HHmm}-{slug}.mdbefore first finding.- Append findings after each file/section/decision and synthesize from the report file at the end.
- 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):
Thought N/M: [aspect]— one aspect per thought, state assumptions/uncertaintyThought N/M [REVISION of Thought K]: ...— when prior reasoning invalidated; state Original / Why revised / ImpactThought N/M [BRANCH A from Thought K]: ...— explore alternative; converge with decision rationaleThought N/M [HYPOTHESIS]: ...then[VERIFICATION]: ...— test before actingThought 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-thinkingskill (.claude/skills/sequential-thinking/SKILL.md) for worked examples (API design, debugging, architecture), advanced techniques (spiral refinement, hypothesis testing, convergence), and meta-strategies (uncertainty handling, revision cascades).
Plan Quality — Every plan phase MUST ATTENTION include test specifications.
- Add
## Test Specificationssection with TC-{FEATURE}-{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 →/spec [mode=tests]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.
## Test Specifications with TC IDs per phase. Call TaskList before creating new tasks.
file:line evidence for every claim. Confidence >80% to act, <60% = do NOT recommend.
MUST ATTENTION apply critical + sequential thinking — every claim needs appropriate traced evidence (file:line for repo/code claims; source URL or artifact section for research, product, content, and docs claims); confidence >80% to act, <60% DO NOT recommend. Anti-hallucination: never present guess as fact, admit uncertainty freely, cross-reference independently, stay skeptical of own confidence.
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 — verify generated content against evidence, trace downstream references before deleting or renaming, verify all affected outputs, re-read files after context loss, and surface ambiguity before acting.
plans/reports/ incrementally and synthesize from disk.Reference docs read: ....lessons.md; project conventions override generic defaults./project-init or the narrow lower-level route before ordinary project-specific work.[N.M] $skill-name — phase prefixes and one-in_progress discipline.IMPORTANT MUST ATTENTION — Protocols in force (concise digest of the SYNC/shared blocks this skill carries):
AI Mistake Prevention: verify generated content against evidence, trace downstream references, verify all affected outputs, re-read after context loss, surface ambiguity.
Understand Code First: read code and grep 3+ patterns before modifying.
Evidence: cite file:line; confidence >80% to act.
Nested Task Creation: expand child phases, link parent when nested.
Project Reference Docs: read required project docs before target work.
Task Tracking & External Report: bootstrap tasks, persist findings to plans/reports/.
Critical Thinking: traced proof per claim, skeptical of own confidence.
Sequential Thinking: multi-step Thought N/M with confidence closer.
Plan Quality: ## Test Specifications with TC IDs per phase.
Iterative Phase Quality: score complexity, decompose at >=6, plan→implement→review→fix→verify.
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.