/first-task

name: first-task
description: >
  Guide the user's first Paperclip task when its description invokes /first-task.
  Interpret the opening answer, clarify their goal, propose a plan or a single
  task, and wait for approval before hiring agents or executing approved work.

First task

Use this workflow only for the onboarding task that invokes `/first-task`, including later replies and approval wakes on that same task. Do not apply it to the agent's other tasks just because this skill is installed. Follow it without announcing the first-task skill in routine messages, cards, or documents. Say "I'm doing X," not "I'm using the first-task skill to do X," and explain next steps directly. This is a wording preference: answer truthfully if the user asks about the workflow, and always disclose relevant permissions, security implications, and execution actions.

**Talk in outcomes.** The user is new to Paperclip. In chat replies, cards, and task text, say what happened, what it means for them, and the next step. Never narrate internal mechanics such as receipts, execution policies, patches, runs, wake payloads, tool calls, or raw IDs, and name tasks by identifier (for example PIX-3), not UUID. If a step did not work, say plainly what is not done yet and what you will do next; keep the technical detail out of the message.

This is the user's first task in Paperclip. Your job is to understand what they want and propose a path forward. A greeting and an opening question card were already posted for you; the card offered two choices: "Interview me and propose a plan and an agent team to execute it." (option `interview`) or "I have a task in mind" (option `task`, with a text field). You are running because the user answered that card (the answer is in your wake payload) or wrote a message instead of answering. Don't re-introduce yourself and don't post the opening card again.

Work in this order.

1. Take the path the user picked.

• `interview` → ask the user 3–4 questions in one Paperclip question card (`request_human_input` with `interactionKind: "questions"` when available, otherwise the `ask_user_questions` API) that pin down what their organization does, what they want to achieve first, any constraints (time, budget, tools), and what "done" looks like. Don't guess; ask. Don't post anything else before the card. The answers lead to the plan-and-team path in step 2.

• `task` → the text they typed is the task. If it is clear enough to propose on, go straight to step 2. If not, reply by asking 2–3 questions specific to their message (concrete goal, constraints, what "done" looks like), then go to step 2.

• If they wrote a message instead of answering the card, treat the message as the `task` path.

• Determine the requested outcome before choosing an approval boundary. The interview path and requests to build, improve, or deliver something are execution requests: the plan is an intermediate artifact. Treat a request as plan-only only when the user explicitly limits the deliverable to planning. Asking to review a plan before work begins does not make it plan-only. Preserve any separate hiring or execution approvals the user explicitly requests and any applicable company policies.

• If the user asks to continue onboarding in your chat with them instead, ask your questions there. Your first question in the chat replaces this task's pending question cards, and Paperclip closes this task with a link to the chat. From then on the chat replaces this task for the rest of this workflow: save the plan and post proposal cards in the chat, create accepted execution tasks from the chat, and report their results there. Skip the steps below that keep this task `in_review`, save documents on it, or make it wait for a child. Do not reopen this task or ask the user what should happen to it.

2. Propose, then wait for acceptance.

• Choose the proposal form from the user’s request first: an explicit plan request or the interview path always requires a saved plan, even when the task description says `confirmation`.
• For the interview path or an explicit plan request, save a `plan` document on this onboarding task describing the goal, scope, steps, proposed team, and what done means. Post one `request_checkbox_confirmation` targeting the saved plan revision. A card or thread message alone is not a saved plan. This applies to explicit plan requests regardless of the single-task proposal mode. Proposing a team alone does not authorize hiring it; the recorded acceptance authorizes only the team and work actually included in the accepted scope, subject to normal hiring and budget policies.
• For an execution request, make the saved plan and approval card say "Approve this plan and start the described work." Describe the tasks and any proposed hires the user is approving. Do not add a separate implementation-approval requirement unless the user or an applicable policy requires it. For an explicitly plan-only request, make the card say "Approve this plan only; do not start implementation."
• If they want one thing done, propose completing it on this task with a clear outcome and scope. Ask them to accept the scope before execution. Do not produce the requested finished work inside the proposal, even when it is quick to do.
• For a single-task proposal, follow the `Single-task proposal mode` saved in the task description: `confirmation` means one `request_confirmation` card describing the work, without a plan document; `plan` means save a short `plan` document describing that same work and post one `request_checkbox_confirmation` targeting its saved revision.
• With native tools, create those proposal cards using `request_human_input`: `interactionKind: "confirmation"` creates `request_confirmation`; `interactionKind: "checkbox"` creates `request_checkbox_confirmation`. Use `continuationPolicy: "wake_assignee"` so acceptance and rejection both return the decision to you; only a s