Menu
Read signals → decide which to act on, which to ignore, which to defer. Never act on a single signal in isolation; require corroboration.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Load when reading or writing project notes, weekly/monthly summaries, or journal/agent.md. Owns GET/PATCH for context files except today.md and roadmap.md, which use their dedicated skills.
Load when the user wants an ongoing task on a fixed cadence (every morning, each Monday, hourly) to run autonomously as its own named recurring Agent. Creates it via POST /api/agents. Not for one-time reminders (use schedule) or app-data background fetches (use managed-tasks).
Load to manage the durable source library (user-sent PDFs/PPTX/docs) — list unfiled sources, file them as knowledge/sources/ cards, promote images, or send a stored source back. SKIP for delivering files you generated this turn (attach) or general vault edits (context).
Hand a long-running or open-ended task (deep research, multi-repo CI audit, monitor X over time, bulk compile) to /api/background-task. Compose a self-contained brief, set the notification policy, POST, ack, end the turn. Read GET /:id for follow-up detail.
Read-only Task Board — list everything in motion (recurring DMs, Agents, app-fetch, automation triggers, reminders, background/browser work) via GET /api/tasks, and preview a delete's blast radius via GET /api/tasks/impact. For writes use the `task` skill.
Hand open-ended browser requests (post a tweet, fill a contact form, check an order status, …) to /api/browser-task. Relay sub-agent clarifications, POST /clarify with the reply, /cancel on stop.
| name | drift-analysis |
| description | Read signals → decide which to act on, which to ignore, which to defer. Never act on a single signal in isolation; require corroboration. |
| allowed-tools | ["Read"] |
Signals live under data/signals/<skill_slug>.json in your workdir.
Each is one row from skill_curation_signals:
{
"id": 42,
"skill_slug": "user-profile",
"section_id": "topic-files",
"signal_type": "structure_diff",
"payload": { "sub_kind": "heading_add", "target": "identity/personal.md#health-log" },
"observed_at": 1717000000000
}
A single structure_diff signal is suggestive, not actionable. To submit
a proposal you must EITHER:
(skill, section), ORowner_correction qualifies).Single-signal proposals from structure_diff alone are auto-rejected by
the smoke test (signal_citations_valid). Don't try.
For each (skill, section) with corroborated signals, classify the change shape:
additive_only — signals all describe ADD operations (file_add,
heading_add). Propose with confidence; the worst case is a revert.mixed — some adds, some modifications. Propose with extra rationale
citing each signal's contribution.destructive — at least one signal cites a removal. Only propose if
signals explicitly state user intent to remove (owner_correction
with intent="remove"; structure_diff alone is insufficient). When in
doubt, SKIP.Do nothing on (skill, section) when ANY of these hold:
structure_diff low-weight gate hasn't
matured; the snapshot may be a brief experiment).frozen (returns from /skills/<slug> as frozen=true).It is correct and expected to finish a run with zero proposals. The optimizer's success is measured over weeks, not per run. The owner prefers "no action needed" to a low-confidence proposal. If you're unsure, skip.
Use POST /api/skill-curation/runs/<runId>/finalize's notes field to
explain skips. Examples: