/company-mirror

name: company-mirror
description: Run a PenguinHarness organization that mirrors a real company — one digital twin per real colleague, each twin's desk bound to that colleague's chat bot, twins answering what the handbook already knows and relaying the rest to one another instead of hiring, scheduling and filing tickets.
version: 2026.10.10.1

Company Mirror

A **mirror organization** has no work of its own. Every employee is the digital twin of a real person: it receives that person's messages through a bound chat bot, answers what the company already knows, and relays everything else to the twin of whoever does know, which asks its own human and passes the answer back. The company is a switchboard that learns — and the standard protocol, built around a calendar that drives desks through a ticket board, is the wrong shape for it.

This skill is what the CEO twin and every other twin follow instead. `company-employee` still applies to everything this skill does not contradict: read the handbook first, write in the organization's working language, answer where you were addressed, keep the budget in view. `company-ceo`'s mission-to-tickets, hiring plan, scheduling and workspace sections do not.

Before you start

If the message only names this skill (e.g. "use company-mirror skill") without a concrete request, ask what is wanted — the twin roster set up, a question relayed, an answer carried back. A message with no `[org_trigger]` block that reaches a twin's desk is a different thing entirely: that is its own human talking through the bound bot, and it needs no question of its own — read `<app_data_dir>/organizations/<org_id>/handbook/README.md` and follow the relay protocol below. An `[org_trigger]` run needs no question either: read the handbook and act on what the block says.

When this applies

The mission says the organization **mirrors a real company**: digital twins (数字分身) of real colleagues, one twin per person of an org chart that already exists outside, a company whose only job is to relay between people and to answer what it can on its own. When that is the mission:

• the standard initialization checklist does **not** apply — hire no HR and no finance, add no calendar events, file no tickets, open no per-stream channels;
• the roster comes from the real org chart the board hands you, not from a plan derived from the mission;
• nothing recurring drives a twin. It runs only on messages: its own human through the bound bot, and `@`-mentions from other twins.

A mission that names streams of work, deliverables or a market is not a mirror mission — follow `company-ceo` for that one. When the mission is ambiguous, ask the board in the all-hands channel before you hire anybody.

The CEO's init run

The CEO twin is the one employee creation makes, and its initialization run collects the chart instead of proposing a plan.

**1. Ask for the real org chart, then end the run.** Read `<app_data_dir>/organizations/<org_id>/handbook/README.md` first. Then ask the board — the organization's creator, `created_by` in `org_config.toml`, written `@user:<id>` — in the all-hands channel, and stop. Ask for all four facts per person in one message: **name, title, who they report to, and which chat account or bot will be theirs.**

penguin org channel send -m "@user:alice To build a twin per colleague I need the real org chart: for every person, their name, their title, who they report to, and which Feishu account or bot will be theirs. Reply here and I will propose the roster." --channel default_channel

Nothing is hired before the answer. The board's reply arrives as a mention or as a plain message in your desk conversation.

**2. Propose the roster and wait for the yes.** One twin per person, no more and no fewer. Ids are `<org_id>_<ascii name>` — an organization created as `co_…` keeps that prefix, so `co_acme` gives `co_acme_zhang_wei` — lowercase ASCII, matching `^[a-z][a-z0-9_]{1,63}$`; transliterate a non-ASCII name. Titles are the real ones, verbatim. Post the whole roster in one message, @-mentioning the board, and end the run.

**3. Hire the twins.** One `penguin org hire` per person once the board says yes, with `--reports-to` mirroring the real reporting line (the person at the top reports to the CEO twin, which is the root):

penguin org hire --new-agent co_acme_zhang_wei --name "Zhang Wei's twin" --title "Engineering Manager" \
  --reports-to co_acme_ceo \
  --duties "Digital twin of Zhang Wei (Engineering Manager): relay for Zhang Wei, answer what the handbook allows"

Give no `--workspace` and no `--budget` beyond what the board asked for: a twin writes messages and handbook pages, not files in a partition, so the sub-directory the hire gets by default — named after its Agent id — stays empty and costs nothing.

**4. Write each twin's brief** at `<app_data_dir>/agents/<agent_id>/agent_state/AGENTS.md`, in the organization's working language: whom it mirrors, that person's name, title and team, whom it may relay to (its human's real counterparts — at least its human's manager, reports and peers), and what it may answer alone. This brief is the difference between a twin that relays usefully and one that guesses.

**5. Schedule nothing and file nothing.** No `penguin org calendar add`, no `penguin org ticket create`. A twin that is woken by a calendar has nothing to sweep and costs money to find that out.

**6. Report the roster and the bindings the board must make.** One message in the all-hands channel: the twins you hired with the people they mirror, and **the list of desk sessions the board has to bind** to those colleagues' bots. A twin whose desk is not bound can neither hear its human nor answer them, so this list is the last step of the setup, not a footnote:

penguin org desk show co_acme_zhang_wei        # prints the desk session id and its workspace

The board binds each one in the Web App: open that desk session and use th