absolute-work

Name: absolute-work
Author: maddhruv

26installs32forks

How to install absolute-work?

maddhruv/absolute/absolute-work

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

Installs into the current project.

Summary

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. Trigger

Files · 1

View on GitHub

SKILL.md

1	> Start your first response with the 🛠️ emoji.
2
3	## Absolute Work: End-to-End AI Development Lifecycle
4
5	Absolute Work takes any unit of work — a ticket, a task, a plan, a migration — from
6	fuzzy intent to verified code. It is one continuous skill with hard gates between
7	phases: brainstorm a shared design, write and review a spec, decompose into a
8	dependency-graphed task board, then peel tasks off one safe wave at a time with
9	test-first verification. Nothing is assumed, nothing is silently expanded, and no code
10	is written until the design is approved.
11
12	The lifecycle has 6 phases:
13	INTAKE & BRAINSTORM → SPEC → DECOMPOSE & PLAN → EXECUTE → VERIFY → CONVERGE
14
15	---
16
17	## The Phase Gate Rule
18
19	**Absolute Work STOPS at the end of every phase and waits for the user's explicit "go"
20	before advancing.** This is non-negotiable. The phases are:
21
22	```
23	INTAKE & BRAINSTORM ─┃ gate ┃─ SPEC ─┃ gate ┃─ DECOMPOSE & PLAN ─┃ gate ┃─ EXECUTE ─┃ gate per wave ┃─ VERIFY ─┃ gate ┃─ CONVERGE
24	```
25
26	At each gate, present what was produced, summarize what comes next, and ask the user
27	to confirm before proceeding. Never chain two phases without an approval in between.
28	Use `AskUserQuestion` (where available) for every gate and every interview question.
29
30	---
31
32	## Activation Protocol
33
34	Immediately after the banner, enter plan mode before doing anything else:
35
36	1. On platforms with native plan mode (e.g. Claude Code's `EnterPlanMode`): invoke it immediately.
37	2. On platforms without it: simulate plan mode — complete INTAKE & BRAINSTORM and SPEC fully, write no code, and get explicit approval before EXECUTE.
38
39	The first three phases are planning work. No files are created or modified (other than the
40	spec and the board) until the user approves the task graph and execution begins.
41
42	---
43
44	## Session Resume Protocol
45
46	When Absolute Work is invoked and a `.absolute-work/board.md` already exists in the project root:
47
48	1. Detect: Read the board and determine its status.
49	2. Display: Print a compact summary of completed / in-progress / blocked / remaining tasks.
50	3. Resume: Pick up from the last incomplete wave — do NOT restart from INTAKE.
51	4. Reconcile: If the codebase changed since the last session, diff against the board's expected state and flag conflicts before resuming.
52
53	If the board is `completed`, ask whether to start a new session (archive the old board to
54	`.absolute-work/archive/`) or review the finished work. **Never blow away an existing board
55	without explicit user confirmation.**
56
57	---
58
59	## Codebase Convention Detection
60
61	Before INTAKE begins, auto-detect the project's conventions so every phase is grounded
62	in reality, not assumptions. If `.absolute.config.json` or `~/.absolute/config.json` exists
63	(from `/absolute init`), resolve the effective config (project file → global `projects["<cwd>"]`
64	→ global `defaults`), read its cached `conventions` first, and detect only what's missing. The
65	`preferences` (`tdd`, `autonomy`, `specDir`, `boardTracking`) likewise drive later phases.
66
67	\| Signal \| Files to Check \|
68	\|---\|---\|
69	\| Package manager \| `package-lock.json` (npm), `yarn.lock`, `pnpm-lock.yaml`, `bun.lockb`, `Cargo.lock`, `go.sum` \|
70	\| Language/Runtime \| `tsconfig.json`, `pyproject.toml` / `setup.py`, `go.mod`, `Cargo.toml` \|
71	\| Test runner \| `jest.config.`, `vitest.config.`, `pytest.ini`, `.mocharc.*`, test directory patterns \|
72	\| Linter/Formatter \| `.eslintrc.`, `eslint.config.`, `.prettierrc.*`, `ruff.toml`, `.golangci.yml` \|
73	\| Build system \| `Makefile`, `vite.config.`, `next.config.`, `turbo.json` \|
74	\| CI/CD \| `.github/workflows/`, `.gitlab-ci.yml`, `Jenkinsfile` \|
75	\| Available scripts \| `scripts` in `package.json`, `Makefile` targets \|
76	\| Directory conventions \| `src/`, `lib/`, `app/`, `tests/`, `__tests__/`, `spec/` \|
77
78	Write detected conventions to the board under `## Project Conventions`. Reference them in
79	every later phase — especially PLAN and the mandatory verification tail tasks. Always run
80	verification through the project's own scripts (`npm test`, `make lint`), never raw tools.
81
82	---
83
84	## When to Use This Skill
85
86	Use Absolute Work when:
87	- Picking up a ticket or task that needs design before implementation
88	- Multi-step fea

People who liked this also viewed

6 picks

Type

absolute-work

26installs32forks

View on GitHub

How to install absolute-work?

maddhruv/absolute/absolute-work

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

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	> Start your first response with the 🛠️ emoji.
2
3	## Absolute Work: End-to-End AI Development Lifecycle
4
5	Absolute Work takes any unit of work — a ticket, a task, a plan, a migration — from
6	fuzzy intent to verified code. It is one continuous skill with hard gates between
7	phases: brainstorm a shared design, write and review a spec, decompose into a
8	dependency-graphed task board, then peel tasks off one safe wave at a time with
9	test-first verification. Nothing is assumed, nothing is silently expanded, and no code
10	is written until the design is approved.
11
12	The lifecycle has 6 phases:
13	INTAKE & BRAINSTORM → SPEC → DECOMPOSE & PLAN → EXECUTE → VERIFY → CONVERGE
14
15	---
16
17	## The Phase Gate Rule
18
19	**Absolute Work STOPS at the end of every phase and waits for the user's explicit "go"
20	before advancing.** This is non-negotiable. The phases are:
21
22	```
23	INTAKE & BRAINSTORM ─┃ gate ┃─ SPEC ─┃ gate ┃─ DECOMPOSE & PLAN ─┃ gate ┃─ EXECUTE ─┃ gate per wave ┃─ VERIFY ─┃ gate ┃─ CONVERGE
24	```
25
26	At each gate, present what was produced, summarize what comes next, and ask the user
27	to confirm before proceeding. Never chain two phases without an approval in between.
28	Use `AskUserQuestion` (where available) for every gate and every interview question.
29
30	---
31
32	## Activation Protocol
33
34	Immediately after the banner, enter plan mode before doing anything else:
35
36	1. On platforms with native plan mode (e.g. Claude Code's `EnterPlanMode`): invoke it immediately.
37	2. On platforms without it: simulate plan mode — complete INTAKE & BRAINSTORM and SPEC fully, write no code, and get explicit approval before EXECUTE.
38
39	The first three phases are planning work. No files are created or modified (other than the
40	spec and the board) until the user approves the task graph and execution begins.
41
42	---
43
44	## Session Resume Protocol
45
46	When Absolute Work is invoked and a `.absolute-work/board.md` already exists in the project root:
47
48	1. Detect: Read the board and determine its status.
49	2. Display: Print a compact summary of completed / in-progress / blocked / remaining tasks.
50	3. Resume: Pick up from the last incomplete wave — do NOT restart from INTAKE.
51	4. Reconcile: If the codebase changed since the last session, diff against the board's expected state and flag conflicts before resuming.
52
53	If the board is `completed`, ask whether to start a new session (archive the old board to
54	`.absolute-work/archive/`) or review the finished work. **Never blow away an existing board
55	without explicit user confirmation.**
56
57	---
58
59	## Codebase Convention Detection
60
61	Before INTAKE begins, auto-detect the project's conventions so every phase is grounded
62	in reality, not assumptions. If `.absolute.config.json` or `~/.absolute/config.json` exists
63	(from `/absolute init`), resolve the effective config (project file → global `projects["<cwd>"]`
64	→ global `defaults`), read its cached `conventions` first, and detect only what's missing. The
65	`preferences` (`tdd`, `autonomy`, `specDir`, `boardTracking`) likewise drive later phases.
66
67	\| Signal \| Files to Check \|
68	\|---\|---\|
69	\| Package manager \| `package-lock.json` (npm), `yarn.lock`, `pnpm-lock.yaml`, `bun.lockb`, `Cargo.lock`, `go.sum` \|
70	\| Language/Runtime \| `tsconfig.json`, `pyproject.toml` / `setup.py`, `go.mod`, `Cargo.toml` \|
71	\| Test runner \| `jest.config.`, `vitest.config.`, `pytest.ini`, `.mocharc.*`, test directory patterns \|
72	\| Linter/Formatter \| `.eslintrc.`, `eslint.config.`, `.prettierrc.*`, `ruff.toml`, `.golangci.yml` \|
73	\| Build system \| `Makefile`, `vite.config.`, `next.config.`, `turbo.json` \|
74	\| CI/CD \| `.github/workflows/`, `.gitlab-ci.yml`, `Jenkinsfile` \|
75	\| Available scripts \| `scripts` in `package.json`, `Makefile` targets \|
76	\| Directory conventions \| `src/`, `lib/`, `app/`, `tests/`, `__tests__/`, `spec/` \|
77
78	Write detected conventions to the board under `## Project Conventions`. Reference them in
79	every later phase — especially PLAN and the mandatory verification tail tasks. Always run
80	verification through the project's own scripts (`npm test`, `make lint`), never raw tools.
81
82	---
83
84	## When to Use This Skill
85
86	Use Absolute Work when:
87	- Picking up a ticket or task that needs design before implementation
88	- Multi-step fea

People who liked this also viewed

6 picks

Type