Algis DumbrisandClaude Opus 4.6
d9d1b7fee2
Complete speckit spec for the feature: a coordinator-driven system where a human types a goal, a meta-agent decomposes into a task tree, proposes spawning specialist sub-agents, runs them on heartbeats, verifies their outputs, and iterates. Includes: - spec.md (9 user stories, 46 FRs, 12 SCs) - plan.md (constitution check PASS) - research.md (17 design decisions documented) - data-model.md (5 migrations) - contracts/mcp-tools.md (9 new MCP tools + 5 REST endpoints) - quickstart.md (10-minute runbook) - tasks.md (135 tasks, 12 phases, MVP at phase 8) - checklists/requirements.md (quality gates) Doc-gardener example is the end-to-end acceptance test. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
1.9 KiB
1.9 KiB
Specification Quality Checklist: Dynamic Agent Spawning
Purpose: Validate specification completeness and quality before proceeding to planning Created: 2026-04-14 Feature: spec.md
Content Quality
- No implementation details (languages, frameworks, APIs)
- Focused on user value and business needs
- Written for non-technical stakeholders
- All mandatory sections completed
Requirement Completeness
- No [NEEDS CLARIFICATION] markers remain
- Requirements are testable and unambiguous
- Success criteria are measurable
- Success criteria are technology-agnostic (no implementation details)
- All acceptance scenarios are defined
- Edge cases are identified
- Scope is clearly bounded
- Dependencies and assumptions identified
Feature Readiness
- All functional requirements have clear acceptance criteria
- User scenarios cover primary flows
- Feature meets measurable outcomes defined in Success Criteria
- No implementation details leak into specification
Notes
- The spec leans technical in the Assumptions section (tables, migration numbers, CGO) because the feature is itself an internal platform primitive — the consumers are the coordinator and future agent authors. This is acceptable for an internal-facing spec in a single-repo code-first project and matches the style of prior specs (014, 017).
- Implementation cues (SHA-256, recursive CTE, SQLite table names) are tolerated in the Assumptions section because they document pre-existing constraints from the codebase (pure Go, modernc.org/sqlite, no CGO), not free-floating implementation choices. The Functional Requirements and Success Criteria remain technology-agnostic.
- 0 [NEEDS CLARIFICATION] markers — all open design questions were resolved in the brainstorming conversation that produced the Assumptions section.