Execution Guardrails

Execution Guardrails

Shared quality floor for the workflow. This skill does not replace a stage's primary skill; it reinforces how work should be carried out across brainstorm, spec, plan, TDD, and review.

When to Use This Skill

Use this skill when:

• an agent is guessing instead of clarifying
• a plan or implementation is growing more abstract than the requirement justifies
• a diff starts touching unrelated code, comments, or formatting
• success criteria are vague ("make it work") and need to become testable
• you want an explicit quality reset before handing work to another agent

Four Shared Guardrails

1. Assumptions explicit
   Separate facts, assumptions, and unknowns. If ambiguity materially changes the approach, stop and clarify or label the assumption.

2. Simplicity first
   Implement the smallest solution that satisfies the current requirement. Do not add speculative flexibility, abstraction, or configuration for future possibilities.

3. Surgical changes
   Touch only what the request requires. Clean up only the dead code your change creates. Do not perform drive-by refactors.

4. Verifiable success criteria
   Convert work into checks: tests, assertions, or explicit manual verification. Avoid vague definitions of done.

Anti-Hallucination Checks

Activate these additional checks before finalizing any artifact that downstream agents or humans will treat as authoritative (spec, plan, test-plan, impact analysis):

5. Negative Space Check
   List all content in this output that the user may NOT have explicitly requested. Label each item [USER_REQUESTED], [INFERRED], or [ADDED_BY_AI]. Any [ADDED_BY_AI] item without justification is a Source Fabrication risk — surface it before proceeding.

6. Reference Grounding
   For every external function, API endpoint, library, standard, or service cited: state your confidence it exists (HIGH / MEDIUM / LOW / UNVERIFIED). Surface all [UNVERIFIED] references to the user before treating them as actionable.

7. Confidence Flagging
   Mark any statement you are less than 80% confident about with [UNCERTAIN]. Do not omit this step because the artifact looks internally coherent — coherence does not equal factual accuracy.

How to Apply by Stage

• Brainstorm: separate confirmed requirements from assumptions; avoid prematurely collapsing options into one interpretation.
• Spec: keep assumptions, non-goals, and unresolved questions distinct from requirements and acceptance criteria.
• Plan: plan only current scope; every step needs a verification method; call out assumptions that could invalidate multiple phases.
• Code / TDD: prefer the smallest diff that makes the target test pass; reject speculative abstractions and unrelated edits.
• Review: explicitly flag hidden assumptions, overengineering, and diff-scope drift when present.

See:

• Stage usage guide
• Anti-patterns and corrections

Relationship to the Existing Workflow

Use this layering model:

1. Agent — who does the work
2. Primary skill — the main methodology for that stage
3. Execution guardrails — shared constraints on how the work is performed
4. Quality gate — agentic-eval / gate-check before handoff

Operationally:

• the always-on core lives in copilot-instructions.md and core agents
• this skill is the manual fallback / explicit reload
• agentic-eval rubrics score whether the resulting artifact is safe to hand off

Manual Invocation Examples

CLI

/execution-guardrails check this plan for hidden assumptions and speculative scope
/execution-guardrails review this diff for unrelated edits and overengineering
/execution-guardrails help me turn this vague goal into verifiable success criteria

VS Code

/execution-guardrails review this spec for assumptions vs confirmed requirements

Recommended Output Format

When using this skill directly, structure the response as:

1. Assumptions / Unknowns
2. Simplicity Risks
3. Scope / Diff Hygiene Risks
4. Verification Gaps
5. Source Fabrication Risks (negative space items tagged [ADDED_BY_AI])
6. Unverified References (library functions, APIs, services tagged [UNVERIFIED])
7. Uncertain Statements (items tagged [UNCERTAIN])
8. Recommended correction

Keep corrections targeted. Do not rewrite the entire artifact unless the user asks.

Common Rationalizations

在執行護欄約束過程中，AI 可能以下列藉口繞過核心規則：

Verification

在完成任何有護欄約束的任務前，逐項確認（Gate = 交付前閘門；Verification = 自我完成確認）：

• 所有假設均已明確標記並向使用者確認（無隱性假設）
• git diff --stat 確認只有預期範圍內的檔案被修改
• 無投機性抽象（未來可能有用的功能 / 介面 / 擴充點）被加入
• 每個被修改的行均可溯源至使用者請求的具體部分
• 所有 [ADDED_BY_AI]、[UNVERIFIED]、[UNCERTAIN] 標記已解決或向使用者說明
• 成功標準已具體化（可驗證的測試輸出 / 靜態確認），非意圖性描述
• Financial Precision 守則已確認（若涉及金融領域）：無 float/double 用於金錢