absolute-spec — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited absolute-spec (Agent Skill) and scored it 96/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 1 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 1 flagged
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Start your first response with the 📋 emoji.
Absolute Spec turns a fuzzy intent into a reviewed design-spec document — then stops. It is the planning artifact of work, lifted out of the full lifecycle: scan the codebase, ask only the questions the code can't answer, write the spec, run an independent scored review, and hand back a doc you can discuss, hand off, or feed into /absolute work to build.
It is deliberately lightweight. No relentless interview, no task board, no decompose, no execution. One deliverable: a spec good enough that an unfamiliar developer could build from it.
Use `spec` when:
Do NOT use `spec` when:
Phase 2, followed by decompose + safe-wave execution).
`/absolute docs` (reference/explanation docs, not a forward design).
The line vs work: `spec` produces a doc and stops; `work` produces a doc and then builds it. If you're unsure whether you'll build it now, start with spec — you can chain into work afterward and it will pick the spec up.
grill work runs. Batching questions is fine.
independent scored review.
absolute-work's references/spec-writing.md. This command is the thin flow around them.
SCAN ─→ CLARIFY ─→ WRITE ─→ REVIEW ─→ HANDOFFNo hard gates between steps (that's work). The one checkpoint is the clarify pass — ask, get answers, then proceed straight through to a reviewed spec.
Ground the spec in reality before asking anything.
work's Codebase Convention Detection table (packagemanager, language/runtime, test runner, linter, build system, directory conventions). See the table in absolute-work's SKILL.md under Codebase Convention Detection. The spec must speak the project's real stack, scripts, and paths.
docs/ (README first), root README.md,CLAUDE.md, CONTRIBUTING.md, docs/plans/ (overlapping/related designs), recent commits (last 10–20), package manifests, and the directories the feature touches.
any overlapping prior design). Do not dump a file listing.
Detect the work type (feature / refactor / greenfield / migration) only enough to shape the spec — spec does not run the full per-type question banks.
Ask only the questions the codebase genuinely cannot answer — the preference and scope forks. Cap at 3–5 questions; batching is allowed (one AskUserQuestion call with multiple questions where available).
Good questions to ask (when code can't answer them):
Do NOT ask: anything a config, manifest, test file, or existing pattern already states. When the code answers it, say so in the spec instead of asking.
If the user said "no questions, just draft it" — skip to WRITE and capture every guess in an ## Open Questions / assumptions section instead.
Write the spec to docs/plans/YYYY-MM-DD-<topic>-design.md (<topic> = short kebab-case slug).
Use the template, section-scaling rules, writing style, and Decision Log format from `absolute-work`'s `references/spec-writing.md` — that file is the single source of truth; do not restate it here, load it. In particular:
heuristic table, and scale sections accordingly. Remove sections that would only say "N/A".
"an endpoint for X".
each with a one-line rationale.
Dispatch a separate reviewer subagent — the agent that wrote the spec does not grade it (generator ≠ evaluator). Use the rubric and reviewer prompt template verbatim from absolute-work's references/spec-writing.md (Scored Spec Review Protocol): graded on Completeness, Consistency, Clarity, Scope, Testability (1–5 each, weighted).
| Weighted Score | Verdict | Action |
|---|---|---|
| 4.0 – 5.0 | Approved | Proceed to HANDOFF |
| 3.0 – 3.9 | Needs Work | Fix the flagged issues, re-dispatch (max 3 iterations) |
| < 3.0 | Major Gaps | Surface to the user immediately; do not silently iterate |
Reviewer approval is necessary but not the end — the user still has the final say at HANDOFF.
verdict. Summarize the key decisions in 2–4 lines.
its decompose phase rather than re-running intake. Make this an explicit, optional next step.
the user commits.
left spec. Stop at the reviewed doc.
scan first, ask second.
makes a standalone spec trustworthy. Keep it.
two copies drift.
work's interview. Tighten.Respond terse like smart caveman. All technical substance stay. Only fluff die. Drop articles, filler, pleasantries, hedging. Fragments OK. Technical terms exact. Code blocks and quoted errors unchanged. Drop caveman for security warnings, irreversible-action confirmations, and any multi-step sequence where fragment order risks misread; resume after. Spec prose itself is written normally (it's a deliverable, not chat).
Sibling commands in this skill chain naturally around spec:
Suggest them where relevant; they're always available (same skill, no extra install).
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.