plugins/origin/skills/brief/SKILL.md
Session-start briefing from Origin. Reads the project status file (the /handoff-maintained ledger of Active/Backlog work), then loads identity, preferences, and topic-relevant memories so the agent walks in with context. Surfaces any memories the daemon has flagged for human revision before the session uses them. Invoked as `/brief [topic]`. Call FIRST at session start, before any other Origin verb.
npx skillsauth add davepoon/buildwithclaude briefInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Pull a curated session brief from Origin. Three sources, in order:
/handoff last wrote. Authoritative for
"what's left to do" right now.context MCP — identity, preferences, topic-relevant memories.
Background, not ledger.list_pending_revisions — daemon-flagged memories awaiting review.Status file wins on "what's next" because memories rank by topic similarity and surface stale items alongside fresh ones; the status file is the live ledger maintained per session.
Detect project root:
Bash: cd_repo=$(git -C "$PWD" rev-parse --show-toplevel 2>/dev/null); echo "${cd_repo:-no-git}"
<project> = basename (e.g. origin).no-git → <project> = cwd basename.Read ~/.origin/sessions/_status/<project>.md:
Bash: cat ~/.origin/sessions/_status/<project>.md
If the file exists, render its ## Last session, ## Active, and ## Backlog
sections verbatim at the top of the brief output, under a heading like
Status (last session <date>). This is the authoritative "what's left" frame.
If the file is missing, say nothing about it. First-time projects haven't been handed off yet.
Call the origin MCP server's context tool. If the user passed a topic
argument, pass it through. Otherwise infer scope from the working directory and
the conversation so far — don't ask the user.
context(topic="<args or inferred>", space=<inferred from cwd or recent turns>)
Scope inference rules:
topic: if user omitted args, pass the most recent topic from the
conversation (file or feature being discussed), or omit for a fresh
general brief at session start.space: from cwd. ~/Repos/origin/... → "origin". Other repos → repo
name. Outside any repo → omit. Always pass when scope is known; if
uncertain, run list_spaces later (post-PR-C) or omit./recall (more targeted)./capture./handoff.Treat the status file as the live ledger (what's next), and the context
memories as background (how the user thinks). When the status file says an
item is done but a memory still says it's pending, trust the status file —
memories don't auto-supersede. If you see drift, flag it inline rather than
parrot the stale memory.
Model how the user thinks. Their preferences, corrections, and past decisions tell you how they want to be helped, not just what they already know. Don't just look things up: adjust your behavior.
After loading context, call:
list_pending_revisions(limit=10)
If the result is empty, say nothing. Do not print "0 pending revisions" or any "all clear" line. The brief is already noisy enough.
If the MCP call errors, log a one-line warning and continue. Do not error out the brief.
If the result is non-empty, render a block at the end of the brief (after the context summary, before handing back to the user). The daemon returns rows already sorted by last_modified DESC; just slice the first three.
Each PendingRevisionItem carries target_source_id, revision_source_id, revision_content, source_agent, and last_modified. The original memory's content is not on this response. The block displays the proposed revision text and the target memory id; if the user wants to see the original before deciding, they can run /recall <target_source_id> first.
Pending revisions (<N> total, top 3 shown):
1. target: mem_abc123 (proposed by <source_agent or "daemon">)
revision: "Origin uses Turso libSQL fork (libSQL-server) for vectors..."
Action: accept (replace original) | dismiss (drop revision) | skip
2. ...
Inline accept/dismiss verbs map to:
accept_revision(target_source_id="<id>")dismiss_revision(target_source_id="<id>")If <N> > 3, end the block with one line:
Run `/review revisions` to walk the rest.
Do not auto-action anything. The user picks per item.
Note: this block surfaces all pending revisions, not just this session's, because revisions are about memories you may still be using right now, regardless of when the contradiction was flagged.
tools
Assesses the current state of the startup project and recommends what to focus on next. Use when there is a need or a question from the user to understand what the next steps are or what to focus on next.
data-ai
Use at the start of any conversation about a startup idea, product validation, founder strategy, or work inside a `startup/` workspace. Establishes file conventions, voice-input handling, subagent dispatch rules, and how to update each artifact safely. Activate before invoking any other startup-superpowers skill.
tools
Manages the founder's survey-based validation — crafting the right questions, deploying a survey to the internet, and analyzing results against hypotheses. Use when the founder wants to run a survey, create survey questions, validate hypotheses at scale, check how a survey is going, understand whether a survey is the right tool right now, or deploy a question set to get quantitative signal. Also bring this up if you believe that creating a survey to collect quantitative evidence may be useful at this point.
development
Guides the founder through designing and optionally building the simplest MVP or prototype that validates their current hypotheses. Use when the founder wants to build something to test assumptions, discusses what to build next, wants to interpret results from a live MVP, or is deciding whether the current approach is still right. Also use when a founder proposes something to build — the skill will check whether the proposed form is the simplest thing that generates honest signal.