菜单
Start-of-session orientation — read the handoff and continue work. Use when starting a new session, resuming after a break, or picking up someone else's work.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Dispatch Codex to review all unreviewed repository work, then verify its correlated findings ticket or clean result. Use when requesting an independent Codex review, auditing all changes, checking work since the last review, or waiting for Codex findings. Trigger: dispatch codex review, independent review, review all changes, check codex findings, run review agent.
Always-on: when a project has tickets, work the frontier (first unblocked open ticket), mark done, update plan status.
Incremental and full-history repository review with resumable adoption batches. Use when reviewing new work, initializing review tracking, reviewing all work to date, resuming historical review, inspecting unreviewed commits, or reviewing changed tickets. Trigger: review new work, adopt repository, review all history, resume review, review marker, unreviewed commits.
End-of-session handoff that captures current state for the next session. Use when ending a work session, switching context, or before a long break.
Consolidate project artifacts — promote scratch to memory, deduplicate memory, process decisions, organize scripts, update steering/skills accuracy. Use periodically or when the project feels cluttered.
Run and interpret crew-research evals — run.sh flags, scores.jsonl fields, activation TPR/FPR verdicts, resuming interrupted runs. Use when running evals, reading eval results, diagnosing a failing definition, or resuming a dead run. Trigger: run the evals, eval results, scores.jsonl, activation test, TPR, delta threshold, resume the run, skip-completed, known gap.
| name | read-handoff |
| description | Start-of-session orientation — read the handoff and continue work. Use when starting a new session, resuming after a break, or picking up someone else's work. |
| metadata | {"type":"process","invocation":"user-only","practice":null,"params":{"ephemeral_path":".scratch","handoff_file":"HANDOFF.md","glossary_path":".memory/CONTEXT.md"}} |
Orient yourself to continue work from where the last session left off.
recall is on PATH, run recall prime — internalize silently{{params.ephemeral_path}}/{{params.handoff_file}}{{params.glossary_path}} (internalize key terms)git log --oneline {base_commit}..HEADproposal-plan.md exists, read it for project mapdocs/plan.md.tickets/ exists, scan for frontier (open tickets with all blockers done)Internalize all of this. The briefing you present is a distillation, not a dump.
Objective — What we're building or doing, in one sentence.
Progress — Where we are. What's done, what phase we're in. If the repo moved since the handoff, summarize what landed. Write as narrative, not a status table.
Unresolved — Things we don't have answers to yet. Open questions, untested assumptions, unknowns that block confident decisions. Plain language — no internal labels or commit refs.
Heads up — Anything the user should be aware of before we proceed. Prior approaches that failed (and what we'll try differently), environmental quirks, risks to the proposed next step. Only include if there's something worth flagging — skip this section if everything is straightforward.
Open tasks — What's on the board. Numbered list from tickets, plan, or handoff next-steps. Keep to actionable items, not background work.
Next step — A specific, concrete proposal: "I'll [do X]. Proceed?" Don't ask what to do — propose and offer to start.
Before proposing next step, assess silently:
If 2+ are true → trigger vertical-slice-planning before proceeding. Mention this in the briefing as "I think we need to re-plan before continuing" rather than citing the rule.
If the project has a test suite or validation script: