zhu1090093659/spec_driven_develop — Prompts
Excerpt 1 — spec-driven-develop SKILL.md: Phase 1 parallel dispatch (verbatim)
1. Launch `project-analyzer` sub-agents **in parallel** to analyze the codebase concurrently. Split the work by focus area:
- **Agent 1 — Architecture & Stack**: Project structure, directory layout, technology stack, entry points, build/run commands
- **Agent 2 — Module Inventory**: Each module's responsibility, public API surface, size, internal/external dependencies. **Must evaluate each module against all five S.U.P.E.R principles** (Single Purpose, Unidirectional Flow, Ports over Implementation, Environment-Agnostic, Replaceable Parts) and assign a per-principle compliance rating.
- **Agent 3 — Risks & S.U.P.E.R Health**: Transformation risks, complexity hotspots, platform-specific code, coding conventions. **Must produce a S.U.P.E.R Architecture Health Summary** evaluating the overall codebase against each principle, identifying violation hotspots that become priority targets in the transformation plan.
Provide each agent with the preliminary direction from Phase 0 AND `references/super-philosophy.md` so they can assess findings against S.U.P.E.R principles in context of the intended transformation.
If sub-agents are not available on the current platform, perform the analysis sequentially yourself — the scope is the same either way.
Prompting technique: Graceful degradation instruction. The skill is designed for multi-agent platforms but explicitly handles the single-agent case ("perform the analysis sequentially yourself"). This makes the skill portable without breaking on platforms without subagent support.
Excerpt 2 — S.U.P.E.R Quick Check (verbatim from SKILL.md)
S.U.P.E.R Code Review Checklist (run after every task before marking complete):
| Check | Principle |
|:------|:----------|
| Every new module/file has exactly one responsibility | S |
| No function does more than one conceptual thing | S |
| Data flows input → processing → output, no reverse deps | U |
| No circular imports introduced | U |
| Cross-module interfaces are schema-defined | P |
| Module I/O is serializable | P |
| No hardcoded paths, URLs, keys, or config values | E |
| All new dependencies explicitly declared | E |
| New modules can be replaced without changes to others | R |
| All tests pass after the change | — |
**All pass = proceed. 1-2 fail = fix before marking complete. 3+ fail = stop and refactor.**
Prompting technique: Gated checklist with explicit numeric thresholds. The 1-2 fail vs. 3+ fail distinction creates a decision boundary rather than leaving it to agent discretion, reducing inconsistent enforcement.
Excerpt 3 — Adaptive control initialization (verbatim from SKILL.md)
For each Milestone created, compute the percentage-based drift thresholds from the task count in that phase and append the adaptive control YAML block to the Milestone description:
```yaml
---
adaptive:
drift_score: 0
strategy: "<decomposition-strategy>"
thresholds:
annotate: <ceil(total_tasks * 0.20)>
replan: <ceil(total_tasks * 0.40)>
rescope: <ceil(total_tasks * 0.60)>
total_tasks: <count>
completed_tasks: 0
last_updated: "<ISO-8601>"
**Prompting technique**: Computed thresholds with ceiling function. Rather than fixed numbers, thresholds are calculated from the actual task count — making the adaptive control system scale correctly regardless of plan size.