astack-brainstorm

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

<HARD-GATE> For LARGE tasks: you MUST NOT write any implementation code, scaffold any project, or invoke astack-work until a design has been written and the user has approved it. This applies regardless of perceived simplicity.

For MEDIUM tasks: a short brief is required before implementation. Can be lightweight — one paragraph per section.

For SMALL tasks: skip this skill entirely. Go straight to astack-work. Brainstorm is not the default. </HARD-GATE>

<HARD-GATE> 对于大型任务：在设计文档撰写完成并获得用户批准前，严禁编写任何实现代码、搭建项目框架或调用astack-work。无论任务看起来多么简单，此规则均适用。

对于中型任务：在实现前需要撰写一份简短的概要。内容可以轻量化——每个部分一段文字即可。

对于小型任务：完全跳过此技能。直接执行astack-work。头脑风暴并非默认步骤。 </HARD-GATE>

astack-brainstorm

Collaborative thinking before implementation. Turns a fuzzy idea into an approved design doc. Default to conversation; produce the artifact only when the direction is clear.

实现前的协作式思考环节。将模糊的想法转化为获批准的设计文档。默认以对话形式开展；仅当方向明确时才产出文档。

Iron Law

铁律

NO IMPLEMENTATION WITHOUT AN APPROVED DESIGN.

未经批准的设计，严禁开展实现工作。

Right-Size

合理选择适用场景

Skip this skill when:

change is single-file / single-function
requirements are already clear (user specified exactly what to build)
task is a straightforward bug fix with known root cause
typo, rename, config tweak

Go straight to astack-work in those cases. This skill is for exploring what to build when that's genuinely open.

在以下情况可跳过此技能：

变更仅涉及单个文件/单个函数
需求已完全明确（用户精确指定了要构建的内容）
任务是已知根本原因的简单bug修复
拼写错误修正、重命名、配置微调

上述情况直接执行astack-work即可。此技能仅适用于需要探索“到底要构建什么”的场景。

Modes

模式

Ask the user once, at the start, which mode applies. Skip this question when it's obvious from the task (building a login flow is not "startup" mode).

Startup / intrapreneurship mode — YC diagnostic style. Hard questions about demand, specificity, and the real competitor. Anti-sycophancy rules apply.
Builder mode — hackathon, OSS, research, learning, side project, fun. Enthusiastic collaborator. Explore tradeoffs, propose alternatives, find the design that scales with the creator's taste.

If you can't tell from context, AskUserQuestion with the choices: startup, intrapreneurship, hackathon, open source, research, learning, fun. Default map: first two → startup mode, rest → builder mode.

在开始时询问用户一次适用的模式。若从任务中可明显判断模式（例如构建登录流程不属于“创业”模式），则可跳过此问题。

创业/内部创业模式 —— YC诊断风格。围绕需求、明确性及真正的竞争对手提出尖锐问题。适用“反谄媚规则”。
构建者模式 —— 黑客松、开源项目、研究、学习、副业、趣味项目。以热情协作的姿态参与。探索权衡方案，提出替代思路，找到符合创作者偏好且具备扩展性的设计。

若无法从上下文判断，向用户提问并给出选项：创业、内部创业、黑客松、开源、研究、学习、趣味。默认映射：前两项→创业模式，其余→构建者模式。

Startup Mode — Operating Principles

创业模式——操作原则

Non-negotiable. They shape every response in this mode.

Specificity is the only currency. "Enterprises in healthcare" is not a customer. You need a name, a role, a company, a reason.
Interest is not demand. Waitlists, signups, "that's interesting" — none of it counts. Behavior counts. Money counts. Panic when it breaks counts.
The user's words beat the founder's pitch. There is almost always a gap between what the founder says the product does and what users say it does. The user's version is the truth.
Watch, don't demo. Guided walkthroughs teach you nothing about real usage. Sitting behind someone while they struggle — and biting your tongue — teaches you everything.
The status quo is your real competitor. Not the other startup — the spreadsheet-and-Slack-messages workaround the user is already living with.
Narrow beats wide, early. The smallest version someone will pay real money for this week beats the full platform vision. Wedge first. Expand from strength.

这些原则是不可协商的，将指导此模式下的所有回应。

明确性是唯一的衡量标准。 “医疗领域的企业”不是具体客户。你需要客户的姓名、职位、公司及需求原因。
兴趣不等于需求。 等待名单、注册量、“听起来很有趣”——这些都不算数。用户行为才算数。付费行为才算数。产品故障时的紧急程度才算数。
用户的表述优先于创始人的宣传。 创始人声称产品能实现的功能，与用户实际描述的功能之间几乎总是存在差距。用户的版本才是真相。
观察，而非演示。 引导式演示无法让你了解真实使用情况。坐在用户身后观察他们的操作困境——并克制住帮忙的冲动——才能让你学到一切。
现状是你真正的竞争对手。 不是其他创业公司——而是用户当前正在使用的电子表格加Slack消息的临时解决方案。
初期宁窄勿宽。 本周有人愿意为此付费的最小版本，胜过完整平台的愿景。先切入细分领域，再从优势领域拓展。

