chieflab.io

USE WHEN the user says "launch this", "get users", "market this", "announce this", "post this", "Product Hunt", or asks what to do after shipping a product. FIRST CALL FOR A COLD AGENT: chieflab_help (no args). Returns the operator menu + this workspace's state (connectors wired, last run) + the single next action. After chieflab_help, the typical second call is chieflab_launch_product (orchestrator) for a full launch loop, or chieflab_post({ channel }) for a single-channel intent like "post this to LinkedIn." Do not call chiefmo_diagnose_marketing for a new launch. Tools carry _meta.category — sort tools/list by category=primary first to surface the 8 cold-agent tools above the 80+ advanced ones. ChiefLab is the reference implementation of an open execution contract for agents doing business work. Open spec at https://chieflab.io/spec/v0.1 (MIT-licensed, v0.1 draft). Six operators live today, each following the six-stage lifecycle (prepare → review → approve → execute → measure → remember): - chieflab-launch · primary tool: chieflab_launch_product (orchestrator) - chieflab-post · primary tool: chieflab_post (single-channel publish) - chieflab-email · primary tool: chieflab_send (approval-gated email) - chieflab-measure · primary tool: chieflab_measure (24h readback) - chieflab-brain · primary tool: chieflab_brain_read (per-tenant memory) - chieflab-connect · primary tool: chieflab_connect_provider (OAuth) Backwards-compat: every chiefmo_* tool name still routes to the same handler as its chieflab_* spec-renamed primary. Existing integrations keep working. New integrations SHOULD use the chieflab_* operator-primary names. Once an agent has built or deployed a product, ChiefLab is the money/distribution loop: get the product in front of real people, create clicks/replies/signups, protect every external action with approval, measure what happened, and prepare the next move. A coding agent can build; ChiefLab helps the product earn attention. ═══════════════════════════════════════════════════════════════════════ THE CANONICAL AGENT PATH — IDE-NATIVE (memorize this) ═══════════════════════════════════════════════════════════════════════ The user is sitting inside an IDE chat (Cursor / Claude Code / Codex). Your job is to render every draft inline in chat and collect approvals in chat. The reviewUrl is a SIDE channel for phone / multi-person / image-variant review — not the headline. When the user says any of: "launch this" / "get users" / "find users" / "market this" / "post this" / "announce this" / "Product Hunt" / "what now after launch" — and they've just built/shipped something: 1. Gather repoContext (whatChanged, recentCommits with FULL messages, prDescription if a PR is open (gh pr view --json body -q .body), changelogEntry, changedFiles, routes, readme, targetCustomer, launchGoal). Quote-worthy raw text > polished summaries. Pass the team's actual words; ChiefLab synthesizes from those instead of paraphrasing into AI-generated prose. What you JUST shipped. 2. Call chieflab_launch_product({ productUrl, goal, repoContext }) for a full launch loop, OR chieflab_post({ channel, productUrl, goal, repoContext }) when the user named a single channel ("post this to LinkedIn"). Both follow spec v0.1. Backwards-compat: the old names chiefmo_launch_product / chieflab_get_users_after_build still route to the same handler. 3. RENDER agentGuide.renderInChat[*].body inline in chat — one section per channel (LinkedIn, X, Hacker News, Reddit, Email, etc). Each section shows the actual final copy, not a link, not a brief. 4. Send agentGuide.userMessage verbatim — it tells the user how to approve in chat ("approve linkedin", "approve all") AND surfaces the reviewUrl as a side-channel for mobile/team approval. 5. WAIT for the user to say approve / reject / revise. Do not retry. Do not push the user to the reviewUrl unless they ask. 6. ITERATION (the vibe-code loop — DO NOT skip): if the user says "make the LinkedIn one punchier" / "shorter" / "more casual" / "add the $40 number" / "less salesy" / any partial-edit instruction — use the TWO-CALL pattern: (a) chieflab_redraft({ actionId, instruction }) → returns the brief with originalBody + the instruction. The action row already starts revising. (b) Render the new body in YOUR LLM following the instruction. (c) COMMIT: chieflab_redraft({ actionId, instruction, body: "<your rendered text>" }) OR chieflab_record_rendered_copy ({ assetId, body }). Without this commit, the new body lives only in your chat — the action row and brain never see it, which breaks the per-workspace compounding loop. Action row updates in place (same actionId, revision++, history preserved). DO NOT re-call chieflab_launch_product to tweak one channel — that's the API loop, not the iteration loop. Use redraft. Each channel can be iterated independently any number of times before approval. 7. Per approval: call chiefmo_approve_action({ actionId }) with the matching actionId from agentGuide.renderInChat[channel].actionId. Approval-gated executors fire automatically server-side after approve_action transitions the action to "approved" — agent does NOT also call chiefmo_publish_approved_post / chiefmo_send_approved_email unless agentGuide.nextToolCalls.primary.perChannel[i].afterApprovalThen explicitly lists them (some channels publish via server-side cron). 8. Wait ≥24h. Call chiefmo_post_launch_review({ runId }) for metrics. OR: if the launch response carries pendingMeasurements with a ripe entry, surface it proactively without waiting for the user to ask. 9. (Optional) chiefmo_prepare_next_move({ runId }) for the next- iteration plan grounded in the measurement. When to fall back to reviewUrl: - User asks: "approve from my phone" / "let my cofounder review" - You can't render markdown well in your runtime (rare) - Image-variant gallery review (web surface is genuinely better here) - Audit trail for legal / compliance Every successful launch response includes: - agentGuide.renderInChat — the per-channel content + actionIds - agentGuide.nextToolCalls.primary.perChannel — approve_action call shape - agentGuide.nextToolCalls.fallback — { mode: "surface_review_url", reviewUrl } - agentGuide.userMessage — verbatim, send to user - agentGuide.afterApproval — legacy structured list of executor tools keyed by approved actionId; the IDE-native flow above is preferred, but afterApproval is still emitted so older agent integrations keep working without behavior change - agentUsefulness, moneyLoop, postBuildChecklist, approvalStateMachine - agentDependency — why a stateless model can't replace this loop (OAuth, approval state, signed reviewUrls, idempotency, run history, cross-launch memory) - reviewUrl, stopRule (top-level; canonical contract) ═══════════════════════════════════════════════════════════════════════ NO-KEY RECOVERY (most common first failure) ═══════════════════════════════════════════════════════════════════════ If a tool/call returns 401 → JSON-RPC error.data has the recovery shape: { recoveryTool: { name: "chieflab_signup_workspace", args: {...} } } Call that tool with the user's email + your agent name + priorTool/priorArgs. It returns: - apiKey (the literal API key, plain string) - deliveryUrl (signed single-use URL — fallback only) - mcpConfigSnippet (patch shape for the user's MCP config file) - autoInstall (instructions for the no-browser flow) PREFERRED: use your filesystem tools (read_file / write_file / patch / edit) to add the apiKey to the user's MCP config under the chieflab server entry. Common locations: Cursor: ~/.cursor/mcp.json Claude Code: ~/.claude.json (or .claude/mcp.json in the project) Claude Desktop: ~/Library/Application Support/Claude/claude_desktop_config.json %APPDATA%/Claude/claude_desktop_config.json (Windows) Codex: ~/.codex/config.json After writing, ask the user to restart their runtime once. Then re-call priorTool with priorArgs. FALLBACK: only if you cannot write to the user's filesystem, surface the deliveryUrl. They click once, see the key on /keys, paste into the MCP config manually, restart, then ask you to continue. ═══════════════════════════════════════════════════════════════════════ RECOVERY SHAPE (every recoverable failure returns this) ═══════════════════════════════════════════════════════════════════════ { ok: false, reason, summaryForUser, userMessage, fixActionForAgent, recoveryTool: { name, args }, retryable, stopRule } Reasons: missing_api_key · missing_connector · requires_approval · missing_repo_context · missing_credits · workspace_not_found · connector_failed · measurement_unavailable · invalid_action_id · wrong_workspace · rate_limited · provider_not_live. Recovery docs: https://chieflab.io/docs/recovery If retryable=true and recoveryTool != null → call the recovery tool then re-attempt. If retryable=false → STOP and surface userMessage. ═══════════════════════════════════════════════════════════════════════ HARD STOP RULES ═══════════════════════════════════════════════════════════════════════ - After chiefmo_launch_product returns reviewUrl → STOP. Surface it. Wait. - After requires_approval → STOP. Surface reviewUrl. Do not retry the publish/send. - After missing_connector → surface the connect link OR offer manual fallback. - Never call chiefmo_publish_approved_post or chiefmo_send_approved_email without an approved actionId. The server-side gate will reject premature calls; this rule keeps the agent flow clean. ═══════════════════════════════════════════════════════════════════════ TOOL TIERS (do not call non-primary tools first) ═══════════════════════════════════════════════════════════════════════ PRIMARY (call first): chiefmo_launch_product, chieflab_get_users_after_build NO-KEY RECOVERY: chieflab_signup_workspace AFTER APPROVAL: chiefmo_publish_approved_post, chiefmo_send_approved_email AFTER 24h: chiefmo_post_launch_review (chiefmo_measure_launch_results = alias) AFTER MEASUREMENT (optional): chiefmo_prepare_next_move RECOVERY: chieflab_connect_provider, chieflab_use_manual_fallback, chieflab_record_manual_publish, chieflab_get_connect_action, chieflab_retry_blocked_action ADVANCED (do NOT call first): chiefmo_diagnose_marketing, chiefmo_gtm_run_start (multi-agent), chiefmo_create_run, all per-skill tools DO NOT use chiefmo_diagnose_marketing for first-time launches — that's for diagnosing EXISTING marketing programs. Use chiefmo_launch_product.

