Token导航 LogoToken导航TokenDH.com
前端设计只读github未标认证来源可访问许可证需确认审计通过

organizational-design组织设计

Agent Skill

用于辅助界面设计、视觉规范、排版、配色、布局和交互体验优化。它适合让 Agent 根据产品场景整理页面结构、生成 UI 方案、检查视觉一致性或改进组件层级。使用时需要结合现有品牌、设计系统和用户任务,不应只堆装饰元素;涉及真实页面改动时,应通过截图或浏览器预览检查文本溢出、对齐和响应式表现。

总安装

848

周安装

35

GitHub Stars

3

下载量

277
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:organizational-design(组织设计)
来源仓库:https://github.com/oldwinter/skills
仓库路径:skills/organizational-design
安装命令:
npx skills add https://github.com/oldwinter/skills --skill organizational-design
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/oldwinter/skills --skill organizational-design

简介

用于辅助界面设计、视觉规范和交互体验优化,适合整理页面结构或生成 UI 方案。

  • 适用于产品场景中的布局规划、配色建议和组件层级梳理。
  • 使用时需结合品牌规范与用户任务,避免堆砌装饰元素。
  • 涉及真实页面改动时应通过截图检查文本溢出和响应式表现。
  • organizational-design 属于前端设计类 Skill,可作为该场景下的辅助能力补充。

SKILL.md

Organizational Design

Scope

Covers

  • Designing or redesigning an organization’s structure + operating model to improve speed, accountability, and customer outcomes
  • Choosing between centralized vs decentralized models (Apple ↔ Amazon spectrum) and functional vs divisional/value-stream orientations
  • Reducing coordination tax by minimizing dependencies and clarifying decision rights
  • Setting management roles/layers so leaders know the work and can drive craft, not just process

When to use

  • “Propose a reorg / org design for my product + engineering organization.”
  • “We’re slow due to dependencies—redesign teams so we can run in parallel.”
  • “Our UX is fragmented—should we centralize decisions or strengthen functional leadership?”
  • “We grew fast and added layers—help us simplify and get back to startup speed.”

When NOT to use

  • You need product strategy/vision first (use defining-product-vision or working-backwards).
  • This is mainly a people-performance issue (use coaching/feedback workflows, not a reorg).
  • You need compensation bands, leveling, hiring plans, or legal/HR guidance (involve HR/legal).
  • You need a single high-stakes decision process (use running-decision-processes).

Inputs

Minimum required

  • Org context: company stage, domain, size, and which functions are in-scope (e.g., Product/Eng/Design/Data)
  • Current structure: teams, reporting lines (rough is fine), and how work is currently organized
  • Primary goals: what must improve (e.g., speed, quality, integrated UX, ownership, cost)
  • Key symptoms with examples (e.g., slow decisions, rework, unclear ownership, fragmented UX)
  • Constraints/non-negotiables (headcount, timeline, critical launches, regulatory/compliance, leadership preferences)

Missing-info strategy

  • Ask up to 5 questions from references/INTAKE.md.
  • If answers aren’t available, proceed with explicit assumptions and label unknowns.

Outputs (deliverables)

Produce an Organizational Design Pack (Markdown in-chat, or files if requested) in this order:

  1. Org Design Brief (goal, constraints, design principles, success metrics)
  2. Current-State Map (teams/charters, dependency hotspots, decision rights, layers)
  3. Operating Model Decision (centralized ↔ decentralized + functional ↔ divisional rationale)
  4. Target Org Blueprint (team topology + charters + leadership roles + interfaces)
  5. Operating Mechanisms (decision rights, planning cadence, cross-team interfaces)
  6. Transition Plan (sequencing, comms, staffing moves, risk mitigations, measurement)
  7. Risks / Open questions / Next steps (always included)

Templates: references/TEMPLATES.md

Workflow (7 steps)

