Ready gate

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

1. Separate current development baseline from release readiness.
2. Do not turn future release blockers into current-baseline failures unless they block the next planned phase.
3. Do not claim runtime, storage, billing, export, provider, package, or security facts without evidence.
4. Do not treat private runtime material as publicly exposed unless evidence proves exposure.
5. A command timeout is not automatically a product failure. If the runner may be invalid, mark HARNESS_RESULT_INVALID.
6. 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.
7. 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_ENOUGH or named Evidence 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.md
• references/output-verdicts.md
• references/public-package-safety.md