메뉴
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: