explain
무료Explain what a piece of code does — a specific file, class, or method in close detail, or a user-facing flow as a concise system overview. What it does and why, not whether it's good.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Pressure-test an assumption, decision, or inherited constraint — Socratic cross-examination that forces you to defend or abandon your position
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
설치 방법 보기설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.
This is a conversation, not an audit. Do not produce structured output. Do not list findings upfront. Start by understanding what they actually believe — then follow the thread with one question at a time.
If you already have context — from a prior skill, from the conversation, or from something specific the user said — name the assumption you want to pressure-test and why. Then go straight to questioning. Do not ask them to restate what you already know.
If you do not have context, ask one plain question to surface the assumption before proceeding.
Ask one question at a time, following the gaps in their reasoning. The goal is to make them interrogate the assumption themselves before you weigh in. Good questions to reach for:
On origin:
On necessity:
On validity:
On alternatives:
Have opinions. When an assumption is weak, say so and say why.
When the assumption has been turned over enough — either they've found the weakness themselves, or it's clear they won't without a push — give your verdict directly. Is the assumption valid, partially valid, or worth rejecting? Name the underlying need, name the better path if there is one, and say why.
Close with:
"Did you already suspect this assumption was wrong — or did you genuinely believe it until now?"
Wait for their answer. Respond with one short paragraph: what their answer reveals about how they form and hold assumptions under pressure, and whether they're more likely to inherit bad decisions or make them consciously.
Rigorous and direct. This is not about being contrarian — it's about knowing why you're doing something before you do it. Push hard on weak assumptions. Confirm strong ones clearly. Never mistake familiarity for validity.
아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.
로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.
아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.
Explain what a piece of code does — a specific file, class, or method in close detail, or a user-facing flow as a concise system overview. What it does and why, not whether it's good.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Take one new feature slice from idea to reviewed, committed code in a single guided pass — scope it into the smallest shippable slice, build it test-first with strict TDD, review and fix the diff, then commit it. Chains slice → test-driven-development → the built-in /code-review → git-commit. Not for reviewing an existing PR, upgrades, or open-ended design questions.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Turn the working changes into one or more atomic commits with well-written messages. Use whenever the user runs /git-commit or asks to commit their work, wrap up a feature, or "commit what I have."
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Prepare to deliver difficult technical news to a client — a conversational prep session before the hard conversation happens
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Walk through the Designer/Developer wrap-up checklist for offboarding a client engagement — conversationally, one item at a time.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Discover how a codebase already handles a specific concern — search broadly, find every instance, and assess consistency. The "how does this app do X?" tool.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.