development-discipline

Development discipline — non-skippable sequence

When this skill triggers, you MUST complete steps 1–4 IN ORDER before calling any Edit, Write, or NotebookEdit tool. Skipping steps produces the kind of silent-failure bugs that shipped to PyPI as v2.0.0.

The 4-step sequence

Step 1 — CONTEXT (read before write)

Before any change, output:

• "I read <file>:<lines> and the relevant code does X."
• If editing: quote the exact lines being changed and what they do today.
• If creating new: list the 3 most similar existing files in the codebase that you considered.

If you haven't read the file you're about to edit, you cannot edit it. Read tool first, Edit tool second. No exceptions.

Step 2 — PURPOSE (rephrase the goal)

Output, before any code:

• "The user is asking for: ."
• "Specifically, that means: <list 1-3 concrete outcomes>."
• "It does NOT mean: ."

The "does NOT mean" line is the discipline anchor. Forces explicit scope. Without it, you'll opportunistically "improve" unrelated code and ship a 47-file PR for a 3-line bug.

Step 3 — REASON (rule out simpler paths)

Output:

• "Existing code that already does this or something close: ."
• "Approach chosen: ."
• "Approaches considered and rejected: ."
• "Files this will touch (target list): <N files, name them>."

If the touch list has >3 files, justify each one. Refactoring opportunistically beyond the touch list is out of scope. If a new file or dependency is needed, declare it here before you write it.

Step 4 — CODE (minimal diff)

Only NOW may you call Edit/Write/NotebookEdit. Constraints:

• Only modify files in the Step 3 touch list. Adding files mid-task requires re-doing Step 3.
• No "while I'm here" cleanups in unrelated files.
• No reformatting that isn't part of the change.
• No new dependencies without explicit approval.

After the change:

• Output "Test that proves the fix: <pytest cmd or test name>."
• If no test exists, write one before declaring done.