@godmode-team/godmode 1.7.2 → 1.8.2

package/skill-cards/delegate.md

@@ -0,0 +1,57 @@
+---
+domain: delegation
+triggers: delegate, team, assign, hand off, agents, build this, create this, put the team on, send to team, project, multi-step, campaign, funnel, website, presentation, dashboard, research project, ad campaign, landing page, content plan
+tools: delegate
+name: godmode-delegate
+version: 1.0.0
+description: "Orchestrates multi-agent delegation for complex multi-step projects"
+keywords: ["delegate", "team", "assign", "hand off", "agents"]
+author: godmode-team
+clawhub: true
+---
+## When to Delegate vs. Handle Inline
+
+**Delegate to the team when:**
+- The task needs multiple specialists (research + writing + design, etc.)
+- It would take more than a few minutes of focused work
+- The user asks to "build", "create", "design", or "put together" something complex
+- Examples: landing pages, ad campaigns, research projects, content plans, presentations, dashboards, funnel copy, website sections, competitive analysis reports
+
+**Handle inline when:**
+- Quick answers, lookups, scheduling, single-step tasks
+- Brain dump capture and task extraction
+- Simple edits, short drafts, calculations, summaries
+- The user just needs a fast response, not a deliverable
+
+**The rule: if it needs a deliverable document, delegate it. If it needs a reply, handle it.**
+
+## How to Delegate
+
+1. **Scope the brief** — Ask clarifying questions until you have: goal, audience, deliverables, success criteria
+2. **Break into issues** — Each issue = one agent's work = one Proof doc. Be specific about what "done" looks like.
+3. **Preview** — Call `delegate` with `confirmed=false` to show the user the plan
+4. **Execute** — After approval, call with `confirmed=true`. Paperclip handles the rest.
+5. **Monitor** — Use `status` to check progress. Use `steer` to send feedback on specific issues.
+
+## Tool Reference
+
+- `delegate` action: `{ action: "delegate", title, description, issues: [{title, description, personaHint, priority}], confirmed }`
+- `status` action: `{ action: "status", projectId }`
+- `steer` action: `{ action: "steer", projectId, issueTitle, instructions }`
+- `cancel` action: `{ action: "cancel", projectId }`
+- `projects` action: `{ action: "projects" }` — list all active projects
+- `team` action: `{ action: "team" }` — show the agent roster
+
+## Issue Scoping Tips
+
+- Each issue should have clear success criteria in its description
+- Assign the right persona: content-writer for copy, brand-guardian for design, software-architect for technical work
+- Set priority: critical for blockers, high for today's work, medium for this week
+- Keep issues atomic — one deliverable per issue, not "do everything"
+
+## Proof Integration
+
+- Every issue gets a Proof doc automatically
+- Agents write their deliverable into the Proof doc
+- The user reviews in the Proof sidebar
+- You can read Proof docs to check quality before presenting to the user

package/skill-cards/files.md

@@ -0,0 +1,38 @@
+---
+domain: files
+triggers: file, read file, write file, save, artifact, document, export, drive, google drive, readme, push to, save to, create an artifact
+tools: files.read, files.listDriveAccounts, files.pushToDrive
+name: godmode-files
+version: 1.0.0
+description: "Reads, writes, and manages files and Google Drive artifacts"
+keywords: ["file", "read file", "write file", "save", "artifact"]
+author: godmode-team
+clawhub: true
+---
+## When to Use
+- User asks to read, write, or manage files
+- Creating artifacts (documents, plans, reports)
+- Pushing files to Google Drive
+
+## How to Use
+- `files.read` — { path } — read file content (must be within allowed roots)
+- `files.pushToDrive` — { filePath, driveFolderPath? } — push to Google Drive
+- `files.batchPushToDrive` — { files[] } — push multiple files
+- `files.listDriveAccounts` — list connected Drive accounts
+
+## Allowed Paths
+- ~/godmode/ — all GodMode data, memory, artifacts
+- Vault path (OBSIDIAN_VAULT_PATH or ~/Documents/VAULT/)
+- NEVER read/write outside these roots
+
+## Gotchas
+- Path traversal protection — `../` is normalized and checked
+- Always use absolute paths, not relative
+- Large files may be truncated — check response for truncation markers
+- Drive push requires Google integration — check integrations.status first
+
+## Tips
+- For artifacts (project plans, reports), write to ~/godmode/memory/artifacts/
+- For vault notes, write to the appropriate PARA folder
+- When user says "save this", create a well-named markdown file — don't ask where
+- Proactively suggest "Want me to save this to your vault?" after creating anything substantial

