Help a human understand and inspect completed AI-authored repository work through actual results, before-and-after explanations, and supporting evidence. Use when the user asks to understand the work before accepting it, examine assumptions beyond an AI summary, or resume a human review after switching tasks. Also use for explicit requests to judge unresolved product behavior. Ordinary change summaries, automated defect hunting, and non-repository content do not need this skill.
中文简介正在准备中。当前显示原文说明。
实测评分 未实测
查看安装方法安装前可以查看交给 AI 代理的指令内容。
Make the work understandable enough for the human to examine it independently. Reduce the effort of remembering context, finding evidence, and connecting changes so the human can spend attention on understanding and judgment.
Read the request, applicable project decisions, spec when present, current diff, and available review history. Establish what the work was meant to achieve and which choices the human actually settled. Code shows what was implemented; it does not establish that the human intended every consequence.
Open with the purpose, the resulting change, and where to start looking. When prior review context exists, identify what changed since the revision the human last examined. Otherwise describe a fresh starting point. Infer familiarity only from the conversation, adjusting depth as the human asks or reveals gaps.
Before compressing the change, account for each changed behavior, access rule, data effect, external interaction, and failure path. For each, distinguish what to explain, what needs a product decision, and any confirmed defect; separately record what was observed, inferred from source, or remains unverified. This prevents a concise explanation from silently omitting part of the change. Keep the complete list accessible and put blockers and consequential unknowns near the opening.
Explain one coherent behavior at a time, connecting its trigger, before/after result, mechanism, and consequences. Keep its place in the whole change visible and let the human choose another part, including choices the AI considers settled. Organize by what happens rather than by file or implementation layer.
Use the smallest representation that makes the relationship easy to inspect: actual UI captures, request/response values, a short source comparison, an access table, or a flow diagram. Put the relevant evidence beside the claim or behind an adjacent disclosure. Explain technical details when they help the human check how a result follows; keep the deeper source available on demand.
Inspect the actual product and run the smallest safe checks needed to support the explanation. Tie each observed result to the named revision or dirty diff, route or command, and environment. Identify supplied observations as supplied and preserve their provenance. Prior AI summaries are claims, not proof. Label source-derived conclusions and missing observations accurately; a mock or proposed screen is never an observed result. Redact secrets and personal data, and preserve the product while preparing the review.
Write in the human's language using concrete actions and outcomes. Name the actual question, changed behavior, or place to see the evidence instead of abstract process labels such as “unresolved commitments,” “review disposition,” or “evidence path.” Keep necessary technical names and explain unfamiliar ones in context. Omit time estimates, severity codes, scores, and file/test counts that do not help examine the behavior.
Invite examination at consequential assumptions or boundaries, not an acknowledgment after every explanation. A question should expose a real choice and what each answer changes. Do not invent a product decision because evidence is missing, a diff is large, or a confirmed defect needs repair.
Keep at most three unresolved product decisions active and name every deferred decision so it can follow as earlier ones settle. Start with choices whose consequences are costly or hard to reverse. This limit applies to decisions, not to the work the human can inspect. With no open product decision, still explain the behavior and make its evidence available; say separately whether defects or missing observations prevent a readiness claim.
Treat a choice as settled only when the human explicitly states it in conversation. Opening a section, reading, silence, and a general acknowledgment are not acceptance. Preserve reusable confirmed decisions through the project's existing decision process; temporary review pages and notes are not that record.
When review pauses or the human switches tasks, preserve a concise note in the conversation, or beside a temporary review artifact when a portable handoff is useful. Include the source revision and any dirty changes, retaining the relevant diff or snapshot when uncommitted edits are part of that source. Record the parts actually examined, the human's expressed decisions or questions, what remains open, and the next useful action. Link the note and its source evidence so another session can pick it up. Keep observed navigation separate from expressed understanding and acceptance; if none is known, say so.
On return, compare the current work with the recorded source before reusing earlier observations. Point out what needs another look and why, preserve unaffected discussion, and resume at the open question. If the earlier source cannot be recovered, say which comparison is unavailable rather than claiming the review is current. Before handing off any review, provide a next starting point without pretending the human has already examined it.
Keep simple explanations in conversation. When comparison, navigation, or continued review benefits from HTML, adapt assets/review.html outside the repository. It provides context, a map of behaviors, before/after sections, nearby evidence, and an optional return note. Translate labels, replace placeholders, and remove unused sections; the template is a starting point, not a compulsory screen for every change.
For HTML, exercise navigation, comparisons, disclosures, and a narrow viewport in a browser. Fix incomplete content or broken controls before calling the surface ready. If browser verification is unavailable, state that limitation. Run the finished HTML using a method supported by the current harness and share an address the user can open, plus a preview when supported. Keep the server available for review. Browser verification establishes that the review surface works, not that the underlying product is correct or approved.
A successful handoff supports explaining the behavior, inspecting an assumption the AI did not flag, and resuming after a switch. Do not claim improved human understanding merely because the page renders or the human grants approval.
还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
Audit and establish current agent context for the technologies that define a project's stack. Use when setting up a project for agent work, after selecting or adding a framework, library, developer tool, or hosted service, or when entering an existing project whose agent context has not been audited.
中文简介正在准备中。当前显示原文说明。
Revise active `docs/specs/SLUG/` specs so they match what has shipped since they were written. Use when earlier work has landed and queued specs may now rest on stale assumptions, acceptance criteria, constraints, terms, or prototypes, or when implementation reports a spec as stale before changing source. Takes one or more spec folders, or every folder under `docs/specs/` when none is named. Do not use to shape a new spec from a problem and direction, which belongs to `shape-idea`, or to reconcile durable project context and retire shipped folders, which belongs to `maintain-project-context`.
中文简介正在准备中。当前显示原文说明。
Build a complete dummy-data HTML prototype or a temporary comparison of up to three alternatives for a specific user situation. Use to settle a screen-based product before implementation or resolve a visual or interaction decision during shaping or prototype review. Do not use for production implementation or CLI, terminal, or voice interfaces.
中文简介正在准备中。当前显示原文说明。
Create Git commits for the current request's in-scope changes as logical Conventional Commits. Always use this skill for an actual Git commit operation, including requests to commit or amend changes, save work in repository history, stage and record selected files, or group staged or unstaged changes into commits. Use it even when the request describes recording changes without saying "commit"; it performs the commit rather than only suggesting a message, and it does not push.
中文简介正在准备中。当前显示原文说明。
Interview the user to define or revise the app's overall product direction, then preserve the confirmed meaning in root PRODUCT.md. Always use for a new app direction or any app-wide change to users, usage situations, problem, promised change, core loop, durable boundaries, experience principles, success signals, assumptions, or unknowns, even when PRODUCT.md is not named. Start from an existing definition or a rough app direction. Do not use for blank-page idea discovery, architecture, or shaping or specifying one feature or work unit.
中文简介正在准备中。当前显示原文说明。
Render an explanation as a diagram, comparison, trace with real values, or annotated code. Use when the user asks to have a concept, decision, flow, or code explained, or says they do not follow.
中文简介正在准备中。当前显示原文说明。