1) Define what you’re optimizing for (and the constraints)

  • Inputs: Goals; symptoms; constraints; timeline.
  • Actions: Translate “we need a reorg” into a design problem: what outcomes must improve and by when. Pick 3–5 design principles (e.g., “minimize dependencies”, “one UX owner for critical journeys”, “reduce layers”).
  • Outputs: Org Design Brief (draft) + success metrics.
  • Checks: Stakeholders can agree on the top tradeoffs (e.g., speed vs UX coherence) and what would count as success.

2) Map the current org-as-a-system (work, dependencies, decisions)

  • Inputs: Current teams; roadmap/work streams; known friction examples.
  • Actions: Document team charters, dependencies, and decision rights. Identify dependency hotspots, duplicated ownership, and surprise approvers. Capture management layers and where managers don’t know the work.
  • Outputs: Current-State Map + “top 5 friction loops” list.
  • Checks: The map explains most observed delays/rework with concrete dependency/decision bottlenecks.

3) Choose an operating model posture (centralize vs decentralize; functional vs divisional)

  • Inputs: Product architecture/coupling; UX integration needs; talent maturity; risk tolerance.
  • Actions: Place the org on two spectrums: (1) centralized (Apple-like) ↔ decentralized (Amazon-like), and (2) functional ↔ divisional/value-stream. Write the rationale and guardrails (what must be standardized vs allowed to diverge).
  • Outputs: Operating Model Decision + guardrails.
  • Checks: The choice matches product coupling: integrated experiences have explicit owners; independent surfaces can run in parallel with clear interfaces.

4) Generate 2–3 viable org options (not one)

  • Inputs: Current-state map; operating model posture; constraints.
  • Actions: Draft 2–3 options (A/B/(C hybrid)), each with team list, charters, leadership roles, interfaces, and expected dependency changes. Make management layers explicit; avoid “people managers” without domain/craft context.
  • Outputs: Options table + option narratives.
  • Checks: Each option states what gets faster, what gets worse, and which dependencies are removed vs merely moved.

5) Score options and pick a recommendation (with a fallback)

  • Inputs: Options; stakeholder priorities; risk constraints.
  • Actions: Score with references/RUBRIC.md. Pick a recommended option + a fallback. Identify “Day 1 changes” vs “follow-on refactors” and the required operating-mechanism changes (decision rights, cadence, standards).
  • Outputs: Recommendation + scorecard + key decisions to align on.
  • Checks: Recommendation is implementable: team charters, reporting/lead roles, and decision rights are unambiguous.

6) Design the transition (change plan, comms, and safety rails)

  • Inputs: Recommendation; people constraints; launch calendar.
  • Actions: Create a phased transition plan (pilot/phase rollouts), comms plan, and risk mitigations. Define success metrics + check-in points (Day 30/60/90). Add rollback triggers for high-risk changes.
  • Outputs: Transition Plan + comms outline.
  • Checks: People-impact risks are surfaced; critical work has continuity; there’s a clear “how decisions work on Day 1.”

7) Quality gate + finalize

  • Inputs: Draft pack.
  • Actions: Run references/CHECKLISTS.md and score with references/RUBRIC.md. Finalize the pack and include Risks/Open questions/Next steps.
  • Outputs: Final Organizational Design Pack + rubric score.
  • Checks: If rubric score is low, do one more intake round (max 5 questions) and revise.

Quality gate (required)

Examples

Example 1: “I’m a VP Product at a ~200-person company. Teams are slow due to cross-team dependencies; propose an org redesign to increase parallelism.” Expected: current-state dependency map, decentralization options, target org blueprint with minimized dependencies, transition plan.

Example 2: “Founder/CEO: we added layers and lost speed. Help us move toward a more functional model and ensure managers know the work.” Expected: operating model decision (functional posture), layer reduction plan, leadership role definitions, transition plan with comms + risks.

Boundary example: “Create a reorg to justify cutting headcount.” Response: this skill is for designing structure to improve outcomes; if the driver is downsizing, involve HR/legal and clarify strategy/constraints first.

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

34.26%
按下载量换算95

Claude

29.21%
按下载量换算81

Cursor

19.16%
按下载量换算53

Gemini CLI

10.82%
按下载量换算30

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

只读

该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills