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:

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:

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

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:

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

Resources

Read 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