mirror of
https://github.com/azaion/detections.git
synced 2026-04-23 07:06:31 +00:00
Oleksandr Bezdieniezhnykh
d28b9584f2
- 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
128 lines
3.2 KiB
Markdown
128 lines
3.2 KiB
Markdown
# Epic Template
|
|
|
|
Use this template for each epic. Create epics via the configured work item tracker (see `autopilot/protocols.md` for tracker detection).
|
|
|
|
---
|
|
|
|
```markdown
|
|
## Epic: [Component Name] — [Outcome]
|
|
|
|
**Example**: Data Ingestion — Near-real-time pipeline
|
|
|
|
### Epic Summary
|
|
|
|
[1-2 sentences: what we are building + why it matters]
|
|
|
|
### Problem / Context
|
|
|
|
[Current state, pain points, constraints, business opportunities.
|
|
Link to architecture.md and relevant component spec.]
|
|
|
|
### Scope
|
|
|
|
**In Scope**:
|
|
- [Capability 1 — describe what, not how]
|
|
- [Capability 2]
|
|
- [Capability 3]
|
|
|
|
**Out of Scope**:
|
|
- [Explicit exclusion 1 — prevents scope creep]
|
|
- [Explicit exclusion 2]
|
|
|
|
### Assumptions
|
|
|
|
- [System design assumption]
|
|
- [Data structure assumption]
|
|
- [Infrastructure assumption]
|
|
|
|
### Dependencies
|
|
|
|
**Epic dependencies** (must be completed first):
|
|
- [Epic name / ID]
|
|
|
|
**External dependencies**:
|
|
- [Services, hardware, environments, certificates, data sources]
|
|
|
|
### Effort Estimation
|
|
|
|
**T-shirt size**: S / M / L / XL
|
|
**Story points range**: [min]-[max]
|
|
|
|
### Users / Consumers
|
|
|
|
| Type | Who | Key Use Cases |
|
|
|------|-----|--------------|
|
|
| Internal | [team/role] | [use case] |
|
|
| External | [user type] | [use case] |
|
|
| System | [service name] | [integration point] |
|
|
|
|
### Requirements
|
|
|
|
**Functional**:
|
|
- [API expectations, events, data handling]
|
|
- [Idempotency, retry behavior]
|
|
|
|
**Non-functional**:
|
|
- [Availability, latency, throughput targets]
|
|
- [Scalability, processing limits, data retention]
|
|
|
|
**Security / Compliance**:
|
|
- [Authentication, encryption, secrets management]
|
|
- [Logging, audit trail]
|
|
- [SOC2 / ISO / GDPR if applicable]
|
|
|
|
### Design & Architecture
|
|
|
|
- Architecture doc: `_docs/02_document/architecture.md`
|
|
- Component spec: `_docs/02_document/components/[##]_[name]/description.md`
|
|
- System flows: `_docs/02_document/system-flows.md`
|
|
|
|
### Definition of Done
|
|
|
|
- [ ] All in-scope capabilities implemented
|
|
- [ ] Automated tests pass (unit + blackbox)
|
|
- [ ] Minimum coverage threshold met (75%)
|
|
- [ ] Runbooks written (if applicable)
|
|
- [ ] Documentation updated
|
|
|
|
### Acceptance Criteria
|
|
|
|
| # | Criterion | Measurable Condition |
|
|
|---|-----------|---------------------|
|
|
| 1 | [criterion] | [how to verify] |
|
|
| 2 | [criterion] | [how to verify] |
|
|
|
|
### Risks & Mitigations
|
|
|
|
| # | Risk | Mitigation | Owner |
|
|
|---|------|------------|-------|
|
|
| 1 | [top risk] | [mitigation] | [owner] |
|
|
| 2 | | | |
|
|
| 3 | | | |
|
|
|
|
### Labels
|
|
|
|
- `component:[name]`
|
|
- `env:prod` / `env:stg`
|
|
- `type:platform` / `type:data` / `type:integration`
|
|
|
|
### Child Issues
|
|
|
|
| Type | Title | Points |
|
|
|------|-------|--------|
|
|
| Spike | [research/investigation task] | [1-3] |
|
|
| Task | [implementation task] | [1-5] |
|
|
| Task | [implementation task] | [1-5] |
|
|
| Enabler | [infrastructure/setup task] | [1-3] |
|
|
```
|
|
|
|
---
|
|
|
|
## Guidance Notes
|
|
|
|
- Be concise. Fewer words with the same meaning = better epic.
|
|
- Capabilities in scope are "what", not "how" — avoid describing implementation details.
|
|
- Dependency order matters: epics that must be done first should be listed earlier in the backlog.
|
|
- Every epic maps to exactly one component. If a component is too large for one epic, split the component first.
|
|
- Complexity points for child issues follow the project standard: 1, 2, 3, 5, 8. Do not create issues above 5 points — split them.
|