Bridge Curator

bridge-curator is the periodic background-reflection skill. Once a week (configurable), it walks the Bridge's own state and asks three orthogonal questions:

1. Is the skill library still coherent? (Library pass)
2. Is the proposal queue still actionable? (Queue pass)
3. What has the system observed about how this user works lately? (User-pattern pass)

The output of all three phases is always proposals — markdown files under work/_learning/proposals/ with source.type: curator-suggestion. The curator never edits Bridge files directly. All accepts happen via /bridge-learn.

This is the deliberate inversion of the autonomy-maximalist curator pattern observed in some agentic frameworks (e.g. Hermes Agent's background-curator-fork). See rules/learning-autonomy.md § Layer B for the full design rationale.

When to run

• Manual: user says /bridge-curator, "bridge curator", "curator", etc.
• Scheduled: weekly via cron or /schedule, if configured in

bridge-config.yaml.learning.curator.schedule.

• Surface in `/briefing`: on the configured auto_surface_in_briefing

day (default Sunday), /briefing Stream D adds a "curator due / overdue" one-liner. Running the curator itself stays manual unless user opts into auto-run.

Arguments

Three passes

Pass 1 — Library

Full procedure in references/library-pass.md.

Scans skills/, protocols/, rules/, docs/. Detects:

• Sleeping skill — no invocation in skill-usage.jsonl for ≥30 days

(if Phase-4 telemetry on); else heuristic via skill-name in work/log.md

• Trigger overlap — two or more skills with significantly overlapping

trigger phrases in their description fields

• Description-budget buster — a SKILL.md description field that alone

exceeds 1536 chars (Skills 2.0 discovery budget)

• Umbrella candidate — three or more skills that share a clear parent

workflow and could be one skill with internal modes

• Stale doc — a doc whose last_updated: is older than the last edit

to anything it references

• Missing scope frontmatter — a skill or agent file without explicit

scope: (already caught by /bridge-audit Check 6, but the curator cross-references the audit-history JSON to escalate if recurring)

Each finding becomes a proposal in work/_learning/proposals/.

Pass 2 — Queue

Full procedure in references/queue-pass.md.

Scans work/_learning/proposals/. Detects:

• Stale pending — status: pending and created >30 days ago
• Same-target conflict — two pending proposals with the same

target.path and incompatible target.action

• Likely supersede — a newer proposal that is a strict superset of

an older one (covers same finding plus additional context)

• Drift in source — a proposal whose target.path has been edited in

git since the proposal was written (the diff_preview may be stale)

• Reject-pile accumulation — proposals/rejected/ has accumulated

>10 entries with the same target.type pattern, suggesting the underlying generator (postmortem questions, audit checks) is producing low-signal proposals that should be filtered upstream

Output: each cluster becomes a meta-proposal — a curator-suggestion that asks /bridge-learn to perform a specific consolidation action (accept-A-reject-B, defer-both, merge into combined).

Pass 3 — User patterns

Full procedure in references/user-pattern-pass.md.

Reads, in this order:

• work/log.md last 30 days
• work/done/YYYY-MM/<slug>/STATUS.md postmortems closed in window
• work/_learning/audit-trail.md accept/reject decisions in window
• work/_learning/proposals/rejected/*.md reasons in window
• work/_learning/trigger-corrections.md (if Phase-4 active)

Synthesizes 3-8 observations about how the user works. Format:

- <Observation in 1-2 sentences>.
  Evidence: <pointers — N postmortems, M rejections, K log entries>
  Strength: weak | medium | strong

Writes append-only to work/_learning/user-patterns.md under a new section ## YYYY-MM-DD — Weekly synthesis (n=<sessions>, n=<postmortems>).

Does NOT write to MEMORY.md. A strong-pattern observation may produce an additional proposal with target.type: memory that /bridge-learn can accept into the user's MEMORY.md via the normal proposal flow.

Minimum-signal threshold: if window contains fewer than 5 postmortems and 5 accept/reject events combined, the user-pattern pass produces an "insufficient signal" note instead of forced observations.

Output: Curator Report

After running, emit a single block:

═══ Bridge Curator — <YYYY-MM-DD> ═══

Library pass:   <N> findings → <K> proposals written
  • <severity> <topic-slug>  — <one-line>
  ...

Queue pass:    <N> findings → <K> meta-proposals written
  • <topic-slug> — <conflict-or-stale-or-supersede>
  ...

User-patterns: <N> observations appended to work/_learning/user-patterns.md
                <K> strong-pattern proposals (target.type: memory)
  • <observation excerpt>
  ...

→ Review via /bridge-learn  (current pending: <total>)

If --dry-run: same output, but report uses "would write" instead of "wrote", no files touched.

Proposal-file shape for curator-suggestions

Standard _schema.proposal.yaml with these field defaults:

source:
  type: curator-suggestion           # NEW source.type enum value
  evidence:
    - "work/_learning/audit-history/<ts>.json"     # if Phase 3 data drove it
    - "work/done/<month>/<slug>/STATUS.md#postmortem"  # if postmortem drove it
    - "skills/<name>/SKILL.md"                    # the affected file

severity: P2                         # default, P1 if recurring or strong
status: pending
scope: core | user (depends on target)

target:
  type: skill | standing_order | rule | doc | memory
  path: ...
  action: edit | delete | rename | create

proposal_type: structured | needs-triage

The source.evidence chain is always concrete — the curator must cite which files / scans led to the finding. No invented proposals.

Edge cases

• Empty Bridge (new install, no postmortems, no audit-history yet) →

all three passes return "insufficient signal — run more sessions then re-curate". Friendly message, no error.

• Conflicting consolidation suggestions (library pass says merge A+B

into C, queue pass says A is stale) → emit both as separate proposals and let /bridge-learn resolve.

• Privacy mode in user-pattern pass — if bridge-config.yaml.learning.curator.user_patterns.privacy: strict,

observations are written with redacted task slugs and customer names (replaced by <task> / <customer> placeholders) so the file is safe to share. Strict mode is opt-in, not default.

• Pass-failure isolation — if user-pattern pass crashes (e.g.

malformed log entry), library + queue still complete. Failures are reported in the curator report, not bubbled as fatal.

What this skill deliberately does NOT do

• ❌ Edit any Bridge file directly. All changes route via proposals.
• ❌ Write to MEMORY.md. User-patterns is a separate, lower-trust file.
• ❌ Auto-accept its own proposals. Even if a finding has 5-of-5 evidence

pointers, /bridge-learn still gates the apply.

• ❌ Send any data off-machine. No cloud user-model service. No

telemetry export.

• ❌ Run in a separate subprocess / agent fork without user awareness.

The curator is a foreground skill invocation; the user sees the report.

• ❌ Promote findings to your org overlay or open-bridge automatically.

Promotion is /bridge-sync territory after /bridge-learn accept flowed it through the normal commit pipeline.

Related

• rules/learning-autonomy.md — the design rule this skill embodies
• skills/task-close-postmortem/ — Layer 1 proposal generator (postmortem)
• skills/bridge-audit/ — Layer 1 proposal generator (recurring findings)
• skills/bridge-learn/ — the review surface that closes the loop
• work/_learning/README.md — aggregation layer layout
• work/_learning/user-patterns.md — output target for Pass 3
• bridge-config.yaml.learning.curator — config block (schedule + pass toggles)