菜单
Use when completing and archiving a change after all tasks are done and specs are synced. Triggers: "archive the change", "complete this change", "close out the change", "finish the change", "archive".
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
| name | sdd-archive |
| description | Use when completing and archiving a change after all tasks are done and specs are synced. Triggers: "archive the change", "complete this change", "close out the change", "finish the change", "archive". |
Complete a change by moving its directory to the archive.
SPECS_ROOTis resolved by thesddrouter before this skill runs. Replace.specs/with your project's actual specs root in all paths below.
sdd-archive.tasks.md are complete (- [x])sdd-syncsdd-sync first (no automatic check; user judgement)Check tasks.md for unchecked tasks before archiving.
If incomplete tasks remain:
"{N} tasks are still incomplete. Archive anyway?"
Wait for user confirmation before proceeding.
tasks.md — count complete vs. total tasksTarget path: .specs/changes/archive/YYYY-MM-DD-<change-name>/
Where YYYY-MM-DD is today's date.
If the target already exists:
"Archive target already exists:
.specs/changes/archive/{date}-{name}/. Suggest using{name}-2or waiting until tomorrow."
Stop and ask the user how to proceed.
mkdir -p .specs/changes/archive/
mv .specs/changes/<name>/ .specs/changes/archive/YYYY-MM-DD-<name>/
Confirm the move succeeded by checking the archive path exists.
The change's .verify/ scratch (if present) is self-gitignored, so it never enters the archived commit even though mv carries it along — leave it or delete it; it is not part of the archived record.
Archived: .specs/changes/<name>/ → .specs/changes/archive/YYYY-MM-DD-<name>/
Tasks: {N}/{N} complete
Use when the user asks for a deep, exhaustive, multi-pass, or variance-reducing repository-wide or scoped-path security scan. Run repeated independent discovery passes over one resolved scope with worker-specific threat models, semantically merge candidates, synthesize one canonical validation threat model, then run validation, attack-path analysis, canonical JSON completion, and generated reporting once. Do not use for PRs, commits, branch diffs, or working-tree diffs.
Use when the user explicitly asks to fix and verify a validated or plausible security finding. Do not use as the primary trigger for full PR, commit, branch, patch, or repository scans.
Use when the user asks for a security scan or review of a repository, a scoped path (package, folder, or submodule), or a Git-backed change set (pull request, commit, branch diff, or working-tree patch). Point it at the target; it runs the full threat-model, discovery, validation, and attack-path pipeline and writes a report. Do not use to triage externally supplied findings or to fix a single finding.
Use when the user supplies existing security findings or vulnerability reports — SARIF results, CVE/GHSA or advisory text, scanner tickets, bug bounty reports, or finding artifacts — and wants static repo-impact triage. Do not use for discovery, duplicate-bug triage, validation, or fixes.
Use when the user wants any spec-driven development action — exploring before speccing, deriving specs from code or translating specs from another system, proposing a change, applying or implementing, verifying, syncing delta specs, or archiving. Triggers: 'spec this out', 'create a change', 'apply tasks', 'verify implementation', 'sync specs', 'archive change', or any mention of 'specs' or 'sdd'.
Use when verifying that an implementation matches a change's SDD artifacts. Triggers: "verify", "check implementation", "did I implement everything", "verify the change", "is implementation complete", "check conformance".