Menu
Canonical rules for spec manifest management — statuses, transitions, and the manifest-ops script. Auto-loads when working with spec files.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Develop, validate, and publish DorkOS marketplace packages — agents, plugins, skill-packs, and adapters. Use when creating marketplace items, working in the dork-labs/marketplace repo, or helping users build packages for the personal marketplace.
First-touch triage for incoming GitHub issues on dork-labs/dorkos. Use when DorkBot is asked to triage the issue queue: label each new issue by type and runtime, find likely duplicates, and ask the reporter for missing reproduction steps. Read-and-suggest by default; only comments or edits labels when explicitly allowed to act.
Regenerate DorkOS product screenshots and video loops from the real UI, and manage the shot registry, human overrides, and version archives that feed the marketing site, docs, and changelogs. Use when marketing/docs media is stale after UI changes, a new feature or docs page needs a money shot, a person wants to override an automated capture, or a release calls for a fresh capture or archive — anything under apps/site/public/product/ or the apps/e2e/capture pipeline.
Skill whose frontmatter name does not match its directory name.
Implements the Calm Tech design system using Tailwind CSS v4 and Shadcn UI. Use when writing styles, building components, or theming. For design decisions, see designing-frontend.
Writes human-friendly changelog entries and release notes. Use when populating changelog, preparing releases, or reviewing release notes quality.
| name | managing-specs |
| description | Canonical rules for spec manifest management — statuses, transitions, and the manifest-ops script. Auto-loads when working with spec files. |
| user-invocable | false |
| paths | specs/** |
The spec manifest (specs/manifest.json) tracks every specification in the project. Never edit it by hand — always use the manifest-ops script.
node --experimental-strip-types --disable-warning=ExperimentalWarning .claude/scripts/spec-manifest-ops.ts <command> [args] [options]
Only four statuses are valid:
| Status | Meaning |
|---|---|
ideation | Spec has 01-ideation.md |
specified | Spec has 02-specification.md |
implemented | Spec has 04-implementation.md |
superseded | Replaced by a newer spec |
Non-canonical aliases are normalized automatically: draft -> ideation, specification -> specified, completed -> implemented.
Statuses move forward only: ideation -> specified -> implemented -> superseded. The script rejects regressions unless --force is passed.
01-ideation.md -> set to ideation02-specification.md -> set to specifiedimplementedsupersedednode --experimental-strip-types --disable-warning=ExperimentalWarning \
.claude/scripts/spec-manifest-ops.ts update-status <slug> <status>
node --experimental-strip-types --disable-warning=ExperimentalWarning \
.claude/scripts/spec-manifest-ops.ts add <slug> "Title" --status=ideation
Options: --status=<s>, --project=<p>, --created=YYYY-MM-DD.
| Command | Purpose |
|---|---|
get <slug> | Print a spec entry as JSON |
list [--status=<s>] | List specs, optionally filtered |
audit [--json] | Audit manifest vs filesystem |
fix [--dry-run] | Auto-fix all audit findings |
remove <slug> | Remove a spec entry from the manifest (leaves files) |
archive <slug> | Retire a spec: move to specs/archive/ and drop the entry |
specs/ is append-only by default: implemented specs stay listed forever. To
retire one, archive it. This mirrors the decisions/archive/ lifecycle: the
spec directory is MOVED to specs/archive/<slug>/ and its entry is REMOVED from
specs/manifest.json, so the active manifest only ever lists live specs.
node --experimental-strip-types --disable-warning=ExperimentalWarning \
.claude/scripts/spec-manifest-ops.ts archive <slug>
archive vs superseded: superseded is a manifest status for a spec that
is still tracked; archiving removes the spec from the manifest entirely. A
spec can be archived from any status (usually implemented or superseded).
When to archive (policy, not an automated rule): a spec that is implemented and
shipped more than ~6 months ago, or one that is superseded by a shipped
replacement, or an abandoned direction. When in doubt, leave it in place. Before
archiving, grep for inbound specs/<slug> references and re-point any you move.
The full policy and recovery steps live in
specs/archive/README.md. Bulk-migrating the
existing backlog is a separate, deliberate follow-up, not something this command
does in one sweep.
New specs get a coordination-free timestamp id (YYMMDD-HHMMSS), which add
stamps from the local clock via .claude/scripts/id.ts — no shared counter, so
two branches can never allocate the same id (spec #271 / DOR-184). The ~260
existing specs are frozen and keep their legacy number; list, audit, and
fix display each entry by its key (the timestamp id, or a zero-padded legacy
number, which sorts before timestamp ids). There is no nextNumber field to
maintain — add and fix self-allocate ids, and archiving or removing an entry
is always safe because ids are never reused.
These slash commands should update the manifest as part of their workflow:
| Command | Manifest action |
|---|---|
/flow:ideate | add <slug> "Title" --status=ideation |
/flow:specify | Ensure entry exists with status specified |
/flow:execute | update-status <slug> implemented on completion |