/company-setup

name: company-setup
description: Create a company-mode organization together with the user — collect its id, name, mission, shared workspace, model and CEO budget one question at a time, confirm the whole thing in one summary, then run penguin org create and hand the user over to company mode.

Company Setup

Company mode is the second work mode of PenguinHarness: a Project's Agents organized into a **company** — a CEO at the root of a reporting tree, one standing desk session per employee, a calendar as the only periodic driver, a ticket board that carries the work, channels where `@` mentions interrupt, and monthly budgets that pause spending before it runs away. Creating one takes six facts and a single command.

This skill is how you collect those six facts and run that command. **It ends there.** You never hire, never schedule a calendar event and never file a ticket: creation produces the CEO and nothing else, and the CEO does the rest — after it has proposed a plan and the board (the humans of the Project) has answered.

Before you start

If the user's message only invokes this skill (e.g. "use company-setup skill") without naming a company to create, ask what organization they want and what it should do. One sentence is enough to start the questions below; do not create anything until every question has an answer and the user has said yes to the summary.

Look before the first question:

penguin org ls --json     # the Project's organizations, so you never propose a taken id

If that call answers `404`, company mode is off for this server (System settings › Server › Company mode). Say so and stop — nothing here can succeed until an admin turns it on.

Which Project the organization lands in

Inside a harness agent session every command subprocess carries `PENGUIN_API_URL`, `PENGUIN_API_TOKEN` and `PENGUIN_PROJECT_ID`, and `penguin org create` reads that last one as its `--project-id` — so you normally pass no flag and the organization is created in the Project you are running in. Check which one that is before you create anything:

echo "${PENGUIN_PROJECT_ID:-default_project}"

Name the Project in the summary. Pass `--project-id <id>` only when the user explicitly wants a different one.

Ask one question at a time

One question per message, in the user's own language, in this order. Never batch them into a form and never fill one in yourself: an unanswered question is asked again, not guessed. Each answer is echoed back in the summary at the end, so a mistake costs one line, not a re-run.

1. **Organization id.** The directory name and the id every command takes: `[a-z][a-z0-9_]{1,63}` — a lowercase letter, then lowercase letters, digits and underscores, 2–64 characters. Suggest one derived from what the user has already called the company: lowercase it, transliterate to ASCII, join the words with underscores and put `co_` in front — "Plugin Marketplace" → `co_plugin_marketplace`. The prefix is the convention (`co_` for an organization, `ch_` for a channel, so an id says what it names); the server does not enforce it, so a user who wants a bare id gets one. Let them confirm or replace the suggestion. If nothing in the conversation names the company yet, ask question 2 first and derive the suggestion from that answer — those two questions swap, the rest of the order does not. Never propose an id already in `penguin org ls`; the server refuses it with `409 org_exists`. 2. **Name.** The display name, free text. Say that leaving it empty makes it the id. 3. **Mission.** One sentence: what the company is for, and how one would know it succeeded. This is the single most load-bearing answer — it becomes the CEO's initialization run, the handbook and the first tickets. A vague mission ("build a website") produces a vague company, so if the user's sentence is broad, **propose a sharper wording** and ask them to confirm or correct it; propose once, do not negotiate it into a paragraph. Their wording wins if they keep it. The mission's own language also decides the organization's **working language** — a Chinese mission gives a company that writes its channel messages, tickets, handbook and briefs in Chinese, an English one a company that writes them in English — so say that when you take the answer, and reach for `--language zh|en` only when the user wants the other one. A **mirror company** is a mission like any other, and one worth proposing when the user talks about their real colleagues rather than about work to produce: *"Set up a company that mirrors our real company: I will give the CEO our real org chart and the CEO creates one digital twin per real employee; each twin's desk session is bound to that colleague's Feishu bot. A twin only receives its own colleague's messages by default, answers what it can on its own and relays the rest to the relevant colleague's twin, who passes it on to the real person. The CEO hires nobody on its own, schedules nothing and files no tickets; the company only relays and solves what it can."* Take it through the same six questions — the shared workspace and the budget still apply — and say what follows from it: the CEO will ask for the real org chart before it hires anybody, and each twin's desk session has to be bound to that colleague's bot (the **远程控制** / Remote control panel of the desk session) before it can hear or answer them. 4. **Shared workspace.** The company's working directory, whose root holds the shared inputs and is nobody's desk: every desk works in a sub-directory of it — the CEO's is `ceo/`, and each hire's is named after its Agent id until the CEO assigns another. Either an **existing absolute directory** or the default — the organization's own `workspace/` inside the Project directory, which is what most missions want. Offer the default explicitly; if the user names a path, check it exists before you put it in the summary (the server refuses one that does not). 5. **Model.** The prov