nobrainer-build

NoBrainer Build

Implement one bounded work unit without expanding the product or hiding weak evidence behind polished output. This skill owns the edit loop. Route ambiguous requirements to nobrainer-ultra, causal diagnosis to nobrainer-rca, and the independent close gate to nobrainer-review.

Start gate

Use the actual task workspace, including an ordinary folder without Git. Repository, branch, commit and build fields are NOT_APPLICABLE when absent; do not initialize Git or request a repository merely to deliver an artifact. Verify documents through their source facts, acceptance and content/rendered readback.

Before the first write, resolve:

• observable outcome and acceptance IDs or checks;
• exact repository, checkout, dirty state, write scope and exclusions;
• expected files with one reason each, plus protected untouched files;
• relevant instructions, current callers/consumers and baseline behavior;
• cheapest useful failing proof, target tests, broader verifier/build/runtime;
• side effects, owner gates, rollback and the Done clean condition.

Preserve unrelated changes. Use an isolated worktree or disjoint write scope when another writer is active. If a missing requirement changes architecture, scope, public behavior or safety, stop at SPEC_CHANGE_PROPOSED; do not invent it inside the patch.

Engineering gate

Apply these principles as decision rules, not slogans:

• KISS: choose the simplest complete design that satisfies acceptance.
• YAGNI: do not add extension points, compatibility layers or options for an unproven future requirement.
• DRY: keep each rule and mutable fact under one owner, but do not abstract incidental similarity. Duplication can be cheaper than the wrong coupling.
• SOLID: preserve cohesive responsibilities and stable dependency boundaries; this is not a mandate for object-oriented ceremony, tiny classes or needless interfaces.

Before writing, stop at the first complete option that satisfies acceptance: