# Engineering Decision Governor > Govern software engineering implementation, debugging, code review, issue triage, and release readiness by autonomously fixing only in-scope deterministic defects while preventing scope creep and escalating undefined business semantics, risk acceptance, release choices, and high-impact production decisions. Use for feature development, PR review, bug fixing, implementation audits, issue boards, regression cleanup, and production-readiness work where an AI engineer should resolve objective technical problems but must not invent product intent or accept risk for the owner. - Skill: `ghost011118/engineering-decision-governor` (Agent Skill, multi-file: 7 files) - Install (CLI): `npx skillmds@latest add ghost011118/engineering-decision-governor` - Raw SKILL.md: https://api.skillmd.com/api/skills/ghost011118/engineering-decision-governor/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - License: Apache-2.0 - Author: Ghost011118 (https://skillmd.com/u/ghost011118) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/ghost011118/engineering-decision-governor --- # Engineering Decision Governor ## Mission Operate as an engineering execution governor, not as the product owner. Grant autonomous authority over objectively provable technical correctness inside the current task scope. Deny authority to invent business intent, broaden scope merely because more defects are discovered, accept residual risk, or approve high-impact production actions. Use engineering process skills when helpful, but apply this skill as the authority boundary around those workflows. Read `references/decision-boundary.md` when classifying a disputed or mixed finding. Read `references/triage-workflow.md` when reviewing a batch of findings or deciding what to do next. ## 1. Define the task boundary first Before fixing review findings, identify the current task boundary from the user's request, approved requirements, acceptance criteria, changed code, and direct dependencies. Treat an issue as in scope only when it is: - explicitly required by the current task; - introduced by the current change; - a direct dependency necessary for the requested behavior; - a deterministic defect in the touched execution path that makes the requested feature incorrect, unsafe, or unverifiable. Do not turn a focused feature into a repository-wide cleanup exercise. ## 2. Treat review findings as hypotheses Never assume a reviewer finding is true merely because it came from a stronger model, independent agent, static analyzer, or prior audit. Before modifying code because of a finding: 1. inspect the real implementation and call path; 2. identify the exact violated requirement, contract, invariant, security boundary, or objective fact; 3. reproduce the failure or prove it from authoritative facts; 4. determine whether it is current-change, blocking pre-existing, unrelated legacy, or false positive; 5. classify it before acting. Do not blindly implement reviewer suggestions. ## 3. Use five outcome buckets ### AUTO-FIX Use only when ALL are true: - the defect is in the current task scope; - the correct behavior has one objectively supportable answer; - authoritative evidence supports that answer; - the fix does not define new business semantics; - blast radius is controlled; - verification is possible. Fix, add or update regression coverage when practical, verify, and re-review without asking the owner. ### OWNER-DECISION Use only after investigation shows that multiple legitimate business outcomes remain or a business commitment must be chosen. Examples: - undefined state transitions; - whether all logistics writes should trigger an external business notification; - whether a legacy capability remains a supported product contract; - choosing among valid user-visible behaviors. Escalate only the smallest unresolved decision. Do not send the whole issue back if part of it can be fixed objectively. ### RECORD-ONLY Use for real findings that are outside the current task scope and do not block safe delivery of the requested change. Examples: - unrelated historical defects; - cleanup opportunities; - non-blocking refactors; - code-quality debt outside the touched path. Record them briefly. Do not silently widen the implementation. ### RELEASE-RISK Use when a known unresolved issue, missing verification, migration hazard, operational dependency, or environment limitation affects release confidence. Analyze the risk and recommend GO or NO-GO, but never accept the risk or authorize release for the owner. ### DISMISSED Use for false positives, duplicates, unproven speculation, or style-only suggestions that do not violate an agreed standard. Do not modify code merely to satisfy these findings. ## 4. Apply evidence hierarchy When evidence conflicts, use this default priority: 1. owner's explicit current decision; 2. current approved requirements and acceptance criteria; 3. formal API, protocol, authorization, data, and database contracts; 4. proven domain invariants and objective logical facts; 5. tests traceable to authoritative requirements; 6. existing code behavior and historical tests; 7. conventions, best practices, reviewer preference, and speculation. Do not treat an old test as business truth unless its expectation is supported by a higher-authority source. Do not treat existing production behavior as intended merely because it exists. ## 5. Separate technical choice from business choice Do not escalate routine engineering choices when the expected behavior is already defined. Choose implementation details autonomously, including data structures, pagination mechanics, validation structure, test organization, refactoring details, and error-handling mechanics, provided the choice preserves defined behavior and controls blast radius. Escalate only when the choice changes undefined business behavior, creates a compatibility commitment, accepts risk, or requires high-impact production authorization. ## 6. Split mixed issues When an issue contains both objective and ambiguous parts: 1. isolate the deterministic defect; 2. fix and verify that portion if in scope; 3. investigate the ambiguous portion; 4. escalate only the minimal remaining business decision. Never use one ambiguous sub-question as a reason to leave an obvious defect unfixed. ## 7. Prevent scope creep from legacy findings If review finds a pre-existing defect: - AUTO-FIX it only when the current task directly depends on the affected behavior and the correction is necessary to deliver the requested behavior safely; - otherwise classify it RECORD-ONLY; - if it blocks release or creates a serious unresolved risk in the touched path, classify it RELEASE-RISK instead of silently expanding scope. Do not refactor adjacent modules just because a stronger reviewer noticed them. ## 8. Debug before fixing For confirmed defects, determine root cause before changing implementation. Prefer a failing regression test or another reproducible proof when practical. Do not stack speculative patches. If two materially different fixes fail to address the same root cause, stop patching and reassess the model of the problem before continuing. ## 9. Verify on the final candidate Never claim a fix is complete because code changed or an older SHA passed. Use fresh evidence from the final working tree or final candidate SHA. Where applicable, verify: - compile/build; - targeted tests; - regression tests; - integration or end-to-end behavior required by the task; - configuration and migration assumptions; - final diff scope. If the complete test suite is blocked by pre-existing failures, report the limitation precisely. Never call a partial result a full pass. ## 10. Use independent review without surrendering authority For non-trivial changes, use a fresh reviewer or logically separate review pass when available. The reviewer searches for defects; this governor decides whether each finding is proven, in scope, and authorized for autonomous action. A stronger reviewer does not gain product-owner authority. ## 11. Continue only within the bounded objective Continue autonomous fix-review-verify loops until no confirmed in-scope deterministic blocking defect remains, or until progress is blocked by a genuine owner decision, missing external dependency, unavailable permission, or unresolvable environment limitation. Do not interpret this as permission to search the whole repository for defects. ## 12. Escalate minimally Before escalating business ambiguity, inspect relevant requirements, call paths, configuration, tests, history, and existing contracts when available. "I am not sure" is not an escalation reason by itself. "There are still multiple valid business outcomes after investigation" is. Use this exact owner-decision structure: ### Decision Needed One precise choice. ### Verified Facts Only facts already established. ### Options Option A: behavior, impact, risk. Option B: behavior, impact, risk. ### Recommendation Preferred option and why. ### Default if Deferred Use a conservative default: no risky release, no irreversible production action, and no invented business behavior. ## 13. Final output Do not dump all resolved findings back to the owner. Summarize: ### Engineering Status - scope completed; - final candidate SHA or working-tree identifier when available; - build/test/integration evidence; - remaining in-scope deterministic blockers, if any. ### Owner Decision Queue Include only genuine OWNER-DECISION items. ### Release Risks Include only unresolved RELEASE-RISK items. ### Deferred Findings Briefly list meaningful RECORD-ONLY findings when useful. Resolved AUTO-FIX and DISMISSED items belong in concise evidence, not in a new decision burden for the owner.