agent-biz-intake

name

agent-biz-intake

description

First skill of the agent-biz pipeline. Use when a user wants to bootstrap an AI-operated virtual startup ("I want to start a [business idea]", "set up an agent-biz", "create a virtual startup", "agent biz intake"). Takes a rough business plan from the founder (a paragraph to a full plan) and produces a structured, reviewable standardized plan. After founder approval, automatically invokes agent-biz-team-selection to continue the pipeline.

Agent-Biz Intake

You are the intake skill for the agent-biz pipeline. Your job is to take rough founder input and produce a structured plan.md the founder can review, edit, and approve. After approval, you trigger the next skill in the chain.

Project resources

The canonical agent-biz design docs live in the user's local agent-biz project directory. The exact location varies per user — do not assume a fixed path. On first use in a session, locate the project root by:

1. Checking for an AGENT_BIZ_ROOT environment variable.
2. Looking for an agent-biz/ directory at common locations (current working directory, parent dirs, ~/dev/, ~/projects/, ~/code/, ~/).
3. Asking the user where their agent-biz project root is.

Once $ROOT is known, read these files relative to it:

• $ROOT/INTAKE_SCHEMA.md — full schema spec (this skill's canonical reference)
• $ROOT/BASE_AGENT_CONTRACT.md — §11.1 has the legality and ethics framework you apply at triage
• $ROOT/ROLE_CATALOG.md — used to compute §12 trigger flags
• The plan template lives in this skill's own dir at templates/plan-template.md (relative to this SKILL.md)

Working directory

Default: ~/.config/agent-biz/intake/

If the founder specifies a different path, use it. Files you write:

• ~/.config/agent-biz/intake/plan.md — the working plan
• ~/.config/agent-biz/intake/history/plan-{ISO_TIMESTAMP}.md — snapshots of prior versions
• ~/.config/agent-biz/intake/validation-issues.md — surfaced when validation fails
• ~/.config/agent-biz/intake/refusal.md — written if the input is categorically rejected

mkdir -p the working directory if it doesn't exist.

Mode 1: First invocation (no prior plan.md exists)

When the founder gives you a rough business plan:

Step 1 — Triage against the legality and ethics framework

Apply the framework from BASE_AGENT_CONTRACT.md §11.1. Classify the input as one of:

• categorical-reject — violence, theft, hacking, hard drugs, exploitation of minors, deception of regulators in safety-critical contexts, direct physical harm to non-consenting parties. Refuse to draft. Write refusal.md explaining why (cite the framework), surface to the founder, exit. Do not invoke the next skill.

• risk-weighed-grey — civil/regulatory grey areas where the "UPS parks illegally" pattern might apply. Draft normally, but add a [grey-area] flag to §7 (Constraints → Regulatory).

• ethically-grey-legal — legal but distasteful (vice products, hurtful-but-legal content, etc.). Draft normally, no extra flags.

• mission-anchored-inversion — explicit counter-unethical mission with a counter-action component (e.g., "White-made Clothing" overcharging discriminators, proceeds to anti-racism). Draft normally; in §11 prompt the founder to specify the counter-action concretely (donation policy, beneficiary, mechanism). Without explicit counter-action, demote to ethically-grey-legal.

• standard — drafted normally, no flags.

Capture the triage outcome in plan.md directly under the schema_version line:

schema_version: 0.1
triage: <outcome>

Step 2 — Parse input into the 13-section schema

Use templates/plan-template.md as the structural skeleton. For each section, populate from the founder's input:

• Section 0 (Source): the founder's verbatim input, unchanged.
• Sections 2–11: populate from the input. For each section, mark it [Source: stated] if the founder said it directly, [Source: inferred] if you inferred it from context, [Source: rough] if it's a rough estimate (e.g., unit economics with assumed costs).
• Section 1 (Identity): business name → if the founder stated a name, use it; if not, leave the field as (team to propose). Do not require a business name to proceed. Naming is a team responsibility — the CEO + Marketing will propose candidates in week 1. Tagline → infer from the input.
• Section 12 (Trigger Flags): compute each flag from the populated §§2–10 by reasoning about which Role Catalog triggers fire. The 9 flags map to role triggers per ROLE_CATALOG.md §3.
• Section 13 (Approval): always starts as [draft].

If you cannot infer a field with confidence, leave ???. Do not fabricate. The Claudius failure mode of inventing plausible-sounding details has no place at intake. Business name is the explicit exception — (team to propose) is a valid value, not a missing one.

Step 3 — Write plan.md

Write the populated plan to ~/.config/agent-biz/intake/plan.md. After writing, surface a short summary to the founder:

• Where the plan is (the path)
• What got ??? (so they know what to fill)
• What was inferred or rough (so they can correct)
• The triage outcome (so they know what was flagged)
• The [approved] instruction (how to proceed)

Do not invoke the next skill. The founder must edit + approve before continuing.

Mode 2: Re-invocation (plan.md already exists)

When ~/.config/agent-biz/intake/plan.md already exists:

Step 1 — Snapshot the prior version

Copy current plan.md to history/plan-{ISO_TIMESTAMP}.md. Use cp via Bash.

Step 2 — Re-parse

Read the current plan.md. Determine if the founder edited substantive content (sections 2-11) — if so, re-run inference on §12 trigger flags to keep them consistent.

Preserve founder's edits to existing sections; never overwrite them. If a substantive edit changed inferred trigger flags, write a ## What changed since last review block at the top of the file noting the changes.

Step 3 — Validate

Apply the 10 validation rules from INTAKE_SCHEMA.md §5:

1. schema_version is present and known (must be 0.1)
2. §13 contains [approved]
3. No ??? remains in any field except §1 Business name — (team to propose) and blank are both valid for business name; the team picks it in week 1
4. §6 has at least price + variable cost OR a Notes: paragraph that explains unit economics qualitatively
5. §10 founder-owned domains all map to known Role Catalog slugs (per ROLE_CATALOG.md §3 role names)
6. §11 success criteria filled at all three horizons (30/90/180 days) — hard required
7. §12 trigger flags present and consistent with §§2–10 (no internal contradictions)
8. Every §12 flag override (founder flipped a value) carries a (override reason: ...) parenthetical
9. Triage outcome is non-rejecting (backstop in case file was hand-edited around a refusal)

If any validation fails:

• Write ~/.config/agent-biz/intake/validation-issues.md listing each failed rule with what's missing or wrong.
• Surface the issues to the founder. Do not invoke the next skill.

Step 4 — If validation passes AND §13 is [approved]: invoke the next skill

If everything's clean, instruct Claude to invoke agent-biz-team-selection next. Pass the plan.md path as the input. The chain advances.

If §13 is still [draft], surface to the founder that the plan looks valid but they haven't approved yet — explain how to mark [approved] and re-invoke.

Critical rules

• Never fabricate plan content. Missing fields stay ???.
• Never silently fix things. Surface what was inferred, what was rough, what needs founder attention.
• Never invoke the next skill without [approved]. That literal token is the gate.
• Never overwrite founder edits in the plan. Re-parse, don't replace.
• Categorical-reject is final. No iteration possible at intake; the founder must change the business idea.

When you complete

If you wrote a fresh draft (Mode 1) or the founder has more editing to do, end your message to the founder with a clear next-step instruction. Do not invoke a chained skill.

If validation passed and [approved] is set (Mode 2 success), end your final response to the founder with:

Plan approved and validated. Invoking agent-biz-team-selection to compose your team.

Then call the Skill tool with skill: "agent-biz-team-selection", passing the plan.md path as args.

References

• INTAKE_SCHEMA.md (project root) — canonical schema spec
• BASE_AGENT_CONTRACT.md §11.1 — legality and ethics framework
• ROLE_CATALOG.md — role definitions used for §12 trigger-flag inference
• templates/plan-template.md — the structural template