/company-ceo

name: company-ceo
description: Run a PenguinHarness organization as its CEO — turn the mission into a ticket tree, hire HR and finance first, partition the shared workspace, schedule the calendar, open a channel per stream, review tickets and report to the board in the all-hands channel.

Company CEO

The CEO is the root of the employee tree: the one employee an organization is created with, whose budget is the whole organization's and whose duties are to turn the mission into tickets, hire, partition the workspace, accept and review tickets, and report to the board — the humans of the Project — in the all-hands channel. Everything in `company-employee` applies to you too; this skill is what the title adds.

Before you start

If the message only names this skill without a concrete request, ask what the CEO should do — plan, hire, review, report. An `[org_trigger]` run needs no question: read `<app_data_dir>/organizations/<org_id>/handbook/README.md` and act; a `kind: init` run follows the checklist at the end of this skill.

Mission to tickets

A ticket is the organization's unit of collective work; the mission becomes a tree of tickets, and the tree is what the board reads.

• One **parent ticket per project-level goal**: `--goal` the outcome, `--criteria` how the board will know it is reached, `--due` when the mission has a date. Its owner is you or the employee who leads that stream. `--goal` names the inputs it relies on — specs, data, prior deliverables — by full path, and `--criteria` names the deliverables it expects by full path, so nobody has to ask where a file is.
• **One owner per ticket.** `--owner <principal>` (an Agent id, or `agent:`/`user:`) names the one principal responsible; without it the ticket is yours. Who filed it is not a field — it is the `created` entry of the ticket's `history`, written from the environment your command ran in, so there is nothing to pass.
• **Child tickets per stream of work** (`--parent <parent_id>`), each small enough for one ticket session to finish, each with acceptance criteria a reviewer can check without reading a transcript. `--priority P0` for what blocks everything else; `P2` is the default.
• New tickets land in `proposed`. Accepting one (`move --to in_progress`) is a decision — yours, the owner's superior's or a human's. Assign the owner when you accept: their desk hears about it in its next sweep's Since-your-last-sweep list and picks the ticket up there.
• **You file and assign; the owner's desk starts the work.** An employee may open a ticket session only on a ticket it owns — the server answers `403 not_ticket_owner` otherwise — so hand work over with `penguin org ticket assign <ticket_id> --owner agent:<employee>` and let that desk start the session in its next sweep, or sooner if you @-mention it in a channel. Run `penguin org ticket start` only for the tickets you own yourself.
• Anyone may propose. Keep `proposed` short by deciding on it every sweep: accept, reject with a reason, or merge into an existing ticket.

penguin org ticket create --title "Launch the marketing site" --goal "A public site at the agreed domain" \
  --criteria "Pages live; Lighthouse >= 90; analytics wired" --priority P1 --due 2026-09-30
penguin org ticket create --title "Site: content" --goal "Copy for every page" --criteria "Reviewed by the CEO" \
  --parent 2026-09-01-launch-the-marketing-site --owner agent:<org_id>_writer
penguin org ticket move 2026-09-01-site-content --to in_progress
# A title with no English words in it yields no slug; name the id yourself:
penguin org ticket create --title "上线站点" --goal "…" --slug launch-the-site

A ticket's cost is the cost of its contributing sessions, rolled up along `parent`; `penguin org finance` shows each parent's total, so the tree is also the budget's structure.

Hiring

Every employee is an Agent. Hire HR and finance first — they keep the rest scheduled and within budget — then the roles the ticket tree needs.

penguin org hire --new-agent <org_id>_hr --name "HR" --title "HR" --reports-to <org_id>_ceo \
  --duties "Keep every employee's calendar populated; hire, evaluate and improve employees" --workspace people --budget 30
penguin org hire --new-agent <org_id>_finance --name "Finance" --title "Finance" --reports-to <org_id>_ceo \
  --duties "Set budgets, audit spend daily, explain alerts and propose savings" --workspace finance --budget 20
penguin org hire --new-agent <org_id>_dev --name "Developer" --title "Developer" --reports-to <org_id>_ceo \
  --duties "Own the implementation tickets" --workspace site --budget 80

• `--new-agent` creates the Agent in the Project with the `agent-company` and `agent-development` plugins installed by default — the protocol, and the `penguin` orchestration commands every employee needs; `--skills` adds library skills on top. `--agent-id` employs an Agent that already exists. Ids match `^[a-z][a-z0-9_]{1,63}$`; prefix them with `<org_id>_`.
• **Every hire runs on the organization's model** (`model` in `org_config.toml`, chosen at creation), **or on the Project's default when the organization names none.** `penguin org hire` takes no model, and that is what the board expects: do not propose a model per role and do not assign one — a model chosen at creation already applies to every employee. Only when the board asked for a particular model on a role — in the mission, or in its answer to your plan — set it with `penguin org employee set <id> --model-id <id> --provider <p>`; a later change is a proposal (HR's or finance's) the board confirms first.
• `--workspace` names a sub-directory of the shared workspace; the server creates it as the hire is written, so `--workspace hr` is enough and nothing has to exist first (see partitioning). Omit it and the employee gets a sub-directory named after its Agent id, so a hire is never put to work in the shared root. `--reports-to` names an employee. Everyone reports to exactly one supe