following-plans

# Following Plans

## Overview

This skill is **embedded in agent prompts** during plan execution. It provides an algorithmic decision tree for determining when to follow the plan exactly vs when to report STOPPED.

**Purpose:** Prevent agents from rationalizing "simpler approaches" that were already considered and rejected during design.

## When to Use

This skill is **embedded in agent prompts during plan execution**. It applies when:

- Agent executing implementation plan encounters situation requiring deviation
- Current approach in plan seems problematic or won't work
- Agent discovers syntax errors or naming issues in plan
- Agent wants to use "simpler approach" than plan specifies
- Tests fail with planned approach
- Plan contains contradictions or errors

**This skill prevents:**
- Unauthorized architectural changes during execution
- Scope creep from "better ideas" during implementation
- Rationalization of deviations without approval
- Silent changes that break plan assumptions

## Quick Reference

```
Is change syntax/naming only?
├─ YES → Fix it, note in completion, STATUS: OK
└─ NO → Does it change approach/architecture?
    ├─ YES → Report STATUS: STOPPED with reason
    └─ NO → Follow plan exactly, STATUS: OK
```

**Allowed without STOPPED:**
- Syntax corrections (wrong function name in plan)
- Error handling implementation details
- Variable naming choices
- Code organization within file
- Test implementation details

**Requires STOPPED:**
- Different algorithm or approach
- Different library/framework
- Different data structure/API design
- Skipping/adding planned functionality
- Refactoring not in plan

## Implementation Boundaries

When evaluating changes from plan:

| Domain | Within Boundaries (tsv pass) | Exceeds Boundaries (tsv fail) |
|--------|-----------------------------|-------------------------------|
| Logic | syntax/naming | algorithm changes |
| Deps | calls within lib | swap library |
| Scope | edge cases | add/skip features |
| Int