99 lines
3.1 KiB
Markdown
99 lines
3.1 KiB
Markdown
---
|
|
name: analyze-design-inputs
|
|
description: "Extract implementation surfaces and sequencing constraints from architecture and code design documents. Planning pipeline step one. Produces internal analysis only and does not write files."
|
|
---
|
|
|
|
This skill analyzes upstream design inputs before planning begins.
|
|
|
|
**Announce at start:** "I'm using the analyze-design-inputs skill to extract implementation surfaces and sequencing constraints from the design documents."
|
|
|
|
## Purpose
|
|
|
|
Read the architecture and code design documents together, identify all implementation surfaces, and determine the natural task boundaries and dependency constraints for planning.
|
|
|
|
## Important
|
|
|
|
This skill produces internal analysis only. It MUST NOT write any file artifacts.
|
|
|
|
## Hard Gate
|
|
|
|
Do NOT generate tasks in this skill. This skill only extracts, classifies, and organizes planning inputs. Task generation happens in `generate-plan`.
|
|
|
|
## Process
|
|
|
|
You MUST complete these steps in order:
|
|
|
|
1. Read the architecture document end-to-end
|
|
2. Read the code design document end-to-end
|
|
3. Extract all implementation surfaces:
|
|
- schema and migration surfaces
|
|
- packages/modules to create or update
|
|
- interfaces and model definitions
|
|
- handlers/transports/endpoints
|
|
- services/use cases
|
|
- repositories/data access boundaries
|
|
- async producers/consumers
|
|
- external integrations
|
|
- config and DI wiring
|
|
- build/deploy and operational surfaces
|
|
4. Identify sequencing constraints:
|
|
- what must happen before implementation can start
|
|
- what depends on migrations or schema rollout
|
|
- what depends on interface/model definitions
|
|
- what can be parallelized
|
|
5. Identify risk-heavy work:
|
|
- backfills
|
|
- dual-write/read transitions
|
|
- zero-downtime rollouts
|
|
- external dependency setup
|
|
6. Identify potential task groupings that would make good milestones
|
|
7. Flag upstream ambiguities that block planning
|
|
|
|
## Internal Analysis Format
|
|
|
|
Retain this analysis internally. Do not write it to disk.
|
|
|
|
```markdown
|
|
## Inputs Reviewed
|
|
- Architecture: `docs/architecture/{feature}.md`
|
|
- Code Design: `docs/code-design/{feature}.md`
|
|
|
|
## Implementation Surfaces
|
|
| Surface Type | Item | Source Doc | Planning Notes |
|
|
|--------------|------|------------|----------------|
|
|
| migration | ... | architecture/code-design | ... |
|
|
| repository | ... | code-design | ... |
|
|
| service | ... | code-design | ... |
|
|
|
|
## Dependency Constraints
|
|
| Item | Depends On | Reason |
|
|
|------|------------|--------|
|
|
| ... | ... | ... |
|
|
|
|
## Parallel Work Opportunities
|
|
| Group | Tasks That Can Run In Parallel | Preconditions |
|
|
|-------|--------------------------------|---------------|
|
|
| ... | ... | ... |
|
|
|
|
## Risk Notes
|
|
| Risk | Affected Work | Planning Impact |
|
|
|------|---------------|-----------------|
|
|
| ... | ... | ... |
|
|
|
|
## Upstream Ambiguities
|
|
List blockers requiring clarification. If none, write "None identified."
|
|
```
|
|
|
|
## Guardrails
|
|
|
|
Do:
|
|
- Analyze both upstream inputs together
|
|
- Focus on implementation surfaces and dependency structure
|
|
- Preserve strict separation from design and QA responsibilities
|
|
|
|
Do not:
|
|
- Create tasks
|
|
- Change design decisions
|
|
- Write the plan file
|
|
- Produce any file artifacts
|