메뉴
Draft a clear standup, end-of-day update, weekly update, or client progress note. Use when summarizing completed work, next steps, blockers, risks, decisions, and support needed for a team or stakeholder audience.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Pressure-test an assumption, architecture decision, estimate, or inherited constraint. Use when the user asks to challenge a belief, play devil's advocate, test reasoning, or find a simpler alternative.
Explain a code location, component, command, or user-facing system flow. Use when the user asks what code does, why it exists, how a feature works, or wants a trace of entry points, branches, dependencies, and side effects.
Prepare difficult technical or delivery news for a client, stakeholder, or team. Use for delays, incidents, security findings, cost changes, failed approaches, or other conversations where clarity and trust matter.
Plan and work through project, client, vendor, or team offboarding. Use for handovers, access removal, ownership transfer, documentation, credential rotation, data cleanup, and knowledge-transfer checklists.
Discover how a codebase already handles a concern before extending it. Use when asked how the repository does something, where a pattern lives, whether implementations are consistent, or what convention new work should follow.
Help the user think through a confusing problem or decision by asking focused questions and reflecting their reasoning. Use when they want to think out loud, untangle a problem, or find the question beneath the question.
| name | standup |
| description | Draft a clear standup, end-of-day update, weekly update, or client progress note. Use when summarizing completed work, next steps, blockers, risks, decisions, and support needed for a team or stakeholder audience. |
Produce an accurate, ready-to-review update without making the reader decode commit messages. Determine the audience, time window, and desired format first when they are not evident.
Use supplied context and, when relevant, read-only repository evidence such as status, recent local commits, diffs, issues, or test results. Do not fetch remotes or inspect unrelated private activity merely to fill a standup.
Ask only about information the evidence cannot provide, especially:
Use the team's established structure. Otherwise organize the message around:
Lead with outcomes rather than file lists. Distinguish completed, in progress, planned, and blocked work. Do not claim tests, delivery, impact, or certainty that the evidence does not support. Keep internal detail out of client-facing updates unless it helps them understand impact or make a decision.
Draft only. Never post or send the update without explicit approval.
Adapted from Thoughtbot's rails-consultant standup skill at revision
f2cb97d. Distributed under the accompanying MIT license.