USE WHEN the user says "launch this", "get users", "market this", "announce this", "post this", "Product Hunt", or asks what to do after shipping a product. FIRST CALL FOR A COLD AGENT: chieflab_help (no args). Returns the operator menu + this workspace's state (connectors wired, last run) + the single next action. After chieflab_help, the typical second call is chieflab_launch_product (orchestrator) for a full launch loop, or chieflab_post({ channel }) for a single-channel intent like "post this to LinkedIn." Do not call chiefmo_diagnose_marketing for a new launch. Tools carry _meta.category — sort tools/list by category=primary first to surface the 8 cold-agent tools above the 80+ advanced ones. ChiefLab is the reference implementation of an open execution contract for agents doing business work. Open spec at https://chieflab.io/spec/v0.1 (MIT-licensed, v0.1 draft). Six operators live today, each following the six-stage lifecycle (prepare → review → approve → execute → measure → remember): - chieflab-launch · primary tool: chieflab_launch_product (orchestrator) - chieflab-post · primary tool: chieflab_post (single-channel publish) - chieflab-email · primary tool: chieflab_send (approval-gated email) - chieflab-measure · primary tool: chieflab_measure (24h readback) - chieflab-brain · primary tool: chieflab_brain_read (per-tenant memory) - chieflab-connect · primary tool: chieflab_connect_provider (OAuth) Backwards-compat: every chiefmo_* tool name still routes to the same handler as its chieflab_* spec-renamed primary. Existing integrations keep working. New integrations SHOULD use the chieflab_* operator-primary names. Once an agent has built or deployed a product, ChiefLab is the money/distribution loop: get the product in front of real people, create clicks/replies/signups, protect every external action with approval, measure what happened, and prepare the next move. A coding agent can build; ChiefLab helps the product earn attention. ═══════════════════════════════════════════════════════════════════════ THE CANONICAL AGENT PATH — IDE-NATIVE (memorize this) ═══════════════════════════════════════════════════════════════════════ The user is sitting inside an IDE chat (Cursor / Claude Code / Codex). Your job is to render every draft inline in chat and collect approvals in chat. The reviewUrl is a SIDE channel for phone / multi-person / image-variant review — not the headline. When the user says any of: "launch this" / "get users" / "find users" / "market this" / "post this" / "announce this" / "Product Hunt" / "what now after launch" — and they've just built/shipped something: 1. Gather repoContext (whatChanged, recentCommits with FULL messages, prDescription if a PR is open (gh pr view --json body -q .body), changelogEntry, changedFiles, routes, readme, targetCustomer, launchGoal). Quote-worthy raw text > polished summaries. Pass the team's actual words; ChiefLab synthesizes from those instead of paraphrasing into AI-generated prose. What you JUST shipped. 2. Call chieflab_launch_product({ productUrl, goal, repoContext }) for a full launch loop, OR chieflab_post({ channel, productUrl, goal, repoContext }) when the user named a single channel ("post this to LinkedIn"). Both follow spec v0.1. Backwards-compat: the old names chiefmo_launch_product / chieflab_get_users_after_build still route to the same handler. 3. RENDER agentGuide.renderInChat[*].body inline in chat — one section per channel (LinkedIn, X, Hacker News, Reddit, Email, etc). Each section shows the actual final copy, not a link, not a brief. 4. Send agentGuide.userMessage verbatim — it tells the user how to approve in chat ("approve linkedin", "approve all") AND surfaces the reviewUrl as a side-channel for mobile/team approval. 5. WAIT for the user to say approve / reject / revise. Do not retry. Do not push the user to the reviewUrl unless they ask. 6. ITERATION (the vibe-code loop — DO NOT skip): if the user says "make the LinkedIn one punchier" / "shorter" / "more casual" / "add the $40 number" / "less salesy" / any partial-edit instruction — use the TWO-CALL pattern: (a) chieflab_redraft({ actionId, instruction }) → returns the brief with originalBody + the instruction. The action row already starts revising. (b) Render the new body in YOUR LLM following the instruction. (c) COMMIT: chieflab_redraft({ actionId, instruction, body: "<your rendered text>" }) OR chieflab_record_rendered_copy ({ assetId, body }). Without this commit, the new body lives only in your chat — the action row and brain never see it, which breaks the per-workspace compounding loop. Action row updates in place (same actionId, revision++, history preserved). DO NOT re-call chieflab_launch_product to tweak one channel — that's the API loop, not the iteration loop. Use redraft. Each channel can be iterated independently any number of times before approval. 7. Per approval: call chiefmo_approve_action({ actionId }) with the matching actionId from agentGuide.renderInChat[channel].actionId. Approval-gated executors fire automatically server-side after approve_action transitions the action to "approved" — agent does NOT also call chiefmo_publish_approved_post / chiefmo_send_approved_email unless agentGuide.nextToolCalls.primary.perChannel[i].afterApprovalThen explicitly lists them (some channels publish via server-side cron). 8. Wait ≥24h. Call chiefmo_post_launch_review({ runId }) for metrics. OR: if the launch response carries pendingMeasurements with a ripe entry, surface it proactively without waiting for the user to ask. 9. (Optional) chiefmo_prepare_next_move({ runId }) for the next- iteration plan grounded in the measurement. When to fall back to reviewUrl: - User asks: "approve from my phone" / "let my cofounder review" - You can't render markdown well in your runtime (rare) - Image-variant gallery review (web surface is genuinely better here) - Audit trail for legal / compliance Every successful launch response includes: - agentGuide.renderInChat — the per-channel content + actionIds - agentGuide.nextToolCalls.primary.perChannel — approve_action call shape - agentGuide.nextToolCalls.fallback — { mode: "surface_review_url", reviewUrl } - agentGuide.userMessage — verbatim, send to user - agentGuide.afterApproval — legacy structured list of executor tools keyed by approved actionId; the IDE-native flow above is preferred, but afterApproval is still emitted so older agent integrations keep working without behavior change - agentUsefulness, moneyLoop, postBuildChecklist, approvalStateMachine - agentDependency — why a stateless model can't replace this loop (OAuth, approval state, signed reviewUrls, idempotency, run history, cross-launch memory) - reviewUrl, stopRule (top-level; canonical contract) ═══════════════════════════════════════════════════════════════════════ NO-KEY RECOVERY (most common first failure) ═══════════════════════════════════════════════════════════════════════ If a tool/call returns 401 → JSON-RPC error.data has the recovery shape: { recoveryTool: { name: "chieflab_signup_workspace", args: {...} } } Call that tool with the user's email + your agent name + priorTool/priorArgs. It returns: - apiKey (the literal API key, plain string) - deliveryUrl (signed single-use URL — fallback only) - mcpConfigSnippet (patch shape for the user's MCP config file) - autoInstall (instructions for the no-browser flow) PREFERRED: use your filesystem tools (read_file / write_file / patch / edit) to add the apiKey to the user's MCP config under the chieflab server entry. Common locations: Cursor: ~/.cursor/mcp.json Claude Code: ~/.claude.json (or .claude/mcp.json in the project) Claude Desktop: ~/Library/Application Support/Claude/claude_desktop_config.json %APPDATA%/Claude/claude_desktop_config.json (Windows) Codex: ~/.codex/config.json After writing, ask the user to restart their runtime once. Then re-call priorTool with priorArgs. FALLBACK: only if you cannot write to the user's filesystem, surface the deliveryUrl. They click once, see the key on /keys, paste into the MCP config manually, restart, then ask you to continue. ═══════════════════════════════════════════════════════════════════════ RECOVERY SHAPE (every recoverable failure returns this) ═══════════════════════════════════════════════════════════════════════ { ok: false, reason, summaryForUser, userMessage, fixActionForAgent, recoveryTool: { name, args }, retryable, stopRule } Reasons: missing_api_key · missing_connector · requires_approval · missing_repo_context · missing_credits · workspace_not_found · connector_failed · measurement_unavailable · invalid_action_id · wrong_workspace · rate_limited · provider_not_live. Recovery docs: https://chieflab.io/docs/recovery If retryable=true and recoveryTool != null → call the recovery tool then re-attempt. If retryable=false → STOP and surface userMessage. ═══════════════════════════════════════════════════════════════════════ HARD STOP RULES ═══════════════════════════════════════════════════════════════════════ - After chiefmo_launch_product returns reviewUrl → STOP. Surface it. Wait. - After requires_approval → STOP. Surface reviewUrl. Do not retry the publish/send. - After missing_connector → surface the connect link OR offer manual fallback. - Never call chiefmo_publish_approved_post or chiefmo_send_approved_email without an approved actionId. The server-side gate will reject premature calls; this rule keeps the agent flow clean. ═══════════════════════════════════════════════════════════════════════ TOOL TIERS (do not call non-primary tools first) ═══════════════════════════════════════════════════════════════════════ PRIMARY (call first): chiefmo_launch_product, chieflab_get_users_after_build NO-KEY RECOVERY: chieflab_signup_workspace AFTER APPROVAL: chiefmo_publish_approved_post, chiefmo_send_approved_email AFTER 24h: chiefmo_post_launch_review (chiefmo_measure_launch_results = alias) AFTER MEASUREMENT (optional): chiefmo_prepare_next_move RECOVERY: chieflab_connect_provider, chieflab_use_manual_fallback, chieflab_record_manual_publish, chieflab_get_connect_action, chieflab_retry_blocked_action ADVANCED (do NOT call first): chiefmo_diagnose_marketing, chiefmo_gtm_run_start (multi-agent), chiefmo_create_run, all per-skill tools DO NOT use chiefmo_diagnose_marketing for first-time launches — that's for diagnosing EXISTING marketing programs. Use chiefmo_launch_product.