Skill183 repo starsupdated 2d ago
absolute
Absolute is a development workflow engine that orchestrates eleven commands for project setup, iterative building, and maintenance tasks. Use `work` for end-to-end feature development with design interviews and test-driven execution, `spec` to generate standalone design documents, `ui` for intentional interface design with concrete CSS values, and health commands like `upgrade`, `audit`, and `debt` to maintain code quality on the main branch.
Install in Claude Code
Copygit clone --depth 1 https://github.com/maddhruv/absolute /tmp/absolute && cp -r /tmp/absolute/skills/absolute ~/.claude/skills/absoluteThen start a new Claude Code session; the skill loads automatically.
Definition
SKILL.md
# Absolute — Development Workflow Engine
One skill, eleven commands, dispatched as `/absolute <command> [target]`. One sets it up,
the rest split into two families:
**Setup** (run once per repo): `init` — interview + stack detection → JSON config the other commands read.
**Build loop** (the everyday flow):
**think → plan → build** (`work`) → **spec only** (`spec`) → **design** (`ui`) → **polish** (`simplify`) → **document** (`docs`)
**Engineering health** (standing maintenance on green `main`):
`upgrade` (deps) · `audit` (security) · `prune` (dead code) · `debt` (lint/type) · `deflake` (flaky tests)
The body of each command lives in `references/<command>.md`. This file is the
router: it decides which command the user wants, loads that reference, and follows
it. The command references are long and opinionated — load only the one in play. The
five health commands share one loop in `references/health-engine.md` (loaded by each).
---
## Commands
| Command | Phase | What it does | Reference |
|---|---|---|---|
| `init` | Setup | One-time setup: interview how you want absolute to behave (output style, autonomy/gating, TDD strictness, spec dir, families) + detect the stack once, then write `.absolute.config.json` (project, committed) and optionally `~/.absolute/config.json` (user defaults + per-project overrides). Every other command reads it instead of re-detecting; non-destructive, never commits. | [references/init.md](references/init.md) |
| `work [target]` | Think · Plan · Build | End-to-end, phase-gated SDLC: relentless design interview → reviewed spec → dependency-graphed task board → safe-wave TDD execution → verification → converge. Handles features, bugs, refactors, greenfield, planning breakdowns, migrations. | [references/work.md](references/work.md) |
| `spec [target]` | Plan | Lightweight standalone design spec — for when you want a doc to discuss or hand off, not build now. Codebase scan → bounded clarify pass (a few questions, not a grill) → write a reviewed spec to `docs/plans/` → independent scored review → stop. Reuses `work`'s spec template + rubric. | [references/spec.md](references/spec.md) |
| `ui [target]` | Design | Build polished, intentional UIs with concrete CSS/Tailwind values: typography, color, layout, spacing, dark mode, accessibility, animations, components. The most comprehensive UI knowledge base, not vague advice. | [references/ui.md](references/ui.md) |
| `simplify [target]` | Polish | Autonomously simplify your staged/unstaged git changes or a target path — reduce complexity, flatten nesting, remove redundancy and dead code — then run tests to prove nothing broke. | [references/simplify.md](references/simplify.md) |
| `docs [target]` | Document | Diátaxis-driven documentation: write, improve, or audit tutorials, how-tos, reference, explanation, and developer docs (README, CONTRIBUTING, ADRs). Detects the docs stack; verifies every claim against the code. | [references/docs.md](references/docs.md) |
| `upgrade [target]` | Health | Dependency upgrades: list outdated/vulnerable deps, plan them into semver waves (patch/minor batched, majors gated + changelog-read), apply incrementally, regenerate lockfiles, tests green after each. | [references/upgrade.md](references/upgrade.md) |
| `audit [target]` | Health | Vulnerability & security scan (defensive, your own repo): dependency CVEs + risky code patterns (secrets, injection, weak authz), severity × reachability triaged, remediated without suppressing. Complements built-in `/security-review`. | [references/audit.md](references/audit.md) |
| `prune [target]` | Health | Dead code & dependency cleanup, repo-wide: unused deps, unreferenced exports, unreachable code, orphaned files — removed only with tool evidence, in reversible waves. (Diff-scoped cleanup is `simplify`.) | [references/prune.md](references/prune.md) |
| `debt [target]` | Health | Lint & typecheck debt paydown: clear pre-existing repo-wide lint/type violations and suppressions (`@ts-ignore`, `# type: ignore`) one rule per wave, fixing causes not symptoms. (Diff-scoped quality is `simplify`.) | [references/debt.md](references/debt.md) |
| `deflake [target]` | Health | Flaky test fixes: detect nondeterministic tests empirically (repeat/shuffle/parallel runs), diagnose the root cause, fix it — never retry/skip/sleep — and verify across many randomized runs. | [references/deflake.md](references/deflake.md) |
---
## Routing rules
Resolve the command on every invocation, then hand off to its reference.
1. **First word matches a command** (`init`, `work`, `spec`, `ui`, `simplify`, `docs`,
`upgrade`, `audit`, `prune`, `debt`, `deflake`) → read `references/<command>.md`
and follow it exactly. Everything after the command name is the target/argument.
2. **First word doesn't match, but the intent clearly maps to one command** → load
that command's reference and proceed as if it was invoked explicitly:
- "set up / initialize / configure absolute", "first-time setup", "remember my
conventions/preferences for this repo" → **init**
- "build X end-to-end", "plan and build", "break this into tasks", "grill me on
this plan", "pick up this ticket", "run this migration" → **work**
- "write a spec", "spec out this feature", "draft a design doc for X", "I want a
spec to hand off / review, don't build it yet" → **spec**
(The fork vs `work`: `spec` writes a reviewed design doc and stops; `work` writes
the doc *and* builds it. When unsure if they'll build now, prefer `spec` — it can
chain into `work` afterward.)
- "design a pricing page", "style this component", "make this less like AI
slop", "fix the spacing/typography/color", "dark mode" → **ui**
- "simplify this", "clean up my changes", "refactor this", "reduce complexity",
"remove dead code", "tidy this up" → **simplify**
- "write docs/a tutorial/a README", "document this", "improve this doc",
"audit our docs", "restructure the documenta