القائمة
Canonical rules for spec manifest management — statuses, transitions, and the manifest-ops script. Auto-loads when working with spec files.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| 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 |
Keeps skill definitions aligned between Claude Code and Codex. Use when creating, migrating, renaming, or updating skills that must work across `.claude/skills` and `.agents/skills`, or when auditing drift between the two systems.
When to open a pull request in the DorkOS repo (review the pushed branch first, open the PR after it converges) and how the automated review behaves, including its controls (skip-review, review:light/deep, re-review). Use when finishing a branch, opening a PR, deciding how much review a PR should get, or requesting a re-review after addressing feedback.
Decides when agent work needs an isolated git worktree and how to create, enter, and clean one up safely. Use when starting code changes in a checkout that may be shared with another agent, dispatching a Linear task, executing a spec, or running any parallel work that mutates tracked files.
Writes non-release DorkOS blog posts - feature posts, decision essays, ecosystem posts, and release recaps - from the repo's own ADRs, specs, research reports, and changelog fragments. Use when drafting, researching, or reviewing anything in blog/ that is not a version release note.
Guides writing concise, effective Architecture Decision Records. Use when creating ADRs, extracting decisions from specs, or reviewing ADR quality.
Patterns for adding, renaming, removing, or retyping fields in DorkOS user config. Use when editing UserConfigSchema, MarketplacesFileSchema, or any conf-backed store — walks the Zod field → defaults → conf migration → docs → test lifecycle end-to-end.