메뉴
Get oriented on a project's current state when starting or resuming work — what's changed, what's in flight, and the recent decisions. Use at the start of a session, when returning to a repo after a break, or when asked "where were we" or "what's the status".
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | catch-up |
| description | Get oriented on a project's current state when starting or resuming work — what's changed, what's in flight, and the recent decisions. Use at the start of a session, when returning to a repo after a break, or when asked "where were we" or "what's the status". |
Goal: rebuild context on the current state — not the whole codebase (that's explore).
git_context for modified/uncommitted files, recent commits, and which changed files are in the index.list_checkpoints for the latest checkpoints; search_checkpoints "<area you're resuming>" for ones relevant to the task.get_annotations on the changed files for known bugs, constraints, or "don't touch until X" notes left earlier.search_conversation "<task/area>" to recall what was being worked on and any unresolved threads.Finish: a short status — what changed, what's in flight, decisions/caveats affecting the next step — with file:line and checkpoint references. Confirm the plan before continuing.
Rebuild a flow-first project wiki using the mimirs wiki MCP tool. Use when the user asks to generate, rebuild, refresh, or write the wiki for a codebase.
Build an accurate mental model of an unfamiliar codebase, feature, or area before changing it — where it lives, how it connects, what it does, and why. Use when asked how something works, where something is, when onboarding to a repo, or before editing code you don't know. For a cross-cutting question that needs answering from many sources, use research instead.
Wrap up a work session so the next session (or another agent) can pick up cleanly — what was done, what's in flight, what to watch out for. Use when ending a session, switching tasks, or asked to hand off, wrap up, or save state for later.
Design an implementation plan before writing code — where the change lands, what it will touch, what could break, and the steps in order. Use when asked to plan a feature, scope a change, or figure out how to approach an edit before making it. To assess a change that already exists (a diff, refactor, or rename), use review instead.
Answer "why" and "when" questions about a project's decisions — the intent behind a past choice, when it was made, what was tried before and rejected. Use when asked why something was decided, what the rationale was, or before reversing or redoing earlier work. For why the code mechanically behaves a certain way use research; for why it breaks use debug.
Answer a hard, open-ended question about how the project works or is built by synthesizing every source — code, structure, git history, prior decisions, discussion, caveats — and verifying each claim against the source. Use for deep cross-cutting questions that span more than one area. Narrower siblings — a single area's structure is explore, the rationale behind one past decision is recall, a failure's root cause is debug.