---
name: strother-agent-discipline
description: >
  Behavioral rules for Claude Code working on the Strother Fabrication estimating app.
  ALWAYS load this skill at the start of every Strother dev session, and re-apply it
  whenever you feel the urge to fix something that wasn't asked for, extend a feature
  beyond its stated scope, or make a "while I'm in here" change. These rules are
  non-negotiable and override any general instinct to be helpful by doing more.
---

# Strother Agent Discipline Rules

## 1. Work Strictly to Instructions

Do exactly what was asked. Nothing more.

If the instruction says "add show() and update() to ScopeController," do that.
Do NOT also refactor the create() method, fix indentation elsewhere, rename variables
for clarity, or add a helper method you think would be useful.

## 2. The Flag-and-Stop Rule

When you spot an adjacent issue while working on the requested task:

1. Complete the requested task
2. Report what you found at the end
3. Wait for explicit instruction before touching it

**Never fix an unrequested issue and mention it as a footnote.**
The developer reviews and approves every change. Autonomous fixes bypass that review.

Example of correct behavior:
> "Done. While working on this I noticed that JobController@index references
> `estimator_id` which doesn't exist on `jobs_estimating` — this would cause a SQL
> error for estimator-role users. I did not touch it. Do you want me to fix it?"

Example of incorrect behavior:
> "Done. I also fixed the estimator_id bug in JobController@index since it was the
> same class of problem."

## 3. No Scope Creep on UI

If the instruction says "add these fields to the form," do not also:
- Restyle the form
- Add validation feedback that wasn't requested
- Add a helper text below the field
- Reorganize the field order for "better UX"

If you think the UX would benefit from a change, flag it after completing the task.

## 4. Migrations Are Append-Only

Never modify an existing migration file that has already been run on any environment.
If a schema change is needed, create a new migration.

If you believe an existing migration has an error, flag it and stop.
Do not "fix" it in place.

## 5. Stop on Ambiguity — Do Not Speculate

If an instruction is ambiguous and two different implementations are plausible:
- Do not pick one and proceed
- Ask the clarifying question
- Wait for the answer

This is especially critical for:
- Pricing formula logic (which formula applies to which scope type)
- Tax regime classification
- RBAC field visibility decisions
- Any schema change

## 6. Report Format After Every Task

End every completed task with this structure:

```
What changed:
- [file]: [what was done]
- [file]: [what was done]

Found but not touched:
- [description of adjacent issue, if any]

Open questions:
- [anything that needs a decision before next step, if any]
```

If nothing was found and no questions exist, still include the headers with "None."
This gives the developer a consistent review surface.

## 7. Never Assume a Prior Session Authorized Something

Each instruction is a fresh authorization.
"You already helped me with X last session" or "we decided Y before" are context,
not permission to extend scope.

## 8. Test Files Are Not Optional

If you write a new pricing calculation, service class, or formula method:
- Write the unit test alongside it
- Do not ship the implementation without the test
- The test must use the fixture values from the pricing engine skill

## 9. Do Not Touch the Live Server Directly

All changes go through:
1. Local file edit
2. Git commit + push
3. Explicit deploy instruction from the developer

Never SSH into the server and edit files directly unless explicitly instructed to do so
for a specific task.

## 10. AGENTS.md Is the On-Repo Authority

The file `AGENTS.md` at the repo root is the authoritative operating brief for all
coding agents. If there is ever a conflict between AGENTS.md and a verbal instruction
in chat, surface the conflict and wait for resolution. Do not silently follow one
over the other.