# Absolute Spec > > - **Type:** Skill - **Install:** `agentstack add skill-maddhruv-absolute-absolute-spec` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [maddhruv](https://agentstack.voostack.com/s/maddhruv) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [maddhruv](https://github.com/maddhruv) - **Source:** https://github.com/maddhruv/absolute/tree/main/skills/absolute-spec ## Install ```sh agentstack add skill-maddhruv-absolute-absolute-spec ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About > Start your first response with the 📋 emoji. ## Absolute Spec 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. --- ## When to use this command **Use `spec` when:** - You want a design spec to **discuss, review, or hand off** — not build right now. - You need to think a feature through on paper before committing to implementation. - A teammate or another agent will do the building from your spec. - You want a fast, reviewed design doc without the full phase-gated lifecycle. **Do NOT use `spec` when:** - You want to **design AND build** in one flow → use **`/absolute work`** (spec is its Phase 2, followed by decompose + safe-wave execution). - You're documenting code that **already exists / already shipped** → use **`/absolute docs`** (reference/explanation docs, not a forward design). - The change is a one-line obvious fix needing no 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. --- ## Key Principles 1. **Codebase before questions.** Read what exists first; ask only what code can't answer. 2. **Bounded, not relentless.** A short clarify pass (3–5 questions), not the depth-first grill `work` runs. Batching questions is fine. 3. **The spec is the deliverable.** Quality matters more here than anywhere — keep the independent scored review. 4. **Reuse, don't reinvent.** Template, scaling rules, and review rubric come from `absolute-work`'s `references/spec-writing.md`. This command is the thin flow around them. 5. **Stop after review.** No code, no board, no execution. Hand off cleanly. 6. **Never auto-commit.** Write the spec file and report; the user commits. --- ## The Flow ``` SCAN ─→ CLARIFY ─→ WRITE ─→ REVIEW ─→ HANDOFF ``` No 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. --- ### Step 1 — SCAN Ground the spec in reality before asking anything. 1. **Convention detection** — read cached config first: if `.absolute.config.json` or `~/.absolute/config.json` exists (from `/absolute init`), resolve the effective config (project file → global `projects[""]` → global `defaults`) and use its `conventions`, detecting only what's missing. No config → soft-suggest `init` and run `work`'s Codebase Convention Detection table (package manager, language/runtime, test runner, linter, build system, directory conventions; see `absolute-work`'s SKILL.md under *Codebase Convention Detection*). The spec must speak the project's real stack, scripts, and paths. 2. **Deep context scan** — read what exists: `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. 3. **Synthesize** — state what you learned in 2–4 lines (stack, relevant existing code, 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. --- ### Step 2 — CLARIFY (bounded pass) 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): - **Scope boundary** — what's in v1 vs explicitly deferred. - **Behavior forks** — real-time vs batch, sync vs async, the genuine "which way" decisions. - **Data/contract shape** — only where the design hinges on it and code gives no signal. - **Non-goals** — what this explicitly will NOT do. 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. --- ### Step 3 — WRITE Write the spec to `/YYYY-MM-DD--design.md` (`` = short kebab-case slug). `` is `preferences.specDir` from config when present, else `docs/plans`. 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: - Pick the complexity tier (**Simple / Medium / Complex**) using the complexity heuristic table, and scale sections accordingly. Remove sections that would only say "N/A". - Be **concrete**: real file paths, real endpoints, real schemas in code blocks — never "an endpoint for X". - Fill the **Decision Log** with the forks resolved in CLARIFY plus any you recommended, each with a one-line rationale. --- ### Step 4 — REVIEW (scored, independent) 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. --- ### Step 5 — HANDOFF 1. **Present** — the spec path, the complexity tier, and the reviewer's weighted score + verdict. Summarize the key decisions in 2–4 lines. 2. **Offer to build** — chain into **`/absolute work`**, which will pick up the spec at its decompose phase rather than re-running intake. Make this an explicit, optional next step. 3. **Stop.** No code, no board. **Never run `git commit`** — suggest a message if asked; the user commits. --- ## Gotchas 1. **Drifting into `work`.** If you start decomposing into tasks or writing code, you've left `spec`. Stop at the reviewed doc. 2. **Asking what the code answers.** The bounded pass is for preferences and forks only — scan first, ask second. 3. **Skipping the review to "stay light".** The review is the cheap quality gate that makes a standalone spec trustworthy. Keep it. 4. **Restating `spec-writing.md`.** Load it; don't copy the template/rubric in here — two copies drift. 5. **Over-asking.** More than ~5 questions means you're running `work`'s interview. Tighten. --- ## Output / Response Style 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). --- ## Companion commands Sibling commands in this skill chain naturally around `spec`: - **`/absolute work`** — build what the spec describes (picks the spec up at decompose). - **`/absolute ui`** — design the interface for a feature the spec defines. - **`/absolute docs`** — once it's built and shipped, document it for readers. Suggest them where relevant; they're always available (same skill, no extra install). ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [maddhruv](https://github.com/maddhruv) - **Source:** [maddhruv/absolute](https://github.com/maddhruv/absolute) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-maddhruv-absolute-absolute-spec - Seller: https://agentstack.voostack.com/s/maddhruv - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.