The two paths
Decision matrix
- Building or changing a product feature users touch →
specs/{core}/. Start withcreate-spec(runeos-spec precedentfirst for prior art). - Designing how we build — a CLI command, a skill, CI, a workflow, a refactor of the
tooling itself →
docs/superpowers/specs/viasuperpowers:brainstorming. - Unsure? If it ships in the app and has acceptance criteria a user could verify, it’s a product spec. If it changes the developer/agent workflow, it’s a superpowers design.
The bridge
A superpowers design may spawn one or more Encore product specs (e.g. a tooling design that requires a new PF feature). There is intentionally no auto-conversion. When a design spawns product specs, list their IDs in the design doc’s “Deliverables” section and, in each product spec, reference the design path under its context. Keep the governed spec as the source of truth for the shipped feature; the design doc stays as the rationale record.Tooling notes (2026-05-30 dogfood)
eos-spec tasks <id>writes a SCAFFOLD, not finished tasks. It stamps the generic phase template (with{core}_{entity_name}and<US-1 value>placeholders) and does no spec-aware fill or migration-collision analysis. The spec-aware task breakdown is thegenerate-tasksskill; collision detection is thenext/landscape advisory (migration-collision.ts). Don’t treat the rawtasksscaffold as final, and don’t expect collision warnings from it.- Fresh git worktrees need
npm ci. A worktree created offdevelopmenthas nonode_modules, sonpx @encore-os/eos-spec …(ornpm run spec -- …) fails withERR_MODULE_NOT_FOUND. Runnpm ciin the worktree — that installs the canonical@encore-os/eos-specpackage (no build step; the in-tree fork is retired #1831). Symlinking the main checkout’snode_modulesis not reliable — it produces intermittentUnknown system error -70reads on this filesystem.