plugins/second-brain/skills/process-inbox/SKILL.md
Process accumulated inbox notes through the full pipeline (ingest, enrich, route, connect, link). User-facing orchestrator.
npx skillsauth add technicalpickles/pickled-claude-plugins process-inboxInstall 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.
Process accumulated inbox notes through the full pipeline: ingest, enrich, route, connect, link to daily note.
See references/pipeline.md for stage definitions and status flow.
npx @techpickles/sb config default
npx @techpickles/sb config vaults
If no vault configured:
Second brain not configured. Run /second-brain:setup first.
Load skill references:
second-brain:obsidian for tool mechanicsreferences/pipeline.md for stage definitionsreferences/routing-memory.md for learning loopreferences/routing.md for scoring algorithmreferences/connecting.md for connection discoveryreferences/daily-linking.md for daily note linkingreferences/sb-cli.md for sb command referencenpx @techpickles/sb inbox list --detail
Parse the JSON response. Group notes by status field (notes without status are raw).
Check for stale notes (captured more than 14 days ago based on captured frontmatter field).
Present summary:
Inbox: {total} notes
{n} raw (session notes awaiting ingestion)
{n} ingested (insights awaiting enrichment)
{n} enriched (notes awaiting routing)
{n} pending-review (need your input)
{n} routed (awaiting connection)
{n} connected (awaiting daily linking)
{If stale notes exist:}
Heads up: {n} notes have been in the inbox for over 2 weeks.
If inbox is empty:
Inbox is empty. Nothing to process.
Work through notes in pipeline order. Each stage picks up notes at its expected input status.
For each note with status: raw and type: session-notes:
ingest skill to split into individual insight notesIngested: {session filename} -> {n} insightsFor each note with status: ingested and type: insight:
enrich skill to create proper zettelkasten notesEnriched: {filename}For each note with status: enriched:
route skillRouted: {filename} -> {destination}references/routing-memory.mdAlso process any pre-existing pending-review notes from previous runs.
For each note with status: routed:
connect skillSkipped connections: qmd not available (once, not per note)For each note with status: connected:
link-daily skillsb daily append call when possibleLinked {n} notes to daily notePipeline complete:
{n} session notes ingested -> {m} insights extracted
{n} insights enriched
{n} notes routed ({auto} auto, {manual} manual)
{n} notes connected ({links} links added)
{n} notes linked to daily note
{n} notes still pending review
tools
--- name: writing-for-scannability description: Use when structuring prose so readers can skim it - drafting or restructuring READMEs, docs, PR or issue bodies, design docs, RFCs, or any long-form text where a wall of prose hides the structure. Also use when explicitly asked to make something scannable or skimmable, convert prose to a list, surface a buried list, fix a wall of text, or decide whether bullets or prose fit. Strong signal: text with parallel sentence shapes, contrast markers ("that
development
Ignore actually-lsp nudges for an ecosystem in this project. Use when the user wants to silence, dismiss, or ignore the LSP setup nudges for a specific ecosystem (Rust, TypeScript, Ruby), or invokes `/actually-lsp-ignore` directly. Writes `dismissed=true` to `.claude/actually-lsp.json`. Persistent across sessions for this project only.
tools
Diagnose and fix LSP setup for the current project's detected ecosystems (Rust, TypeScript, Ruby). Use when the SessionStart hook nudged about a missing LSP plugin, when the env isn't ready (no `bundle install`, no `cargo build`, missing server binary), when LSP calls are failing, or when the user invokes `/actually-lsp-doctor` directly. Walks the per-ecosystem state machine, reports what's missing, then runs the fix.
tools
--- name: investigating-runs description: Use whenever the user mentions a GitHub Actions / GHA run, even casually — invoke this skill before reaching for raw `gh` commands, because the bundled `gha-snapshot` helper distills `gh run view --log-failed` (a firehose) into a readable block with per-job status, failed-step log tails, and annotations. Specific triggers (any one is enough): a `github.com/.../actions/runs/...` URL; the phrase "GitHub Actions" or "GHA"; the `gh run` CLI; a failing workfl