absolute-spec
From the author
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 review before committing to implementation. Chains into absolute-work when ready to build. Triggers on "absolute spec", "write a spec", "spec out this feature", "draft a design doc", "I want a spec to hand off / review, don't build it yet".
Install
npx skills add maddhruv/absolute --skill absolute-spec -a claude-code
Installs to .claude/skills/absolute-spec/ · Each command fetches the skill straight from GitHub with the open skills CLI.
Byte-identical to the scanned commit, with the repository’s licence and a SOURCE.txt.
Want your agent to suggest skills while you type? See how to use skills from your IDE.
Safety checks on SKILL.md
No warnings.
Why 80
aiqbench computes the trust score from public signals. It is not a security audit, so read a skill before you install it.
Similar skills
Closest to this one by what they do and when they are used.
- absolute-workmaddhruv/absoluteEnd-to-end, phase-gated SDLC for AI coding agents: relentless design interview → reviewed spec → dependency-graphed task board → safe-wave TDD execution → verification → converge. Handles features, bugs, refactors, greenfield projects, planning breakdowns, and migrations. Triggers on "absolute work", "build this end-to-end", "plan and build", "break this into tasks", "grill me on this plan", "pick up this ticket", "run this migration".Testing★ 223
- ai-test-plannerarcasilesgroup/ai-engineeringPlan and write the tests for a feature, bottom-up. Everything that code or the CLI can verify (pure logic, API endpoints, DB constraints, auth/role rules) is tested without a browser. UI end-to-end tests come last and cover only what the lower layers can't. Use when the user asks to plan tests, write tests, or add test coverage for a feature or checkpoint (e.g. "/ai-test-planner discount rules").Testing★ 61
- specKerberosClaw/kc_ai_skillsUse when the user wants a spec-driven development workflow for implementing a feature in the current codebase, from fuzzy idea or existing active spec through requirements, technical plan, tasks, implementation, verification, and closure report. Auto-detects project/spec state, writes persistent files under specs/, asks one grounded question at a time when requirements are ambiguous, and stops at stage gates. NOT for stakeholder PRDs (prd-create), ADO ticket breakdown (prd-breakdown), single architecture-decision records (adr), or already-frozen tasks that should simply be implemented.Planning★ 79
- review-spectranhieutt/software_development_departmentReviews a product, technical, API, UI, or implementation spec for completeness, testability, architectural fit, and readiness before planning or implementation.Planning★ 74
- spec-extractarcasilesgroup/ai-engineeringTurn an unwritten agreement into a checkable spec — pull the requirements out of this conversation, a ticket, a pasted thread, or a design discussion, and write them to the project's spec file as numbered, falsifiable claims. Use before starting a feature, when the user says "write this up", "turn this into a spec", "make a design doc", "what did we agree", "capture the requirements", or "create design.md"; when a review skill halts because no spec exists; and at the point a conversation has produced enough decisions that the next session would lose them. This produces the contract that `design-check` and `verify-feature` measure against — it does not verify anything itself.Planning★ 61
- plan-a-featuretestdouble/hanBuilds a feature specification from scratch through a relentless, evidence-based interview that walks the design tree decision-by-decision, resolving dependencies as it goes. Use when the user wants to plan, design, scope, specify, or flesh out a new feature, capability, or system behavior before implementation. Produces a feature specification focused on system behaviors, not implementation detail. Does not plan a restructure of code that already exists — use plan-a-change. Does not refine or stress-test an existing plan — use iterative-plan-review. Does not document already-built features — use project-documentation. Does not design the contract for an interface — use design-an-api. Does not research open-ended options before there is a feature to specify — use research. Does not map the bounded contexts of existing code — use ddd-analysis.Planning★ 323
Ratings & reviews
—
no reviews
Tried this skill? Rate it to help others. Sign in
Discussion
Join the discussion. Sign in