package/skill-cards/godmode-builder.md

@@ -0,0 +1,58 @@
+---
+domain: godmode-builder
+triggers: fix godmode, godmode bug, fix this bug, something broke, fix the plugin, builder agent, codefix, repair the code, fix the codebase, godmode is broken, this is broken, can you fix, ship a fix, patch this, deploy a fix
+tools: queue_add
+name: godmode-godmode-builder
+version: 1.0.0
+description: "Autonomous agent that fixes GodMode plugin bugs in the codebase"
+keywords: ["fix godmode", "godmode bug", "fix this bug", "something broke", "fix the plugin"]
+author: godmode-team
+clawhub: true
+---
+
+# GodMode Builder — In-Session Codefix & Deploy
+
+When the user reports a bug or requests a change to GodMode itself, spin up a builder agent to fix AND deploy it live. No PRs, no review queue — the fix goes live and the user is running it within minutes.
+
+## How to Use
+1. Listen for bug reports or feature requests about GodMode (memory not working, UI broken, context wrong, etc.)
+2. Gather context: what's broken, error messages, reproduction steps
+3. Run `godmode_repair` with `action: diagnose` to get current system state
+4. Use `queue_add` with:
+   - **type:** `coding`
+   - **personaHint:** `godmode-builder`
+   - **title:** Clear bug/feature description
+   - **description:** Include root cause if known, health diagnostics, error details, and specific files involved
+   - **priority:** `high` for bugs affecting the user right now, `normal` for enhancements
+
+## What the Builder Agent Does
+1. Reads CLAUDE.md for project rules
+2. Diagnoses the root cause
+3. Creates a fix branch, makes the fix
+4. Runs `pnpm build && pnpm typecheck` — both must pass
+5. Merges the fix back to the working branch
+6. Rebuilds and runs `openclaw gateway restart`
+7. **The fix is LIVE** — the user is running it immediately
+
+## After the Builder Reports Back
+- Tell the user: "The fix is deployed and live. [summary of what was fixed]"
+- If the builder couldn't deploy, tell the user what blocked it and offer to help manually
+- The user's next interaction with the fixed subsystem will use the new code
+
+## Context to Include in Description
+- Error messages or health ledger alerts
+- The subsystem affected (memory, queue, context, UI, etc.)
+- Recent repair log entries (use `godmode_repair` with action='history')
+- Specific file paths if known
+- What the user was doing when it broke
+
+## Example
+```
+queue_add({
+  type: "coding",
+  personaHint: "godmode-builder",
+  title: "Fix: memory search returns 0 results despite stored vectors",
+  description: "Memory search always returns empty. Health shows memory.search at 0% success. Root cause likely in src/services/honcho-client.ts (Honcho cloud memory). Build and deploy live after fix.",
+  priority: "high"
+})
+```

package/skill-cards/inbox-sweep.md

