absolute-spec

Name: absolute-spec
Author: maddhruv

25installs32forks

How to install absolute-spec?

maddhruv/absolute/absolute-spec

$npx -y skills add maddhruv/absolute --skill absolute-spec

Installs into the current project.

Summary

Lightweight standalone design spec for AI coding agents: codebase scan → bounded clarify pass (3–5 questions, not a grill) → reviewed design doc written to docs/plans/ → independent scored review → stop. No task board, no build. Use when you want a spec to discuss, hand off, or r

Files · 1

View on GitHub

SKILL.md

1	> Start your first response with the 📋 emoji.
2
3	## Absolute Spec
4
5	Absolute Spec turns a fuzzy intent into a reviewed design-spec document — then
6	stops. It is the planning artifact of `work`, lifted out of the full lifecycle: scan
7	the codebase, ask only the questions the code can't answer, write the spec, run an
8	independent scored review, and hand back a doc you can discuss, hand off, or feed into
9	`/absolute work` to build.
10
11	It is deliberately lightweight. No relentless interview, no task board, no
12	decompose, no execution. One deliverable: a spec good enough that an unfamiliar
13	developer could build from it.
14
15	---
16
17	## When to use this command
18
19	Use `spec` when:
20	- You want a design spec to discuss, review, or hand off — not build right now.
21	- You need to think a feature through on paper before committing to implementation.
22	- A teammate or another agent will do the building from your spec.
23	- You want a fast, reviewed design doc without the full phase-gated lifecycle.
24
25	Do NOT use `spec` when:
26	- You want to design AND build in one flow → use `/absolute work` (spec is its
27	Phase 2, followed by decompose + safe-wave execution).
28	- You're documenting code that already exists / already shipped → use
29	`/absolute docs` (reference/explanation docs, not a forward design).
30	- The change is a one-line obvious fix needing no design.
31
32	The line vs `work`: **`spec` produces a doc and stops; `work` produces a doc and then
33	builds it.** If you're unsure whether you'll build it now, start with `spec` — you can
34	chain into `work` afterward and it will pick the spec up.
35
36	---
37
38	## Key Principles
39
40	1. Codebase before questions. Read what exists first; ask only what code can't answer.
41	2. Bounded, not relentless. A short clarify pass (3–5 questions), not the depth-first
42	grill `work` runs. Batching questions is fine.
43	3. The spec is the deliverable. Quality matters more here than anywhere — keep the
44	independent scored review.
45	4. Reuse, don't reinvent. Template, scaling rules, and review rubric come from
46	`absolute-work`'s `references/spec-writing.md`. This command is the thin flow around them.
47	5. Stop after review. No code, no board, no execution. Hand off cleanly.
48	6. Never auto-commit. Write the spec file and report; the user commits.
49
50	---
51
52	## The Flow
53
54	```
55	SCAN ─→ CLARIFY ─→ WRITE ─→ REVIEW ─→ HANDOFF
56	```
57
58	No hard gates between steps (that's `work`). The one checkpoint is the clarify pass —
59	ask, get answers, then proceed straight through to a reviewed spec.
60
61	---
62
63	### Step 1 — SCAN
64
65	Ground the spec in reality before asking anything.
66
67	1. Convention detection — read cached config first: if `.absolute.config.json` or
68	`~/.absolute/config.json` exists (from `/absolute init`), resolve the effective config
69	(project file → global `projects["<cwd>"]` → global `defaults`) and use its `conventions`,
70	detecting only what's missing. No config → soft-suggest `init` and run `work`'s Codebase
71	Convention Detection table (package manager, language/runtime, test runner, linter, build
72	system, directory conventions; see `absolute-work`'s SKILL.md under *Codebase Convention
73	Detection*). The spec must speak the project's real stack, scripts, and paths.
74	2. Deep context scan — read what exists: `docs/` (README first), root `README.md`,
75	`CLAUDE.md`, `CONTRIBUTING.md`, `docs/plans/` (overlapping/related designs), recent
76	commits (last 10–20), package manifests, and the directories the feature touches.
77	3. Synthesize — state what you learned in 2–4 lines (stack, relevant existing code,
78	any overlapping prior design). Do not dump a file listing.
79
80	Detect the work type (feature / refactor / greenfield / migration) only enough to
81	shape the spec — `spec` does not run the full per-type question banks.
82
83	---
84
85	### Step 2 — CLARIFY (bounded pass)
86
87	Ask only the questions the codebase genuinely cannot answer — the preference and
88	scope forks. Cap at 3–5 questions; batching is allowed (one `AskUserQuestion` call
89	with multiple questions where available).
90
91	Good questions to ask (when code can't answer them):
92	- Scope boundary — what's in v1 vs

People who liked this also viewed

6 picks

Type

absolute-spec

25installs32forks

View on GitHub

How to install absolute-spec?

maddhruv/absolute/absolute-spec

$npx -y skills add maddhruv/absolute --skill absolute-spec

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	> Start your first response with the 📋 emoji.
2
3	## Absolute Spec
4
5	Absolute Spec turns a fuzzy intent into a reviewed design-spec document — then
6	stops. It is the planning artifact of `work`, lifted out of the full lifecycle: scan
7	the codebase, ask only the questions the code can't answer, write the spec, run an
8	independent scored review, and hand back a doc you can discuss, hand off, or feed into
9	`/absolute work` to build.
10
11	It is deliberately lightweight. No relentless interview, no task board, no
12	decompose, no execution. One deliverable: a spec good enough that an unfamiliar
13	developer could build from it.
14
15	---
16
17	## When to use this command
18
19	Use `spec` when:
20	- You want a design spec to discuss, review, or hand off — not build right now.
21	- You need to think a feature through on paper before committing to implementation.
22	- A teammate or another agent will do the building from your spec.
23	- You want a fast, reviewed design doc without the full phase-gated lifecycle.
24
25	Do NOT use `spec` when:
26	- You want to design AND build in one flow → use `/absolute work` (spec is its
27	Phase 2, followed by decompose + safe-wave execution).
28	- You're documenting code that already exists / already shipped → use
29	`/absolute docs` (reference/explanation docs, not a forward design).
30	- The change is a one-line obvious fix needing no design.
31
32	The line vs `work`: **`spec` produces a doc and stops; `work` produces a doc and then
33	builds it.** If you're unsure whether you'll build it now, start with `spec` — you can
34	chain into `work` afterward and it will pick the spec up.
35
36	---
37
38	## Key Principles
39
40	1. Codebase before questions. Read what exists first; ask only what code can't answer.
41	2. Bounded, not relentless. A short clarify pass (3–5 questions), not the depth-first
42	grill `work` runs. Batching questions is fine.
43	3. The spec is the deliverable. Quality matters more here than anywhere — keep the
44	independent scored review.
45	4. Reuse, don't reinvent. Template, scaling rules, and review rubric come from
46	`absolute-work`'s `references/spec-writing.md`. This command is the thin flow around them.
47	5. Stop after review. No code, no board, no execution. Hand off cleanly.
48	6. Never auto-commit. Write the spec file and report; the user commits.
49
50	---
51
52	## The Flow
53
54	```
55	SCAN ─→ CLARIFY ─→ WRITE ─→ REVIEW ─→ HANDOFF
56	```
57
58	No hard gates between steps (that's `work`). The one checkpoint is the clarify pass —
59	ask, get answers, then proceed straight through to a reviewed spec.
60
61	---
62
63	### Step 1 — SCAN
64
65	Ground the spec in reality before asking anything.
66
67	1. Convention detection — read cached config first: if `.absolute.config.json` or
68	`~/.absolute/config.json` exists (from `/absolute init`), resolve the effective config
69	(project file → global `projects["<cwd>"]` → global `defaults`) and use its `conventions`,
70	detecting only what's missing. No config → soft-suggest `init` and run `work`'s Codebase
71	Convention Detection table (package manager, language/runtime, test runner, linter, build
72	system, directory conventions; see `absolute-work`'s SKILL.md under *Codebase Convention
73	Detection*). The spec must speak the project's real stack, scripts, and paths.
74	2. Deep context scan — read what exists: `docs/` (README first), root `README.md`,
75	`CLAUDE.md`, `CONTRIBUTING.md`, `docs/plans/` (overlapping/related designs), recent
76	commits (last 10–20), package manifests, and the directories the feature touches.
77	3. Synthesize — state what you learned in 2–4 lines (stack, relevant existing code,
78	any overlapping prior design). Do not dump a file listing.
79
80	Detect the work type (feature / refactor / greenfield / migration) only enough to
81	shape the spec — `spec` does not run the full per-type question banks.
82
83	---
84
85	### Step 2 — CLARIFY (bounded pass)
86
87	Ask only the questions the codebase genuinely cannot answer — the preference and
88	scope forks. Cap at 3–5 questions; batching is allowed (one `AskUserQuestion` call
89	with multiple questions where available).
90
91	Good questions to ask (when code can't answer them):
92	- Scope boundary — what's in v1 vs

People who liked this also viewed

6 picks

Type