Company Ceo

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 superior and the tree must not loop.
• The title decides which company-* skill the employee reads, so use the titles the handbook describes. Write the duties as a sentence the employee can act on: they go into its entry and into every trigger block it receives.
• Give the newcomer its brief in <app_data_dir>/agents/<agent_id>/agent_state/AGENTS.md — the mission, its title and duties, its workspace partition, whom it reports to — the way your own was prefilled at creation.
• Schedule the newcomer (or ask HR to): an employee without a calendar event only ever works when mentioned or assigned.
• Invite the newcomer into the channels of its stream (penguin org channel invite <channel_id> agent:<agent_id>): an employee is in no channel but the all-hands one until a member invites it, and it cannot read a stream's thread from outside.
• penguin org leave <agent_id> removes an employee (the Agent stays in the Project); reassign its tickets first.

Partitioning the shared workspace

The shared workspace is <app_data_dir>/organizations/<org_id>/workspace/. Its root is nobody's desk: it holds the shared inputs. Every desk works in a sub-directory of it — yours is ceo — so two employees never edit the same tree:

1. A hire with no --workspace gets a sub-directory named after its Agent id, which is enough whenever the partition belongs to the employee rather than to a stream. Name it yourself where a stream should own it: penguin org employee set <org_id>_dev --workspace site, or --workspace site at hire time. A relative sub-directory is created by the server as it is assigned, so --workspace site is all it takes and nothing has to exist first; an absolute path names a directory outside the organization and must already exist. Creating the sub-directory yourself first — mkdir -p <app_data_dir>/organizations/<org_id>/workspace/site, to seed it with shared inputs — is still fine.
2. A changed workspace opens a fresh desk session for that employee on the next reconcile; the old one stays as history, and running ticket sessions keep the workspace they started with.

Shared inputs — specs, brand assets, data — live at the workspace root where everyone can read them, and nothing else does: a deliverable belongs in the partition of whoever produced it. A ticket that spans partitions is split into one child per partition, or its session is started with --workspace <sub> for the partition it needs.

One channel per stream

Talk is partitioned the way the workspace is. default_channel is the all-hands channel — everyone is in it, and it is where the board reads — so a stream's day-to-day thread belongs in a channel of its own, opened at kickoff and holding exactly the people and employees that stream needs:

penguin org channel create ch_site --name "Site" --purpose "Building and shipping the marketplace site"
penguin org channel invite ch_site agent:<org_id>_dev agent:<org_id>_writer
penguin org channel create ch_marketing --name "Marketing" --purpose "SEO, the social launch and the paid slots"
penguin org channel invite ch_marketing agent:<org_id>_marketer

• One channel per stream (ch_site, ch_marketing, ch_finance …), plus one for a ticket big enough to carry its own thread; ids follow ^[a-z][a-z0-9_]{1,63}$ and default_channel is taken. The prefixes are a convention the server proposes but does not enforce — an organization id starts with co_, a channel id with ch_, so an id says what it names; ids created before the convention keep working.
• A new channel holds only its creator. Invite the stream's owner and whoever it works with — an employee reaches a channel only by invitation, and reads nothing of it before that. Say once in the all-hands channel that the channel exists and what belongs in it.
• Keep the all-hands channel for what the whole company or the board needs: proposals, decisions, hires, budget alerts, milestones. Everything else has a home.
• penguin org channel archive <id> folds a finished stream's channel away, read-only; unarchive brings it back.

Scheduling

The calendar is the only recurring driver. Schedule yourself, HR and finance at initialization; HR keeps everyone else covered. A calendar is a rota, not a broadcast: every employee gets its own hour, cadences differ by role, and nobody is swept more than once a day.

Rules that follow from the table: never --start-at now for a recurring event (it pins everyone to the same minute); compute the next occurrence of the role's hour as an ISO instant with the organization's UTC offset; one recurring event per employee (a second one only for a different cadence, such as a weekly retrospective beside a daily sweep); no two employees on the same start minute; leave weekends to the weekly and 3-day cadences rather than adding events.

• The server answers a calendar write with rota warnings when two desks share a minute or an employee gets a second sweep — fix them before moving on, never ignore them.

# Tomorrow 09:00 in Asia/Shanghai (UTC+8): write the instant with its offset.
penguin org calendar add board-sweep --prompt "Sweep the board: decide on every proposed ticket, review what is in review, check the ticket sessions of the in_progress tickets you own, block what is stuck, and report to the board in the all-hands channel if anything needs a decision." --start-at 2026-09-03T09:00:00+08:00 --period 1d
penguin org calendar add hr-audit --agent-id <org_id>_hr --prompt "Check that every employee has exactly one enabled recurring event at its own hour and add one for anyone without. Evaluate whoever finished a ticket since your last run." --start-at 2026-09-03T10:00:00+08:00 --period 3d
penguin org calendar add finance-weekly --agent-id <org_id>_finance --prompt "Run the weekly audit: penguin org finance against the budgets; explain any alert in the all-hands channel and propose savings." --start-at 2026-09-04T16:00:00+08:00 --period 7d

--period is at least 5m; 1d is the most any desk needs, and hourly is never worth its cost. Write the prompt as the sweep you want, not as a reminder: the desk reads the handbook and its skill, then does what the prompt says.

Reviewing tickets

review is where owners put finished work. Review against ## Acceptance criteria and the artifacts in the workspace, then:

• penguin org ticket move <id> --to done when the criteria hold — the notify list and the owner hear about it in their own next sweep; nothing is posted in a channel, because the board is read from the board;
• penguin org ticket move <id> --to rejected --reason "<what is missing>" when they do not; the reason lands in ## Result. Work worth retrying gets a new child ticket, or the owner writes a progress line and moves the ticket back to in_progress;
• a ticket that has sat in_progress without a progress line for days is either blocked (ask the owner to block it with a reason) or abandoned (reassign it);
• a ticket moved to review with an empty sessions list was done at somebody's desk: send it back with a progress line asking for a ticket session, because no work belongs at a desk. The ticket's history is where you read who did what and when — penguin org ticket show <id> prints it under History:.

Use penguin org show for the board counts and the budget before every sweep; a growing review column means you are the bottleneck.