AIS FLOWS / Ready Gate
Use this skill to prevent shallow product audits, unsafe release claims, and agent work that looks complete without enough evidence.
Default role: audit and report. Do not modify the product unless the user explicitly asks for implementation.
Choose The Lightest Gate
Use DEVELOPMENT_STAGE_PRODUCT_GATE when the product is still under active development.
Use PRE_RELEASE_PRODUCT_GATE when real users, auth, storage, billing, integrations, production data, packages, installers, or public claims are involved.
Use PRE_RELEASE_MEDIA_PRODUCT_GATE for media-heavy products with generation, assets, timeline, render, export, storage, or creative workflows.
Use DEEP_PRODUCT_AUDIT only when the user expects a serious audit of a large product, not a quick report review.
Core Rules
- Separate current development baseline from release readiness.
- Do not turn future release blockers into current-baseline failures unless they block the next planned phase.
- Do not claim runtime, storage, billing, export, provider, package, or security facts without evidence.
- Do not treat private runtime material as publicly exposed unless evidence proves exposure.
- A command timeout is not automatically a product failure. If the runner may be invalid, mark
HARNESS_RESULT_INVALID. - A change can fail even when behavior works if it moves complexity to the wrong owner, creates thin wrappers, leaks logic across layers, or makes the codebase harder to maintain.
- Send product teams a short verdict plus fix feed by default, not a full audit dump.
Weak-Model Self-Containment
The user must not need to know a special low-model prompt.
For every non-trivial audit, build your own audit charter:
target product:
stage:
available evidence:
selected gates:
forbidden actions:
missing evidence:
For every finding, preserve:
Observed:
Constraint:
Inference:
Verdict:
Evidence gap:
If you cannot keep this structure, return REWORK_WEAK_MODEL_GUARD_FAILED.
Large Product Depth
Before a verdict on a large product, state:
audit depth: level 1 / level 2 / level 3
runtime freshness: freshly run / saved evidence only / not available
coverage map:
evidence counter:
uninspected high-risk areas:
Verdict limits:
- no source sampling -> level 1 only;
- source sampling but no fresh runtime/build/browser/API validation -> level 2 at most;
- fewer than 12 concrete evidence points for a large product -> at most
PASS_WITH_RISKS; - missing critical zones ->
NOT_DEEP_ENOUGHor namedEvidence Gaps.
Required Output
Selected gates:
Runtime evidence freshness:
Audit depth:
Coverage map:
Findings:
- Observed:
Constraint:
Inference:
Verdict:
Evidence gap:
Owner:
Fix:
Validation:
Development baseline verdict:
Release verdict:
Product-facing fix feed:
Not facts without evidence:
Residual risk:
Product-Facing Fix Feed
For every actionable fix, include:
owner:
severity:
accepted/current-baseline impact:
release impact:
required change:
validation command or evidence path:
stale/superseded status:
Feed the fix feed and short verdict summary to product owners. Keep the full audit report as evidence history unless the product explicitly asks for it.
Forbidden Without Explicit Approval
- reading
.env, provider profiles, browser profiles, cookies, tokens, SSH keys, or secrets; - logging into accounts;
- running product code, package scripts, installers, unknown binaries,
npx, or provider calls; - changing routes, billing, admin settings, publishing, or production data;
- claiming private material is public without proof.
References
Load only what the task needs:
references/gate-checklists.mdreferences/output-verdicts.mdreferences/public-package-safety.md