|
|
|
@@ -8,6 +8,8 @@ description: |
|
|
|
|
|
- "plan", "decompose solution", "architecture planning"
|
|
|
|
|
- "break down the solution", "create planning documents"
|
|
|
|
|
- "component decomposition", "solution analysis"
|
|
|
|
|
category: build
|
|
|
|
|
tags: [planning, architecture, components, testing, jira, epics]
|
|
|
|
|
disable-model-invocation: true
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
@@ -81,7 +83,7 @@ All artifacts are written directly under PLANS_DIR:
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
PLANS_DIR/
|
|
|
|
|
├── e2e_test_infrastructure/
|
|
|
|
|
├── integration_tests/
|
|
|
|
|
│ ├── environment.md
|
|
|
|
|
│ ├── test_data.md
|
|
|
|
|
│ ├── functional_tests.md
|
|
|
|
@@ -115,11 +117,11 @@ PLANS_DIR/
|
|
|
|
|
|
|
|
|
|
| Step | Save immediately after | Filename |
|
|
|
|
|
|------|------------------------|----------|
|
|
|
|
|
| Step 1 | E2E environment spec | `e2e_test_infrastructure/environment.md` |
|
|
|
|
|
| Step 1 | E2E test data spec | `e2e_test_infrastructure/test_data.md` |
|
|
|
|
|
| Step 1 | E2E functional tests | `e2e_test_infrastructure/functional_tests.md` |
|
|
|
|
|
| Step 1 | E2E non-functional tests | `e2e_test_infrastructure/non_functional_tests.md` |
|
|
|
|
|
| Step 1 | E2E traceability matrix | `e2e_test_infrastructure/traceability_matrix.md` |
|
|
|
|
|
| Step 1 | Integration test environment spec | `integration_tests/environment.md` |
|
|
|
|
|
| Step 1 | Integration test data spec | `integration_tests/test_data.md` |
|
|
|
|
|
| Step 1 | Integration functional tests | `integration_tests/functional_tests.md` |
|
|
|
|
|
| Step 1 | Integration non-functional tests | `integration_tests/non_functional_tests.md` |
|
|
|
|
|
| Step 1 | Integration traceability matrix | `integration_tests/traceability_matrix.md` |
|
|
|
|
|
| Step 2 | Architecture analysis complete | `architecture.md` |
|
|
|
|
|
| Step 2 | System flows documented | `system-flows.md` |
|
|
|
|
|
| Step 3 | Each component analyzed | `components/[##]_[name]/description.md` |
|
|
|
|
@@ -152,10 +154,10 @@ At the start of execution, create a TodoWrite with all steps (1 through 6). Upda
|
|
|
|
|
|
|
|
|
|
## Workflow
|
|
|
|
|
|
|
|
|
|
### Step 1: E2E Test Infrastructure
|
|
|
|
|
### Step 1: Integration Tests
|
|
|
|
|
|
|
|
|
|
**Role**: Professional Quality Assurance Engineer
|
|
|
|
|
**Goal**: Analyze input data completeness and produce detailed black-box E2E test specifications
|
|
|
|
|
**Goal**: Analyze input data completeness and produce detailed black-box integration test specifications
|
|
|
|
|
**Constraints**: Spec only — no test code. Tests describe what the system should do given specific inputs, not how the system is built.
|
|
|
|
|
|
|
|
|
|
#### Phase 1a: Input Data Completeness Analysis
|
|
|
|
@@ -177,11 +179,11 @@ At the start of execution, create a TodoWrite with all steps (1 through 6). Upda
|
|
|
|
|
|
|
|
|
|
Based on all acquired data, acceptance_criteria, and restrictions, form detailed test scenarios:
|
|
|
|
|
|
|
|
|
|
1. Define test environment using `templates/e2e-environment.md` as structure
|
|
|
|
|
2. Define test data management using `templates/e2e-test-data.md` as structure
|
|
|
|
|
3. Write functional test scenarios (positive + negative) using `templates/e2e-functional-tests.md` as structure
|
|
|
|
|
4. Write non-functional test scenarios (performance, resilience, security, edge cases) using `templates/e2e-non-functional-tests.md` as structure
|
|
|
|
|
5. Build traceability matrix using `templates/e2e-traceability-matrix.md` as structure
|
|
|
|
|
1. Define test environment using `templates/integration-environment.md` as structure
|
|
|
|
|
2. Define test data management using `templates/integration-test-data.md` as structure
|
|
|
|
|
3. Write functional test scenarios (positive + negative) using `templates/integration-functional-tests.md` as structure
|
|
|
|
|
4. Write non-functional test scenarios (performance, resilience, security, edge cases) using `templates/integration-non-functional-tests.md` as structure
|
|
|
|
|
5. Build traceability matrix using `templates/integration-traceability-matrix.md` as structure
|
|
|
|
|
|
|
|
|
|
**Self-verification**:
|
|
|
|
|
- [ ] Every acceptance criterion is covered by at least one test scenario
|
|
|
|
@@ -192,7 +194,7 @@ Based on all acquired data, acceptance_criteria, and restrictions, form detailed
|
|
|
|
|
- [ ] External dependencies have mock/stub services defined
|
|
|
|
|
- [ ] Traceability matrix has no uncovered AC or restrictions
|
|
|
|
|
|
|
|
|
|
**Save action**: Write all files under `e2e_test_infrastructure/`:
|
|
|
|
|
**Save action**: Write all files under `integration_tests/`:
|
|
|
|
|
- `environment.md`
|
|
|
|
|
- `test_data.md`
|
|
|
|
|
- `functional_tests.md`
|
|
|
|
@@ -212,7 +214,7 @@ Capture any new questions, findings, or insights that arise during test specific
|
|
|
|
|
**Constraints**: No code, no component-level detail yet; focus on system-level view
|
|
|
|
|
|
|
|
|
|
1. Read all input files thoroughly
|
|
|
|
|
2. Incorporate findings, questions, and insights discovered during Step 1 (E2E test infrastructure)
|
|
|
|
|
2. Incorporate findings, questions, and insights discovered during Step 1 (integration tests)
|
|
|
|
|
3. Research unknown or questionable topics via internet; ask user about ambiguities
|
|
|
|
|
4. Document architecture using `templates/architecture.md` as structure
|
|
|
|
|
5. Document system flows using `templates/system-flows.md` as structure
|
|
|
|
@@ -222,7 +224,7 @@ Capture any new questions, findings, or insights that arise during test specific
|
|
|
|
|
- [ ] System flows cover all main user/system interactions
|
|
|
|
|
- [ ] No contradictions with problem.md or restrictions.md
|
|
|
|
|
- [ ] Technology choices are justified
|
|
|
|
|
- [ ] E2E test findings are reflected in architecture decisions
|
|
|
|
|
- [ ] Integration test findings are reflected in architecture decisions
|
|
|
|
|
|
|
|
|
|
**Save action**: Write `architecture.md` and `system-flows.md`
|
|
|
|
|
|
|
|
|
@@ -237,7 +239,7 @@ Capture any new questions, findings, or insights that arise during test specific
|
|
|
|
|
**Constraints**: No code; only names, interfaces, inputs/outputs. Follow SRP strictly.
|
|
|
|
|
|
|
|
|
|
1. Identify components from the architecture; think about separation, reusability, and communication patterns
|
|
|
|
|
2. Use E2E test scenarios from Step 1 to validate component boundaries
|
|
|
|
|
2. Use integration test scenarios from Step 1 to validate component boundaries
|
|
|
|
|
3. If additional components are needed (data preparation, shared helpers), create them
|
|
|
|
|
4. For each component, write a spec using `templates/component-spec.md` as structure
|
|
|
|
|
5. Generate diagrams:
|
|
|
|
@@ -251,7 +253,7 @@ Capture any new questions, findings, or insights that arise during test specific
|
|
|
|
|
- [ ] All inter-component interfaces are defined (who calls whom, with what)
|
|
|
|
|
- [ ] Component dependency graph has no circular dependencies
|
|
|
|
|
- [ ] All components from architecture.md are accounted for
|
|
|
|
|
- [ ] Every E2E test scenario can be traced through component interactions
|
|
|
|
|
- [ ] Every integration test scenario can be traced through component interactions
|
|
|
|
|
|
|
|
|
|
**Save action**: Write:
|
|
|
|
|
- each component `components/[##]_[name]/description.md`
|
|
|
|
@@ -306,7 +308,9 @@ Fix any issues found before proceeding to risk identification.
|
|
|
|
|
### Step 5: Test Specifications
|
|
|
|
|
|
|
|
|
|
**Role**: Professional Quality Assurance Engineer
|
|
|
|
|
|
|
|
|
|
**Goal**: Write test specs for each component achieving minimum 75% acceptance criteria coverage
|
|
|
|
|
|
|
|
|
|
**Constraints**: Test specs only — no test code. Each test must trace to an acceptance criterion.
|
|
|
|
|
|
|
|
|
|
1. For each component, write tests using `templates/test-spec.md` as structure
|
|
|
|
@@ -341,11 +345,14 @@ Fix any issues found before proceeding to risk identification.
|
|
|
|
|
|
|
|
|
|
**Self-verification**:
|
|
|
|
|
- [ ] "Bootstrap & Initial Structure" epic exists and is first in order
|
|
|
|
|
- [ ] "Integration 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
|
|
|
|
|
|
|
|
|
|
7. **Create "Integration Tests" epic** — this epic will parent the integration test tasks created by the `/decompose` skill. It covers implementing the test scenarios defined in `integration_tests/`.
|
|
|
|
|
|
|
|
|
|
**Save action**: Epics created in Jira via MCP
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
@@ -354,7 +361,7 @@ Fix any issues found before proceeding to risk identification.
|
|
|
|
|
|
|
|
|
|
Before writing the final report, verify ALL of the following:
|
|
|
|
|
|
|
|
|
|
### E2E Test Infrastructure
|
|
|
|
|
### Integration Tests
|
|
|
|
|
- [ ] Every acceptance criterion is covered in traceability_matrix.md
|
|
|
|
|
- [ ] Every restriction is verified by at least one test
|
|
|
|
|
- [ ] Positive and negative scenarios are balanced
|
|
|
|
@@ -366,14 +373,14 @@ Before writing the final report, verify ALL of the following:
|
|
|
|
|
- [ ] Covers all capabilities from solution.md
|
|
|
|
|
- [ ] Technology choices are justified
|
|
|
|
|
- [ ] Deployment model is defined
|
|
|
|
|
- [ ] E2E test findings are reflected in architecture decisions
|
|
|
|
|
- [ ] Integration test findings are reflected in architecture decisions
|
|
|
|
|
|
|
|
|
|
### Components
|
|
|
|
|
- [ ] Every component follows SRP
|
|
|
|
|
- [ ] No circular dependencies
|
|
|
|
|
- [ ] All inter-component interfaces are defined and consistent
|
|
|
|
|
- [ ] No orphan components (unused by any flow)
|
|
|
|
|
- [ ] Every E2E test scenario can be traced through component interactions
|
|
|
|
|
- [ ] Every integration test scenario can be traced through component interactions
|
|
|
|
|
|
|
|
|
|
### Risks
|
|
|
|
|
- [ ] All High/Critical risks have mitigations
|
|
|
|
@@ -387,6 +394,7 @@ Before writing the final report, verify ALL of the following:
|
|
|
|
|
|
|
|
|
|
### Epics
|
|
|
|
|
- [ ] "Bootstrap & Initial Structure" epic exists
|
|
|
|
|
- [ ] "Integration Tests" epic exists
|
|
|
|
|
- [ ] Every component maps to an epic
|
|
|
|
|
- [ ] Dependency order is correct
|
|
|
|
|
- [ ] Acceptance criteria are measurable
|
|
|
|
@@ -403,7 +411,7 @@ Before writing the final report, verify ALL of the following:
|
|
|
|
|
- **Copy-pasting problem.md**: the architecture doc should analyze and transform, not repeat the input
|
|
|
|
|
- **Vague interfaces**: "component A talks to component B" is not enough; define the method, input, output
|
|
|
|
|
- **Ignoring restrictions.md**: every constraint must be traceable in the architecture or risk register
|
|
|
|
|
- **Ignoring E2E findings**: insights from Step 1 must feed into architecture (Step 2) and component decomposition (Step 3)
|
|
|
|
|
- **Ignoring integration test findings**: insights from Step 1 must feed into architecture (Step 2) and component decomposition (Step 3)
|
|
|
|
|
|
|
|
|
|
## Escalation Rules
|
|
|
|
|
|
|
|
|
@@ -431,7 +439,7 @@ Before writing the final report, verify ALL of the following:
|
|
|
|
|
│ PREREQ 3: Workspace setup │
|
|
|
|
|
│ → create PLANS_DIR/ if needed │
|
|
|
|
|
│ │
|
|
|
|
|
│ 1. E2E Test Infra → e2e_test_infrastructure/ (5 files) │
|
|
|
|
|
│ 1. Integration Tests → integration_tests/ (5 files) │
|
|
|
|
|
│ [BLOCKING: user confirms test coverage] │
|
|
|
|
|
│ 2. Solution Analysis → architecture.md, system-flows.md │
|
|
|
|
|
│ [BLOCKING: user confirms architecture] │
|
|
|
|
|
Oleksandr Bezdieniezhnykh