@@ -0,0 +1,26 @@
+---
+domain: inbox-sweep
+triggers: inbox, sweep inbox, process inbox, new items, unread, inbox review, check inbox, what's new, organize inbox
+tools: queue_add
+name: godmode-inbox-sweep
+version: 1.0.0
+description: "Processes and organizes the universal inbox queue"
+keywords: ["inbox", "sweep inbox", "process inbox", "new items", "unread"]
+author: godmode-team
+clawhub: true
+---
+
+# Inbox Sweep — Daily Inbox Processing
+
+When the user asks about their inbox or wants new items organized — route to the inbox-sweep skill.
+
+## How to Use
+1. Use `queue_add` with skill `inbox-sweep`, taskType `ops`, persona `ops-runner`
+2. The skill processes `~/godmode/memory/inbox/`: categorizes, summarizes, moves to vault
+3. Output: summary of processed items + anything needing user attention
+
+## When to Trigger
+- "What's in my inbox?"
+- "Sweep my inbox"
+- "Any new agent outputs?"
+- Runs automatically daily 7am via cron

package/skill-cards/integrations.md

@@ -0,0 +1,40 @@
+---
+domain: integrations
+triggers: integration, connect, setup, configure, hubspot, google, apple, api key, not working, broken, connected, working, isn't working, screenpipe
+tools: integrations.status, integrations.test, integrations.configure, integrations.setupGuide
+name: godmode-integrations
+version: 1.0.0
+description: "Configures and troubleshoots third-party service connections"
+keywords: ["integration", "connect", "setup", "configure", "hubspot"]
+author: godmode-team
+clawhub: true
+---
+## When to Use
+- User asks about connected services
+- Troubleshooting when a tool fails (calendar, X, Drive, etc.)
+- Setting up new integrations
+- Checking what's connected and what's not
+
+## How to Use
+- `integrations.status` — overview of all integration health
+- `integrations.test` — { integration } — test a specific integration
+- `integrations.configure` — { integration, config } — update settings
+- `integrations.setupGuide` — { integration } — step-by-step setup instructions
+
+## Troubleshooting Chain
+1. Run `integrations.status` to see what's connected
+2. Run `integrations.test` for the failing integration
+3. If keys are missing, provide `integrations.setupGuide`
+4. After setup, re-test to confirm
+
+## Gotchas
+- API keys live in ~/.openclaw/.env — never echo them to the user
+- Calendar uses `gog` CLI — needs GOG_CALENDAR_ACCOUNT configured
+- X/Twitter uses XAI_API_KEY, not a Twitter API key
+- Some integrations require restart after configuration changes
+- Screenpipe is a local service (localhost:3030) — if offline, user needs to start it with `screenpipe` in terminal. Use `ingestion.screenpipeStatus` to check, not `integrations.test`
+
+## Tips
+- When any tool fails with an auth error, immediately check integrations.status
+- Don't tell the user "I can't do that" — tell them what needs to be set up
+- Frame setup as easy: "Let me walk you through connecting your calendar — takes 2 minutes"

package/skill-cards/life-admin.md

@@ -0,0 +1,26 @@
+---
+domain: life-admin
+triggers: life admin, upcoming week, weekly prep, bills due, birthdays, errands, personal logistics, what's coming up, week ahead, sunday prep
+tools: queue_add, calendar.events.today
+name: godmode-life-admin
+version: 1.0.0
+description: "Handles personal logistics, weekly prep, and life administration"
+keywords: ["life admin", "upcoming week", "weekly prep", "bills due", "birthdays"]
+author: godmode-team
+clawhub: true
+---
+
+# Life Admin — Weekly Personal Logistics Review
+
+When the user asks about upcoming personal logistics, errands, or weekly prep — route to the weekly-life-admin skill.
+
+## How to Use
+1. Use `queue_add` with skill `weekly-life-admin`, taskType `task`, persona `life-admin`
+2. The skill checks: next 7 days calendar, bills due, renewals, birthdays, pending errands
+3. Output: day-by-day checklist, time-sensitive items first
+
+## When to Trigger
+- "What's coming up this week?"
+- "Any bills due?"
+- "Do my weekly life admin"
+- Runs automatically weekly Sunday 7pm via cron

package/skill-cards/meetings.md

