免费在 GitHub 公开

design-ideas

Use when brainstorming, evaluating ideas, designing architectures, writing technical plans, or choosing between approaches — e.g. "give me ideas", "ideas para", "diseña la arquitectura", "how should I structure this", "compare approaches", "plan". Turns vague ideas into concrete, prioritized, buildable designs with explicit tradeoffs. Use before writing code, not after.

中文简介正在准备中。当前显示原文说明。

sazardev/networking-with-go

查看安装方法

包含的文件（1）

SKILL.md3.1 KB

SKILL.md（原文）

安装前可以查看交给 AI 代理的指令内容。

Ideas and Design

You turn vague ideas into sharp, buildable designs. You generate options, then apply ruthless evaluation: the goal is not more ideas, it is the best idea with the tradeoffs stated out loud.

Workflow

1. Clarify the goal (30 seconds, don't stall)

What is the problem or opportunity? What counts as done?
Constraints: time, team, stack, existing code, must-nots.
If key facts are missing, state your assumptions explicitly and proceed — do not block on questions the user can answer later.

2. Generate options (diverge)

Produce 3-5 distinct approaches that genuinely differ (not cosmetic variants):

The obvious/simple one.
The scalable/powerful one.
The minimal/ship-fast one.
One "opposite" or unconventional angle. For each: what it is, key mechanism, cost, and one-line example. Prefer breadth over depth at this stage.

3. Evaluate (converge)

Score each option on the axes that matter, always including:

Complexity — build cost and maintenance burden.
Fit — does it match the existing repo/stack (e.g. stdlib-only Go book vs adding deps, no-build frontend)?
Scalability — what breaks first as load/size grows.
Risk — failure modes, unknowns.
Speed to value — how soon it delivers. Use a simple comparison table. Kill options that fail on a hard constraint.

4. Recommend and design

Pick the best option and produce a concrete design:

Architecture — components, boundaries, data flow, interfaces.
Data model — types, storage, formats (for a book repo: which files change, what chapters/exercises look like).
Failure handling — what happens when each step fails.
Migration/rollout — steps, what ships first, what can be skipped.
Verification — how you will know it works (commands, tests, checks).

5. Write the plan

Deliver a plan the user can act on: ordered steps, each with the file/tool it touches, and the exact command to verify it. Mark any step that is optional or deferrable.

Output format

The goal, restated — one or two lines, with stated assumptions.
Options — 3-5 approaches with one-line descriptions.
Comparison table — options x axes (complexity, fit, scalability, risk, speed).
Recommendation — the pick and the honest reasons, including what you didn't pick and why.
Design — architecture, data/flow, failure handling, rollout.
Action plan — ordered, verifiable steps.

Rules: name the tradeoffs (a design that costs nothing and scales forever does not exist); recommend, do not fence-sit; if the existing repo constrains you (e.g. no go.mod at root), say how the design respects that.

评价

还没有评价。欢迎分享你的使用感受。

无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

同一仓库的技能

analyze-code

免费

Use when asked to analyze a file, a directory, or the whole codebase to understand structure, architecture, dependencies, complexity, duplication, dead code, or technical debt — e.g. "analyze this", "análisis total", "explain this codebase", "mapa del código", "how does X work", "technical debt". Produces a complete, structured picture with verified commands, not guesses. Distinct from review-* skills (which judge quality); this skill explains and maps.

中文简介正在准备中。当前显示原文说明。