mirror of
https://github.com/azaion/ai-training.git
synced 2026-04-23 09:46:35 +00:00
Oleksandr Bezdieniezhnykh
cdcd1f6ea7
- Rewrite autopilot flow resolution to 4 deterministic rules based on source code + docs + state file presence - Replace all hard-coded Jira references with tracker-agnostic terminology across 30+ files - Move project-management.mdc to _project.md (project-specific, not portable with .cursor) - Rename FINAL_implementation_report.md to context-dependent names (implementation_report_tests/features/refactor) - Remove "acknowledged tech debt" option from test-run — failing tests must be fixed or removed - Add debug/error recovery protocol to protocols.md - Align directory paths: metrics -> 06_metrics/, add 05_security/, reviews/, 02_task_plans/ to README - Add missing skills (test-spec, test-run, new-task, ui-design) to README - Use language-appropriate comment syntax for Arrange/Act/Assert in coderule + testing rules - Copy updated coderule.mdc to parent suite/.cursor/rules/ - Raise max task complexity from 5 to 8 points in decompose - Skip test-spec Phase 4 (script generation) during planning context - Document per-batch vs post-implement test run as intentional - Add skill-internal state cross-check rule to state.md
3.5 KiB
3.5 KiB
Step 6: Work Item Epics
Role: Professional product manager
Goal: Create epics from components, ordered by dependency
Constraints: Epic descriptions must be comprehensive and self-contained — a developer reading only the epic should understand the full context without needing to open separate files.
- Create "Bootstrap & Initial Structure" epic first — this epic will parent the
01_initial_structuretask created by the decompose skill. It covers project scaffolding: folder structure, shared models, interfaces, stubs, CI/CD config, DB migrations setup, test structure. - Generate epics for each component using the configured work item tracker (see
autopilot/protocols.mdfor tracker detection), structured pertemplates/epic-spec.md - Order epics by dependency (Bootstrap epic is always first, then components based on their dependency graph)
- Include effort estimation per epic (T-shirt size or story points range)
- Ensure each epic has clear acceptance criteria cross-referenced with component specs
- Generate Mermaid diagrams showing component-to-epic mapping and component relationships
CRITICAL — Epic description richness requirements:
Each epic description MUST include ALL of the following sections with substantial content:
- System context: where this component fits in the overall architecture (include Mermaid diagram showing this component's position and connections)
- Problem / Context: what problem this component solves, why it exists, current pain points
- Scope: detailed in-scope and out-of-scope lists
- Architecture notes: relevant ADRs, technology choices, patterns used, key design decisions
- Interface specification: full method signatures, input/output types, error types (from component description.md)
- Data flow: how data enters and exits this component (include Mermaid sequence or flowchart diagram)
- Dependencies: epic dependencies (with tracker IDs) and external dependencies (libraries, hardware, services)
- Acceptance criteria: measurable criteria with specific thresholds (from component tests.md)
- Non-functional requirements: latency, memory, throughput targets with failure thresholds
- Risks & mitigations: relevant risks from risk_mitigations.md with concrete mitigation strategies
- Effort estimation: T-shirt size and story points range
- Child issues: planned task breakdown with complexity points
- Key constraints: from restrictions.md that affect this component
- Testing strategy: summary of test types and coverage from tests.md
Do NOT create minimal epics with just a summary and short description. The epic is the primary reference document for the implementation team.
Self-verification:
- "Bootstrap & Initial Structure" epic exists and is first in order
- "Blackbox Tests" epic exists
- Every component maps to exactly one epic
- Dependency order is respected (no epic depends on a later one)
- Acceptance criteria are measurable
- Effort estimates are realistic
- Every epic description includes architecture diagram, interface spec, data flow, risks, and NFRs
- Epic descriptions are self-contained — readable without opening other files
- Create "Blackbox Tests" epic — this epic will parent the blackbox test tasks created by the
/decomposeskill. It covers implementing the test scenarios defined intests/.
Save action: Epics created via the configured tracker MCP. Also saved locally in epics.md with ticket IDs. If tracker: local, save locally only.