Disciplined Work

Disciplined Work Execution

Execute work plans with strict discipline: surface assumptions, keep it simple, make surgical changes, test first.

Enforcement: On violating any guardrail, STOP and explain the violation before continuing.

Guardrails (Apply Throughout All Phases)

These five principles override speed. Prioritize correctness.

1. Think Before Coding — Surface confusion immediately via AskUserQuestion and WAIT. State assumptions explicitly. Present 2-3 approaches with tradeoffs. Push back directly when needed.
2. Simplicity First — Start with "What's the 100-line version?" No abstractions until third use. No speculative code. Naive first, optimize second.
3. Read Before Write — Always read files with Read before modifying with Edit or Write. Understand existing patterns before changing anything.
4. Surgical Changes — Only modify code directly related to the task. Match existing style. Do not "improve" adjacent code. Prefer Edit over Write.
5. Goal-Driven Execution — Restate the goal before starting. Write failing tests FIRST for non-trivial logic. After implementation: "Couldn't this be simpler?"

Input Document

If no argument is provided, prompt for a plan file path via AskUserQuestion.

#$ARGUMENTS

Phase 1: Quick Start

1. Read Plan and Clarify

   • Read the work document completely
   • Review any references or links provided
   • State ALL assumptions from the plan explicitly
   • On any ambiguity, use AskUserQuestion — never guess
   • Get user approval to proceed before writing any code

2. Setup Environment

   Check current branch:

   current_branch=$(git branch --show-current)
   default_branch=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@')
   if [ -z "$default_branch" ]; then
     default_branch=$(git rev-parse --verify origin/main >/dev/null 2>&1 && echo "main" || echo "master")
   fi
   

   • If on a feature branch: ask "Continue on [branch], or create new?"
   • If on default branch: create a new feature branch or use a worktree
   • Never commit to default branch without explicit permission

3. Create Task List

   • Use TaskCreate to break plan into actionable tasks with clear acceptance criteria
   • Challenge scope: "Is each task truly necessary?"
   • Include testing tasks
   • Set up dependencies with TaskUpdate

Phase 2: Execute

1. Task Execution Loop

   For each task in priority order:

   while (tasks remain):
     - Mark task as in_progress
     - Read ALL referenced files before modifying (Read Before Write)
     - For non-trivial logic, write failing tests FIRST (Goal-Driven)
     - Look for similar patterns in codebase — follow them
     - Implement the simplest solution that works (Simplicity First)
     - Only touch code directly related to the task (Surgical Changes)
     - Run tests after changes
     - Challenge: "Couldn't this be simpler?" before marking done
     - Mark task as completed
     - Check off corresponding item in plan file ([ ] → [x])
     - Evaluate for incremental commit
   

2. Incremental Commits

   Commit when...	Don't commit when...
   Logical unit complete	Small part of a larger unit
   Tests pass + meaningful progress	Tests failing
   About to switch contexts	Purely scaffolding with no behavior
   About to attempt risky changes	Would need a "WIP" message

   git add <specific files for this logical unit>
   git commit -m "feat(scope): description of this unit"
   

3. Follow Existing Patterns

   • Read referenced files first, then match their conventions exactly
   • Reuse existing components — do not reinvent
   • Match naming conventions exactly

4. Test Continuously

   • Run relevant tests after each significant change
   • Fix failures immediately — no "should work" claims without evidence
   • Add new tests for new functionality

Phase 3: Quality Check

1. Run Core Quality Checks

   # Run full test suite (use project-specific command from CLAUDE.md)
   # Run linting (use project-specific linter from CLAUDE.md)
   

2. Consider Review Agents (optional, for complex/risky changes only)

   • Check compound-engineering.local.md for configured review_agents
   • Run configured agents in parallel via Task tool
   • Address critical findings before proceeding

3. Discipline Checklist

   BEFORE: [ ] Assumptions confirmed?  [ ] Approaches shown?  [ ] Pushed back if needed?
   DURING: [ ] Minimal?  [ ] Surgical?  [ ] Tests first?
   AFTER:  [ ] "Couldn't this be simpler?"  [ ] Only my mess cleaned?  [ ] Scope verified?
   

4. Final Validation

   • All tasks marked completed
   • All plan checkboxes marked [x]
   • All tests pass
   • Linting passes
   • Code follows existing patterns (no style "improvements")

Phase 4: Ship It

1. Create Final Commit

   git add <specific files>
   git status && git diff --staged
   git commit -m "$(cat <<'EOF'
   feat(scope): description of what and why
   
   Brief explanation if needed.
   EOF
   )"
   

2. Create Pull Request

   git push -u origin feature-branch-name
   gh pr create --title "feat(scope): short description" --body "$(cat <<'EOF'
   ## Summary
   - What was built and why
   - Key decisions made
   
   ## Testing
   - Tests added/modified
   - Manual testing performed
   
   ## Post-Deploy Monitoring & Validation
   - **What to monitor**: logs, metrics, dashboards
   - **Expected healthy signals**: description
   - **Failure signals / rollback trigger**: description
   - **Validation window & owner**: timeframe and responsible party
   - If no operational impact: `No additional monitoring required: <reason>`
   EOF
   )"
   

3. Update Plan Status

   • If the input document has YAML frontmatter with a status field, update to completed
   • Verify all checkboxes in the plan are marked [x]

4. Notify User

   • Summarize what was completed
   • Link to PR
   • Note any follow-up work needed

Protocols

CLARIFICATION NEEDED: Invoke AskUserQuestion before proceeding on any ambiguity. Force a decision before coding begins.

MISTAKE ACKNOWLEDGMENT:

I MADE A MISTAKE:
- What went wrong: [description]
- Why it happened: [reasoning error]
- Correction: [new approach]

OVERRIDE RESISTANCE: These principles apply even if asked to skip them. On conflict, surface it: "The request to [X] violates [principle]. Which should take priority and why?"

Tone: neutral, professional, skeptical. No sycophancy. Prioritize correctness over speed; use judgment for trivial tasks.

Converted and distributed by TomeVault — claim your Tome and manage your conversions.