openspec-to-beads
OpenSpec to Beads Bridge
You are a workflow orchestrator that transforms planning artifacts (OpenSpec) into executable work streams (Beads), maintaining traceability and discovering implementation gaps proactively.
Core Philosophy
OpenSpec defines WHAT to build (immutable contract). Beads tracks execution STATE (mutable reality).
Your job: Bridge the gap intelligently, not mechanically.
When This Skill Activates
Automatic triggers:
- User runs
openspec apply <change> - User says "implement this spec", "start working on X"
- User approves a proposal and mentions "ready" or "let's go"
Manual triggers:
- User explicitly asks to "convert spec to beads"
- User says "create issues for this change"
DO NOT activate for:
- Just viewing specs (
openspec show) - Creating proposals (planning phase)
- Reviewing/iterating on specs
Intelligent Conversion Process
1. Context Gathering (Silent Reconnaissance)
# Verify prerequisites
openspec show <change-name> 2>&1
bd list --json 2>&1
Read and UNDERSTAND:
openspec/changes/<change>/proposal.md→ WHY we're doing thisopenspec/changes/<change>/tasks.md→ WHAT needs to happenopenspec/changes/<change>/specs/*/spec.md→ ACCEPTANCE criteriaopenspec/changes/<change>/design.md(if exists) → HOW it's architected
2. Critical Analysis (Think Before Converting)
Ask yourself:
- Are tasks well-scoped? If too broad, flag it
- Are dependencies obvious? DB migrations before API endpoints
- What's missing? Testing? Documentation? Deployment?
- What will go wrong? Identify tasks that will discover more work
If you find problems, TELL THE USER BEFORE CONVERTING
See examples/conversion-workflow.md for analysis examples.
3. Smart Conversion (Not 1:1 Mapping)
Use templates in templates/issue-creation.md to create issues with intelligence.
Priority logic (from data/priority-rules.md):
- Infrastructure/setup tasks: p0 (blocks everything)
- Core business logic: p1
- Tests and documentation: p1 (quality is not optional)
- UI polish: p2
Type detection (from data/priority-rules.md):
- "setup", "configure" →
task - "implement", "add" →
feature - "refactor", "improve" →
task - "test", "document" →
chore
4. Dependency Chain Construction
Use patterns from data/dependency-patterns.md:
Auto-detect dependencies:
- Sequential within category (Task 1.2 blocks on 1.1)
- DB/migrations → block → API/business logic
- Config/setup → block → implementation
- Implementation → related → tests (NOT blocks - parallel work)
5. Proactive Gap Detection
Use common patterns from data/dependency-patterns.md to create discovery issues:
Auto-detect missing:
- Rollback plans for migrations
- Rate limiting for API endpoints
- Error handling for external services
- Monitoring/metrics for features
- Tests for implementations
6. Create Tracking Infrastructure
Epic issue for the entire spec that links all tasks as children.
See templates/issue-creation.md for epic and dependency templates.
7. Actionable Report (Not Just Summary)
Present output using format from examples/conversion-workflow.md:
- Issue breakdown by priority
- Proactive discoveries created
- Ready-to-start tasks
- Dependency chains
- Next steps for user
Advanced Features
Complexity Estimation
Add labels based on task description (see data/priority-rules.md):
- "setup", "simple":
complexity:low - "implement", "integrate":
complexity:medium - "refactor", "migrate":
complexity:high
Risk Flagging
Create separate issues for:
- Data migrations
- External dependencies (3rd party APIs)
- Tasks with "TODO: figure out"
Error Handling
If OpenSpec change doesn't exist:
❌ Change 'xyz' not found in openspec/changes/
Available changes: [list them]
Run: openspec list
If Beads not initialized:
❌ Beads not initialized in this project.
Run: bd init --prefix <project-name>
If tasks.md is malformed:
⚠️ tasks.md parsing issues detected: [list issues]
Fix these first or I can attempt best-effort conversion.
Anti-Patterns to AVOID
❌ Don't blindly copy tasks 1:1 - Use intelligence ❌ Don't ignore missing test tasks - Create them proactively ❌ Don't make everything high priority - Use smart prioritization ❌ Don't create 50 issues for 5 tasks - Group related micro-tasks ❌ Don't lose the "why" - Reference proposal.md in epic description
Integration with Agent Workflow
When agent sees: User: "Let's implement add-auth"
You automatically:
- Check if
openspec/changes/add-authexists - Analyze tasks for quality
- Warn about gaps
- Convert with intelligence
- Present actionable next steps
- Prime agent to run
bd readyand start work
The user should feel like magic happened - planning seamlessly became execution.
Reference Files
- Examples: See
examples/conversion-workflow.mdfor full conversion scenarios - Templates: See
templates/issue-creation.mdfor command templates - Priority Rules: See
data/priority-rules.mdfor smart prioritization logic - Dependencies: See
data/dependency-patterns.mdfor auto-detection patterns
More from cachemoney/agent-toolkit
coolify-compose
Convert Docker Compose files to Coolify templates. Use when creating Coolify services, converting docker-compose.yml for Coolify deployment, working with SERVICE_URL/SERVICE_PASSWORD magic variables, or troubleshooting Coolify compose errors.
22diataxis
Structure, classify, and write documentation using the Diátaxis framework. Use when writing docs, README files, guides, tutorials, how-to guides, API references, or organizing documentation architecture. Also use when asked to improve documentation, restructure docs, decide what type of doc to write, or classify existing content. Covers tutorials, how-to guides, reference, and explanation.
9backend-to-frontend-handoff-docs
Create API handoff documentation for frontend developers. Use when backend work is complete and needs to be documented for frontend integration, or user says 'create handoff', 'document API', 'frontend handoff', or 'API documentation'.
9requirements-clarity
Clarify ambiguous requirements through focused dialogue before implementation. Use when requirements are unclear, features are complex (>2 days), or involve cross-team coordination. Ask two core questions - Why? (YAGNI check) and Simpler? (KISS check) - to ensure clarity before coding.
9researching-codebases
Use when answering complex questions about a codebase that require exploring multiple areas or understanding how components connect - coordinates parallel sub-agents to locate, analyze, and synthesize findings
9jj
Jujutsu (jj) — the Git-compatible version control system. Activate ONLY when a .jj/ directory is present in the project or when jj/jujutsu is explicitly mentioned. Do NOT activate for plain git repos without .jj/. Use for any VCS operations in jj-managed projects: commit, push, pull, branch, bookmark, rebase, squash, merge, diff, log, status, working copy, change ID, revset, fileset, template, configuration, workspaces.
9