- Replace all Jira-specific references with generic tracker/work-item terminology (TRACKER-ID, work item epics); delete project-management.mdc and mcp.json.example - Restructure refactor skill: extract 8 phases (00–07) and templates into separate files; add guided mode for pre-built change lists - Add Step 3 "Code Testability Revision" to existing-code workflow (renumber steps 3–12 → 3–13) - Simplify autopilot state file to minimal current-step pointer - Strengthen coding rules: AAA test comments per language, test failures as blocking gates, dependency install policy - Add Docker Suitability Assessment to test-spec and test-run skills (local vs Docker execution) - Narrow human-attention sound rule to human-input-needed only - Add AskQuestion fallback to plain text across skills - Rename FINAL_implementation_report to implementation_report_* - Simplify cursor-meta (remove _docs numbering table, quality thresholds) - Make techstackrule alwaysApply, add alwaysApply:false to openapi
4.4 KiB
Phase 1: Discovery
Role: Principal software architect
Goal: Analyze existing code and produce RUN_DIR/list-of-changes.md
Constraints: Document what exists, identify what needs to change. No code changes.
Skip condition (Targeted mode): If COMPONENTS_DIR and SOLUTION_DIR already contain documentation for the target area, skip to Phase 2. Ask user to confirm skip.
Mode Branch
Determine the input mode set during Context Resolution (see SKILL.md):
- Guided mode: input file provided → start with 1g below
- Automatic mode: no input file → start with 1a below
Guided Mode
1g. Read and Validate Input File
- Read the provided input file (e.g.,
list-of-changes.mdfrom the autopilot testability revision step or user-provided file) - Extract file paths, problem descriptions, and proposed changes from each entry
- For each entry, verify against actual codebase:
- Referenced files exist
- Described problems are accurate (read the code, confirm the issue)
- Proposed changes are feasible
- Flag any entries that reference nonexistent files or describe inaccurate problems — ASK user
1h. Scoped Component Analysis
For each file/area referenced in the input file:
- Analyze the specific modules and their immediate dependencies
- Document component structure, interfaces, and coupling points relevant to the proposed changes
- Identify additional issues not in the input file but discovered during analysis of the same areas
Write per-component to RUN_DIR/discovery/components/[##]_[name].md (same format as automatic mode, but scoped to affected areas only).
1i. Produce List of Changes
- Start from the validated input file entries
- Enrich each entry with:
- Exact file paths confirmed from code
- Risk assessment (low/medium/high)
- Dependencies between changes
- Add any additional issues discovered during scoped analysis (1h)
- Write
RUN_DIR/list-of-changes.mdusingtemplates/list-of-changes.mdformat- Set Mode:
guided - Set Source: path to the original input file
- Set Mode:
Skip to Save action below.
Automatic Mode
1a. Document Components
For each component in the codebase:
- Analyze project structure, directories, files
- Go file by file, analyze each method
- Analyze connections between components
Write per component to RUN_DIR/discovery/components/[##]_[name].md:
- Purpose and architectural patterns
- Mermaid diagrams for logic flows
- API reference table (name, description, input, output)
- Implementation details: algorithmic complexity, state management, dependencies
- Caveats, edge cases, known limitations
1b. Synthesize Solution & Flows
- Review all generated component documentation
- Synthesize into a cohesive solution description
- Create flow diagrams showing component interactions
Write:
RUN_DIR/discovery/solution.md— product description, component overview, interaction diagramRUN_DIR/discovery/system_flows.md— Mermaid flowcharts per major use case
Also copy to project standard locations:
SOLUTION_DIR/solution.mdDOCUMENT_DIR/system_flows.md
1c. Produce List of Changes
From the component analysis and solution synthesis, identify all issues that need refactoring:
- Hardcoded values (paths, config, magic numbers)
- Tight coupling between components
- Missing dependency injection / non-configurable parameters
- Global mutable state
- Code duplication
- Missing error handling
- Testability blockers (code that cannot be exercised in isolation)
- Security concerns
- Performance bottlenecks
Write RUN_DIR/list-of-changes.md using templates/list-of-changes.md format:
- Set Mode:
automatic - Set Source:
self-discovered
Save action (both modes)
Write all discovery artifacts to RUN_DIR.
Self-verification:
- Every referenced file in list-of-changes.md exists in the codebase
- Each change entry has file paths, problem, change description, risk, and dependencies
- Component documentation covers all areas affected by the changes
- In guided mode: all input file entries are validated or flagged
- In automatic mode: solution description covers all components
- Mermaid diagrams are syntactically correct
BLOCKING: Present discovery summary and list-of-changes.md to user. Do NOT proceed until user confirms documentation accuracy and change list completeness.