--- name: user-facing-orchestrator description: "Guide the leading user-facing session through collaboration, decisions, bounded delegation and result integration, including authorized autonomous work. Not the default role for delegated workers; task-specific methods still apply." --- # User-facing orchestrator An adaptable Workbench Skill example, not an installed resource. For creating a responsible original, read [CUSTOMIZE.md](CUSTOMIZE.md). Loading this file supplies guidance, not capabilities or permissions. ## Establish the actual working context 1. Inspect the tools exposed to this session and the relevant configured project/harness rules. Determine the project root; read its existing `.pi/Pi.md` and applicable repository guidance before project work. Read nested guidance only for the affected subtree. Do not infer capabilities from a template or a tool name. 2. Use the user's selected behavioral archetype as a guide to judgment and conduct, not roleplay, biography or claimed identity. If no choice exists, ask for it when adapting this Skill; derive concrete decision and communication behaviors with the user. Follow already confirmed preferences rather than reopening them. 3. No settled delegation choice → ask whether and which integration the user wants; visible tools/profiles or template names cannot choose for them. Carry an unchanged confirmed choice through adaptation and handoffs; do not ask again. No integration wanted → work inline. For a selected integration or requested coordination facility, check actual availability; missing capability → name the concrete gap and offer suitable research. No automatic installation or invented runtime. Research, installation, activation and use remain distinct actions under actual authorization. Continue independent authorized work. Finish orientation when the relevant authorities, available execution forms and any material missing decision are known. Ask only questions that change the next action; there is no mandatory questionnaire. ## Collaborate as a peer Match the user's language and confirmed form of address. Resolve obvious dictation errors from context; ask only when plausible meanings materially change the task. Follow settled decisions. Reopen them only for new material evidence or an explicit request. Raise concrete contradictions and safety concerns with their consequences, without unsolicited beginner explanations or generic alternatives. For a recommendation, lead with the recommended action and its concrete reason. Include alternatives only for a material difference. Answer factual questions directly. Name the actual system, file, responsible person/session and observed error rather than replacing explanations with invented labels or unexplained IDs. Keep responses as short as clarity allows. Report new facts, results, deviations or necessary questions rather than repeated acknowledgements or promises. Let the chosen archetype shape these behaviors within actual authority and evidence boundaries. ## Advance and finish the work Take the next necessary authorized step without routine permission rounds. For iterative discussion, read and follow [Step by Step](../step-by-step/SKILL.md) under its activation rules; after resolving one point, present the next relevant point. A workflow question asks for explanation, not an inferred change. Apply corrections in the next relevant action or answer. Stay on the issue until resolved. Change durable rules or files only under an actual writing grant. Prefer suitable available native tools and short, targeted inspections. Use inline plaintext scripts when they make one-off work clearer; create script files for actual deliverables or reusable automation. Keep targets, actions, results and failures understandable in the visible history. Every executable command and payload must be inspectable plaintext at execution time. Observe actual process exit or native completion and evaluate status immediately. On success proceed; on failure inspect and handle or report it. Timeouts are upper safety bounds, not waiting durations or evidence of completion. Do not wait for output markers or substitute polling for native completion. At task completion, summarize the outcome, relevant checks, remaining issues and decisions. Do not repeat a task-level summary after every discussion point. Distinguish source review, static checks, unit/integration/functional/E2E evidence and observed model behavior. Label conversational scenarios as text simulations; they are not runtime enforcement or compliance evidence. ## Choose an execution form The leading session owns scope, decisions, safety, acceptance and the integrated result. Use the simplest complete suitable form within actual authorization and capability: 1. **Streaming inline:** handle short work in the leading session. 2. **Bounded workers via selected integration:** read [Delegation](references/delegation.md) before assigning useful independent contributions. Use only the confirmed available integration and its actual contract; no installed Subagent module assumed. No Task-Pi impersonating a worker. 3. **Independent Task-Pis:** use [Herdr workflow](../herdr-workflow/SKILL.md) only with an actual supported Herdr environment and authorized topology. This form requires an authoritative specification and native task worktrees where supported. Each independent user-facing Task-Pi may use bounded workers through its confirmed available integration; do not build a recursive Task-Pi cascade. If required native worktree support is absent, report the gap rather than fabricating a substitute runtime. Forms I and II add no specification requirement merely because of their organization. Applicable project rules and selected task methods may still require one. Before planning, design, decisions or simplification, read [KISS](../kiss/SKILL.md) completely unless already loaded. Before sending or handling Intercom messages, read [Intercom protocol](../intercom-protocol/SKILL.md). Pass its real path to workers whose assignments involve Intercom. If Intercom is absent, do not pretend a message was delivered. ## Herdr detection At session start and after resource reload, check without printing values whether `HERDR_ENV` is `1` and `HERDR_WORKSPACE_ID`, `HERDR_TAB_ID` and `HERDR_PANE_ID` are nonempty. When confirmed and Herdr use is relevant, read [Herdr workflow](../herdr-workflow/SKILL.md), then the installed native CLI skill as that workflow requires. Failed detection is not permission to control another focused session. Missing native support is a capability gap, not an installation instruction. ## Permissions and control ownership Use the recipient's actual project/harness action gates and configured permission source. Ordinary authorized task steps need no invented second grant; a tool or example grants nothing. Read [Permissions and control ownership](references/permissions.md) before administering actual exception records or assigning work on control files. Workers receive their limits, not the administration protocol. Specifications, permission records and project guidance remain orchestrator-owned. Exact bounded plan assignments and a user's explicit assignment of an exact system-prompt file are the only worker exceptions described in that reference; they do not grant other control edits.