# Intense Job Checklist

> Run a living checklist workflow for large, intense engineering tasks from kickoff through production sign-off. Use this skill whenever work spans multiple subsystems, requires repeated validation, or needs continuous tracking of findings, fixes, and sign-off readiness. This includes audits, multi-file refactors, migrations, major rollouts, production hardening, balance tuning, comprehensive test passes, codebase-wide cleanups, and any task where "done" requires proving that nothing was missed. Also use when the user says things like "do a thorough job", "make sure everything works", "audit this", "harden this", or "production-ready." Do not use for single-file quick fixes, informational Q&A, or narrow edits where checklist overhead adds no value.

- Skill: `gurulost/intense-job-checklist` (Agent Skill, multi-file: 7 files)
- Install (CLI): `npx skillmds@latest add gurulost/intense-job-checklist`
- Raw SKILL.md: https://api.skillmd.com/api/skills/gurulost/intense-job-checklist/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: gurulost (https://skillmd.com/u/gurulost)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/gurulost/intense-job-checklist

---


# Intense Job Checklist

A structured workflow for complex engineering tasks where "done" means provably done. This skill creates a living checklist file that serves as the single source of truth — tracking scope, findings, fixes, validations, and sign-off gates — so nothing falls through the cracks during large, multi-step work.

## Why This Exists

Complex tasks fail in predictable ways: discovered issues get forgotten, validations run once but aren't rerun after later changes, and "done" gets declared based on vibes instead of evidence. This skill prevents that by enforcing a structured checklist that requires proof at every step.

## Quick Start

Set `SKILL_ROOT` to the directory that contains this `SKILL.md`.
Typical values include `~/.claude/skills/intense-job-checklist` or `${CODEX_HOME:-$HOME/.codex}/skills/intense-job-checklist`.

1. **Bootstrap** the checklist in the target repo:
```bash
python3 "$SKILL_ROOT/scripts/bootstrap_checklist.py" "<job title>" --repo-root "<repo-root>"
```
2. **Update** the checklist after every completed step and every newly discovered finding.
3. **Validate** before declaring the job done:
```bash
python3 "$SKILL_ROOT/scripts/validate_checklist.py" "<checklist-path>" --require-signoff
```

**If Python is unavailable:** Copy the template from `assets/checklist-template.md` manually into `docs/<slug>-production-checklist.md`, fill in the title and timestamps, and validate by reading through each checklist section before sign-off. The scripts automate this, but the workflow works without them.

## When to Use This Flow

Use this skill by default when at least one of these is true:
- Work spans multiple systems or files and will likely need iteration
- The user asks for a deep audit, comprehensive hardening, or production readiness
- The task involves migration, balance tuning, refactor, rollout, or many edge cases
- Validation requires multiple commands, tests, and reruns

**Stop and skip this flow** for single-file quick fixes, informational-only responses, or narrow edits. If the checklist would have more overhead than the actual work, don't use it.

If a checklist already exists for the same active job, continue using it rather than creating a new one.

## Workflow

### Step 0: Re-anchor on Checklist State

If your context gets long or compacted, reopen the checklist file and resume from its current state. The checklist is authoritative — it tracks what's queued, what's been found, what's been fixed, and what's been validated. Trust it over memory.

### Step 1: Bootstrap the Checklist

Create the checklist as early as possible — before doing substantive work. This forces scope to be explicit upfront rather than drifting.

- Default location: `docs/<slug>-production-checklist.md` in the repository
- Announce the checklist path to the user so they can follow along
- The template lives at `assets/checklist-template.md`

### Step 2: Use the Right Item Format

Every tracked item follows this format:
```
- [ ] X-000 [status:open] summary
```

**Prefixes** (each prefix tracks a different kind of work):
| Prefix | Purpose |
|--------|---------|
| `G-` | Sign-off gates — must all be checked before declaring done |
| `Q-` | Execution queue — the work items themselves |
| `F-` | Findings — issues discovered during work |
| `P-` | Fixes — corrective changes linked to findings |
| `V-` | Validation — commands/tests with timestamps and outcomes |
| `R-` | Residual risks — known issues accepted with rationale |

**Allowed statuses:** `open`, `in_progress`, `blocked`, `verified`, `accepted_risk`

### Step 3: Run the Continuous Update Loop

After each meaningful action, update the checklist immediately — don't batch updates until the end. This is the core discipline that makes the system work: if it's not on the checklist, it didn't happen.

1. Mark completed queue items
2. Add new queue items when scope expands
3. Log every discovered issue under Findings with severity (`[P0]`–`[P3]`) and confidence
4. Log each corrective change under Fix Log, linked to the finding it addresses
5. Record validation outcomes with timestamp and pass/fail

### Step 3.5: Recheck Scope After Discovery

After completing the discovery/audit phase (`Q-002`), pause and sanity-check the checklist before grinding through the rest of the work. Ask:
- Does the scope in `Q-000` still match what you actually found?
- Are the validation commands in `V-*` still the right ones, or did discovery reveal that different tests matter?
- Did the audit surface an entirely different problem than expected?

If the answers change, update the checklist now. Rigorously completing the wrong plan is worse than no plan at all.

### Step 4: Attach Evidence

Each finding, fix, and validation needs proof. The reason: without evidence, items get marked "done" based on memory, which degrades as context grows.

- **Findings**: File path + line number, command output, or repro steps
- **Fixes**: Linked finding ID + what changed (commit, file refs, test proof)
- **Validations**: Command run, timestamp, pass/fail outcome

If evidence is missing, keep the item open. If no findings are discovered, convert the placeholder `F-001` into a verified no-findings record with evidence of what was audited.

### Step 5: Enforce the Rerun Matrix

This catches the most common mistake in complex work: running validations, then making more changes, then declaring done without revalidating.

- If code changes after a checked `V-*` item, uncheck affected validation items
- Rerun validations after the final code edit
- Gate `G-003` stays unchecked until this final rerun pass completes

### Step 6: Definition of Done

Before declaring the job complete:

1. Run the validator with sign-off enforcement:
```bash
python3 "$SKILL_ROOT/scripts/validate_checklist.py" "<checklist-path>" --require-signoff
```
2. Resolve any validator errors
3. Confirm all `G-*` gate items are checked and truthful
4. Ensure residual risks have explicit owners and follow-up plans

**The job is done when:**
- Validator exits cleanly with `--require-signoff`
- All `G-*` items are checked
- No unresolved `F-*`, `P-*`, required `V-*`, or `Q-*` items remain
- Residual risks are either resolved or explicitly accepted with an owner

Never declare completion while unresolved findings, fixes, or validations remain.

## Communication

- Announce the checklist path early so the user can track progress
- Mention checklist updates as they happen
- When scope expands, add queue/findings items before continuing work
- Base completion claims on checklist state, not intuition

## Finding Severity Guide

| Level | Meaning |
|-------|---------|
| `P0` | Data loss, security break, production stop |
| `P1` | Major functional break or high-confidence regression |
| `P2` | Moderate risk, edge-case bug, maintainability issue with user impact |
| `P3` | Low-risk polish or robustness issue |

## Resources

Read [checklist-operating-model.md](references/checklist-operating-model.md) for the full operating model including status rules, evidence standards, and sign-off conditions.

- Bootstrap script: `scripts/bootstrap_checklist.py`
- Validation script: `scripts/validate_checklist.py`
- Template: `assets/checklist-template.md`