Source profileQuality 86/100Review permissions

davepoon/buildwithclaude/plugins/origin/skills/brief/SKILL.md

brief

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.

Source repository stars
3,251
Declared platforms
0
Static risk flags
2
Last source update
2026-08-02
Source checked
2026-08-04

Decision brief

What it does—and where it fits

Pull a curated session brief from Origin. Three sources, in order:

Best for

  • Session start — call BEFORE any other Origin tool.
  • Major topic shift mid-session.
  • User says "catch me up", "what's the background on X", "remind me about Y".

Not for

  • Specific factual lookup → use /recall (more targeted).
  • Storing a new memory → use /capture.

Compatibility matrix

Platform support, with evidence labels

PlatformStatusEvidenceWhat to check
CodexNot declaredNo explicit evidencePortability before use
Claude CodeNot declaredNo explicit evidencePortability before use
CursorNot declaredNo explicit evidencePortability before use
Gemini CLINot declaredNo explicit evidencePortability before use
Open the compatibility checker

Installation

Inspect first. Install second.

The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

Source-detected install commandSource
npx skills add https://github.com/davepoon/buildwithclaude --skill "plugins/origin/skills/brief"
Safe inspection promptEditorial

Inspect the Agent Skill "brief" from https://github.com/davepoon/buildwithclaude/blob/13c9cb58201c74e15f8eb51522795d388ac4fe1b/plugins/origin/skills/brief/SKILL.md at commit 13c9cb58201c74e15f8eb51522795d388ac4fe1b. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.

Workflow

What the source asks the agent to do

  1. 01

    How to use the result

    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…

    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…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.
  2. 02

    1. Read project status file first

    Read /.origin/sessions/status/.md:

    If output is a path → = basename (e.g. origin).If no-git → = cwd basename.- If output is a path → = basename (e.g. origin). - If no-git → = cwd basename.
  3. 03

    2. Call context

    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.

    topic: if user omitted args, pass the most recent topic from thespace: from cwd. /Repos/origin/... → "origin". Other repos → repoCall 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.
  4. 04

    When to use

    Session start — call BEFORE any other Origin tool.

    Session start — call BEFORE any other Origin tool.Major topic shift mid-session.User says "catch me up", "what's the background on X", "remind me about Y".
  5. 05

    When NOT to use

    Specific factual lookup → use /recall (more targeted).

    Specific factual lookup → use /recall (more targeted).Storing a new memory → use /capture.End of session → use /handoff.

Permission review

Static risk signals and limitations

Reads files

low · line 16

The documentation asks the agent to read local files, directories, or repositories.

## 1. Read project status file first

Runs scripts

medium · line 21

The documentation asks the agent to run terminal commands or scripts.

Bash: cd_repo=$(git -C "$PWD" rev-parse --show-toplevel 2>/dev/null); echo "${cd_repo:-no-git}"

Runs scripts

medium · line 30

The documentation asks the agent to run terminal commands or scripts.

Bash: cat ~/.origin/sessions/_status/<project>.md

Evidence record

Why each signal appears

EvidenceSourceComputedTestedEditorial
SignalValueEvidence typeMeaning
Quality score86/100ComputedDocumentation, specificity, maintenance, and trust rules
Repository stars3,251SourceRepository attention, not individual Skill quality
Compatibility0 platformsSourceDeclared in the catalog source record
Usage guideautomated source guideEditorialGenerated or reviewed according to the visible evidence level

Pinned source

Provenance and original SKILL.md

Repository
davepoon/buildwithclaude
Skill path
plugins/origin/skills/brief/SKILL.md
Commit
13c9cb58201c74e15f8eb51522795d388ac4fe1b
License
MIT
Collected
2026-08-04
Default branch
main
View the original SKILL.md

/brief

Pull a curated session brief from Origin. Three sources, in order:

  1. Project status file — what /handoff last wrote. Authoritative for "what's left to do" right now.
  2. context MCP — identity, preferences, topic-relevant memories. Background, not ledger.
  3. 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.

1. Read project status file first

Detect project root:

Bash: cd_repo=$(git -C "$PWD" rev-parse --show-toplevel 2>/dev/null); echo "${cd_repo:-no-git}"
  • If output is a path → <project> = basename (e.g. origin).
  • If 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.

2. Call context

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.

When to use

  • Session start — call BEFORE any other Origin tool.
  • Major topic shift mid-session.
  • User says "catch me up", "what's the background on X", "remind me about Y".
  • Mid-session check-in to confirm assumptions.

When NOT to use

  • Specific factual lookup → use /recall (more targeted).
  • Storing a new memory → use /capture.
  • End of session → use /handoff.

How to use the result

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.

3. Pending revisions check

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: accept_revision(target_source_id="<id>")
  • dismiss: dismiss_revision(target_source_id="<id>")
  • skip: no call; the revision stays pending for the next /brief

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.