القائمة
Use before saying development work is done, or when choosing project-shaped tests/checks to prove code behavior, bug fixes, refactors, config, infrastructure, or UI changes.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when a development task is unclear, multi-step, risky, or needs coordinated gates for shared understanding, research, parallel lanes, workflow artifacts, and verification. For a single concern, use the matching gate skill if available; for tiny mechanical changes, skip unless the user asks.
Use when development work has independent lanes for research, codebase exploration, inventory, validation, review, or non-overlapping implementation that can run in subagents, parallel tool calls, or separately owned workstreams.
Use when development work is large, risky, multi-session, multi-agent, interrupted, or needs durable plan/handoff memory for continuity across coding agents.
Use when development work depends on current or external facts: latest docs/APIs, library or platform behavior, security guidance, unfamiliar errors, migrations, comparisons, best practices, prior art, or known fixes.
Use when a development request is vague, exploratory, conflicted, under-specified, or the user says they are unsure, wants to be grilled, wants assumptions challenged, or needs goal, scope, constraints, and success criteria clarified before planning or implementation.
Pi-only web research workflow for environments that have pi-9router-ext and a subagent extension such as @tintinweb/pi-subagents configured. Use this skill when the user explicitly asks to use 9router, pi-9router-ext, ninerouter tools, or a 9router route/combo for web research, or when project/user instructions state that 9router-web-researcher is the preferred research stack. Do NOT use for ordinary web research in standard shared-mcp-only or non-Pi clients; use web-researcher instead. This skill always delegates research lanes to subagents and then synthesizes compact cited findings.
| name | verification-gate |
| description | Use before saying development work is done, or when choosing project-shaped tests/checks to prove code behavior, bug fixes, refactors, config, infrastructure, or UI changes. |
Never call work done without evidence or an explicit unverifiable reason.
First inspect the repo's verification culture:
terraform fmt, terraform validate, terraform plan, policy checks, or dry runs.Use TDD when the project structure supports it and the change is behavioral enough to benefit. Do not introduce a new test framework just to satisfy this workflow unless the user approves.
Ask the user for manual verification only when credentials, protected environments, real devices, or subjective product judgment are required.
The gate passes only when every relevant changed surface has a chosen check or an explicit unverifiable reason; all run checks pass, or each failure is classified as existing, unrelated, environment-blocked, or intentionally accepted by the user; change-caused failures are fixed and rerun or the work is stopped as blocked. The final report lists commands/checks, results, manual checks, gaps, and residual risk.