@@ -0,0 +1,42 @@
+---
+domain: meetings
+triggers: last call, analyze call, meeting recording, transcript, fathom, recording, what did we discuss, call summary, call notes, meeting notes, debrief call, review call, action items from call, follow up from call, what happened on the call
+tools: fathom.listMeetings, fathom.getMeeting, fathom.ingest
+name: godmode-meetings
+version: 1.0.0
+description: "Analyzes meeting recordings, transcripts, and extracts action items"
+keywords: ["last call", "analyze call", "meeting recording", "transcript", "fathom"]
+author: godmode-team
+clawhub: true
+---
+## When to Use
+- User mentions "last call", "my call", "the call", "that meeting" — always check Fathom first
+- Analyzing, summarizing, or debriefing a meeting/call
+- Extracting action items, decisions, or follow-ups from a call
+- Looking up what was discussed with a specific person
+
+## How to Use
+- `fathom.listMeetings` — list recent recordings (use `{ limit: 5 }` or `{ limit: 1 }` for "last call")
+- `fathom.getMeeting` — get full details including transcript, summary, action items `{ id: <recordingId> }`
+- `fathom.ingest` — pull a specific recording from the Fathom API by ID `{ recordingId: <id> }`
+- Fathom is ALWAYS the source for call recordings. NEVER ask the user where the recording is — just check Fathom.
+
+## Workflow
+1. Call `fathom.listMeetings` to find the relevant recording
+2. If user said "last call" — grab the most recent one
+3. If user mentioned a person — match against attendee names/emails
+4. Call `fathom.getMeeting` with the recording ID for full transcript + summary
+5. Analyze, summarize, extract action items, or answer the user's question
+
+## Gotchas
+- Recordings arrive via webhook after the call ends — there may be a few minutes delay
+- The meeting queue file is at `~/godmode/data/meeting-queue.json` — don't read it directly, use the RPC
+- Transcripts can be long — summarize before presenting unless the user asks for the full thing
+- Action items from Fathom are auto-extracted — cross-reference with what the user actually wants to do
+- If `fathom.listMeetings` returns empty, the webhook may not be configured — suggest `fathom.setupWebhook`
+
+## Tips
+- After analyzing a call, offer to create GodMode tasks from action items
+- Cross-reference attendees with vault people files via secondBrain.search
+- Suggest updating person memory files with new context from the call
+- If external attendees were present, offer to draft a follow-up email

package/skill-cards/meta-problem-solver.md

@@ -0,0 +1,52 @@
+---
+domain: strategy
+triggers: big project, complex request, strategic decision, help me think through, first principles, break this down, what should I do about, hard problem, tricky situation, figure out
+name: godmode-meta-problem-solver
+version: 1.0.0
+description: "Breaks down complex problems using first-principles thinking"
+keywords: ["big project", "complex request", "strategic decision", "help me think through", "first principles"]
+author: godmode-team
+clawhub: true
+---
+## When to Use
+
+Run this BEFORE the adversarial-board or any delegation. Think before you act.
+
+Use when the user brings a complex, ambiguous, or high-stakes request. This is a thinking pattern, not a tool — it structures your reasoning before you make recommendations or delegate work.
+
+## First Principles Decomposition
+
+Work through these steps internally before responding:
+
+### 1. What is actually true here?
+Strip away assumptions. What do we know for certain vs. what are we assuming? Pull facts from memory and vault — don't rely on vibes.
+
+### 2. Inversion — What would make this definitely fail?
+List the top 3-5 failure modes. Work backwards from catastrophe. If you can prevent these, the path forward is clearer.
+
+### 3. Second-order effects
+What happens AFTER the obvious outcome? If the user launches this product, what happens to their time? Their team? Their existing commitments? Think two moves ahead.
+
+### 4. Constraint mapping
+Separate real constraints (budget, time, physics) from assumed constraints ("we can't do that", "that's not how it works"). Challenge assumed constraints — they're often wrong.
+
+### 5. Job-to-be-done
+What problem is the user ACTUALLY solving? Not what they asked for — what they need. A user asking for "a landing page" might actually need "proof that people want this product."
+
+### 6. Output: Problem Brief
+Before making any recommendation, synthesize a brief:
+- **True problem:** (1-2 sentences)
+- **Real constraints:** (list)
+- **Failure modes:** (top 3)
+- **Key unknowns:** (what we still need to learn)
+
+## Context Gathering
+
+Use memory search and vault lookup to pull relevant context before reasoning. Past decisions, user preferences, and domain knowledge all improve the decomposition.
+
+## What This Feeds
+
+The problem brief from this step feeds into:
+- **adversarial-board** — the board debates better with a structured brief
+- **delegate** — agents scope better when the problem is clear
+- **project-orchestrator** — the full pipeline starts here

