Install the "absolute-work" agent skill from https://github.com/maddhruv/absolute/tree/main/skills/absolute-work into .claude/skills/absolute-work/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "absolute-work", then confirm the skill loads.
Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Type this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
skills CLI
$ npx skills add maddhruv/absolute --skill absolute-work -a codex
Project install goes to .agents/skills/; add -g for ~/.codex/skills/.
Install the "absolute-work" agent skill from https://github.com/maddhruv/absolute/tree/main/skills/absolute-work into .agents/skills/absolute-work/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "absolute-work", then confirm the skill loads.
Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
skills CLI
$ npx skills add maddhruv/absolute --skill absolute-work -a cursor
Project install goes to .agents/skills/; add -g for ~/.cursor/skills/.
Install the "absolute-work" agent skill from https://github.com/maddhruv/absolute/tree/main/skills/absolute-work into .cursor/skills/absolute-work/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "absolute-work", then confirm the skill loads.
Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
skills CLI
$ npx skills add maddhruv/absolute --skill absolute-work -a gemini-cli
Project install goes to .agents/skills/; add -g for ~/.gemini/skills/.
Install the "absolute-work" agent skill from https://github.com/maddhruv/absolute/tree/main/skills/absolute-work into .gemini/skills/absolute-work/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "absolute-work", then confirm the skill loads.
Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Installs for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
skills CLI
$ npx skills add maddhruv/absolute --skill absolute-work -a github-copilot
Project install goes to .agents/skills/; add -g for ~/.copilot/skills/.
Install the "absolute-work" agent skill from https://github.com/maddhruv/absolute/tree/main/skills/absolute-work into .github/skills/absolute-work/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "absolute-work", then confirm the skill loads.
GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
skills CLI
$ npx skills add maddhruv/absolute --skill absolute-work -a opencode
OpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
Install the "absolute-work" agent skill from https://github.com/maddhruv/absolute/tree/main/skills/absolute-work into .opencode/skills/absolute-work/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "absolute-work", then confirm the skill loads.
OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Works in 6 steps: INTAKE & BRAINSTORM (Relentless Design… → SPEC (Spec-Driven Development) → DECOMPOSE & PLAN (Build the Task Board) → …
Build this end-to-end
SKILL.md covers Absolute Work: End-to-End AI…, The Phase Gate Rule, Activation Protocol and Session Resume Protocol, plus 14 more sections
Calls npm, make and git
What it does
Absolute Work is an agent skill from maddhruv/absolute. End-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".
Its SKILL.md is about 5.3k tokens, which your agent loads only when the skill is triggered. The skill folder holds 8 other files, including reference files (for example `README.md`, `references/board-format.md` and `references/execution-model.md`).
It sits in Agent Workflows, covering Refactoring, Requirements gathering and Test-driven development. The repository describes itself as: Absolute Skills to 10x your Development Lifecycle. The licence is MIT.
When your agent uses it
Build this end-to-end
Break this into tasks
Grill me on this plan
Pick up this ticket
Example prompts
“absolute work”
“build this end-to-end”
“plan and build”
“/absolute-work”
Workflow steps
6 steps, taken from the step headings in SKILL.md.
Read from SKILL.md and the folder at commit 2166274. It shows what the files ask for, not the result of running them.
Tool permissions
Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.
From allowed-tools in the SKILL.md frontmatter.
Runs code
Shell commands in SKILL.md call:
npm
make
git
From the folder's file list and the shell code blocks in SKILL.md.
Network
No URLs in SKILL.md. Its commands use npm and git, which can reach the network depending on how they are called.
From URLs in SKILL.md, links to its own repository left out.
Credentials
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Context cost
Absolute Work loads about 5.3k tokens when it runs, and up to ~19k if it reads all its reference files. Until then it costs about 113 tokens; SKILL.md has 2,626 words of instructions outside code blocks.
Always· name and description, kept in context so the agent knows when to use it
~113
When it runs· the whole SKILL.md, loaded when a task matches
~5.3k
With references· SKILL.md plus every file in references/, read only if the agent opens them
~19k
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
Safety
Auto-check passed
The automated check found no risky patterns in SKILL.md.
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.
Download SKILL.mdSave it as .claude/skills/absolute-work/SKILL.md (or your agent's skills folder). This skill also uses 7 other files; get the full folder from GitHub.
name
absolute-work
description
End-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".
Absolute Work: End-to-End AI Development Lifecycle
Absolute Work takes any unit of work — a ticket, a task, a plan, a migration — from
fuzzy intent to verified code. It is one continuous skill with hard gates between
phases: brainstorm a shared design, write and review a spec, decompose into a
dependency-graphed task board, then peel tasks off one safe wave at a time with
test-first verification. Nothing is assumed, nothing is silently expanded, and no code
is written until the design is approved.
The lifecycle has 6 phases:
INTAKE & BRAINSTORM → SPEC → DECOMPOSE & PLAN → EXECUTE → VERIFY → CONVERGE
The Phase Gate Rule
Absolute Work STOPS at the end of every phase and waits for the user's explicit "go"
before advancing. This is non-negotiable. The phases are:
At each gate, present what was produced, summarize what comes next, and ask the user
to confirm before proceeding. Never chain two phases without an approval in between.
Use AskUserQuestion (where available) for every gate and every interview question.
Activation Protocol
Immediately after the banner, enter plan mode before doing anything else:
On platforms with native plan mode (e.g. Claude Code's EnterPlanMode): invoke it immediately.
On platforms without it: simulate plan mode — complete INTAKE & BRAINSTORM and SPEC fully, write no code, and get explicit approval before EXECUTE.
The first three phases are planning work. No files are created or modified (other than the
spec and the board) until the user approves the task graph and execution begins.
Session Resume Protocol
When Absolute Work is invoked and a .absolute-work/board.md already exists in the project root:
Detect: Read the board and determine its status.
Display: Print a compact summary of completed / in-progress / blocked / remaining tasks.
Resume: Pick up from the last incomplete wave — do NOT restart from INTAKE.
Reconcile: If the codebase changed since the last session, diff against the board's expected state and flag conflicts before resuming.
If the board is completed, ask whether to start a new session (archive the old board to
.absolute-work/archive/) or review the finished work. Never blow away an existing board
without explicit user confirmation.
Codebase Convention Detection
Before INTAKE begins, auto-detect the project's conventions so every phase is grounded
in reality, not assumptions. If .absolute.config.json or ~/.absolute/config.json exists
(from /absolute init), resolve the effective config (project file → global projects["<cwd>"]
→ global defaults), read its cached conventions first, and detect only what's missing. The
preferences (tdd, autonomy, specDir, boardTracking) likewise drive later phases.
Write detected conventions to the board under ## Project Conventions. Reference them in
every later phase — especially PLAN and the mandatory verification tail tasks. Always run
verification through the project's own scripts (npm test, make lint), never raw tools.
When to Use This Skill
Use Absolute Work when:
Picking up a ticket or task that needs design before implementation
Multi-step feature development touching 3+ files or components
"Build this end-to-end", "plan and execute this", "break this into tasks"
Greenfield projects, major refactors, or migrations
Planning/breakdown work — turning a vague goal into a sequenced task list
Complex bug fixes spanning multiple systems
The user wants to be grilled on a design before building
Do NOT use Absolute Work when:
Single-file bug fixes or typo corrections where the answer is obvious
Quick questions, code explanations, or pure research
Tasks the user explicitly wants to drive manually
Key Principles
Phase gates always. Stop and get explicit approval between every phase. Control over speed.
Codebase before questions. Search the code first; only ask what code genuinely cannot answer.
Relentless until aligned. Interview one question at a time until BOTH you and the user are 100% confident. Doubt on either side means keep going.
Spec before code. No implementation until a written spec is reviewed and approved.
Dependency-first decomposition. Every task is a node in a DAG, not a flat list.
Safety-first execution. Blockers and dependents run sequentially; only provably-independent tasks parallelize. When in doubt, serialize. (See references/execution-model.md.)
Test-first verification. Every task writes tests before implementation. "Done" means tests pass.
Generator ≠ evaluator. The agent that builds a task does not grade it.
Persistent state. All progress lives in .absolute-work/board.md, surviving across sessions.
No silent scope creep. Everything outside the agreed scope goes to Deferred Work, visible on the board.
Never auto-commit. Suggest a commit; the user commits.
Turn fuzzy intent into a shared, bulletproof design. This is a structured interrogation of
every assumption, dependency, and design branch — not a casual chat.
The interview directive — operate by this verbatim:
Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
Ask the questions one at a time.
If a question can be answered by exploring the codebase, explore the codebase instead.
Step 1 — Deep context scan
Read what exists before asking anything: docs/ (README first), root README.md, CLAUDE.md,
CONTRIBUTING.md, docs/plans/ (overlapping designs), recent commits (last 10-20), package
manifests, top-level structure. Synthesize what matters — do not dump a file listing.
Step 2 — Codebase-first intelligence
Before asking ANY question, check if the codebase answers it. Facts live in code
(database, test framework, auth); preferences require asking (visual style, real-time vs batch).
When code answers it, state what you found: "I see you're using Prisma with PostgreSQL — I'll
design around that." See references/intake-playbook.md.
Step 3 — Detect the work TYPE and adapt
Identify the type and swap in its tailored question bank (full banks in references/intake-playbook.md):
Type
Focus
Feature
user problem, flow, happy/error paths, scope boundary
Bug
repro steps, expected vs actual, blast radius, fix criteria
Refactor
pain point, target state, blast radius, test safety net, incremental vs all-at-once
Greenfield
problem/user fit, v1 scope, stack, data model, deploy target
If the request spans multiple independent subsystems, flag it and decompose into sub-projects
first; brainstorm the first sub-project through the normal flow.
Step 5 — Relentless interview
One question at a time via AskUserQuestion. Never batch.
Strictly linear — resolve decision A before asking about dependent decision B.
Walk the design tree depth-first — purpose → data model → behavior → UI → edge cases. Every branch has an error/edge-case child; walk it.
Honest options — only propose multiple approaches at a genuine fork; always mark one (Recommended) with rationale tied to project context. When the answer is obvious, present it and briefly say why alternatives were dismissed.
Mutual 100% confidence — after each decision, confirm both sides are sure. Hesitation means probe deeper.
Step 6 — Confidence self-check
Before presenting the design, review every decision: am I 100% sure, or filling gaps with
assumptions? Any sub-100% decision → return to the interview. State your confidence to the user.
Step 7 — Design presentation
Present section by section (architecture, components, data flow, error handling, testing),
scaled to complexity. Get approval per section. Design for isolation: small units, one clear
purpose each, well-defined interfaces. Follow existing patterns; don't fight the codebase.
━━ GATE: user approves the full design before Phase 2. ━━
Phase 2: SPEC (Spec-Driven Development)
Write the approved design to docs/plans/YYYY-MM-DD-<topic>-design.md (clear prose, file
paths, code blocks for schemas/interfaces, a Decision Log). Scale sections to complexity.
Then run a scored spec review with a separate reviewer subagent (generator-evaluator
separation): graded on Completeness, Consistency, Clarity, Scope, Testability (1-5 each).
See references/spec-writing.md for the template, scaling rules, and review rubric.
━━ GATE: user reviews and approves the spec before Phase 3. ━━
Phase 3: DECOMPOSE & PLAN (Build the Task Board)
Break the spec into atomic sub-tasks, build the dependency graph, and write the board.
Decompose
Each sub-task has: ID (AW-001), Title (action-oriented), Description (2-3 sentences),
Type (code | test | docs | infra | config), Size (S < 50 lines | M 50-200;
no L — decompose further), Dependencies (task IDs).
Rules: test tasks separate from code; infra/config before dependents; aim for 5-15 tasks; every
graph ends with the three mandatory tail tasks (Self Code Review → Requirements Validation →
Full Project Verification — see references/verification-framework.md). Apply the complexity budget:
if scope exceeds ~15 M-equivalent tasks, suggest splitting into multiple sessions.
Build the DAG and assign safe waves
Compute each task's depth (max(dependency depth) + 1) and group by depth into waves. Then apply
the safety pass: within a wave, only tasks that touch disjoint files and share no
interfaces may run in parallel; everything else is serialized. Assign shared-file ownership to a
single task. When in doubt, serialize. See references/execution-model.md and references/board-format.md.
Per-task plan
For each task: files to create/modify, test files (TDD — written first), approach, acceptance
criteria, and concrete test cases (happy path, edge, error). Write everything to
.absolute-work/board.md. Use preferences.boardTracking from config for the git-tracked vs
gitignored decision; only ask during intake when config doesn't set it.
Present the ASCII dependency graph + wave/sequence plan.
━━ GATE: user approves the task graph before Phase 4. ━━
Phase 4: EXECUTE (Onion-Peel, One Safe Wave at a Time)
Show full SKILL.md (1,055 more words)Show less
Pre-execution snapshot
Before touching any file: ensure the tree is clean (commit or stash), record the current commit
hash on the board under ## Rollback Point. This is the safety net for catastrophic failure.
Wave loop
for each wave in [Wave 1 … Wave N]:
partition tasks: sequential (blockers/dependents/shared-file) vs parallel-safe (disjoint, independent)
run sequential tasks in dependency order, one at a time
run parallel-safe tasks concurrently (separate agents)
each task → TDD: write failing tests (red) → implement (green) → refactor → update board
wave boundary: conflict check + compact progress report
━━ GATE: confirm before starting the next wave ━━
Each agent gets a self-contained prompt from the board (conventions + research + plan +
acceptance criteria) and the rule: write tests first, stay in scope, report blockers — never work
around them. Scope creep: blocking discoveries become new visible tasks; non-blocking ones go to
## Deferred Work. See references/execution-model.md for the agent template, conflict
resolution, blocked-task handling, and failure recovery.
Phase 5: VERIFY (Signals + Independent Evaluator)
Every task proves it works before closing, using two layers:
Signals (binary gate) — run the project's test, lint, typecheck, and build scripts. Any
failure goes straight back to the generator to fix (up to 2 retries). No skipping tests, no
@ts-ignore/eslint-disable/type: ignore to pass checks.
Evaluator (scored gate) — if signals pass, a separate evaluator subagent grades the work
against a scored rubric (Correctness, Code Quality, Completeness, Test Coverage, Integration
Safety). 4.0+ passes; 3.0-3.9 iterates on specific feedback (max 5); < 3.0 escalates to the user.
S-size tasks may skip the evaluator if all signals pass cleanly; M-size, failed, or
shared-interface tasks always get it. See references/verification-framework.md.
After the final wave, run the full suite and the three mandatory tail tasks.
━━ GATE: present verification results before Phase 6. ━━
Phase 6: CONVERGE (Close Out)
Full suite — run the complete test/lint/build one final time.
Documentation — update any docs that were in scope.
How to test it — end every session with concrete, copy-pasteable steps the user can run to exercise the added functionality themselves: the exact commands to start the app/script, the inputs or routes to hit (curl, UI clicks, CLI invocation), and the expected output for each. Cover the happy path plus at least one edge/error case. Ground every command in the detected conventions (real scripts, real ports, real file paths) — never invent commands the project does not have.
Close board — mark completed with a timestamp; the board is the audit trail.
Suggest commit — propose a message. Never run git commit yourself.
Gotchas
Chaining phases without a gate. The whole point is control — never advance past a phase boundary without the user's explicit "go".
Asking questions the codebase answers. Search configs, deps, and test files before every question; it erodes trust to ask what the code already states.
Parallel agents editing shared files. Two same-wave tasks editing one utility produce a wave-boundary conflict. Detect shared files in DECOMPOSE, assign ownership, and serialize the rest. Default to sequential when unsure.
Rollback point recorded mid-wave. Capture the commit hash before Wave 1 touches anything, or the snapshot already contains partial changes.
Board marked complete without running checks. The mandatory tail tasks are skipped most often. Never mark completed until the actual test/lint/build output is on the board.
DISCOVER/research skipped for "obvious" tasks. Agents duplicate existing utilities or miss conventions a 2-minute scan would catch. Research every task.
Silent scope creep. Adjacent improvements absorbed mid-task obscure what changed and blow the estimate. Everything outside scope goes to Deferred Work.
Auto-committing. This skill suggests commits; it never runs them.
Anti-Patterns
Anti-Pattern
Better Approach
Jumping to code before the spec is approved
Hard gate: no implementation until the spec passes review and the user approves
Batching multiple interview questions
One question at a time, depth-first, dependency-resolved
Flat task lists without dependencies
Model as a DAG — hidden dependencies cause ordering bugs and conflicts
Parallelizing everything for speed
Safety first — only disjoint, independent tasks parallelize; serialize when in doubt
Proposing fake alternatives when the answer is obvious
Present the single right answer with rationale; options only at genuine forks
Skipping TDD for "simple" changes
Tests are the proof of correctness — write them first, always
Self-grading completed work
Dispatch a separate, skeptical evaluator — generators over-praise their own work
Massive L-sized tasks
Decompose until every task is S or M
Starting fresh when a board exists
Detect, display status, resume from the last incomplete wave
Advancing with private doubts
Stop, reason, and either resolve the doubt or surface it as a question
Output / Response Style
Respond terse like smart caveman. All technical substance stay. Only fluff die.
Persistence
ACTIVE EVERY RESPONSE once triggered. No revert after many turns. No filler drift. Still active if unsure. Off only when user says "stop caveman" or "normal mode".
Rules
Drop: articles (a/an/the), filler (just/really/basically/actually/simply), pleasantries (sure/certainly/of course/happy to), hedging. Fragments OK. Short synonyms (big not extensive, fix not "implement a solution for"). Abbreviate common terms (DB/auth/config/req/res/fn/impl). Strip conjunctions. Use arrows for causality (X -> Y). One word when one word enough.
Not: "Sure! I'd be happy to help you with that. The issue you're experiencing is likely caused by..." Yes: "Bug in auth middleware. Token expiry check use < not <=. Fix:"
Examples
"Why React component re-render?"
Inline obj prop -> new ref -> re-render. useMemo.
"Explain database connection pooling."
Pool = reuse DB conn. Skip handshake -> fast under load.
Auto-Clarity Exception
Drop caveman temporarily for: security warnings, irreversible action confirmations, multi-step sequences where fragment order risks misread, user asks to clarify or repeats question. Resume caveman after clear part done.
Example — destructive op:
Warning: This will permanently delete all rows in the users table and cannot be undone.
sql
DROP TABLE users;
Caveman resume. Verify backup exist first.
References
Load a reference only when its phase needs it — they are long and consume context.
references/intake-playbook.md — adaptive question banks per work type, codebase-first intelligence, design-tree traversal, calibration, example sessions
Absolute Work next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
One-time setup for absolute: interview how you want it to behave (output style, autonomy, TDD strictness, spec dir, families) + detect the stack once, then write .absolute.config.json (project…
Vulnerability and security scan (defensive, your own repo): dependency CVEs plus risky code patterns (secrets, injection, weak authz), severity x reachability triaged and remediated without…
A skill your agent uses when the user wants to simplify, clean up, refactor, tidy, or refine code — their staged/unstaged git changes or a target file/path.
Lint and 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.
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.
End-to-end, phase-gated SDLC for AI coding agents: relentless design interview → reviewed spec → dependency-graphed task board → safe-wave TDD execution → verification → converge. Absolute Work is an agent skill from maddhruv/absolute. End-to-end, phase-gated SDLC for AI coding agents: relentless design interview → reviewed spec → dependency-graphed task board → safe-wave TDD execution → verification → converge.
When should I use Absolute Work?
Absolute Work fits situations like: build this end-to-end; break this into tasks; grill me on this plan; pick up this ticket.
How do I install Absolute Work in Claude Code?
Run `npx skills add maddhruv/absolute --skill absolute-work -a claude-code`. Or copy the skill folder (skills/absolute-work in maddhruv/absolute) into .claude/skills/absolute-work in your project. Claude Code loads it when a task matches its description.
How do I install Absolute Work in Codex?
Run `npx skills add maddhruv/absolute --skill absolute-work -a codex`. Or copy the skill folder (skills/absolute-work in maddhruv/absolute) into .agents/skills/absolute-work in your project. Codex loads it when a task matches its description.
Can I use Absolute Work in Cursor, Gemini CLI or GitHub Copilot?
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add maddhruv/absolute --skill absolute-work -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/absolute-work, .gemini/skills/absolute-work, .github/skills/absolute-work and .opencode/skills/absolute-work in your project.
What does Absolute Work need to run?
Going by SKILL.md and its folder, Absolute Work needs the command-line tools its instructions call (npm, make and git).
Does Absolute Work access the network?
SKILL.md contains no URLs. Its commands use npm and git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.
Is Absolute Work safe to install?
Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.
What licence does Absolute Work use?
Absolute Work is published under the MIT licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.
How many tokens does Absolute Work use?
About 5.3k tokens (SKILL.md is roughly 21k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 13k tokens, read only when the agent opens those files.
What are the alternatives to Absolute Work?
Skills that share tags, products or a category with Absolute Work: TDD Workflow (hellangleZ/burn-in-cceverywhere-ralph, 112 stars), TDD Workflow (affaan-m/ECC, 275k stars), Code That Fits In Your Head (CodeAlive-AI/ai-driven-development, 157 stars) and Ab Create Task From Handoff (ayoubben18/ab-method, 192 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
Who maintains Absolute Work?
maddhruv (a GitHub user) maintains it in maddhruv/absolute, which has 218 GitHub stars. The repository holds 10 skills in this directory. The repository was last updated on July 6, 2026.
Source: maddhruv/absolute on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.
