@godmode-team/godmode 1.7.2 → 1.8.2

package/skill-cards/quality-gate.md

@@ -0,0 +1,57 @@
+---
+domain: quality-gate
+triggers: review, check, validate, qa, quality, verify, fact check, before sending, before publishing, is this good, proofread, double check
+tools: queue_add
+name: godmode-quality-gate
+version: 1.0.0
+description: "Reviews and validates work before publishing or sending"
+keywords: ["review", "check", "validate", "qa", "quality"]
+author: godmode-team
+clawhub: true
+---
+## When to Use
+- After any agent completes work that will be published, sent, or acted on
+- When the user asks you to validate or review something
+- Automatically for high-stakes outputs (ads, client deliverables, public content)
+- When an agent's trust score is below 6/10 — route through QA before delivering
+
+## Quality Gate Routing
+Match the right reviewer to the content type:
+
+| Content Type | Reviewer | When |
+|---|---|---|
+| Marketing copy, ads, VSLs, emails, landing pages | `qa-copy-reviewer` | Always for client-facing content |
+| Research, analysis, reports with factual claims | `qa-fact-checker` | Always for research outputs |
+| General agent output, mixed content | `qa-reviewer` | When unsure or for general QA |
+
+## How to Use
+1. When an agent finishes, check: is this output going to be published, sent to a client, or acted on?
+2. If yes → queue a review with the appropriate QA agent before delivering to the user
+3. Include the original task description AND the agent's output in the QA queue item description
+4. If the QA agent returns FAIL → send corrections back to the original agent, re-run, re-review
+5. If PASS → deliver to user's inbox with the confidence tag from the review
+
+## Queue Item Format for QA
+```
+Title: QA Review: [original task title]
+Description:
+## Original Task
+[paste the original task description]
+
+## Agent Output to Review
+[paste the agent's output]
+
+## Review Instructions
+Review this output against your checklist. Be thorough.
+```
+
+## When to Skip QA
+- Internal notes and research the user asked for casually
+- Quick answers the user will obviously verify themselves
+- Draft iterations the user is actively co-editing in Proof
+- When the user explicitly says "just give me a rough draft" or "skip the review"
+
+## Tips
+- The QA loop should be invisible to the user — they just see better output
+- If an agent keeps failing QA, that's a signal to update its persona with corrections
+- QA agents also get scored in the inbox — the feedback loop applies to reviewers too

package/skill-cards/quarterly-review.md

@@ -0,0 +1,26 @@
+---
+domain: quarterly-review
+triggers: quarterly review, quarter goals, quarterly, how did the quarter go, quarter recap, quarterly report, quarter priorities, next quarter, q1, q2, q3, q4
+tools: queue_add
+name: godmode-quarterly-review
+version: 1.0.0
+description: "Runs quarterly goal reviews, recaps, and priority planning"
+keywords: ["quarterly review", "quarter goals", "quarterly", "how did the quarter go", "quarter recap"]
+author: godmode-team
+clawhub: true
+---
+
+# Quarterly Review — Goals, Metrics & Priorities
+
+When the user asks about quarterly goals, performance, or wants to plan the next quarter — route to the quarterly-review skill.
+
+## How to Use
+1. Use `queue_add` with skill `quarterly-review`, taskType `analysis`, persona `executive-briefer`
+2. The skill reviews: goal status, key metrics, wins, misses, patterns
+3. Output: 1-page executive brief with next-quarter priorities (3 goals + start/stop/continue)
+
+## When to Trigger
+- "How did this quarter go?"
+- "Let's do a quarterly review"
+- "Plan next quarter's goals"
+- Runs automatically at quarter boundaries via cron

package/skill-cards/queue.md

