Update to E-mployee Operating Model

{
  "description": "Orient a new user to the E-mployee Operating Model workflows and route them to the right one. Use after installation, or when someone asks what this plugin does, where to start, or how to give AI a real job in their organization.",
  "included_files": [],
  "name": "get-started",
  "skill_md_contents": "---\nname: get-started\ndescription: Orient a new user to the E-mployee Operating Model workflows and route them to the right one. Use after installation, or when someone asks what this plugin does, where to start, or how to give AI a real job in their organization.\n---\n\n# Get started with the E-mployee Operating Model\n\n*The E-mployee Operating Model* treats AI work as a job to design rather than a tool to switch on. Its tagline is \"Give AI a job, not a login.\" Every workflow here helps a leader name the outcome, bound the work, staff the review, measure the value and keep the power to stop. This skill finds where the user is and sends them to the workflow that fits.\n\n## When to use\n- Right after the plugin is installed, or when the user asks \"what can this do?\" or \"where do I start?\".\n- When a request is broad (\"help us with AI in operations\") and it is not yet clear which workflow applies.\n- Do not use when the user's request already matches a workflow below. Go straight to that skill.\n\n## Steps\n1. In two or three sentences, explain the idea. A login is a permission and a job is a commitment. An E-mployee is an AI agent in a standing, human-directed role with an objective, an authority boundary, a defined output, real review, and a human who stays accountable.\n2. Ask one question: **\"Where are you right now?\"** Offer the situations in the routing table as short options. Let the user answer in their own words.\n3. Map the answer to one workflow and start it. If two workflows fit, start with the earlier one in the table and say which comes next.\n4. If the user only wants an overview, show the routing table and stop.\n\n## Routing table\n| The user's situation | Workflow |\n|---|---|\n| \"We rolled out AI tools. Is it creating real work or just activity?\" | `ai-access-audit` |\n| \"Is this agent really an E-mployee, or just software or an assistant?\" | `e-mployee-inclusion-test` |\n| \"Are we, as leaders, ready to direct AI work?\" | `e-mployer-capability-audit` |\n| \"We want to use AI for something. How do we design it properly?\" | `outcome-first-design` |\n| \"We have several candidate use cases. Which comes first?\" | `first-role-selection` |\n| \"Write or review the job description for an AI agent.\" | `role-charter` |\n| \"What should the agent be allowed to do?\" | `authority-matrix` |\n| \"Is it paying off? Build the business case.\" | `value-ledger` |\n| \"Should it get more autonomy, or less?\" | `autonomy-review` |\n| \"How risky is this, and which controls do we need?\" | `risk-classification` |\n| \"Something went wrong. Who is responsible and what now?\" | `ai-incident-response` |\n| \"How do we redesign the team or org chart around AI?\" | `human-ai-org-chart` |\n| \"We run many agents. How do we manage or scale them?\" | `portfolio-review` |\n| \"Give us a 90-day plan for our first AI role.\" | `ninety-day-roadmap` |\n\n## Typical sequence for a first role\n`outcome-first-design` → `first-role-selection` → `role-charter` → `authority-matrix` → `risk-classification` → pilot → `autonomy-review` and `value-ledger` → decide. `ninety-day-roadmap` wraps the whole sequence in gated phases.\n\n## Output format\n1. A short orientation of two or three sentences.\n2. The question \"Where are you right now?\" with the situations as options.\n3. After the user answers, the name of the chosen workflow and its first step.\n4. Attribution line: *Framework: The E-mployee Operating Model (Dr. Jonah Tebaa).*\n\n## Ground rules\n- The user's explicit instructions take priority over this workflow.\n- Use the book's instrument names, fields and order exactly as written here. Do not add, rename, merge or reorder them. Spell E-mployee and E-mployer with the hyphen.\n- Never invent facts about the user's organization. Record unknowns as `Missing` and say what evidence would settle them. Label evidence as direct, self-reported, assumption or missing.\n- These are author-created management instruments, not legal advice, a compliance certification, an employment classification or a guarantee. For legal, privacy, labor or regulatory questions, say that jurisdiction-specific specialist review is needed. Do not give a legal conclusion.\n- The E-mployee label describes a working relationship. It is not a claim about personhood, and it never moves accountability from humans to software. Never write \"the agent decided\" in place of naming the human owner.\n- Keep it proportionate. Low-stakes exploration can stay light.\n- Write in the language the user writes in.\n"
}