菜单
Before starting work, ask the user clarifying questions to surface contradictions, cut overkill, find the task's true goal and boundaries, and reach a shared understanding. Use at the start of any non-trivial task, or whenever the request is vague, contradictory, or too broad.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Implement a task in wastech-orchestrator end to end — a backlog ADR (docs/backlog/), a follow-up, or a free-form request — driving it through the project's own workflow (understand → shape → plan → build → check → sync docs → review → commit) while enforcing the hard invariants. Use when the user says "implement X", "build the ADR for Y", "do the backlog item Z", or hands you a task to carry out in this repo. Orchestrates the sibling skills (/clarify-task, /assess-refactor, /simplify-task, /run-checks, /sync-docs, /simplify-review); it does not replace them.
After a behavior/CLI/config/architecture change in wastech-orchestrator, bring the docs and the follow-ups tracker in sync with the code. Use after implementing a change (the Stop docs-sync gate reminds you), before a commit, or whenever the docs no longer match the code.
Write or revise a single flow node's role prompt (`role_file`) for wastech-orchestrator — the Markdown text that becomes that node's instructions — honoring the node's typed output contract and the `{name}` variable allowlist. Use when you want to change what a step says without changing the graph; author a whole new flow with worc-flow, or repoint a step's provider/model with worc-flow-tune.
Author a new custom flow for wastech-orchestrator — a validated graph of typed nodes saved as `.worc/flows/<task_type>.yaml` with its own prompt folder, that a task selects by `task_type`. Use when you need different steps, a different output kind, or a different route than a built-in flow gives you — not to change what one step says (that is worc-flow-role) or which model a step uses (that is worc-flow-tune).
Tune an existing wastech-orchestrator flow's per-node execution knobs — which `provider`/`model`/`reasoning` a step runs on, plus `timeout_seconds`, `network_access`, `extra_args`, and the flow's loop `budgets` — without changing the graph or the prompts. Use when a step should run on a different provider or effort; author a new flow with worc-flow, or reword a step with worc-flow-role.
Build or revise a wastech-orchestrator `config.yaml` for a specific repository. Use when an operator wants help choosing providers, checks.command_sets, Git publishing, Telegram, or safe defaults for their repo, and wants a ready-to-edit config with the orchestrator's security invariants preserved.
| name | clarify-task |
| description | Before starting work, ask the user clarifying questions to surface contradictions, cut overkill, find the task's true goal and boundaries, and reach a shared understanding. Use at the start of any non-trivial task, or whenever the request is vague, contradictory, or too broad. |
This skill helps you not rush into doing, but first understand the task together with the user. The goal: both the agent and the user see the task the same way, in the same words, and drop the unnecessary parts up front.
Speak in simple, plain language, in the user's language (default to the language they wrote in), with minimal technical detail. Imagine explaining to a smart person who is not a programmer.
If the task is small and unambiguous — don't ask questions for the sake of it, just do it.
Restate in your own words. Say back what they're asking for, in your own words. Ask: "did I get this right?" This catches mismatched understanding immediately.
The true goal. Not "what to build" but "why". What problem does this solve? Who is better off, and how exactly? Ask "why" as many times as needed to reach the real reason.
Definition of success. How will we know the task is done well? What should become visible or measurable? If you can't name a criterion, the goal isn't clear yet.
Contradictions. Find where requirements fight each other (fast and cheap but perfect; simple and flexible at once). Name the contradiction out loud and ask which matters more.
Boundaries (what is NOT included). Spell out clearly what the task does not cover. This is often more important than the list of what it does.
Overkill. For each non-obvious item ask: "is this really needed now?" Separate "must" from "nice to have". Offer a simpler path if one exists, and show what the complex one costs.
Shared words. If the user and you mean different things by a word, lock in one shared meaning. From then on, use only that.
Pull together a short summary in plain language (5–8 lines):
End with a direct question: "Shall we proceed like this?" Do not start work until the user confirms the summary.
