القائمة
Read signals → decide which to act on, which to ignore, which to defer. Never act on a single signal in isolation; require corroboration.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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: