developer-execution-discipline

name	developer-execution-discipline
description	Enforces a disciplined implementation posture before coding or broad refactors: surface assumptions, narrow scope, prefer the simplest complete fix, define verification targets, and avoid speculative cleanup. Use when: a developer agent is about to implement, refactor, review, or change non-trivial code and there is meaningful ambiguity, risk, or temptation to over-engineer.
license	MIT
compatibility	opencode
metadata	{"owner":"backend-developer","type":"read-only","approval":"No"}

developer-execution-discipline

Owner: backend-developer Type: read-only Approval: No

---

What I Do

Provide a shared execution discipline for developer agents so they do not jump from vague intent to broad edits. This skill forces explicit assumptions, smallest-sufficient scope, and concrete verification before non-trivial work.

---

When to Use Me

• The user request is technically plausible but still ambiguous in meaning or scope
• A refactor, bug fix, or platform change could sprawl into unrelated cleanup
• A developer agent is about to choose between a simple fix and a more abstract redesign
• A non-trivial code change needs a clear verification target before editing

---

Context Requirements

Requires already loaded:
  {framework-home}/agents/{role}/AGENT.md
  .crux/workspace/{role}/TODO.md

Loads during execution (lazy):
  task-specific docs or code paths only after scope is narrowed

Estimated token cost: ~350 tokens
Unloaded after: task completion

---

Inputs

Input	Source	Required
user-request	user	Yes
candidate-scope	local inspection	No
affected-paths	local inspection	No

---

Steps

1. Restate the task as a concrete change goal.

2. Surface material assumptions.
   IF an assumption changes implementation shape or risk
     → say it explicitly before editing.

3. Narrow the scope.
   Define the smallest set of files or behaviours that must change.
   Exclude adjacent cleanup unless the requested fix requires it.

4. Choose the simplest complete solution.
   Prefer the least abstract design that fully solves the task.
   Do not add indirection, configurability, or new layers without a concrete need.

5. Define verification before editing.
   State what will prove the change is correct:
   tests, behaviour, contract, output, or inspection target.

6. Implement only after steps 1-5 are clear.

7. On completion, summarise:
   - assumptions used
   - what changed
   - how it was verified

8. Skill complete — unload

---

Output

Writes to: none directly Format: execution discipline applied to implementation

- concrete goal
- explicit assumptions
- smallest sufficient scope
- simplest complete solution
- verification target

---

Error Handling

Condition	Action
Scope remains ambiguous	Ask the narrowest clarifying question or state the safest assumption
Simple fix and broad redesign are both possible	Prefer the simple fix and explain why the redesign is not yet justified
Verification is unclear	Define at least one concrete validation target before editing
Unexpected failure	Stop. Explain the blocker and preserve narrowed scope.