القائمة
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.
