Maintain a project's canonical terms and settled decisions that future work should reuse, and record follow-ups a session discovers but does not resolve. Use when project-specific terms are being clarified, when a choice that may constrain future work is being considered or settles, including during planning, or when a session applies a temporary workaround whose root cause stays open or observes an out-of-scope defect with evidence. Do not use for simple definitions, routine implementation details, or carrying out an already-settled decision.
The English summary is being prepared. Showing the original description.
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
Resolve unclear project terms and preserve settled decisions so future work uses the same language and does not re-litigate the same trade-offs.
Read GLOSSARY.md when it exists.
GLOSSARY.md if needed and update it
immediately using the glossary template.GLOSSARY.md.When docs/decisions/README.md exists, read it and load only the subject files
relevant to the current work.
Record a project decision only when it is all of the following:
Require evidence that a choice was intentional before treating it as settled. Implementation or lack of objection alone is insufficient.
For each qualifying decision, use the
decision contract template to create or
update its single subject file in docs/decisions/. Preserve only the context
future work needs to apply the decision without repeating the original analysis.
Record a follow-up when a workaround applied in this session is temporary and its root cause stays open, or when an out-of-scope defect or suspected cause is observed with evidence. Work that closed inside the session, a guess without evidence, and a defect already fixed in the current change do not qualify.
Write each qualifying item at the moment of discovery to its own
docs/follow-ups/<slug>.md using the
follow-up template, naming the slug for the symptom.
An item must let a later session act without this conversation. Reporting the
discovery in conversation does not preserve it.
A follow-up records an open question, not a settled decision, so it does not
enter GLOSSARY.md or a decision contract until its outcome settles on its own
terms. Delete the file when the work ships or the item is promoted into a spec
folder.
GLOSSARY.md, or a relevant
decision contract, surface the mismatch instead of choosing silently. Code
shows current behavior, but not whether that behavior was intentional.No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
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.
The English summary is being prepared. Showing the original description.
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`.
The English summary is being prepared. Showing the original description.
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.
The English summary is being prepared. Showing the original description.
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.
The English summary is being prepared. Showing the original description.
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.
The English summary is being prepared. Showing the original description.
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.
The English summary is being prepared. Showing the original description.