@@ -0,0 +1,40 @@
+---
+domain: queue
+triggers: queue, delegate, background, agent, run this, can you do, draft, research for me, write this up, code review, research, deep dive
+tools: queue_add, queue_check, queue_action
+name: godmode-queue
+version: 1.0.0
+description: "Manages the background agent queue for delegated tasks"
+keywords: ["queue", "delegate", "background", "agent", "run this"]
+author: godmode-team
+clawhub: true
+---
+## When to Use
+- User wants work done in the background (research, drafting, code review, analysis)
+- Complex tasks that benefit from a dedicated agent with a full context window
+- Anything that takes more than a quick chat response
+
+## How to Use
+- `queue_add` tool — { title, description, taskType, persona?, priority? }
+- `queue_check` tool — check status of queued items
+- `queue_action` tool — { id, action } — approve, reject, retry, or remove a queue item
+
+## Workflow
+1. Scope the work clearly in the description — be specific about deliverables
+2. Pick the right taskType: research | coding | creative | analysis | review | ops | task
+3. The system matches a persona from the agent-roster based on taskType
+4. User gets notified when output is ready for review
+5. User approves, rejects (with feedback → lesson), or edits
+
+## Gotchas
+- ALWAYS confirm with the user before queuing — "Want me to queue that up?"
+- The description IS the agent's prompt — make it detailed and specific
+- Don't queue trivial things — if you can answer in chat, just answer
+- Queue items need approval before they're "done" — remind user to review
+- If rejected, the feedback becomes a lesson for future runs
+
+## Tips
+- Frame queue items like a senior engineer writing a perfect ticket
+- Include context: who is this for, what's the goal, what format is expected
+- For research: specify what sources to check, what to ignore, depth expected
+- For creative: include tone, audience, length, examples of good output

package/skill-cards/screenpipe.md

@@ -0,0 +1,49 @@
+---
+domain: screenpipe
+triggers: screenpipe, screen capture, ambient memory, screen recording, screen history, what was on my screen, what was I looking at, screen recall
+tools: ingestion.screenpipeStatus, ingestion.screenpipeConfigure, ingestion.screenpipeToggle, ingestion.runPipeline, secondBrain.search
+name: godmode-screenpipe
+version: 1.0.0
+description: "Manages Screenpipe ambient memory — screen & audio capture, setup, and recall"
+keywords: ["screenpipe", "screen", "capture", "ambient", "recall"]
+author: godmode-team
+clawhub: true
+---
+## When to Use
+- User mentions Screenpipe (setup, status, configuration, troubleshooting)
+- User asks "what was on my screen" or wants to recall something they saw
+- User wants to configure blocked apps, retention, or privacy settings
+- Screenpipe shows as offline in the Engine panel
+
+## How to Use
+- `ingestion.screenpipeStatus` — check if Screenpipe is running, get current config
+- `ingestion.screenpipeConfigure` — { enabled?, blockedApps?, retention?, privacy? } — update settings
+- `ingestion.screenpipeToggle` — quick enable/disable toggle
+- `ingestion.runPipeline` — { pipeline: "screenpipe-hourly" } — manually trigger ingestion
+- `secondBrain.search` — search for Screenpipe-captured content in the vault
+
+## Setup Flow
+1. Check status: `ingestion.screenpipeStatus`
+2. If not installed: "Install with `brew install screenpipe` (macOS) or download from screenpi.pe"
+3. If installed but not running: "Start with `screenpipe` in terminal"
+4. If running but not enabled: `ingestion.screenpipeToggle` to enable
+5. Configure blocked apps (e.g., banking, health apps) via `ingestion.screenpipeConfigure`
+
+## Architecture
+- Screenpipe runs locally on the user's machine (localhost:3030)
+- GodMode ingests screen/audio data via hourly → daily → weekly → monthly compression
+- Summaries are stored in memory/screenpipe/ and forwarded to Honcho
+- Entity extraction pulls out people, decisions, URLs from screen activity
+- All data stays local — no cloud upload
+
+## Gotchas
+- Screenpipe must be running as a separate process — GodMode doesn't start it
+- Default API URL is localhost:3030, override with SCREENPIPE_API_URL env var
+- Privacy: configure blockedApps to exclude sensitive apps (banking, medical)
+- The ingestion pipeline runs hourly — recent screen data may not be indexed yet
+
+## Tips
+- When user asks about Screenpipe, ALWAYS check status first with ingestion.screenpipeStatus
+- Never evaluate whether Screenpipe is "worth using" — it's already integrated. Help configure it.
+- If offline, guide the user to start it, don't suggest alternatives
+- Frame privacy controls positively: "Let's make sure sensitive apps are excluded"

package/skill-cards/second-brain.md

