zai-grounded

name	zai-grounded
description	Reliability gate for answers. Forces evidence-based reasoning, explicit uncertainty, and “insufficient information” instead of guesses. Use when user says “be 100% sure”, “no hallucinations”, “only if verified”, “grounded answer”, or when stakes are high.
argument-hint	[question or task]
allowed-tools	Read Write Edit Glob Grep Bash AskUserQuestion Questions
disable-model-invocation	true

Language and Coding Standards

• Communication: Always talk in Thai when interacting with users.
• Code & Technical Assets: All code, comments, documentation, and technical definitions must be in English.

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.

ZeaZ Platform & apps/* Monorepo Rules

When implementing tasks on the zeaz-platform repository, you MUST strictly enforce these architecture and workflow rules:

1. Monorepo Architecture (apps/*): The platform is a unified monorepo. ALL applications, microservices, frontends, and AI toolings (e.g., zLinebot, zwallet, zdash) reside inside the apps/ directory. Do not create top-level directories for apps. When refactoring or adding features, always scope your work to the specific apps/<app-name>/ folder.
2. Environment Variables: Avoid scattering .env files. Consolidate environment variables into a central .env.example inside the respective app folder. Canonical Cloudflare variables (e.g. CLOUDFLARE_API_TOKEN, CLOUDFLARE_ZONE_ID) MUST be used instead of legacy CF_ variants.
3. Commit Workflow: NEVER use git commit or git push directly. ALWAYS stage your intended files with git add and commit using make gpg-finalize COMMIT_MSG="..." from the repository root to ensure all GitOps and DevSecOps checks pass.
4. Security: NEVER commit or generate real secrets. Unsafe placeholders like test-secret-value-value-value, test-secret-value-value-value, test-secret-value-value-value are FORBIDDEN.
5. Language: Code, documentation, and technical definitions MUST be in English.

Workflow

Step 0: Load Skill Context

Read .ai-factory/skill-context/zai-grounded/SKILL.md — MANDATORY if the file exists.

This file contains project-specific rules accumulated by /zai-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:

1. Repo-grounded — can be answered purely from the local codebase and command outputs.
2. Doc-grounded — requires authoritative docs/specs/logs provided by the user or accessible tooling.
3. 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.