notque/fast

/fast - Zero-Ceremony Execution

The Fast tier sits at the bottom of the five-tier task hierarchy (Fast > Quick > Simple > Medium > Complex). It exists because the full ceremony of plan files, agent routing, and quality gates is wasteful for a typo fix. Execute inline without plans or subagents, commit the result, and log it.

---

Instructions

Phase 1: UNDERSTAND

Goal: Confirm the task is Fast-eligible and know exactly what to change.

Step 1: Read CLAUDE.md

Read and follow the repository CLAUDE.md before any other action, because repository-specific constraints may affect how the edit should be made.

Step 2: Parse the request

Identify from the user's request:

• Which file(s) need editing
• What specific change is needed
• Whether this is clearly a 1-3 edit task

If --dry-run was passed, show what would change without editing and stop.

Step 3: Scope check

Ask these questions silently (do not display to user):

| Question | If Yes | |----------|--------| | Does this need reading docs, investigating behavior, or understanding unfamiliar code? | Redirect to /quick --research because investigation means uncertainty, and uncertainty means this is not a Fast task | | Does this touch more than 3 files? | Redirect to /quick because uncapped "fast" tasks silently grow into untracked large changes | | Does this add imports from new packages, install libraries, or modify dependency files (go.mod, package.json, requirements.txt)? | Redirect to /quick because new dependencies carry risk that needs proper tracking | | Is the change ambiguous or underspecified? | Ask user one clarifying question. If still ambiguous after one round, redirect to /quick --discuss |

If redirecting, say:

This task exceeds /fast scope ([reason]). Redirecting to /quick.

Then invoke the quick skill with the original request.

Step 4: Locate target files

Read the file(s) that need editing. Confirm the exact lines to change.

GATE: Task is confirmed Fast-eligible (1-3 edits, no research, no new deps). Target files identified and read.

Phase 2: DO

Goal: Make the edits inline without spawning subagents, because subagents add latency and context setup cost that dwarfs the actual work at this tier.

Do not create task_plan.md, because the overhead of planning exceeds the task itself for a 1-3 edit change.

Step 1: Execute edits

Make the changes using the Edit tool. Track the number of files edited after each operation, because the 3-edit scope gate depends on an accurate count.

Step 2: Mid-execution scope check

After each edit, check: have we hit 3 edits? If the task needs MORE edits to complete, stop immediately — do not rationalize "just one more edit" because the 3-edit gate exists specifically to prevent silent scope creep:

Scope exceeded during execution (3+ edits needed). Preserving work done.
Redirecting remainder to /quick.

Hand off to /quick with context about what was already done. Do not start additional "while I'm here" fixes, because scope creep in fast mode produces untracked large changes with no plan or review.

GATE: All edits complete. Edit count is 1-3.

Phase 3: COMMIT

Goal: Commit the changes with a clean message, because uncommitted fast edits are invisible to the audit trail and defeat the traceability that justifies using the system at all. Even one-line changes get commits because one-line changes cause one-line bugs that are invisible without commit history.

If --no-commit was passed, skip this phase (for when the user wants to batch changes).

Step 1: Check branch

If on main/master, create a feature branch first because even fast tasks get proper branches — never commit directly to main:

git checkout -b fast/<brief-description>

Step 2: Stage and commit

git add <specific-files>
git commit -m "$(cat <<'EOF'
<type>: <description>
EOF
)"

Use conventional commit format. The type is usually fix:, chore:, or refactor: for fast tasks.

GATE: Commit succeeded. Verify with git log -1 --oneline.

Phase 4: LOG

Goal: Record the task for auditability, because without logging fast tasks are invisible and the system loses its audit trail.

Step 1: Append to STATE.md

If STATE.md exists in the repo root, append to the quick tasks table. If it does not exist, create it.

Format:

## Quick Tasks

| Date | ID | Description | Commit | Tier |
|------|----|-------------|--------|------|
| YYYY-MM-DD | - | <description> | <short-hash> | fast |

Fast tasks do not get task IDs (that is a Quick-tier feature). Use - for the ID column.

Step 2: Display summary

===================================================================
 FAST: <description>
===================================================================

 Files edited: <N>
 Commit: <hash> on <branch>
 Logged: STATE.md

===================================================================

---

Error Handling

Error: Scope Exceeded Mid-Execution

Cause: Task turned out to need more than 3 edits Solution: Stop, preserve work, redirect to /quick with context about completed edits. Do not undo work already done.

Error: Ambiguous Request

Cause: Cannot determine exact files or changes from the request Solution: Ask user one clarifying question. If still ambiguous after one round, redirect to /quick --discuss.

Error: On Main Branch

Cause: Currently on main/master Solution: Create fast/<description> branch before editing. Never commit directly to main.