Menu
Detect drift between a Spectra change and the current codebase state
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
Analyze artifact consistency for a change
Implement Spectra tasks with a sub-agent quality gate after completion
Archive a completed change
Query openspec/documents and answer questions
Audit changed code for security sharp edges — dangerous defaults, type confusion, and silent failures
Commit files related to a specific Spectra change
| name | cash-drift |
| description | Detect drift between a Spectra change and the current codebase state |
| context | fork |
| agent | Explore |
| disallowedTools | ["Edit","Write"] |
| license | MIT |
| compatibility | Requires spectra CLI. |
| metadata | {"author":"spectra","version":"1.0"} |
This generated Claude Code skill runs with context: fork. The rules in this section take precedence over the shared drift body below.
When no change name is provided, run spectra list --json. Auto-select only when there is exactly one active change. If there are zero active changes or more than one active change, return the candidate list or empty-state message and ask the main thread to rerun /cash-drift <change-name>. Do NOT ask an interactive selection question inside the fork.
Detect drift between a Spectra change and the current codebase state. Reports time dormancy, broken design anchors, task collisions with external commits, and a single recommended next command.
Input: Optionally specify a change name (e.g., /cash-drift add-auth). If omitted, infer from conversation context or auto-select if only one active change exists.
Prerequisites: This skill requires the spectra CLI. If any spectra command fails with "command not found" or similar, report the error and STOP.
Steps
Determine change name
If not provided, infer from context or run spectra list --json to auto-select. If multiple active changes exist and no name is given, list candidates and ask the user to rerun with an explicit name.
Run programmatic drift analysis
spectra drift <change-name> --json
The JSON contains:
severity: "light" / "medium" / "heavy"total_score: aggregate over Time / Structure / Tasks (Environment is display-only)dimensions: array of { kind, status, score, contributes_to_total }broken_anchors: design.md references (file paths / symbols / functions / CLI flags) that no longer resolvetasks_blocked_external: pending tasks whose referenced files were modified by commits outside the change dirtasks_maybe_resolved: pending tasks whose verb+target keywords match commit subjects since createdprimary_recommendation: a single copy-pasteable command linePresent the report
Use a user-readable, conclusion-first format. The first substantive paragraph after the title MUST be a plain-language conclusion that says what to do next before showing score tables, broken anchors, task collisions, or severity labels.
Translate severity into action-oriented meaning:
Recommended shape:
## Drift Report: <change-name>
<Plain-language conclusion. Example for medium: "This change can continue, but update the plan before implementing it. Related code has changed since the plan was written, so applying the old tasks directly may cause rework or conflicts.">
### Why
- <1-3 plain-language reasons derived from dimensions, broken anchors, and task collisions>
### Details
| Item | Result |
| ----------------- | ------------------------------------------------------ |
| Time | <status> |
| Design references | <broken anchor count or "No broken references"> |
| Pending tasks | <blocked/maybe-resolved count or "No task collisions"> |
| Overall | <light/medium/heavy, total score N> |
### Recommendation
Run `<primary_recommendation>`.
Keep technical details below the plain-language conclusion. List broken anchors, blocked tasks, and maybe-resolved tasks only when non-empty. Omit empty technical detail sections entirely. Keep the report short enough to skim; the goal is to help the user decide, not to explain the scoring model.
Apply the recommendation interactively
Use the AskUserQuestion tool to offer one decision based on severity. Use plain-language option labels while preserving the exact command in each option description. Do NOT auto-invoke /cash-apply, /cash-ingest, or spectra archive; always wait for the user's choice.
/cash-apply <name>/cash-ingest <name> with the broken references and task collisions as context/cash-apply <name> only if the user knows the reported changes are harmless<primary_recommendation>/cash-ingest <name> before restartingIf the AskUserQuestion tool is not available, present the same plain-language choices as text and wait for the user's response.
Passive Trigger
When /cash-apply is invoked on a change whose .openspec.yaml created date is more than 5 days ago AND no commits have touched the change directory in the past 3 days, the apply skill SHOULD run drift analysis first and surface findings before tasks begin. The trigger is guidance only and MUST NOT block apply from proceeding.
(Threshold reasoning: AI-assisted commits are daily-cadence, not weekly. A change sitting ≥5 days with ≥3 days of no commits is almost always genuine stagnation rather than normal pacing.)
Guardrails
ANCHOR_CAP in spectra_core::drift to bound run-timespectra drift returns a non-zero exit code (e.g., older binary without the drift subcommand), report the error and stop