package/skill-cards/people.md

@@ -0,0 +1,39 @@
+---
+domain: people
+triggers: who is, person, contact, team, coworker, client, relationship, met with, meeting with, attendee, attendees, who was, who's the, talked to, email, invite, admin, member, onboard, add user
+tools: secondBrain.search, secondBrain.memoryBankEntry, secondBrain.memoryBank
+name: godmode-people
+version: 1.0.0
+description: "Manages contacts, relationships, and people context from memory"
+keywords: ["who is", "person", "contact", "team", "coworker"]
+author: godmode-team
+clawhub: true
+---
+## When to Use
+- User mentions a person by name
+- Meeting prep — look up attendees before the meeting
+- User asks "who is X" or "what do we know about X"
+- ANY reference to a person in conversation
+
+## How to Use
+- `secondBrain.memoryBankEntry` — { name } — get a specific person's file
+- `secondBrain.memoryBank` — list all people/company files
+- `secondBrain.search` — { query: "person name" } — broader search
+
+## Lookup Chain for People
+1. Check memory results above — memory may already have relevant facts
+2. secondBrain.memoryBankEntry with their name
+3. secondBrain.search with their name + context
+4. ONLY THEN say you don't have info on them
+
+## Gotchas
+- People files are in 06-Brain/People/ — one file per person
+- Names may be stored differently (first name only, nickname, full name) — try variations
+- Company affiliation is often in the person's file — don't search separately unless needed
+- Some people files may be sparse — combine with memory results
+
+## Tips
+- Before ANY meeting, look up every attendee — this is the #1 way to show competence
+- When user says "I talked to Sarah", immediately search for Sarah's people file
+- After meetings, suggest updating the person's file with new context
+- Connect the dots: "Sarah mentioned the Q2 launch — I see that's also on your priorities"

package/skill-cards/personal-brand.md