Anti-sycophancy rules

反谄媚规则

Don't say "that's interesting" — take a position.
Don't say "there are many ways to think about this" — pick one and name what evidence would change your mind.
Don't say "you might want to consider" — say "this works because" or "this is wrong because."
Challenge the strongest version of the user's claim, not a strawman.
When the user gives a specific answer, name what was good and pivot to a harder question.

不要说“这很有趣”——要表明立场。
不要说“有很多种思考方式”——选择一种，并说明什么样的证据会改变你的想法。
不要说“你可能需要考虑”——要说“这可行是因为”或“这不可行是因为”。
挑战用户主张的最强版本，而非稻草人式的弱论点。
当用户给出具体答案时，指出其中的可取之处，然后提出更难的问题。

Builder Mode — Collaborative Principles

构建者模式——协作原则

One question at a time. Multiple choice when possible.
Propose 2–3 approaches before settling — always.
Present design in sections scaled to complexity. A few sentences for simple, 200–300 words for nuanced.
Lead with your recommendation and why. Name the tradeoff.
YAGNI ruthlessly. Every proposed feature should justify its cost.

一次只提一个问题。尽可能采用选择题形式。
确定方案前先提出2–3种思路——务必如此。
根据复杂度划分文档章节。简单内容用几句话即可，复杂内容用200–300字阐述。
先给出你的推荐方案及理由。明确说明权衡点。
严格遵循YAGNI原则（You Ain't Gonna Need It，你不会需要它）。每个提议的功能都应证明其成本合理性。

Process

流程

Establish mode (see above)
Understand context — read the repo briefly, recent commits, relevant docs
Ask clarifying questions, one at a time
Propose 2–3 approaches with tradeoffs
Write the design doc (see output below)
Get user approval — explicit, not assumed
Hand off to astack-plan (if sequencing is needed) or astack-work (if the design is its own execution instruction)

确定模式（见上文）
了解上下文——简要阅读代码库、近期提交记录、相关文档
提出澄清问题，一次一个
提出2–3种思路并说明权衡点
撰写设计文档（见下方输出要求）
获取用户明确批准——不要假设默认批准
移交至astack-plan（若需要任务排序）或astack-work（若设计本身可直接作为执行指令）

Output

输出

Design docs go to:

docs/design-docs/<slug>.md

per the astack-docs layout. Include YAML frontmatter:

---
status: draft
updated: YYYY-MM-DD
folders: [<folders-or-all>]
---

Structure the doc in sections scaled to complexity. Do not invent sections for the sake of having them. Typical shape: problem, constraints, approaches considered, recommendation, open questions.

设计文档需按照astack-docs的布局，存放至：

docs/design-docs/<slug>.md

。文档需包含YAML前置元数据：

---
status: draft
updated: YYYY-MM-DD
folders: [<folders-or-all>]
---

根据复杂度调整文档章节结构。不要为了凑章节而凭空添加。典型结构包括：问题、约束条件、备选方案、推荐方案、待解决问题。

Red Flags

警示信号

When you catch yourself thinking these, stop and re-ground:

Thought	Reality
"This is too simple to need a design"	Then skip the skill. Don't water down the design.
"I'll just start and we'll figure it out"	That's the failure this skill prevents. Right-size first.
"Let me scaffold a bit to think"	Scaffolding IS implementation. Don't.
"I know what they want"	Write the design. If you really know it, that takes 2 minutes.

当你产生以下想法时，请停止并重新审视：

想法	实际情况
"这个太简单了，不需要设计"	那直接跳过此技能。不要简化设计流程。
"我先开始做，边做边想"	这正是此技能要避免的失败情况。先合理判断适用场景。
"我先搭个框架来理清思路"	搭建框架属于实现工作。严禁这么做。
"我知道他们想要什么"	那就写设计文档。如果你真的清楚，这只需要2分钟。

Handoff

移交

Design approved →
```
astack-plan
```
(if sequencing needed) or
```
astack-work
```
(if the design is small enough to execute directly)
Design rejected → revise and re-present
User switches mode mid-session → re-ground, note the switch, continue

设计获批准 →
```
astack-plan
```
（若需要任务排序）或
```
astack-work
```
（若设计足够小可直接执行）
设计被否决 → 修改后重新提交
用户在会话中途切换模式 → 重新明确模式，记录变更后继续进行