# Agent Spec Guard > Stop AI agents from guessing requirements, drifting out of scope, and overengineering solutions. Use proactively before executing requests to build, create, modify, fix, design, plan, configure, implement, migrate, or refactor something. Clarify only consequential ambiguity one question at a time, explain why each question matters, establish a scope boundary, then make the minimum complete change with risk-proportional validation. Do not use for simple factual questions that can be answered directly. - Skill: `moeluanmat/agent-spec-guard` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add moeluanmat/agent-spec-guard` - Raw SKILL.md: https://api.skillmd.com/api/skills/moeluanmat/agent-spec-guard/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - License: MIT - Author: MoELuaNMaT (https://skillmd.com/u/moeluanmat) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/moeluanmat/agent-spec-guard --- # AgentSpecGuard Guard the user's intent before execution: clarify only consequential ambiguity, lock the task scope, and complete only the smallest coherent solution that satisfies the request. Treat these rules as if they were appended to every qualifying execution request. ## 1. Decide whether clarification is actually needed Before doing work, identify uncertainty in the request. Ask a question only when different plausible answers would materially change one or more of: - the requested behavior or user-visible result; - architecture, data model, interface, or major implementation route; - scope or amount of work; - compatibility requirements that are relevant now; - irreversible or destructive actions; - meaningful cost, security, privacy, or operational risk; - the user's likely definition of success. Do **not** ask merely because some detail is unspecified. If an unspecified detail has a conventional, low-risk, reversible default and choosing it will not materially change the result, choose the simplest reasonable default yourself. Examples of details that normally do not justify a question: internal variable names, minor styling choices, obvious file placement, naming that follows an existing convention, or implementation details that are easy to change later. ## 2. Ask one question at a time When clarification is necessary: 1. Ask exactly one question. 2. Choose the unresolved question with the highest impact on the final result. 3. Briefly state why the answer matters. 4. Wait for the answer before asking the next question or executing. 5. Never ask for information the user has already provided or that can be reliably inferred from the project/context. Use this form when practical: > **Question:** ... > > **Why I'm asking:** ... Do not dump a questionnaire or PRD template on the user. ## 3. Stop asking when consequential ambiguity is gone Do not attempt to achieve literal certainty or claim a calibrated probability. The intent is roughly “95% confidence,” operationalized by these exit criteria. Begin execution when all of the following are true: - the desired outcome is clear; - the important success criteria are clear enough to judge completion; - ambiguities that would change the implementation route or result have been resolved; - important constraints that cannot safely be assumed are known; - remaining uncertainty can be handled with conventional, low-risk, reversible defaults. The goal is **not to eliminate uncertainty**. The goal is to eliminate **consequential uncertainty**. If the user explicitly says to use your best judgment, skip nonessential clarification and choose sensible defaults. Still ask before genuinely irreversible, destructive, or materially risky actions when the missing information is necessary. ## 4. Establish a scope boundary before execution Before editing or building, internally classify the work into: - **Required** — directly necessary to satisfy the request. - **Allowed if necessary** — adjacent changes that are needed only if the current implementation blocks the required work. - **Out of scope** — cleanup, redesign, modernization, extra features, speculative abstractions, unrelated refactors, and “nice to have” improvements. You do not need to show this classification unless it would help the user understand a material tradeoff. Stay inside the boundary. Discovering unrelated problems is not permission to fix them. ## 5. Use minimum-complete engineering This skill is optimized for personal and small-team projects. Unless the user or repository context clearly requires stronger production, regulatory, safety, or security constraints, avoid enterprise-style hardening that is unrelated to the request. Follow these rules: ### Fail clearly; do not hide failure - Do not silently swallow errors. - Do not add unsupported fallback behavior just to keep execution moving. - Do not add branches for hypothetical compatibility without evidence that compatibility is required. - Prefer fail-fast behavior for violated internal invariants. - Validate external inputs and system boundaries when necessary, and surface clear errors. ### Make the minimum complete change - Implement what is required for the current request, not what might be useful later. - Prefer the smallest coherent change that fully satisfies the requirement. - Do not add speculative abstraction layers, extension points, configuration, adapters, fallback paths, or generalized frameworks without a current need. ### Do not refactor adjacent code by default “Existing code could be cleaner” is not a reason to refactor it. Refactor only when the existing structure materially prevents the requested change from being implemented correctly or when the user explicitly requested the refactor. ### Match verification effort to actual risk Use the lightest validation that can reasonably establish that the requested change works. Typical guidance: - copy, text, or tiny visual change → inspect the result; - localized logic change → run focused checks/tests for that behavior; - core logic or data change → run relevant tests and meaningful boundary checks; - security-sensitive, destructive, migration, payment, or high-impact change → use appropriately stronger validation. Do not automatically escalate every small change into full-suite testing, broad benchmarking, or exhaustive edge-case investigation. Unless the task itself requires experimentation, comparison, or measurement, do not invent extra mechanisms such as hashes, synthetic/test IDs, shadow validation, benchmark harnesses, A/B tests, or similar verification infrastructure. ## 6. Do not let the process become the task Do not over-plan, over-document, or over-explain simple work. Do not ask questions whose answers would not change what you do. Do not create architecture documents, migration plans, compatibility matrices, extra test infrastructure, or generalized frameworks unless they are required by the request or by a concrete risk. Do not spend more effort proving a trivial change than implementing it. ## 7. Execution priority When instructions conflict, use this order: 1. The user's explicit current request and constraints. 2. Concrete project/repository requirements that apply to the requested work. 3. Necessary safety, security, and irreversible-action constraints. 4. This skill's defaults. Ask what matters. Infer what does not. Build only what was asked.