diff --git a/openspec/schemas/spec-driven-with-beads/README.md b/openspec/schemas/spec-driven-with-beads/README.md new file mode 100644 index 0000000..38e4865 --- /dev/null +++ b/openspec/schemas/spec-driven-with-beads/README.md @@ -0,0 +1,39 @@ +# spec-driven-with-beads + +OpenSpec workflow that uses Beads (`bd`) for task tracking and execution instead of flat task lists. + +## Workflow + +``` +proposal → specs → design → tasks+beads → apply (via Beads) → archive +``` + +| Phase | Artifact | Beads interaction | +|-------|----------|-------------------| +| `propose` | `proposal.md` | None | +| `specs` | `specs/**/*.md` | None | +| `design` | `design.md` | None | +| `tasks` | `tasks.md` + seeds Beads | `bd create` for each task, `bd dep add` for dependencies | +| `apply` | (tracks via Beads) | `bd ready` → `bd update --claim` → code → `bd close` | +| `archive` | moves to archive | `bd compact` on closed issues | + +## Why Beads? + +- **Context efficiency** — agent queries `bd ready` for next task instead of re-reading tasks.md +- **Dependency tracking** — `bd dep add` makes blockers explicit +- **Persistence** — survive across sessions, no context loss +- **Progress visibility** — `bd stats`, `bd dep tree` show real status + +## Requirements + +- [Beads](https://github.com/gastownhall/beads) installed (`bd` on PATH) +- `bd init` run in the project +- Beads MCP server optional but recommended for richer integration + +## Activation + +In `openspec/config.yaml`: + +```yaml +schema: spec-driven-with-beads +``` diff --git a/openspec/schemas/spec-driven-with-beads/schema.yaml b/openspec/schemas/spec-driven-with-beads/schema.yaml new file mode 100644 index 0000000..b0d20e0 --- /dev/null +++ b/openspec/schemas/spec-driven-with-beads/schema.yaml @@ -0,0 +1,217 @@ +name: spec-driven-with-beads +version: 1 +description: > + OpenSpec workflow powered by Beads issue tracking. + proposal -> specs -> design -> tasks+beads -> apply (via Beads) -> archive (compact). + +artifacts: + - id: proposal + generates: proposal.md + description: Initial proposal document outlining the change + template: proposal.md + instruction: > + Create the proposal document that establishes WHY this change is needed. + + + Sections: + + - **Why**: 1-2 sentences on the problem or opportunity. What problem does + this solve? Why now? + + - **What Changes**: Bullet list of changes. Be specific about new + capabilities, modifications, or removals. Mark breaking changes with + **BREAKING**. + + - **New Capabilities**: List capabilities being introduced. Each becomes + a new `specs//spec.md`. Use kebab-case names. + + - **Modified Capabilities**: List existing capabilities whose + REQUIREMENTS are changing. Check `openspec/specs/` for existing spec + names. Leave empty if no requirement changes. + + - **Impact**: Affected code, APIs, dependencies, or systems. + + IMPORTANT: The Capabilities section is critical. It creates the contract + between proposal and specs phases. + + Keep it concise (1-2 pages). Focus on the "why" not the "how" - + implementation details belong in design.md. + + This is the foundation — specs, design, and tasks all build on this. + requires: [] + + - id: specs + generates: specs/**/*.md + description: Detailed specifications for the change + template: spec.md + instruction: > + Create specification files that define WHAT the system should do. + + Create one spec file per capability listed in the proposal's Capabilities + section. + + - New capabilities: use the exact kebab-case name from the proposal + (specs//spec.md). + + - Modified capabilities: use the existing spec folder name from + openspec/specs// when creating the delta spec at + specs//spec.md. + + Delta operations (use ## headers): + - **ADDED Requirements**: New capabilities + - **MODIFIED Requirements**: Changed behavior — MUST include full updated content + - **REMOVED Requirements**: Deprecated features — MUST include **Reason** and **Migration** + - **RENAMED Requirements**: Name changes only — use FROM:/TO: format + + Format requirements: + - Each requirement: `### Requirement: ` followed by description + - Use SHALL/MUST for normative requirements (avoid should/may) + - Each scenario: `#### Scenario: ` with WHEN/THEN format + - **CRITICAL**: Scenarios MUST use exactly 4 hashtags (`####`). Using 3 hashtags or bullets will fail silently. + - Every requirement MUST have at least one scenario. + + MODIFIED requirements workflow: + 1. Locate the existing requirement in openspec/specs//spec.md + 2. Copy the ENTIRE requirement block (from `### Requirement:` through all scenarios) + 3. Paste under `## MODIFIED Requirements` and edit to reflect new behavior + 4. Ensure header text matches exactly (whitespace-insensitive) + + Common pitfall: Using MODIFIED with partial content loses detail at archive time. + If adding new concerns without changing existing behavior, use ADDED instead. + + Example: + + ``` + ## ADDED Requirements + + ### Requirement: User can export data + + The system SHALL allow users to export their data in CSV format. + + #### Scenario: Successful export + + - **WHEN** user clicks "Export" button + - **THEN** system downloads a CSV file with all user data + + ## REMOVED Requirements + + ### Requirement: Legacy export + + **Reason**: Replaced by new export system + **Migration**: Use new export endpoint at /api/v2/export + ``` + + Specs should be testable — each scenario is a potential test case. + requires: + - proposal + + - id: design + generates: design.md + description: Technical design document with implementation details + template: design.md + instruction: > + Create the design document that explains HOW to implement the change. + + When to include design.md (create only if any apply): + - Cross-cutting change (multiple services/modules) or new architectural pattern + - New external dependency or significant data model changes + - Security, performance, or migration complexity + - Ambiguity that benefits from technical decisions before coding + + Sections: + - **Context**: Background, current state, constraints, stakeholders + - **Goals / Non-Goals**: What this design achieves and explicitly excludes + - **Decisions**: Key technical choices with rationale (why X over Y?). Include alternatives considered for each decision. + - **Risks / Trade-offs**: Known limitations, things that could go wrong. Format: [Risk] → Mitigation + - **Migration Plan**: Steps to deploy, rollback strategy (if applicable) + - **Open Questions**: Outstanding decisions or unknowns to resolve + + Focus on architecture and approach, not line-by-line implementation. + Reference the proposal for motivation and specs for requirements. + + Good design docs explain the "why" behind technical decisions. + requires: + - proposal + + - id: tasks + generates: tasks.md + description: Implementation checklist with trackable tasks. Also seeds Beads issues. + template: tasks.md + instruction: > + Create the task list that breaks down the implementation work AND seed + corresponding issues in Beads. + + + **IMPORTANT: Follow the template below exactly.** + + + Guidelines: + + - Group related tasks under ## numbered headings + + - Each task MUST be a checkbox: `- [ ] X.Y Task description` + + - Tasks should be small enough to complete in one session + + - Order tasks by dependency (what must be done first?) + + + Example: + + ``` + + ## 1. Setup + + - [ ] 1.1 Create new module structure + + - [ ] 1.2 Add dependencies to package.json + + ## 2. Core Implementation + + - [ ] 2.1 Implement data export function + + - [ ] 2.2 Add CSV formatting utilities + + ``` + + + Reference specs for what needs to be built, design for how to build it. + + Each task should be verifiable — you know when it's done. + + + **After writing tasks.md, seed Beads:** + + Run `bd create "Spec-driven Change: " -t epic -p 1` for the + parent epic, then for each task run: + + ``` + bd create "X.Y Task description" -t task -p 1 + ``` + + Then link dependencies using `bd dep add `. + + Use `bd ready` to verify the task list is properly seeded. + requires: + - specs + - design + +apply: + requires: + - tasks + tracks: tasks.md + instruction: | + Use Beads to drive implementation, not tasks.md directly. + + Workflow: + 1. Run `bd ready` to see the next unblocked task. + 2. Pick the highest priority task and run `bd update --claim`. + 3. Read specs/design for context, implement the code. + 4. Run `bd close --reason "Implemented"`. + 5. Repeat from step 1 until `bd ready` returns nothing. + + Mark tasks.md checkboxes as you go for a human-readable view, but + Beads is the source of truth for task state. Do not skip `bd close`. + + Pause if you hit blockers or need clarification. Use `bd show ` to + inspect task details, and `bd update ` to add notes. diff --git a/openspec/schemas/spec-driven-with-beads/spec-driven-with-beads/README.md b/openspec/schemas/spec-driven-with-beads/spec-driven-with-beads/README.md new file mode 100644 index 0000000..0e987a5 --- /dev/null +++ b/openspec/schemas/spec-driven-with-beads/spec-driven-with-beads/README.md @@ -0,0 +1,86 @@ +# spec-driven-with-beads + +OpenSpec custom schema that uses [Beads](https://github.com/gastownhall/beads) molecules for task tracking, execution, and durable knowledge retention across sessions. + +## Workflow + +``` +proposal → specs → design → tasks+beads → apply (via molecule) → consolidate +``` + +## Molecule structure + +``` +bd-xyz (epic: Spec-driven Change: my-feature) +├── bd-xyz.1 proposal (human, needs: —) +├── bd-xyz.2 specs (needs: proposal) +├── bd-xyz.3 design (needs: specs) +├── bd-xyz.4 implement (needs: design) +├── bd-xyz.5 verify-specs-consolidate (auto-injected by spec-compliance aspect) +└── bd-xyz.6 consolidate (human, needs: implement, verify-specs) +``` + +One `bd pour` creates the entire graph. No manual `bd create` × N. + +## What makes this different + +Other schemas end at `archive` — knowledge dies with the session. This one closes the learning loop via `bd remember` + `bd mol distill`. + +### Key features + +| Feature | Description | Default | +|---------|-------------|---------| +| Mandatory deps | `needs:` in formula — `bd ready` only shows unblocked steps | Always on | +| Spec-compliance aspect | Auto-injects "Verify specs pass" before consolidate | Always on | +| Bond points | Compose additional behavior without forking the schema | Opt-in | +| `bd pin` | Pin steps to specific agents for parallel work | Opt-in (bond) | +| Async gates | Human approval, timers, CI checks | Opt-in (bond) | +| `bd lint` | Structural validation in consolidate | Always on | +| `bd mol squash` | Compress completed molecule to lightweight digest | Always on | +| `bd mol distill` | Extract reusable formula from completed change | Agent discretion | +| `bd remember` | Persist learnings across sessions via `bd prime` | Always on | + +### Bond points + +The formula defines three bond points where optional formulas attach: + +| Bond point | Position | Optional behavior | +|---|---|---| +| `parallel-execution` | After implement | Split implement into parallel sub-steps, one per capability, each pinned to a different agent. Uses `waits_for` (fan-in) to rejoin before consolidate | +| `async-gates` | Before implement | Add human approval gates, timer delays, or GitHub CI checks. Blocks step progression until conditions are met | + +Bond nothing → sequential, no extra config. Bond a formula → unlock the feature. + +## Requirements + +- [Beads](https://github.com/gastownhall/beads) installed (`bd` on PATH) +- `bd init` run in your project +- OpenSpec installed (`npm install -g @fission-ai/openspec`) + +## Install + +```bash +npm install -g spec-driven-with-beads +``` + +## Usage + +In `openspec/config.yaml`: + +```yaml +schema: spec-driven-with-beads +``` + +Then: +- `/opsx:propose "my feature"` +- `/opsx:apply` — driven by molecule step order +- `/opsx:consolidate` — lint, squash, remember, distill, archive + +## Links + +- [OpenSpec](https://github.com/Fission-AI/OpenSpec) +- [Beads](https://github.com/gastownhall/beads) +- [Beads Formula docs](https://gastownhall.github.io/beads/workflows/formulas) +- [Beads Molecule docs](https://gastownhall.github.io/beads/workflows/molecules) +- [Beads Aspect docs](https://gastownhall.github.io/beads/workflows/formulas#aspects-cross-cutting) +- [Community schema catalog](https://github.com/intent-driven-dev/openspec-schemas) diff --git a/openspec/schemas/spec-driven-with-beads/spec-driven-with-beads/schema.yaml b/openspec/schemas/spec-driven-with-beads/spec-driven-with-beads/schema.yaml new file mode 100644 index 0000000..408f68f --- /dev/null +++ b/openspec/schemas/spec-driven-with-beads/spec-driven-with-beads/schema.yaml @@ -0,0 +1,316 @@ +name: spec-driven-with-beads +version: 3 +description: > + OpenSpec workflow powered by Beads issue tracking. + proposal -> specs -> design -> tasks+beads -> apply (via Beads) -> consolidate. + +artifacts: + - id: proposal + generates: proposal.md + description: Initial proposal document outlining the change + template: proposal.md + instruction: > + Create the proposal document that establishes WHY this change is needed. + + + Sections: + + - **Why**: 1-2 sentences on the problem or opportunity. What problem does + this solve? Why now? + + - **What Changes**: Bullet list of changes. Be specific about new + capabilities, modifications, or removals. Mark breaking changes with + **BREAKING**. + + - **New Capabilities**: List capabilities being introduced. Each becomes + a new `specs//spec.md`. Use kebab-case names. + + - **Modified Capabilities**: List existing capabilities whose + REQUIREMENTS are changing. Check `openspec/specs/` for existing spec + names. Leave empty if no requirement changes. + + - **Impact**: Affected code, APIs, dependencies, or systems. + + IMPORTANT: The Capabilities section is critical. It creates the contract + between proposal and specs phases. + + Keep it concise (1-2 pages). Focus on the "why" not the "how" - + implementation details belong in design.md. + + This is the foundation — specs, design, and tasks all build on this. + requires: [] + + - id: specs + generates: specs/**/*.md + description: Detailed specifications for the change + template: spec.md + instruction: > + Create specification files that define WHAT the system should do. + + Create one spec file per capability listed in the proposal's Capabilities + section. + + - New capabilities: use the exact kebab-case name from the proposal + (specs//spec.md). + + - Modified capabilities: use the existing spec folder name from + openspec/specs// when creating the delta spec at + specs//spec.md. + + Delta operations (use ## headers): + - **ADDED Requirements**: New capabilities + - **MODIFIED Requirements**: Changed behavior — MUST include full updated content + - **REMOVED Requirements**: Deprecated features — MUST include **Reason** and **Migration** + - **RENAMED Requirements**: Name changes only — use FROM:/TO: format + + Format requirements: + - Each requirement: `### Requirement: ` followed by description + - Use SHALL/MUST for normative requirements (avoid should/may) + - Each scenario: `#### Scenario: ` with WHEN/THEN format + - **CRITICAL**: Scenarios MUST use exactly 4 hashtags (`####`). Using 3 hashtags or bullets will fail silently. + - Every requirement MUST have at least one scenario. + + MODIFIED requirements workflow: + 1. Locate the existing requirement in openspec/specs//spec.md + 2. Copy the ENTIRE requirement block (from `### Requirement:` through all scenarios) + 3. Paste under `## MODIFIED Requirements` and edit to reflect new behavior + 4. Ensure header text matches exactly (whitespace-insensitive) + + Common pitfall: Using MODIFIED with partial content loses detail at archive time. + If adding new concerns without changing existing behavior, use ADDED instead. + + + Specs should be testable — each scenario is a potential test case. + requires: + - proposal + + - id: design + generates: design.md + description: Technical design document with implementation details + template: design.md + instruction: > + Create the design document that explains HOW to implement the change. + + When to include design.md (create only if any apply): + - Cross-cutting change (multiple services/modules) or new architectural pattern + - New external dependency or significant data model changes + - Security, performance, or migration complexity + - Ambiguity that benefits from technical decisions before coding + + Sections: + - **Context**: Background, current state, constraints, stakeholders + - **Goals / Non-Goals**: What this design achieves and explicitly excludes + - **Decisions**: Key technical choices with rationale (why X over Y?). Include alternatives considered for each decision. + - **Risks / Trade-offs**: Known limitations, things that could go wrong. Format: [Risk] → Mitigation + - **Migration Plan**: Steps to deploy, rollback strategy (if applicable) + - **Open Questions**: Outstanding decisions or unknowns to resolve + + Focus on architecture and approach, not line-by-line implementation. + Reference the proposal for motivation and specs for requirements. + + Good design docs explain the "why" behind technical decisions. + requires: + - proposal + + - id: tasks + generates: tasks.md + description: > + Implementation checklist. Seeds Beads molecule via formula pour — + one command creates the entire dependency graph. + template: tasks.md + instruction: > + Create the task list AND seed Beads using the formula + molecule system. + + + **1. Ensure the spec-driven-change formula exists** + + If `.beads/formulas/spec-driven-change.formula.toml` does not exist, + create it from the template at + `openspec/schemas/spec-driven-with-beads/templates/spec-driven-change.formula.toml`. + + Also copy the spec-compliance aspect: + ``` + cp openspec/schemas/spec-driven-with-beads/templates/spec-compliance.aspect.toml .beads/formulas/spec-compliance.aspect.toml + ``` + + The aspect auto-injects a "Verify spec scenarios pass" step before + consolidate — no further action needed. + + + **2. Pour the molecule** + + Run: + + ``` + bd pour spec-driven-change --var name= + ``` + + This creates a molecule (parent epic + 5 child steps) with proper + `needs` dependencies: + + ``` + bd-xyz (epic: Spec-driven Change: ) + ├── bd-xyz.1 proposal (human, needs: —) + ├── bd-xyz.2 specs (needs: proposal) + ├── bd-xyz.3 design (needs: specs) + ├── bd-xyz.4 implement (needs: design) + │ └── [on_complete → bd ready] + ├── bd-xyz.5 verify-specs-consolidate (auto-injected by aspect) + └── bd-xyz.6 consolidate (human, needs: implement, verify-specs) + ``` + + The dependency chain is built into the formula — no manual `bd dep add` needed. + + **Optional — parallel capability implementation (multi-agent):** + If the change has multiple capabilities and you have multiple agents, + bond a multi-agent formula at the `parallel-execution` bond point: + ``` + bd mol bond mol-parallel-execution --ref parallel-execution + ``` + This splits the implement step into N sub-steps (one per capability), + each pinned to a different agent with `bd pin`. All sub-steps use + `waits_for` (fan-in) to rejoin before consolidate. + + **Optional — async gates (human approval, CI checks):** + Bond a gated formula at the `async-gates` bond point: + ``` + bd mol bond mol-gated-approval --ref async-gates + ``` + This adds human approval gates before implementation, timer delays, + or GitHub CI checks. + + If you don't bond anything, the molecule runs sequential — + no extra configuration needed. + + + **3. Label the molecule** + + ``` + bd label add change: + bd label add schema:spec-driven-with-beads + bd label add mode:sequential + ``` + Use `mode:parallel` if you bonded a multi-agent formula. + + + **4. Set acceptance criteria for the implement step** + + ``` + bd update .4 --acceptance "All spec scenarios pass. Tests added." + ``` + + + **5. Write tasks.md** + + Write the standard OpenSpec tasks.md for human readability. + The molecule is the source of truth; tasks.md is a view. + requires: + - specs + - design + +apply: + requires: + - tasks + tracks: tasks.md + instruction: | + Drive implementation through the molecule. The dependency graph + enforces order automatically. + + Sequential (default — no bonding needed): + 1. Run `bd mol list --json` to find the molecule for this change. + 2. Run `bd dep tree ` to see the step hierarchy. + 3. Run `bd ready` — only shows steps whose needs are met. + 4. For the next ready step, claim it: + ``` + bd update .N --claim + ``` + 5. Read specs/design for context, implement the code. + 6. Run acceptance criteria check if applicable: + ``` + bd show .N # view acceptance criteria + ``` + 7. Close the step: + ``` + bd close .N --reason "Implemented" + ``` + 8. Run `bd ready` again — next step in the chain becomes available. + The `on_complete` hook on the implement step runs `bd ready` automatically. + 9. Repeat until all steps are closed. + + Parallel (if bonded at parallel-execution bond point): + 1. Run `bd dep tree ` to see the sub-step hierarchy. + 2. Each sub-step is pinned to an agent via `bd pin`. + 3. Each agent claims, implements, and closes their sub-step independently. + 4. The consolidate step waits for ALL sub-steps via `waits_for` (fan-in). + 5. Use `bd blocked` to check if any sub-step is blocking the fan-in. + + Async (if bonded at async-gates bond point): + 1. Run `bd show .N` to check gate state. + 2. For human gates: wait for approval via `bd gate approve`. + 3. For timer gates: `bd show` shows remaining duration. + 4. For GitHub gates: `bd show` shows CI/PR status. + 5. Emergency override: `bd gate skip .N --reason "..."`. + + Tips: + - `bd blocked` shows steps waiting on dependencies. + - `bd stats` shows molecule progress. + - `bd show .N --json | jq '.gate'` shows gate details. + - Mark tasks.md checkboxes for human readability, but the molecule + is the source of truth. + + Pause if you hit blockers or need clarification. + +consolidate: + requires: + - apply + instruction: | + Close the molecule and persist learnings. + + 1. Verify all steps are closed: + ``` + bd mol show + ``` + + 2. Run structural validation: + ``` + bd lint + ``` + All issues MUST pass lint. If any fail, fix them before proceeding. + + 3. Run molecule compaction: + ``` + bd compact + ``` + + 4. Distill learnings from this change: + ``` + bd remember --key spec-driven-beads- "Lessons from this change: + - What unexpected problems did you encounter? + - What decisions turned out well or poorly? + - Any surprising edge cases or constraints? + - What should the next similar change do differently?" + ``` + + 5. Squash the molecule into a digest issue: + ``` + bd mol squash --summary "Spec-driven change: " + ``` + This compresses the 5 child steps into a single lightweight record. + The molecule remains searchable but no longer clutters the issue graph. + + 6. Optionally extract a reusable formula (if this change + represents a repeatable pattern): + ``` + bd mol distill my-pattern + ``` + This creates `.beads/formulas/my-pattern.formula.toml` from the + completed change. Future projects can `bd pour my-pattern`. + + 7. Label and archive: + ``` + bd label add status:consolidated + openspec archive + ``` + + Future `bd prime` calls will inject the learnings into every session. + The squashed digest and distilled formulas persist beyond the change. diff --git a/openspec/schemas/spec-driven-with-beads/spec-driven-with-beads/templates/design.md b/openspec/schemas/spec-driven-with-beads/spec-driven-with-beads/templates/design.md new file mode 100644 index 0000000..4ab5bd8 --- /dev/null +++ b/openspec/schemas/spec-driven-with-beads/spec-driven-with-beads/templates/design.md @@ -0,0 +1,19 @@ +## Context + + + +## Goals / Non-Goals + +**Goals:** + + +**Non-Goals:** + + +## Decisions + + + +## Risks / Trade-offs + + diff --git a/openspec/schemas/spec-driven-with-beads/spec-driven-with-beads/templates/proposal.md b/openspec/schemas/spec-driven-with-beads/spec-driven-with-beads/templates/proposal.md new file mode 100644 index 0000000..c79b85d --- /dev/null +++ b/openspec/schemas/spec-driven-with-beads/spec-driven-with-beads/templates/proposal.md @@ -0,0 +1,23 @@ +## Why + + + +## What Changes + + + +## Capabilities + +### New Capabilities + +- ``: + +### Modified Capabilities + +- ``: + +## Impact + + diff --git a/openspec/schemas/spec-driven-with-beads/spec-driven-with-beads/templates/spec-compliance.aspect.toml b/openspec/schemas/spec-driven-with-beads/spec-driven-with-beads/templates/spec-compliance.aspect.toml new file mode 100644 index 0000000..bc61ebe --- /dev/null +++ b/openspec/schemas/spec-driven-with-beads/spec-driven-with-beads/templates/spec-compliance.aspect.toml @@ -0,0 +1,21 @@ +formula = "spec-compliance" +description = "Auto-inject spec compliance verification before consolidate" +version = 1 +type = "aspect" + +# This aspect targets any step named "consolidate" and injects a +# spec-verification pre-step. Applied automatically when the aspect file +# exists in .beads/formulas/. + +[[advice]] +target = "*.consolidate" + +[advice.before] +id = "verify-specs-{step.id}" +title = "Verify spec scenarios pass for {step.title}" +needs = ["implement"] +type = "task" +description = > + Read the spec files at openspec/changes/{{name}}/specs/ and verify + every scenario passes against the implementation. If any scenario + fails, block consolidate until the issue is resolved. diff --git a/openspec/schemas/spec-driven-with-beads/spec-driven-with-beads/templates/spec-driven-change.formula.toml b/openspec/schemas/spec-driven-with-beads/spec-driven-with-beads/templates/spec-driven-change.formula.toml new file mode 100644 index 0000000..8e8bb39 --- /dev/null +++ b/openspec/schemas/spec-driven-with-beads/spec-driven-with-beads/templates/spec-driven-change.formula.toml @@ -0,0 +1,75 @@ +formula = "spec-driven-change" +description = "OpenSpec spec-driven change with Beads" +version = 2 +type = "workflow" + +[vars.name] +description = "Change name (kebab-case)" +required = true + +[vars.capabilities] +description = "Comma-separated list of capability names" +required = false + +# Base dependency chain: proposal -> specs -> design -> implement -> consolidate +# +# Bond points for optional composition: +# parallel-execution (after implement) — split implement into parallel sub-steps +# Bond a multi-agent formula here for parallel capability implementation. +# Each sub-step gets its own bd pin for agent assignment. +# Uses waits_for (fan-in) to rejoin before consolidate. +# +# async-gates (before implement) — add gates for async coordination +# Bond a gated formula here for human approval gates, CI checks, or timers. +# Gates block step progression until conditions are met. +# +# spec-compliance (before consolidate) — auto-injected by aspect +# The spec-compliance.aspect.toml injects "Verify specs pass" here. +# Applied automatically when the aspect is installed in .beads/formulas/. + +[[compose.bond_points]] +id = "parallel-execution" +step = "implement" +position = "after" +description = "Bond a multi-agent formula here to split implement into parallel sub-steps per capability" + +[[compose.bond_points]] +id = "async-gates" +step = "implement" +position = "before" +description = "Bond a gated formula here for human approval, CI checks, or timer gates" + +# Base steps + +[[steps]] +id = "proposal" +title = "Review proposal for {{name}}" +type = "human" +description = "Review the proposal document at openspec/changes/{{name}}/proposal.md" + +[[steps]] +id = "specs" +title = "Write specs for {{name}}" +needs = ["proposal"] +description = "Create spec files under openspec/changes/{{name}}/specs/" + +[[steps]] +id = "design" +title = "Design {{name}}" +needs = ["specs"] +description = "Write design document at openspec/changes/{{name}}/design.md" + +[[steps]] +id = "implement" +title = "Implement {{name}}" +needs = ["design"] +description = "Implement the change per specs and design" +[steps.on_complete] +run = "bd ready" + +[[steps]] +id = "consolidate" +title = "Consolidate {{name}}" +needs = ["implement"] +type = "human" +description = "Lint, squash, remember learnings, archive" diff --git a/openspec/schemas/spec-driven-with-beads/spec-driven-with-beads/templates/spec.md b/openspec/schemas/spec-driven-with-beads/spec-driven-with-beads/templates/spec.md new file mode 100644 index 0000000..095d711 --- /dev/null +++ b/openspec/schemas/spec-driven-with-beads/spec-driven-with-beads/templates/spec.md @@ -0,0 +1,8 @@ +## ADDED Requirements + +### Requirement: + + +#### Scenario: +- **WHEN** +- **THEN** diff --git a/openspec/schemas/spec-driven-with-beads/spec-driven-with-beads/templates/tasks.md b/openspec/schemas/spec-driven-with-beads/spec-driven-with-beads/templates/tasks.md new file mode 100644 index 0000000..88ce51e --- /dev/null +++ b/openspec/schemas/spec-driven-with-beads/spec-driven-with-beads/templates/tasks.md @@ -0,0 +1,9 @@ +## 1. + +- [ ] 1.1 +- [ ] 1.2 + +## 2. + +- [ ] 2.1 +- [ ] 2.2 diff --git a/openspec/schemas/spec-driven-with-beads/templates/design.md b/openspec/schemas/spec-driven-with-beads/templates/design.md new file mode 100644 index 0000000..4ab5bd8 --- /dev/null +++ b/openspec/schemas/spec-driven-with-beads/templates/design.md @@ -0,0 +1,19 @@ +## Context + + + +## Goals / Non-Goals + +**Goals:** + + +**Non-Goals:** + + +## Decisions + + + +## Risks / Trade-offs + + diff --git a/openspec/schemas/spec-driven-with-beads/templates/proposal.md b/openspec/schemas/spec-driven-with-beads/templates/proposal.md new file mode 100644 index 0000000..c79b85d --- /dev/null +++ b/openspec/schemas/spec-driven-with-beads/templates/proposal.md @@ -0,0 +1,23 @@ +## Why + + + +## What Changes + + + +## Capabilities + +### New Capabilities + +- ``: + +### Modified Capabilities + +- ``: + +## Impact + + diff --git a/openspec/schemas/spec-driven-with-beads/templates/spec.md b/openspec/schemas/spec-driven-with-beads/templates/spec.md new file mode 100644 index 0000000..095d711 --- /dev/null +++ b/openspec/schemas/spec-driven-with-beads/templates/spec.md @@ -0,0 +1,8 @@ +## ADDED Requirements + +### Requirement: + + +#### Scenario: +- **WHEN** +- **THEN** diff --git a/openspec/schemas/spec-driven-with-beads/templates/tasks.md b/openspec/schemas/spec-driven-with-beads/templates/tasks.md new file mode 100644 index 0000000..88ce51e --- /dev/null +++ b/openspec/schemas/spec-driven-with-beads/templates/tasks.md @@ -0,0 +1,9 @@ +## 1. + +- [ ] 1.1 +- [ ] 1.2 + +## 2. + +- [ ] 2.1 +- [ ] 2.2