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
中文简介正在准备中。当前显示原文说明。
查看安装方法安装前可以查看交给 AI 代理的指令内容。
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.
中文简介正在准备中。当前显示原文说明。