@@ -0,0 +1,46 @@
+---
+domain: second-brain
+triggers: vault, note, notes, obsidian, search, find, look up, brain, knowledge, what do we know, remember, screenpipe, screen recall
+tools: secondBrain.search, secondBrain.identity, secondBrain.memoryBank, secondBrain.memoryBankEntry
+name: godmode-second-brain
+version: 1.0.0
+description: "Searches and manages the Memory vault knowledge base"
+keywords: ["vault", "note", "notes", "obsidian", "search"]
+author: godmode-team
+clawhub: true
+---
+## When to Use
+- User asks about a person, company, project, or any stored knowledge
+- You need context about something and memory results above are insufficient
+- Looking up past research, meeting notes, or project details
+- ANY time you're about to ask the user for info — search here first
+
+## How to Use
+- `secondBrain.search` — { query, scope?, limit? } — hybrid QMD 2.0 search (semantic + BM25 + LLM reranking) across the vault. Scopes: "all" (default), "sessions", or vault collection. Falls back to file walk if QMD unavailable.
+- `secondBrain.identity` — read USER.md and SOUL.md identity files
+- `secondBrain.memoryBank` — list all people/company files
+- `secondBrain.memoryBankEntry` — { name } — get a specific person/company file
+
+## Vault Structure (PARA)
+- 00-Inbox/ — unsorted captures, queue outputs land here
+- 01-Daily/ — daily briefs (YYYY-MM-DD.md)
+- 02-Projects/ — active project notes
+- 03-Areas/ — ongoing areas of responsibility
+- 04-Resources/ — research, references
+- 06-Brain/ — People/, Companies/, Knowledge/ files
+- 08-Identity/ — USER.md, SOUL.md
+- 99-System/ — system files, agent-roster, skill-cards
+
+## Gotchas
+- Search uses QMD 2.0 hybrid retrieval (semantic + full-text + reranking) — natural language queries work best but keywords also work via BM25
+- People files are in 06-Brain/People/ — search by name
+- If search returns nothing, try broader terms or different phrasing
+- Vault is the source of truth for long-term knowledge — memory is for conversational context
+- All searches are logged to retrieval-log.jsonl for trajectory analysis
+- Screenpipe ambient memory (screen/audio captures) feeds into the vault via hourly ingestion — use `ingestion.screenpipeStatus` for status, `secondBrain.search` to query captured content
+
+## Tips
+- When user mentions a person, immediately search for their people file
+- Cross-reference meeting attendees with people files before meeting prep
+- For "what do we know about X" — search vault, then summarize findings
+- Don't quote raw vault content — synthesize it naturally into conversation

package/skill-cards/standup-prep.md

@@ -0,0 +1,26 @@
+---
+domain: standup-prep
+triggers: standup, stand up, standup prep, what did I do yesterday, morning prep, daily prep, what's on my plate, morning summary, daily summary
+tools: queue_add, calendar.events.today, tasks.list
+name: godmode-standup-prep
+version: 1.0.0
+description: "Prepares daily standup summaries and morning briefings"
+keywords: ["standup", "stand up", "standup prep", "what did I do yesterday", "morning prep"]
+author: godmode-team
+clawhub: true
+---
+
+# Standup Prep — Daily Morning Summary
+
+When the user wants a standup summary or morning briefing — route to the daily-standup-prep skill.
+
+## How to Use
+1. Use `queue_add` with skill `daily-standup-prep`, taskType `analysis`, persona `meeting-prep`
+2. The skill reviews yesterday's activity, today's calendar, and due tasks
+3. Output: Yesterday / Today / Blockers format — readable in 30 seconds
+
+## When to Trigger
+- "What did I do yesterday?"
+- "Prep my standup"
+- "What's on my plate today?"
+- Runs automatically weekdays 8am via cron

package/skill-cards/tasks.md

@@ -0,0 +1,34 @@
+---
+domain: tasks
+triggers: task, todo, to-do, remind, reminder, overdue, priority, priorities, what should i, what do i need, i need to, need to get done, focus on, save
+tools: tasks.list, tasks.add, tasks.update
+name: godmode-tasks
+version: 1.0.0
+description: "Manages tasks, to-dos, reminders, and priorities"
+keywords: ["task", "todo", "to-do", "remind", "reminder"]
+author: godmode-team
+clawhub: true
+---
+## When to Use
+- User asks about their tasks, to-dos, priorities, what to work on
+- Overdue task surfacing — proactively mention when tasks are past due
+- Adding, completing, or updating tasks
+
+## How to Use
+- `tasks.list` — all tasks with status, dueDate, workspace
+- `tasks.add` — { title, dueDate?, workspace?, status? }
+- `tasks.update` — { id, status?, title?, dueDate? }
+- Priorities from today's daily brief are often already injected above — check there FIRST
+
+## Gotchas
+- Tasks are a flat list — no subtasks, no hierarchy, no boards. This is intentional.
+- For complex projects, create a markdown artifact instead of 20 subtasks
+- Status values: "pending" | "in-progress" | "done" | "archived"
+- dueDate format: YYYY-MM-DD string, not a Date object
+- Don't create duplicate tasks — call tasks.list first to check
+
+## Tips
+- When user says "I need to...", create the task immediately — don't ask for confirmation
+- Surface overdue tasks naturally in conversation, don't nag
+- Cross-reference with daily brief priorities when suggesting what to work on next
+- For big projects, suggest: "Want me to draft a project plan as a markdown artifact?"

