/comet-design generates a handoff package from your Phase 1 artifacts and loads the Superpowers brainstorming skill to perform deep technical exploration — working through implementation approaches, risks, trade-offs, and testing strategy. Only after you explicitly approve the design proposal does it write the final Design Doc and advance the workflow.
This page uses <classic-root> for the configured Classic OpenSpec root: docs/openspec/ for new projects and openspec/ for projects that retain the legacy layout. The location is selected by classic.artifact_layout; see Project file structure.
Trigger
Normally, invoke/comet. When configuration selects Classic, the internal /comet-classic router reads state and dispatches /comet-design after Phase 1 completes. Invoke the phase Skill directly only for manual control.
Owner
OpenSpec and Superpowers — OpenSpec generates the handoff package from Phase 1 artifacts; Superpowers brainstorming drives the technical exploration and produces the Design Doc.What Happens
1
Generate the OpenSpec → Superpowers handoff package
Before brainstorming begins,
comet-handoff.sh generates a deterministic context package from the Phase 1 artifacts. This produces two files and writes their paths and a SHA256 hash to .comet.yaml:design-context.json— machine-readable index (change, phase, canonical spec, source paths, hash)design-context.md— human-readable context Superpowers reads during brainstorming, with source path markers, line ranges, and SHA256 traceability
2
Brainstorming explores the technical problem
The AI loads the Superpowers
brainstorming skill with the handoff package as context and begins deep technical exploration:- Implementation approach: architecture, data flow, key technology choices
- Trade-offs and risks for each option
- Testing strategy
- Any acceptance scenarios missing from the OpenSpec delta spec (proposed as Spec Patches, not rewritten requirements)
3
You confirm the design proposal (blocking pause)
After brainstorming produces a design proposal, the AI pauses and presents a concise summary:
- The technical approach adopted
- Key trade-offs and risks
- Testing strategy
- Any delta spec changes to be written back
4
Design Doc is written
Once you confirm, the AI creates the Design Doc at This links the Design Doc back to the OpenSpec change without duplicating requirements.
docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md. The file’s frontmatter is minimal by design:5
Delta spec is created or updated
If brainstorming identified missing acceptance scenarios or new capabilities, the OpenSpec delta spec at
<classic-root>/changes/<name>/specs/<capability>/spec.md is created or updated with Spec Patches. The handoff hash is regenerated to reflect the updated artifacts.6
State is updated and guard advances the workflow
The
design_doc path is recorded in .comet.yaml. If delta spec changes occurred, the handoff package is regenerated to keep the hash current. The phase guard then validates all exit conditions — including that handoff_hash matches current artifacts and design-context.md contains script-generated traceability markers — and auto-transitions to phase: build.Artifacts
The Handoff Package
comet-handoff.sh exists to solve a specific problem: AI agents summarizing context on the fly produce inconsistent, untraceable output. By generating the handoff deterministically from actual file content — with SHA256 hashes, source path markers, and line ranges — Comet ensures that Superpowers always works from a verified snapshot of what OpenSpec actually contains.
The default package is a compact, traceable excerpt. If the full content of all source artifacts is genuinely needed, you can generate a full handoff explicitly:
handoff_hash stored in .comet.yaml is checked by the phase guard before the workflow can advance from design to build. If the hash doesn’t match the current OpenSpec artifacts, the guard blocks the transition and reports a mismatch.

