القائمة
Use after intent routing only when unresolved requirements, product intent, architecture, constraints, or tradeoffs can materially change scope, risk, acceptance criteria, or user-visible behavior. Inspect discoverable facts first and avoid exhaustive questioning.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use for an actual ready, non-draft GitLab merge request review, re-review, or approval decision when current discussions, diff, CI, scope, findings, and approval state must be checked. Do not trigger for casual MR discussion, draft/WIP work, GitHub PRs, or local code review.
Use at conversation start, after context recovery, and for non-trivial engineering work to select exactly one primary workflow path plus one task-wide assurance and verification budget. Loading this router does not create artifacts, launch agents, or activate every workflow module.
Use only when creating, resuming, inspecting, updating, completing, or writing artifacts for an authorized .workflow plan or audit run through the bundled Workflow MCP tools. It is an operations contract, not a reason to create workflow artifacts.
Use when an authorized, sufficiently clear change needs a durable decision-complete plan under .workflow because execution is multi-step, risky, resumable, or explicitly requested. Do not create a plan for fast local work or read-only discussion.
Use at conversation start, after compaction or context recovery, and before Agent Memory reads or writes to decide whether durable global or project knowledge can materially change the task. Keep startup reads focused, and do not mutate memory during read-only or no-edits work unless the user explicitly asks to remember something.
Use to execute an approved active .workflow plan with milestone state updates, scoped task ownership, compaction recovery, selective worktree delegation, and one integration path. Do not use for direct fast-path work without a durable plan.
| name | context-discovery |
| description | Use after intent routing only when unresolved requirements, product intent, architecture, constraints, or tradeoffs can materially change scope, risk, acceptance criteria, or user-visible behavior. Inspect discoverable facts first and avoid exhaustive questioning. |
Gather only enough context for a confident execution decision or decision-complete durable plan. Ask only questions whose answers can change scope, architecture, risk, acceptance criteria, or user-visible behavior.
Do not ask for discoverable facts, preferences that do not affect the result, or exhaustive edge cases outside the requested scope.
fast: inspect the diff or named surface, at most five relevant files, and at most three targeted searches.standard: start from the named surface and stop by twelve files or about 50 KB of new tool output unless a concrete unresolved dependency justifies widening.assurance or explicit audit: declare the extra surface before widening and keep each pass tied to a named risk.Do not list or read the whole repository without a named unknown that requires it. Stop when the direct implementation path and affected tests are known. A small user correction reopens only the touched surface; it does not restart discovery.
When feasibility is genuinely uncertain, state the uncertainty and run one disposable experiment or read-only investigation. Use up to three only for distinct unknowns. Record evidence in an active plan when one exists; otherwise summarize in chat. A spike must not drift into production implementation.
Before continuing, capture only the decisions needed by the next step: goal, success criteria, scope/non-goals, constraints, material risks, and unresolved questions. Do not create workflow artifacts unless a durable path is authorized.