القائمة
Use when determining how an AI coding agent can autonomously run and verify a specific user flow end to end before implementation.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Extract decisions, action items, new context, and insights from the current session into LEARNINGS.md and auto-memory. Run before ending any substantive conversation.
Capture a lightweight work item into BUGS.md, NEXT_STEPS.md, DEFERRED.md, or recommend the feature workflow. Use when a bug, fix, small follow-up, next step, deferred idea, or possible feature comes up during development.
Use when seeking a second opinion from OpenAI Codex on documents, specs, plans, or other non-code-diff content.
Use when delegating code implementation to Codex CLI with Claude-managed decomposition, context scoping, and verification.
Use when requesting an OpenAI Codex review of the current branch with documentation research and cross-AI verification.
Detect split data source anti-patterns and scattered business rule duplication where the same logic is reimplemented across multiple files and languages. Catches semantic duplication that syntactic tools like jscpd miss. Use at phase checkpoints or when investigating data consistency issues.
| name | discover-flow-verification |
| description | Use when determining how an AI coding agent can autonomously run and verify a specific user flow end to end before implementation. |
Reach a shared answer to: what would an AI coding agent need in order to run this user flow itself and know whether it worked?
Stay in discovery mode unless the user explicitly asks to implement the harness. The output should be a concrete verification plan, not a generic E2E checklist.
Write the candidate flow in plain user language:
A <user/integration/agent> can <action sequence>, and then <observable product outcome> is true.
If the flow is too broad, narrow it to the first valuable slice the agent should be able to verify.
Decide which channel must actually work for the claim to be true:
Do not substitute an easier adjacent channel. For example, if the product claim is "developers integrate through MCP," the verification must drive an MCP client. If the claim is "CLI retrieves imported messages," the verification must spawn the CLI and inspect its output.
List what the agent currently cannot prove unaided:
This list usually determines the harness design.
For each required state source, decide how the agent can control it:
The target is not perfect realism. The target is enough realism that the agent can catch the failures that matter for this flow.
Define what the agent must assert from outside the implementation:
Include negative assertions when they matter, such as no duplicate imports, no leaked secrets, no human account use, or no stale state after rerun.
Explain how the verification can be torn down and recreated repeatedly:
If repeatability is not possible yet, name the blocker and the smallest prerequisite feature.
When the discussion has enough information, produce a concise plan with:
Do not include implementation tasks until the user asks to build it.
A good result lets a future AI coding agent say:
I can run <exact command or steps>, observe <evidence>, and decide pass/fail for <specific flow> without using a human's private state or asking for manual interpretation.
If the plan does not reach that bar, continue discovery instead of pretending the harness is defined.
When invoked by another skill, finish with:
FLOW_VERIFICATION_DISCOVERY_RESULT
==================================
Status: APPLICABLE | NOT_APPLICABLE | BLOCKED
Flow: {flow claim}
Harness: {recommended harness shape, or none}
Command: {rerunnable command, or not defined}
Issue: {only when BLOCKED}