absolute-work

When this skill is activated, always start your first response with the 🛠️ emoji.

# 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**

---

## Activation Banner

**At the very start of every Absolute Work invocation**, before any other output,
display this ASCII art banner:

```
 █████╗ ██████╗ ███████╗ ██████╗ ██╗     ██╗   ██╗████████╗███████╗
██╔══██╗██╔══██╗██╔════╝██╔═══██╗██║     ██║   ██║╚══██╔══╝██╔════╝
███████║██████╔╝███████╗██║   ██║██║     ██║   ██║   ██║   █████╗
██╔══██║██╔══██╗╚════██║██║   ██║██║     ██║   ██║   ██║   ██╔══╝
██║  ██║██████╔╝███████║╚██████╔╝███████╗╚██████╔╝   ██║   ███████╗
╚═╝  ╚═╝╚═════╝ ╚══════╝ ╚═════╝ ╚══════╝ ╚═════╝    ╚═╝   ╚══════╝
██╗    ██╗ ██████╗ ██████╗ ██╗  ██╗
██║    ██║██╔═══██╗██╔══██╗██║ ██╔╝
██║ █╗ ██║██║   ██║██████╔╝█████╔╝
██║███╗██║██║   ██║██╔══██╗██╔═██╗
╚███╔███╔╝╚██████╔╝██║  ██║██║  ██╗
 ╚══╝╚══╝  ╚═════╝ ╚═╝  ╚═╝╚═╝  ╚═╝
```

Follow the banner immediately with: `Entering plan mode — phase-gated lifecycle active`

---

## 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:

```
INTAKE & BRAINSTORM ─┃ gate ┃─ SPEC ─┃ gate ┃─ DECOMPOSE & PLAN ─┃ gate ┃─ EXECUTE ─┃ gate per wave ┃─ VERIFY ─┃ gate ┃─ CONVERGE
```

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:

1. **On platforms with native plan mode** (e.g. Claude Code's `EnterPlanMode`): invoke it immediately.
2. **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:

1. **Detect**: Read the board and determine its status.
2. **Display**: Print a compact summary of completed / in-progress / blocked / remaining tasks.
3. **Resume**: Pick up from the last incomplete wave — do NOT restart from INTAKE.
4. **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.

| Signal | Files to Check |
|---|---|
| **Package manager** | `package-lock.json` (npm), `yarn.lock`, `pnpm-lock.yaml`, `bun.lockb`, `Cargo.lock`, `go.sum` |
| **Language/Runtime** | `tsconfig.json`, `pyproject.toml` / `setup.py`, `go.mod`, `Cargo.toml` |
| **Test runner** | `jest.config.*`, `vitest.config.*`, `pytest.ini`, `.mocharc.*`, test directory patterns |
| **Linter/Formatter** | `.eslintrc.*`, `eslint.config.*`, `.prettierrc.*`, `ruff.toml`, `.golangci.yml` |
| **Build system** | `Makefile`, `vite.config.*`, `next.config.*`, `turbo.json` |
| **CI/CD** | `.github/workflows/`, `.gitlab-ci.yml`, `Jenkinsfile` |
| **Available scripts** | `scripts` in `package.json`, `Makefile` targets |
| **Directory conventions** | `src/`, `lib/`, `app/`, `tests/`, `__tests__/`, `spec/` |

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

1. **Phase gates always.** Stop and get explicit approval between every phase. Control over speed.
2. **Codebase before questions.** Search the code first; only ask what code genuinely cannot answer.
3. **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.
4. **Spec before code.** No implementation until a written spec is reviewed and approved.
5. **Dependency-first decomposition.** Every task is a node in a DAG, not a flat list.
6. **Safety-first execution.** Blockers and dependents run **sequentially**; only **prova