Menü
Analyze dependencies and separate enablement from feature work.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
Convert ISO spec requirements (StR, FR, NFR) into a TDD-based project plan with dependency analysis, parallel execution tracks, quality gates, and task decomposition. Selects or starts a plan and writes a frontmatter-typed plan bundle under plan/<Plan-id>-<slug>/ (Plan + Task + index + log).
Create or update spec artifacts from a design or change request. Orchestrates authoring each requested requirement type (StR/US/FR/NFR/IT) as a discrete file using quoin catalog templates and Quire validation.
Analyze requirement statements (FR/NFR/StR) for EARS requirement-grammar conformance and author a SpecReview of the findings.
Build and maintain the requirements Test Matrix ensuring 100% coverage.
Review requirements for quality, consistency, and completeness.
Verify a targeted plan is complete and validated — every task done, the Test Matrix backed by real tracking tags in tests, and code fully traced to spec (flagging underspecified code with no owning requirement). Optional semantic review checks that intent↔test↔code actually agree. Emits a quire-validated SpecReview artifact to reviews/YY-MM-DD-<slug>.md.
| name | spec-dependency-analysis |
| description | Analyze dependencies and separate enablement from feature work. |
Identify prerequisite relationships between requirements so work can be sequenced. The deliverable is a directed acyclic graph (DAG) of FRs/StRs/NFRs in logical order, not a schedule.
spec-to-plan — spec-to-plan consumes the DAG.Identify prerequisite edges. For each FR/StR/NFR, list every other requirement that MUST be satisfied before this one can be implemented. Express each as A → B (A is prerequisite to B).
Classify each requirement.
Rule: Enablement requirements MUST be tasked before any feature that depends on them.
Verify acyclicity. If any cycle is found, the spec is malformed — break the cycle by introducing a separation FR or merging the cyclic requirements.
Produce the deliverable. Use the template below.
Record output in spec/analysis/dependency.md (or as a section in spec/spec.md § 7 if your project keeps analysis inline).
# Dependency Analysis
## Classification
| Requirement | Class | Rationale |
|-------------|-------|-----------|
| FR-001 | Enablement | Defines the auth middleware all feature FRs use |
| FR-002 | Enablement | Database schema for user records |
| FR-003 | Feature | Login flow — depends on FR-001, FR-002 |
| FR-004 | Feature | Password reset — depends on FR-001, FR-002 |
## Dependency Graph
```mermaid
graph TD
FR-001[FR-001: Auth middleware]
FR-002[FR-002: User schema]
FR-003[FR-003: Login flow]
FR-004[FR-004: Password reset]
FR-001 --> FR-003
FR-002 --> FR-003
FR-001 --> FR-004
FR-002 --> FR-004
```
## Topological Order (suggested implementation sequence)
1. FR-001, FR-002 (enablement, parallelizable)
2. FR-003, FR-004 (features, parallelizable after enablement)
## Cycles
None detected.