阶段 3：实现

按顺序处理各个分支（它们修改相同的文件）。对于每个分支：检出基础分支，创建 spike/<名称>，完整实现。

完整意味着：所有代码变更、更新的导入和调用点、更新的文档注释。没有存根，没有 TODO。实现应该足够完整，如果团队选择此方法，就可以合并。

遇到错误时即时处理。 预期会出现 lint 失败和编译错误——它们揭示了隐藏的约束。修复它们并记录下来以便比较。

在所有分支上投入相等的精力。 如果你花额外时间让某个分支变得优雅，就是在使比较产生偏差。

阶段 4：验证

实现每个分支后，运行验证命令。修复失败（修复过程本身就是数据），重新运行直到通过，然后提交。在进入下一个分支之前，每个分支都必须能够编译并通过 lint 检查。

阶段 5：比较

展示一个并排的比较表格。选择具有区分度的维度——如果所有分支在某个维度上得分相同，则舍弃它。正确的维度来自问题领域，而非通用清单。

不要选择优胜者。 比较表格就是交付物。用户现在掌握了全貌。询问：

"你打算如何处理这些？"

反模式

• 用存根代替实现 — "TODO: 实现这个" 不是 spike。关键在于感受真实代码。
• 跳过验证 — 无法编译的分支无法进行公平比较。
• 使用通用的比较维度 — "复杂度：中等" 是无用的。使用具体、可衡量的维度。
• 选择优胜者 — 让人类来决定。你已经移除了实现工作的障碍；现在让他们运用判断力。
• 忘记返回基础分支 — 每个分支都从相同的基础分支分叉。在切换分支之间，务必检出基础分支。

默认值

• 如果未指定 -n，则 N = 4
• 分支前缀：spike/
• 如果 N > 6，警告实现时间可能过长，但仍会执行

用户有需要比较的方法。实现 N 个 spike 分支。从阶段 1 开始：选择方法。

每周安装量

1

仓库

corygabrielsen/skills

首次出现

1 天前

安全审计

Gen Agent Trust HubPassSocketPassSnykPass

安装于

zencoder1

amp1

cline1

openclaw1

opencode1

cursor1

Some brainstorm options are complementary — combine them into a single branch when they strengthen each other rather than competing.

Phase 2: Prepare

1. Read all files that will be modified across branches. Load them once — they're the same starting point for every branch.
2. Note the base branch — all spike branches fork from here.
3. Identify the verification command (make format lint, cargo clippy, npm run lint, etc.). Ask if unclear.

Phase 3: Implement

Work through branches sequentially (they modify the same files). For each: check out the base branch, create spike/<name>, implement fully.

Fully means: all code changes, updated imports and call sites, updated doc comments. No stubs, no TODOs. The implementation should be complete enough to merge if the team chose this approach.

Handle errors as they come. Lint failures and compile errors are expected — they reveal hidden constraints. Fix them and note them for the comparison.

Equal effort across all branches. If you spend extra time making one branch elegant, you're biasing the comparison.

Phase 4: Verify

After implementing each branch, run the verification command. Fix failures (the fix is data), re-run until clean, then commit. Every branch must compile and pass lint before moving to the next.

Phase 5: Compare

Present a side-by-side comparison table. Choose dimensions that discriminate — if all branches score the same on a dimension, drop it. The right dimensions come from the problem domain, not a generic checklist.

Don't pick a winner. The comparison table is the deliverable. The user has the full picture now. Ask:

"What do you want to do with these?"

Anti-patterns

• Stubs instead of implementations — "TODO: implement this" is not a spike. The point is to feel the real code.
• Skipping verification — A branch that doesn't compile can't be compared fairly.
• Generic comparison dimensions — "Complexity: medium" is useless. Use specific, measurable dimensions.
• Picking the winner — Let the human decide. You removed the implementation effort barrier; now let them apply judgment.
• Forgetting to return to base — Each branch forks from the same base. Always check out the base between branches.

Defaults

• N = 4 if -n not specified
• Branch prefix: spike/
• If N > 6, warn that implementation time may be excessive, but comply

The user has approaches to compare. Implement N spike branches. Start with Phase 1: Select the approaches.

Weekly Installs

1

Repository

corygabrielsen/skills

First Seen

1 day ago

Security Audits

Gen Agent Trust HubPassSocketPassSnykPass

Installed on

zencoder1

amp1

cline1

openclaw1

opencode1

cursor1