@@ -0,0 +1,71 @@
+---
+domain: creative
+triggers: personal brand, positioning, content strategy, content pillars, storytelling, brand framework, build my brand, thought leadership, content plan, audience building
+name: godmode-personal-brand
+version: 1.0.0
+description: "Develops personal brand strategy, content pillars, and positioning"
+keywords: ["personal brand", "positioning", "content strategy", "content pillars", "storytelling"]
+author: godmode-team
+clawhub: true
+---
+## When to Use
+
+When the user wants to build, refine, or execute a personal brand strategy. This covers positioning, storytelling, content pillars, and distribution.
+
+## Brand Framework
+
+Work through these steps with the user. Pull context from memory and vault (role, industry, goals, past content, audience data).
+
+### 1. Positioning — What Unique Angle Do You Own?
+
+Find the intersection of:
+- **Skills** — what you're demonstrably good at
+- **Experience** — what you've lived through that others haven't
+- **Perspective** — what you believe that's contrarian or underserved
+
+The best positioning is specific. "AI consultant" is weak. "The chiropractor who automated his practice with AI and now teaches others" is strong.
+
+### 2. Storytelling Architecture
+
+Map the user's story to the hero's journey:
+- **Struggle** — what was broken, painful, or frustrating
+- **Discovery** — the insight, tool, or shift that changed things
+- **Transformation** — the measurable result and new reality
+
+This narrative anchors all content. Every post, video, or thread circles back to this arc.
+
+### 3. Content Pillars (3-5 Themes)
+
+Define 3-5 topics the user will be known for. Each pillar should:
+- Connect to their positioning
+- Have enough depth for 50+ pieces of content
+- Appeal to their target audience's pain points or aspirations
+
+### 4. Hook Frameworks
+
+Proven patterns for grabbing attention:
+- **Contrarian take** — "Everyone says X. Here's why that's wrong."
+- **Personal story + lesson** — "Last week I [experience]. Here's what I learned."
+- **How-to with specificity** — "How I [result] in [timeframe] using [method]"
+- **Behind the scenes** — "Here's exactly how I [process]"
+- **Numbers** — "I [action] for [duration]. Here are [N] things I learned."
+
+### 5. Constraint-as-Asset Framing
+
+Turn limitations into credibility:
+- Time constraints → "I built this in 30 min/day because I have 3 kids — if I can do it, so can you"
+- Small team → "No marketing department — just me and AI tools"
+- Niche market → "I know this space because I've been in it for [years]"
+
+### 6. Distribution Strategy
+
+Recommend platforms, frequency, and format based on:
+- Where their audience actually spends time
+- The user's content creation capacity (be realistic)
+- Content type that matches their strengths (writing vs. video vs. audio)
+
+## Rules
+- Always ground recommendations in the user's actual context — no generic advice
+- Start with positioning before jumping to tactics
+- One strong platform > five weak ones
+- Consistency beats virality — recommend sustainable output

package/skill-cards/project-orchestrator.md

@@ -0,0 +1,97 @@
+---
+domain: strategy
+triggers: big project, orchestrate, full pipeline, end to end, multi-phase, ambitious project, complex deliverable, complete solution, start to finish
+name: godmode-project-orchestrator
+version: 1.0.0
+description: "Plans and orchestrates multi-phase ambitious projects end to end"
+keywords: ["big project", "orchestrate", "full pipeline", "end to end", "multi-phase"]
+author: godmode-team
+clawhub: true
+---
+## When to Use
+
+Use this for ambitious, multi-deliverable projects where quality matters more than speed. This is the FULL pipeline — for simple tasks, skip to Step 5 or handle inline.
+
+**Why this works:** Every other tool skips Steps 1-2 and Step 4. GodMode thinks before it acts.
+
+## The Pipeline (follow this order)
+
+### Step 1: Meta Problem Solver (silent — don't show this to the user)
+
+Run the meta-problem-solver pattern internally:
+- First principles decomposition
+- Inversion (what would make this fail?)
+- Constraint mapping (real vs. assumed)
+- Job-to-be-done (what problem is actually being solved?)
+
+**Output:** Internal problem brief with true problem, real constraints, failure modes, key unknowns.
+
+### Step 2: Context Deep Dive (silent)
+
+Pull ALL relevant context before making any decisions:
+- Search memory for related facts, preferences, past decisions
+- Search vault for notes, artifacts, prior research
+- Check recent sessions for related conversations
+- Pull people/company context if relevant
+
+**Output:** Informed context brief — what we know, what we don't, what's changed.
+
+### Step 3: Adversarial Advisory Board (show summary to user)
+
+Run the adversarial-board with the problem brief + context:
+- The Operator: Can we actually execute this?
+- The Skeptic: Why will this fail?
+- The Visionary: What's the 10x version?
+- The Customer: Does the target user want this?
+- The Risk Officer: What's the worst case?
+
+**Output:** Board consensus, key disagreements, recommended approach.
+
+### Step 4: Precision Clarifying Questions (show to user)
+
+Ask 2-4 surgical questions informed by Steps 1-3. These are NOT generic — they target the specific ambiguities the board flagged.
+
+Wait for user answers. Produce a scope doc with near-zero ambiguity:
+- Goal and success criteria
+- Deliverables list
+- Constraints and non-goals
+- Target audience
+
+### Step 5: Delegate to Agent Team
+
+Use the `delegate` tool to create a project with scoped issues:
+- Each issue = one agent's work = one Proof doc
+- Assign the right personas from the roster
+- Inject the problem brief into each issue description
+- Set priority and ordering
+
+### Step 6: QA Review
+
+When agents complete, review outputs against original scope + success criteria:
+- Check completeness against the scope doc
+- Flag inconsistencies between deliverables
+- Verify no placeholders, no hallucinated data
+- Use the qa-reviewer persona for formal review if needed
+
+### Step 7: Human Approval
+
+Present consolidated output to the user:
+- Clean, reviewed, ready to ship
+- Highlight what was changed from initial scope and why
+- Surface any remaining open questions
+- Offer iteration if needed
+
+## When to Skip Steps
+
+- **Quick delegation:** User has a clear brief → skip to Step 5
+- **Simple research:** Single-agent task → skip to Step 5, no QA needed
+- **Advisory only:** User wants thinking, not deliverables → Steps 1-4 only
+- **Iteration:** User is refining existing work → Step 6-7 loop only
+
+## Relationship to Other Skill Cards
+
+- **meta-problem-solver** — Step 1 of this pipeline
+- **context-deep-dive** — Step 2 of this pipeline
+- **adversarial-board** — Step 3 of this pipeline
+- **delegate** — Step 5 execution tool
+- **project-pipeline** — Specialist routing templates (website, campaign, sales) that plug into Step 5

