菜单
Produce the owner's week-ahead plan — scheduled meetings and due-or-overdue reminders for the next 7 days, grouped by day, read from the CRM and enriched from the real calendar, Slack, and knowledge-base briefs when connected. Use for "what's my week", "plan the week ahead", "what's coming up".
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | week-plan |
| description | Produce the owner's week-ahead plan — scheduled meetings and due-or-overdue reminders for the next 7 days, grouped by day, read from the CRM and enriched from the real calendar, Slack, and knowledge-base briefs when connected. Use for "what's my week", "plan the week ahead", "what's coming up". |
| metadata | {"version":"1.1.0","author":"context","tags":["planning","weekly","crm","slack","knowledge"]} |
Runtime skill — a playbook the deployed @context agent runs for its owner, invoked in natural language. Not a coding-agent workflow; those live in
.agents/skills/.
Assemble a clear plan for the next 7 days from the structured crm
store, enriched from the connected sources. This is a read-only retrieval
workflow: it pulls, merges, and formats — it never writes anything.
now → now + 7 days.query_crm (one retrieval —
ask it for both):
starts_at falls between now and now + 7 days.status = 'pending' and due_at ≤ now + 7 days.
Include anything already overdue (due_at < now, still pending) — a
plan that hides what's late isn't useful.calendar source is connected, pull the real calendar too —
query_calendar for events in the same 7-day window — and merge with the
CRM meetings (dedupe by title + start time; the calendar wins on times).slack source is connected,
query_slack for recent threads that touch this week's meetings,
attendees, or active projects — surface commitments and deadlines that
never made it into the CRM as plan items, flagged (from slack). When a
meeting or reminder ties to a project with a brief in the knowledge base,
pull its status from query_knowledge so the plan reflects where things
actually stand. Enrichment is bounded: it adds context to the week's
items, it doesn't grow the window.3 meetings, 5 reminders, 1 overdue.crm, calendar, slack, and
knowledge-base briefs feed this plan; don't pull from web / workspace unless
the owner explicitly asks.crm meetings + reminders, plus
calendar / slack / knowledge where they contributed), and report empty
results honestly rather than guessing.Research a topic and file the result — sweep what we already know (knowledge base, crm, and slack when connected), go to the web for current and external background, then write a clear sourced brief and FILE it into the knowledge base with update_knowledge. Labels what came from the web versus our own notes. Use for "research X and save it", "look into X and write it up", "find out what's known about X and file it", "write up a brief on X".
The owner's morning brief — inbound updates awaiting acknowledgment (via the rundown tool), today's meetings and due-or-overdue reminders from the CRM and the real calendar, the emails worth seeing from Gmail, and the Slack threads that need their eyes — each source folded in when connected and stitched into one short digest. Use for "daily rundown", "what's on today", "morning brief", "catch me up".
Autonomously harden the context agent (or any agent in this repo) — derive probes from the agent's own instructions, run them against the live container, judge the responses and tool calls, and edit the agent until it reliably does what it says it does. Use when the user wants to test, harden, stress-test, or improve an agent's reliability WITHOUT naming a specific change ("make sure context is solid", "harden this agent", "probe it for failure modes"). For a user-directed change use extend-agent; to run the committed eval suite use eval-and-improve.
Repo-wide consistency sweep for @context — diff docs against code (the context agent and its providers wired as documented, every env var documented, every path real, every script behaving as advertised), auto-fix mechanical drift, and flag anything bigger. Use when the user wants to review the repo for consistency, prep a public release, or clean up drift after a refactor ("review the repo", "is everything consistent before we ship", "run the drift sweep"). This is a deliberate full sweep, not a quick lint.
Sweep the knowledge base for what needs attention — stubs with no real content, specs whose status is stale, decisions that were made but never written down, and pages missing from the index — and return a short "what needs attention" list. Read-only, so it reports rather than fixing anything itself. Use for "what in my knowledge base needs attention", "review my knowledge base", "what's stale or unfiled", "knowledge base health check", "tidy up my knowledge".
Run this repo's eval suite (python -m evals), diagnose every failing case, and fix in scope (agent instructions, or the eval case when its assertion was wrong) until all cases pass. Use whenever the user wants to run the evals, check for regressions, or fix a red eval suite ("run the evals", "why is a case failing", "make the eval suite green"). Targets the committed cases in evals/cases.py; for ad-hoc probing of one agent's live behavior use improve-agent instead.