package/skill-cards/visual-qa.md

@@ -0,0 +1,56 @@
+---
+domain: visual-qa
+triggers: qa, visual qa, screenshot, ui check, does it look right, check the ui, visual test, ui test, screenshot tabs, visual review
+tools: queue_add
+---
+
+# Visual QA — Screenshot-Based UI Testing
+
+Automated visual inspection of every GodMode tab using `agent-browser`.
+
+## When to Use
+- After any agent session that modified files in `ui/src/`
+- Before merging a branch with UI changes
+- When the user asks "does it look right" or "check the UI"
+- After overnight builder agent sessions that touched the frontend
+- Before any release
+
+## How to Use
+
+Route to `godmode-builder` persona with the `visual-qa` skill:
+
+```
+queue_add({
+  title: "Visual QA — post-merge UI check",
+  description: "Run visual-qa skill. Screenshot all tabs, check for regressions.",
+  skill: "visual-qa",
+  priority: "high"
+})
+```
+
+The builder agent runs `./scripts/visual-qa.sh`, which:
+1. Builds the project (`pnpm build && pnpm build:ui`)
+2. Starts the Vite dev server on port 5175
+3. Opens each tab in a real browser via `agent-browser`
+4. Takes annotated screenshots + accessibility snapshots
+5. Runs basic health checks (blank pages, error elements)
+6. Generates a report at `.qa-reports/<timestamp>/REPORT.md`
+7. Kills the dev server
+
+## What It Catches
+- White-screen tabs (build broke something)
+- Missing interactive elements (buttons, inputs disappeared)
+- Error banners visible in the DOM
+- Empty tabs that should have content
+- Layout regressions visible in screenshots
+
+## What It Doesn't Catch
+- Subtle styling regressions (needs baseline comparison — future)
+- Backend-dependent content (needs running gateway)
+- Mobile responsiveness (runs at default viewport)
+
+## Tips
+- Use `--skip-build` if you just built: `./scripts/visual-qa.sh --skip-build`
+- Use `--tabs chat,today` to check only specific tabs
+- Screenshots are annotated with element labels — match them to the accessibility snapshot
+- Reports accumulate in `.qa-reports/` — add to `.gitignore`

package/skill-cards/workspace-memory.md

@@ -0,0 +1,51 @@
+---
+name: workspace-memory
+domain: memory
+triggers:
+  - share memory
+  - workspace memory
+  - team memory
+  - publish to workspace
+  - shared knowledge
+---
+
+# Workspace Memory — Publish Rules
+
+You have the `capture_thought` tool with a `scope` parameter. By default, all memory is **personal**. You may publish to a workspace when the information is clearly relevant to that team.
+
+## What to Publish (scope: workspace ID)
+
+- Project decisions and rationale
+- Technical discoveries relevant to the team
+- Client/customer requirements and feedback
+- Process documentation and workflows
+- Meeting outcomes and action items (non-sensitive)
+- Shared research findings
+
+## What NEVER to Publish (keep scope: personal)
+
+- Compensation, salary, equity, or benefits discussions
+- Performance reviews or feedback about individuals
+- Personal opinions about coworkers or management
+- HR matters, disciplinary issues, or complaints
+- Content the user marked as private, confidential, or off-record
+- Personal health, finances, or relationship matters
+- Login credentials, API keys, or secrets
+
+## Decision Framework
+
+When in doubt: **keep it personal.** The user can always ask you to share something later. You cannot un-share.
+
+Ask yourself: "Would the user be comfortable if every workspace member saw this?" If the answer isn't a clear yes, keep it personal.
+
+## How to Use
+
+```
+// Personal (default — no scope needed)
+capture_thought({ topic: "salary-research", content: "..." })
+
+// Workspace-scoped (explicitly published)
+capture_thought({ topic: "api-conventions", content: "...", scope: "patient-autopilot" })
+```
+
+When you publish to a workspace, mention it in chat: "I saved that to the PA workspace memory so the team has it."