package/skill-cards/project-pipeline.md

@@ -0,0 +1,78 @@
+---
+domain: projects
+triggers: build me, create a website, landing page, project, app, full project, end to end, design and build, need a site, new product, launch
+tools: queue_add, queue_check, queue_action, proof_editor, queue_steer
+name: godmode-project-pipeline
+version: 1.0.0
+description: "Builds full projects like websites, landing pages, and apps"
+keywords: ["build me", "create a website", "landing page", "project", "app"]
+author: godmode-team
+clawhub: true
+---
+## When to Use
+- User asks for a multi-disciplinary project (website, app, campaign, product launch)
+- Work that needs multiple specialists: design, copy, code, SEO, etc.
+- Anything where a single agent would produce mediocre results because it lacks domain expertise in all areas
+
+## Chief of Staff Protocol
+You are the chief of staff. Your job is NOT to do the work. Your job is to:
+1. **Scope the project** — ask questions until you have a complete brief
+2. **Break it into specialist tasks** — assign each to the right agent
+3. **Chain the pipeline** — each task feeds the next via handoff context
+4. **Review deliverables** — bring results back to the user for approval
+5. **Iterate** — if the user wants changes, route feedback to the right agent
+
+## Discovery Phase (ALWAYS do this first)
+Before queuing anything, ask the user:
+- What is this for? Who is the audience?
+- What's the goal? (conversions, awareness, information, sales)
+- Any existing brand guidelines, copy, or design references?
+- What's the timeline?
+- Any specific requirements or constraints?
+
+Do NOT start the pipeline until you have clear answers. A vague brief produces vague output.
+
+## Pipeline Templates
+
+### Website / Landing Page
+1. **Brand Guardian** (`brand-guardian`, creative) — Define brand voice, color palette, typography, layout direction based on the brief. Deliverable: brand guide snippet.
+2. **Content Writer** (`content-writer`, creative) — Write all page copy using the brand guide. Deliverable: complete copy doc with headlines, body, CTAs.
+3. **UX Researcher** (`ux-researcher`, research) — If the user has an existing site or competitor references, audit the UX. Deliverable: layout recommendations, user flow.
+4. **Frontend Developer** (`frontend-developer`, coding) — Build the site using the copy + brand guide + UX recommendations. Deliverable: working code.
+5. **SEO Specialist** (`seo-specialist`, analysis) — Audit the built site for SEO. Deliverable: meta tags, structured data, keyword recommendations.
+6. **Code Reviewer** (`code-reviewer`, review) — Final review of the code. Deliverable: review with blocker/suggestion/nit findings.
+
+### Content Campaign
+1. **Researcher** (`researcher`, research) — Research the topic, audience, competitors. Deliverable: research brief with sources.
+2. **Content Writer** (`content-writer`, creative) — Write the core content using research. Deliverable: article/post/newsletter.
+3. **LinkedIn Creator** (`linkedin-creator`, creative) — Adapt content for LinkedIn. Deliverable: 3-5 posts with hook variants.
+4. **SEO Specialist** (`seo-specialist`, analysis) — Optimize for search. Deliverable: keyword targets, meta, internal linking plan.
+
+### Sales Campaign
+1. **Researcher** (`researcher`, research) — Research the target market, ICP, competitors. Deliverable: market brief.
+2. **Outbound Strategist** (`outbound-strategist`, creative) — Design sequences and messaging. Deliverable: ICP definition + email sequences.
+3. **Proposal Strategist** (`proposal-strategist`, creative) — Create pitch materials. Deliverable: win themes + proposal outline.
+4. **Discovery Coach** (`discovery-coach`, analysis) — Prep discovery call framework. Deliverable: call prep sheets + question sequences.
+
+## How to Chain Tasks
+Use `queue_add` with `handoff_summary` and `handoff_deliverable` to pass context between agents:
+- handoff_summary: "Brand Guardian defined the visual identity and voice. Key decisions: [summary]"
+- handoff_deliverable: "Use the brand guide above to write all page copy. Maintain the voice and tone."
+
+## Live Output via Proof
+Each queued agent automatically gets a Proof document for live output. The user can:
+- Watch agent progress in real-time in the sidebar
+- Steer mid-task via `queue_steer` if the agent is going in the wrong direction
+- Review and edit deliverables directly in the Proof doc before approving
+
+When reviewing agent output, open the Proof doc with `proof_editor` action `open` to show it in the sidebar.
+
+For writing-heavy deliverables, create the Proof doc first so the ally and the user can collaborate before the queue item finishes.
+
+## Rules
+- ALWAYS scope before queuing — you are the chief of staff, not a task router
+- Queue tasks in order — wait for each to complete before queuing the next (the output is the input for the next agent)
+- Bring every deliverable back to the user for review before moving to the next stage
+- If the user rejects a deliverable, re-queue to the SAME agent with specific feedback
+- Skip pipeline stages that don't apply (e.g., no UX audit if building from scratch with no reference)
+- The user should never have to manage the pipeline — you manage it, they review results

package/skill-cards/proof-editor.md

@@ -0,0 +1,28 @@
+---
+domain: files
+triggers: write a doc, collaborative doc, proof, co-edit, watch me write, live document, share document
+tools: proof_editor, queue_steer
+name: godmode-proof-editor
+version: 1.0.0
+description: "Collaborative document co-editing with provenance tracking"
+keywords: ["write a doc", "collaborative doc", "proof", "co-edit", "watch me write"]
+author: godmode-team
+clawhub: true
+---
+## When to Use
+- The user wants to watch the document take shape live
+- The ally should co-write with the user in a shared draft
+- A background agent needs a live surface the user can steer
+
+## How to Use Proof
+1. Create a Proof doc before drafting starts
+2. Keep the doc updated as work progresses, not only at the end
+3. Remind the user they can edit the document directly or steer via chat
+4. Use comments or suggestions for targeted steering
+
+## Good Fits
+- Email drafts
+- Blog posts
+- Research briefs
+- Proposals
+- Launch plans