Grounded - Reliability Gate (No Guessing)
This skill minimizes random / fabricated answers by enforcing a strict rule:
Only provide the final answer if confidence is 100/100 based on evidence available.
If confidence is not 100, do not guess and do not implement. Output a short “what’s missing” checklist that explains what would be required to reach 100.
When to use
Use when:
- The user requests maximum reliability (“only if you’re sure”, “no assumptions”).
- The request includes changeable facts (versions, “latest”, policies, prices, schedules).
- The request is security/finance/legal/medical adjacent (high stakes).
- You’re resuming after context loss and need to avoid accidental assumptions.
Workflow
Step 0: Load Skill Context
Read .ai-factory/skill-context/aif-grounded/SKILL.md — MANDATORY if the file exists.
This file contains project-specific rules accumulated by /aif-evolve from patches, codebase conventions, and tech-stack analysis. These rules are tailored to the current project.
How to apply skill-context rules:
- Treat them as project-level overrides for this skill's general instructions
- When a skill-context rule conflicts with a general rule written in this SKILL.md, the skill-context rule wins (more specific context takes priority — same principle as nested CLAUDE.md files)
- When there is no conflict, apply both: general rules from SKILL.md + project rules from skill-context
- Do NOT ignore skill-context rules even if they seem to contradict this skill's defaults — they exist because the project's experience proved the default insufficient
- CRITICAL: skill-context rules apply to ALL outputs of this skill — including the response format, evidence requirements, and confidence assessment. If a skill-context rule says "analysis MUST include X" or "confidence MUST account for Y" — you MUST comply. Producing an analysis that ignores skill-context rules is a bug.
Enforcement: After generating any output artifact, verify it against all skill-context rules. If any rule is violated — fix the output before presenting it to the user.
Step 1: Classify the request
Classify into one of:
- Repo-grounded — can be answered purely from the local codebase and command outputs.
- Doc-grounded — requires authoritative docs/specs/logs provided by the user or accessible tooling.
- External-facts — depends on changeable facts outside the repo (must be verified, otherwise refuse).
Step 2: Define evidence and unknowns
Before answering, list:
- Evidence sources you will use (files, command outputs, provided docs).
- Unknowns (anything not present in evidence).
Hard rule:
- If a claim is not supported by evidence, it becomes an unknown (not an assumption).
Step 3: Mandatory verification for changeable facts
If the request contains any changeable fact (“latest”, “current”, “today”, “default in vX”, “does library Y support Z now”):
- Verify via authoritative docs/specs, release notes, or logs.
- If verification is not possible with available tools/context, return INSUFFICIENT INFORMATION and ask for the needed source (link excerpt, version, log output).
Step 4: Confidence gate
Compute a confidence score 0–100:
- 100 only if every factual claim is supported by evidence you can point to (repo files, command outputs, provided docs), and there are no open unknowns.
- If any unknown remains → confidence < 100 → do not answer/implement.
Step 5: Output format (strict)
If confidence is 100:
Answer:
<final answer or patch summary>
Confidence: 100/100
Evidence:
- <file/command/doc used>
Checks:
- <3 concrete checks someone can run/inspect to confirm>If confidence is < 100:
Result: INSUFFICIENT INFORMATION (no guessing)
Current confidence: <N>/100
Why not 100:
- <top reasons>
Missing evidence:
- <what exact file/output/doc is needed>
To reach 100:
- <1–3 concrete asks or commands for the user to run and paste output>Artifact Ownership and Config Policy
- Primary ownership: none. This skill is a reliability gate for answers, not an artifact-producing workflow.
- Write policy: do not create or modify project artifacts by default.
- Config policy: config-agnostic by design. Evidence comes from the repo, command outputs, provided docs, and authoritative sources, not from
config.yaml.
Implementation guardrail
If the user asks for code changes:
- You may explore the repo and propose what evidence is needed.
- Only apply patches once confidence can be 100 (e.g., requirements are precise + you can verify build/tests or equivalent checks).
- If the repo lacks a verification path (no build/tests and behavior can’t be validated), do not claim 100; return INSUFFICIENT INFORMATION and propose the minimal validation needed.