package/skill-cards/x-twitter.md

@@ -0,0 +1,37 @@
+---
+domain: x-twitter
+triggers: twitter, tweet, tweets, tweeted, x.com, timeline, trending, what's happening, social, post, thread, bookmark, bookmarks, saying, discussions, draft a post, draft a tweet
+tools: x_read, x.search, x.readTweet, x.readThread, x.userTimeline, x.bookmarks
+name: godmode-x-twitter
+version: 1.0.0
+description: "Reads timelines, searches tweets, and drafts posts for X/Twitter"
+keywords: ["twitter", "tweet", "tweets", "tweeted", "x.com"]
+author: godmode-team
+clawhub: true
+---
+## When to Use
+- User asks about tweets, threads, Twitter/X content
+- Searching for what people are saying about a topic
+- Reading a specific tweet or thread URL
+- Checking bookmarks or someone's timeline
+
+## How to Use
+- `x_read` tool — versatile: read tweets, threads, articles, search, bookmarks
+  - Actions: search, readTweet, readThread, userTimeline, readArticle, bookmarks
+- `x.search` method — { query, maxResults? } — search X for topics
+- `x.readTweet` — { tweetId } — read a single tweet
+- `x.readThread` — { tweetId } — read a full thread
+- `x.userTimeline` — { username, maxResults? } — recent posts from a user
+- `x.bookmarks` — user's saved tweets
+
+## Gotchas
+- Requires XAI_API_KEY in ~/.openclaw/.env — if missing, check integrations.status
+- Uses Grok API (grok-4-1-fast-non-reasoning) under the hood
+- Rate limits apply — don't make rapid sequential calls
+- Tweet IDs are strings, not numbers
+- Some tweets may be protected/unavailable
+
+## Tips
+- When user shares an x.com URL, extract the tweet ID and read it automatically
+- For research tasks, combine X search with vault search for full context
+- Summarize threads concisely — don't dump raw tweet text

package/dist/godmode-ui/assets/dashboards-CrT3s0NG.js

@@ -1 +0,0 @@
-async function s(r,d){if(!r.client||!r.connected){r.dashboardsError="Not connected to gateway";return}r.dashboardsLoading=!0,r.dashboardsError=null;try{const a=await r.client.request("dashboards.list",d?{scope:d}:{});r.dashboardsList=a.dashboards,r.activeDashboardId=a.activeDashboard}catch(a){r.dashboardsError=a instanceof Error?a.message:"Failed to load dashboards"}finally{r.dashboardsLoading=!1}}async function i(r,d){if(!r.client||!r.connected){r.dashboardsError="Not connected to gateway";return}r.dashboardsLoading=!0,r.dashboardsError=null;try{const a=await r.client.request("dashboards.get",{id:d});r.activeDashboardId=d,r.activeDashboardManifest=a.manifest,r.activeDashboardHtml=a.html}catch(a){r.dashboardsError=a instanceof Error?a.message:"Failed to load dashboard"}finally{r.dashboardsLoading=!1}}async function e(r,d){if(!r.client||!r.connected)return;const a=(r.dashboardsList??[]).find(o=>o.id===d);if(!a)return;const n=!a.pinned;try{await r.client.request("dashboards.save",{id:a.id,title:a.title,description:a.description,scope:a.scope,pinned:n}),a.pinned=n,r.dashboardsList=[...r.dashboardsList??[]]}catch(o){r.dashboardsError=o instanceof Error?o.message:"Failed to toggle pin"}}async function c(r,d){if(!r.client||!r.connected)return!1;try{return await r.client.request("dashboards.remove",{id:d}),r.dashboardsList=(r.dashboardsList??[]).filter(a=>a.id!==d),r.activeDashboardId===d&&(r.activeDashboardId=null,r.activeDashboardHtml=null,r.activeDashboardManifest=null),!0}catch(a){return r.dashboardsError=a instanceof Error?a.message:"Failed to delete dashboard",!1}}export{c as deleteDashboard,i as loadDashboard,s as loadDashboards,e as toggleDashboardPin};