‹ 首页

collaborative-design

@lexler · 收录于 昨天 · 上游提交 1 周前

Designs software features collaboratively through visual scenarios and iterative refinement. Use when designing features, tools, UIs, workflows, or any system before implementation.

适合你,如果 你在开发前需要协作设计软件功能

/ 通过 npx 安装 校验哈希
npx oh-my-skill add lexler/skill-factory/collaborative-design
/ 通过 bash 安装
curl -fsSL https://oh-my-skill.com/install.sh | bash -s -- lexler/skill-factory/collaborative-design
/ 已经装过?验证本机副本,不用重装
npx oh-my-skill verify lexler/skill-factory/collaborative-design
安装目标可用 --agent / --scope 或 --to 明确指定;省略时只会在唯一已存在的 agent 目录上自动选择,零命中或多命中会停止并提示。content_hash 缺失或不一致均拒装。
223GitHub stars
~574最小装载
~574含声明引用
~585文本包总量
索引托管

怎么用

商店整理自技能原文 · 版本 2eae60e · 表述以原文为准
它做什么

装上后,Claude 会进入设计模式,针对软件功能先通过视觉场景(如输入输出对比、UI 草图)探索问题,而不是直接编码。它会引导你逐步明确需求、研究现有模式、推演流程,并在每一步展示选项让你选择。

什么时候触发

当你提出设计新功能、工具、UI、工作流等系统时触发。适合在实现之前使用。

装好后可以这样说
Claude 会展示注册步骤的视觉场景。
Claude 会画出界面状态转换。
Claude 会展示输入输出对比。
技能原文 SKILL.md作者撰写 · Apache-2.0 · 2eae60e

STARTER_CHARACTER = 🎨

Purpose

Stay in design mode. Resist jumping to implementation. Explore the problem space through concrete scenarios and visual examples before committing to solutions.

Core Principle: Show, Don't Tell

Instead of describing what happens in prose, show it visually. Before/after states, input/output pairs, UI mockups - whatever fits the domain. Visual beats prose.

Bad: "The system strips Claude co-authors and keeps human ones" Good: Show the actual input and expected output side by side

Process
Problem → Research → Timeline → Scenarios → Decisions → Validation
    ↑__________________________________________________|
              (iterate freely)
1. Clarify the Problem
  • What are we building? Why?
  • What does success look like?
  • What constraints exist?
2. Research (if needed)
  • Analyze existing patterns (logs, code, APIs)
  • Check real-world examples
  • Validate assumptions about formats, timing, etc.
3. Think in Timeline

Once the problem is understood, walk through what happens in order:

  • What happens first?
  • Then what?
  • What triggers the next step?

This uncovers unknowns. Each step becomes a scenario to explore.

4. Show Scenarios Visually

For each scenario, show the transformation or state change. Format depends on domain:

  • Config/data: show before and after
  • UI: show screen states and transitions
  • Pipelines: show input → output
  • Workflows: show steps with arrows

Use domain language. Stay high-level. Show complete examples, don't truncate.

5. Surface Options, Then Decide

Present several options with tradeoffs. Don't decide alone:

  • "Option A does X, Option B does Y. Which direction?"
  • Wait for input before proceeding
6. Validate Before Building
  • POC for risky assumptions (API timing, format parsing)
  • Visual test cases (input → expected output)
  • Document findings
7. Document Decisions

Track what was decided and why. Update docs as design evolves.

Anti-patterns
  • Jumping to code before exploring the design space
  • Describing scenarios in prose instead of showing them visually
  • Showing one solution instead of options
  • Asking multiple questions at once (show the whole list, then ask each one at a time)
  • Making assumptions without checking (real data, real APIs)
  • Skipping visuals for "obvious" cases
  • Truncating examples (show complete data)
  • Deciding without discussing tradeoffs
When to Exit Design Mode
  • Problem is understood
  • Key scenarios walked through (shown visually)
  • Major decisions made and documented
  • Test cases exist as visual examples
  • Risky assumptions validated

Then: implementation.

按 Apache-2.0 许可原样转载,未经改动 · 在 GitHub 查看 →

评论

登录即可评论;带「已验证安装」的,是发布者名下有本店的安装或持有记录。