jungho-git/execution

Execution

• Shared examples and formatting reference: references/EXAMPLE.md.
• Keep new guidance, snippets, and edits aligned with that file.

---

Scope

Use this rule when:

• editing existing code, config, scripts, schemas, docs, or tests
• adding small features or fixes
• deciding whether to extract helpers or restructure flow
• deciding whether a cleanup, rename, or comment change is in scope

Execution should produce the smallest complete change that genuinely handles the request.

---

Core Rules

• Apply the smallest complete change that solves the request and required follow-through.
• Preserve existing structure, naming, control flow, file layout, and local idioms unless correctness requires change.
• When generating new code, keep newly authored constant and variable names at 30 chars or fewer by default; preserve external contract names through local aliases.
• Extend existing patterns before introducing new helpers, layers, frameworks, or abstractions.
• Keep simple flows inline.
• Keep related statements together as one cohesive chunk unless extraction has a current, concrete reason.
• Do not widen scope into unrelated cleanup, renaming, formatting, dependency changes, or architecture drift.
• Treat stable local style as part of the contract.
• Use only real APIs, files, types, schemas, commands, and runtime behavior.
• Fail clearly with contextual errors instead of hiding uncertain behavior.
• Leave unrelated user changes intact.

---

Complete Change Criteria

• Include callers when a signature or contract changes.
• Include tests, fixtures, generated artifacts, migrations, schemas, configs, or docs when they are required for correctness or consistency.
• Include exposed error paths when the behavior changes.
• Stop at the coherence radius of the request; do not chase unrelated improvements.
• If the radius is unclear, choose the narrower safe boundary and report what was intentionally left out.

---

Code Shape Guidance

• Match the repository's grouping rhythm, indentation density, naming, and line-wrapping style.
• Preserve existing section-comment scaffolding when the file uses it for scanability.
• Apply the comments skill when adding or materially changing declarations or section comments.
• For brace-based languages, use Stroustrup clause layout: close the preceding block, then start else, catch, or finally on the next line.
• When a control-flow condition wraps, keep only the keyword and opening parenthesis on the first line, put one condition per line, keep && or || at the end of continued condition lines, and use ) { as the closing line.
• Keep one guard at the unstable boundary instead of repeating defensive checks everywhere.
• Reuse normalized values instead of re-checking the same contract repeatedly.
• Avoid formatter-like prettifying of untouched object layout, JSX layout, comments, or line breaks.
• Keep unrelated nearby code unchanged even when it differs from preference.

---

Extraction Gate

Create a helper, wrapper, extracted method, class, script, or new layer only when it:

• removes real duplication in the current change
• isolates unavoidable complexity
• protects a clear boundary
• satisfies an actual contract, test seam, or reuse point
• makes the changed flow easier to verify

Do not extract only because a block looks long, names could be nicer, or future reuse is imaginable.

---

Failure Handling

• Reproduce or localize the first real symptom before patching when fixing a failure.
• Patch the cause, not only the visible symptom.
• Avoid broad defensive validation that duplicates guarantees already established by nearby code.
• Preserve existing error semantics unless changing them is required.
• If a fix depends on an unverified assumption, make the assumption explicit and choose the least invasive path.

---

Boundaries

• Do not fabricate APIs or runtime behavior.
• Do not normalize a whole file when only a local edit is needed.
• Do not treat cosmetic consistency as sufficient reason for broad edits.
• Do not alter generated, cached, vendor, or build output unless the boundary skill allows it.
• Do not use passing static inspection as a substitute for validation when executable checks are available.