wastech-orchestrator

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.

Convert a set of related steps into wastech-orchestrator's operator-authored decomposition — one root task with a subtasks: list plus per-subtask spec files, run sequentially on one branch / one PR. Use when a change is one coherent unit you already know how to split into ordered steps that should land together.

Convert a raw, free-form task into a valid wastech-orchestrator task file (YAML front matter + Description / Acceptance criteria / Constraints), staged in tasks/preparing/ and promoted to tasks/pending/. Use when you have an informal task — a paragraph, a ticket, a Slack message — and want a ready-to-run task file the orchestrator will accept.

Before implementing new functionality, decide whether a focused refactor of the code the feature will touch should happen FIRST. Assesses the health of the area the feature lands in (coupling, duplication, oversized units, missing seams, weak tests, drifted names, near-violations of the architecture rules) and weighs the technical-debt cost of building on it as-is versus cleaning it up first. Analysis-only — recommends refactor-first / refactor-after / no-refactor with a bounded scope, the risk of skipping, and trade-offs; writes no code. Bounded by YAGNI: only refactor what this concrete feature touches. Use after the task is understood and before implementation.

Before writing code, at the requirements/design stage, find the simplest sound approach for the agreed task. Scrutinizes the proposed technical plan against the codebase for unrequested complexity (speculative generality, premature abstraction/config, extra layers) and shapes it for code quality and maintainability via clean seams — extensibility through simplicity, not speculation (YAGNI). Analysis-only — recommends an approach and trade-offs, writes no code. Use after the task is understood and before implementation. Run /clarify-task first if the goal or scope is still unclear.

Run all quality checks for wastech-orchestrator (ruff, mypy, import-linter, interrogate, vulture, deptry, pytest) and report briefly. Use before a commit, before a PR, and before moving to the next implementation stage.

Post-mortem a completed orchestrator task run on a TARGET repo to improve execution quality. Ingests everything the run left behind under the target's `.worc/` — the ledger, per-node logs, prompt-audit, rendered prompts, the committed diff, and the `state.db` audit tables — then cross-references the orchestrator's own source of truth (packaged flows, role prompts, config defaults, model/reasoning resolution) to find concrete improvement points. Produces a prioritized report that maps each finding to the exact lever to change — a role prompt, a flow node's provider/model/reasoning, a config key, the flow graph, or the prompt-building code. Read-only / analysis: it proposes changes, it does not apply them. Run it FROM the orchestrator repo, pointing at the target repo (or a task id). Use after a run finishes (success or failure) to tune prompts, configuration, and model selection.

After implementation, verify the change is no more complex than the task actually required. Flags unrequested complexity (speculative generality, premature config/abstraction, back-compat/migration scaffolding, over-broad error handling, duplication, dead code) and KISS/DRY violations in the diff. Review-only — reports findings and simpler alternatives, does not edit. Use after finishing a task or stage, before a commit or PR, to catch over-engineering nobody asked for.

Scaffold deterministic fake CLI executables and pytest fixtures that stand in for the real Codex/Claude binaries in provider integration tests. Use when adding integration coverage for a provider adapter, the router, or the pipeline (phases 2–5) — success and every infrastructure failure scenario.

Run and diagnose the wastech-orchestrator pytest suite during development — full, targeted, or last-failed — to keep the suite green and find bugs while implementing. Use while writing/changing code (the dev test loop). For the full pre-commit gate (ruff + mypy + pytest) use /run-checks instead.

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.