Token导航 LogoToken导航

Agent Skill · 待分类

decomposition-planning-roadmap(分解规划路线图)

decomposition-planning-roadmap 用于处理 GitHub 仓库、Issue、Pull Request 和代码协作信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要围绕仓库状态、代码变更或协作事项进行整理时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

decomposition-planning-roadmap 是待分类类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为权限未标注;许可证信息还不明确,暂无第三方扫描结果,按安装量在待分类类的 11,209 个 Skill 里排第 1,544。

总安装 2,962周安装 121GitHub Stars 2,196下载 949核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
unknown

安装方式

通过对话安装

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

请帮我安装这个 Agent Skill:decomposition-planning-roadmap(分解规划路线图)
来源仓库:https://github.com/tech-leads-club/agent-skills
仓库路径:skills/decomposition-planning-roadmap
安装命令:
npx skills add https://github.com/tech-leads-club/agent-skills --skill decomposition-planning-roadmap
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

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

skills.shnpx skills
npx skills add https://github.com/tech-leads-club/agent-skills --skill decomposition-planning-roadmap

这个 Skill 是做什么的

这个 Skill 的分类还没最终确定,用法以来源仓库的说明为准。

decomposition-planning-roadmap 暂无可用说明,无法提供功能概述和使用指导。当前分类标记为待分类,建议查看 GitHub 仓库获取最新信息或联系维护者确认用途。安装前请核实来源仓库状态,避免引入未经验证的功能或安全风险。

由于缺乏 SKILL.md 内容,无法判断其适用宿主、权限需求或使用限制。适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

来源仓库内路径:skills/decomposition-planning-roadmap

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/tech-leads-club/agent-skills --skill decomposi…;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    权限没有明确标注,第一次使用时只给一个无关紧要的任务,观察它到底读了哪些文件和网络。

常见问题

6 条

decomposition-planning-roadmap 怎么安装?

在终端执行 npx skills add https://github.com/tech-leads-club/agent-skills --skill decomposition-plann…。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

decomposition-planning-roadmap 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

decomposition-planning-roadmap 需要什么权限?

权限级别没有明确标注。第一次使用时建议只给无关紧要的任务,观察它实际读写了哪些内容。

decomposition-planning-roadmap 是免费的吗?

公开资料没有标注明确许可证,收费和商用限制都无法确认。正式使用前请到来源仓库核对授权说明。

decomposition-planning-roadmap 用的人多吗?

公开数据是累计安装 2,962 次,近一周安装 121 次,下载 949 次,GitHub 2,196 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

decomposition-planning-roadmap 安全吗?

没有查到第三方扫描结果,安全性无法从公开资料判断,安装前请自行审查源码、依赖和命令行为。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 来源仓库有 2,196 星,维护活跃度相对可查。

先想清楚的地方

  • 许可证没有明确标注,能不能商用、能不能再分发都不确定。
  • 没有第三方扫描结果,安全性只能靠自己读源码判断。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理待分类类任务、又不想每次都手写提示词的人。

不太适合

  • 需要明确授权才能用到公司项目里的场景。
  • 要求有安全扫描结论才肯安装的团队。
  • 需要厂商级技术支持和 SLA 的生产系统。

待分类类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
infsh-cli

infsh CLI · Codex、Claude

4,374,576382权限未标注未明确未收录
ai-video-generation

AI 视频生成 · Codex、Claude

4,313,376382调用外部服务未明确有提醒
lark-openapi-explorer

云雀 OpenAPI 浏览器 · Codex、Claude

2,064,1209,011需要联网未明确有提醒
lark-workflow-standup-report

Lark 工作流程站立报告 · Codex、Claude

2,041,6328,978需要联网未明确通过
use-my-browser

使用我的浏览器 · Codex、Claude

1,848,49140操作浏览器未明确未通过
decomposition-planning-roadmap

分解规划路线图 · 本页

2,9622,196权限未标注未明确未收录

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

Decomposition Planning and Roadmap

This skill creates structured decomposition plans and roadmaps to guide the migration from monolithic to distributed architectures, prioritizing work and tracking progress through decomposition patterns.

How to Use

Quick Start

Request creation of a decomposition plan:

  • "Create a decomposition roadmap for this codebase"
  • "Plan the decomposition migration strategy"
  • "Prioritize decomposition work based on component analysis"
  • "Create a step-by-step decomposition plan"

Usage Examples

Example 1: Complete Roadmap

User: "Create a decomposition roadmap for this codebase"

The skill will:
1. Analyze current codebase state
2. Identify decomposition patterns to apply
3. Prioritize work based on risk and value
4. Create phased roadmap
5. Generate architecture stories
6. Estimate effort and dependencies

Example 2: Prioritized Plan

User: "Prioritize decomposition work based on component analysis"

The skill will:
1. Review component inventory and dependencies
2. Assess risk and value for each pattern
3. Prioritize patterns by impact
4. Create prioritized work plan

Example 3: Phase Planning

User: "Create a phased decomposition plan"

The skill will:
1. Group decomposition patterns into phases
2. Identify dependencies between phases
3. Create phase timeline
4. Define phase success criteria

Step-by-Step Process

  1. Assess Current State: Analyze codebase and identify what's been done
  2. Identify Patterns: Determine which decomposition patterns to apply
  3. Prioritize Work: Rank patterns by risk, value, and dependencies
  4. Create Roadmap: Build phased plan with milestones
  5. Generate Stories: Create architecture stories for tracking
  6. Track Progress: Monitor progress through decomposition phases

When to Use

Apply this skill when:

  • Starting a decomposition effort
  • Planning migration from monolith to distributed architecture
  • Prioritizing decomposition work
  • Creating architecture stories for decomposition
  • Tracking progress through decomposition patterns
  • Need structured approach to decomposition
  • Want to estimate effort and dependencies

Core Concepts

Decomposition Pattern Sequence

The six component-based decomposition patterns should be applied in sequence:

  1. Identify and Size Components - Understand what you have
  2. Gather Common Domain Components - Find duplicates
  3. Flatten Components - Remove orphaned classes
  4. Determine Component Dependencies - Assess coupling
  5. Create Component Domains - Group into domains
  6. Create Domain Services - Extract to services

Phased Approach

Decomposition typically follows phases:

Phase 1: Analysis & Preparation (Patterns 1-4)

  • Component identification and sizing
  • Common component detection
  • Component flattening
  • Dependency analysis

Phase 2: Domain Organization (Pattern 5)

  • Domain identification
  • Component grouping
  • Namespace refactoring

Phase 3: Service Extraction (Pattern 6)

  • Domain service creation
  • Service extraction
  • API boundary definition

Prioritization Factors

When prioritizing decomposition work, consider:

  • Risk: Low risk = easier to extract, fewer dependencies
  • Value: High value = business-critical, high impact
  • Dependencies: Can this be done independently?
  • Complexity: Simple = fewer components, clear boundaries
  • Coupling: Low coupling = easier to extract

Analysis Process

Phase 1: Assess Current State

Analyze what's already been done:

  1. Check Component Inventory

- Have components been identified and sized? - Is there a component inventory document? - Are oversized components identified?

  1. Check Common Component Analysis

- Have common domain components been identified? - Are consolidation opportunities documented? - Has coupling impact been analyzed?

  1. Check Component Structure

- Have components been flattened? - Are there orphaned classes? - Is component structure clean?

  1. Check Dependency Analysis

- Have component dependencies been mapped? - Is coupling analysis complete? - Is feasibility assessed?

  1. Check Domain Identification

- Have domains been identified? - Are components grouped into domains? - Are namespaces aligned with domains?

  1. Check Service Extraction

- Have any services been extracted? - Are domain services created? - Is service-based architecture in place?

Output: Current state assessment showing what's done and what's remaining

Phase 2: Identify Patterns to Apply

Determine which decomposition patterns need to be applied:

  1. Review Pattern Prerequisites

- Pattern 1: Always needed (foundation) - Pattern 2: Needed if common components exist - Pattern 3: Needed if components have hierarchy - Pattern 4: Always needed (feasibility check) - Pattern 5: Needed before service extraction - Pattern 6: Final step (service extraction)

  1. Check Pattern Completion

- Which patterns are complete? - Which patterns are in progress? - Which patterns haven't started?

  1. Identify Missing Patterns

- What patterns still need to be applied? - What's blocking pattern application? - What dependencies exist?

Output: List of patterns to apply with status

Phase 3: Prioritize Work

Prioritize decomposition patterns and work items:

  1. Assess Risk

- Low Risk: Infrastructure components, standalone functionality - Medium Risk: Domain components with some dependencies - High Risk: Core business logic, high coupling

  1. Assess Value

- High Value: Business-critical, high impact, frequent changes - Medium Value: Important but not critical - Low Value: Nice to have, low impact

  1. Assess Dependencies

- Independent: Can be done without other work - Dependent: Requires other patterns/work first - Blocking: Blocks other work from proceeding

  1. Calculate Priority Score Priority = (Value × 3) - (Risk × 2) - (Dependencies × 1) Higher score = Higher priority

Output: Prioritized list of patterns and work items

Phase 4: Create Phased Roadmap

Build a phased roadmap with milestones:

  1. Define Phases

- Phase 1: Analysis & Preparation - Phase 2: Domain Organization - Phase 3: Service Extraction - Phase 4: Optimization & Refinement

  1. Assign Patterns to Phases

- Which patterns belong in which phase? - What's the sequence within each phase? - What are the phase dependencies?

  1. Set Milestones

- What marks completion of each phase? - What are the success criteria? - What deliverables are expected?

  1. Estimate Timeline

- How long will each phase take? - What are the dependencies? - What's the critical path?

Output: Phased roadmap with timeline and milestones

Phase 5: Generate Architecture Stories

Create architecture stories for tracking work:

  1. Create Story Template As an architect, I need to [apply pattern/refactor component] to support [architectural characteristic/business need] so that [benefit/outcome]
  2. Break Down Work

- One story per pattern application - One story per major refactoring - One story per domain grouping

  1. Add Acceptance Criteria

- What defines "done"? - What metrics validate success? - What tests verify completion?

  1. Estimate Effort

- Story points or time estimates - Complexity assessment - Risk factors

Output: List of architecture stories with estimates

Phase 6: Track Progress

Monitor progress through decomposition:

  1. Track Pattern Completion

- Which patterns are complete? - Which are in progress? - Which are blocked?

  1. Track Story Completion

- Stories completed - Stories in progress - Stories not started

  1. Track Metrics

- Components identified - Components refactored - Domains created - Services extracted

  1. Identify Blockers

- What's blocking progress? - What dependencies are missing? - What risks have emerged?

Output: Progress dashboard and status report

Output Format

Decomposition Roadmap

# Decomposition Roadmap

## Current State Assessment

**Completed Patterns**:

- ✅ Pattern 1: Identify and Size Components
- ✅ Pattern 2: Gather Common Domain Components
- ⚠️ Pattern 3: Flatten Components (in progress)
- ❌ Pattern 4: Determine Component Dependencies (not started)
- ❌ Pattern 5: Create Component Domains (not started)
- ❌ Pattern 6: Create Domain Services (not started)

**Key Findings**:

- 75 components identified
- 3 common domain components found
- 2 oversized components need splitting
- High database coupling detected

## Phased Roadmap

### Phase 1: Analysis & Preparation (Weeks 1-4)

**Goal**: Complete component analysis and refactoring

**Patterns**:

1. Complete Pattern 3: Flatten Components
2. Apply Pattern 4: Determine Component Dependencies
3. Refactor oversized components

**Milestones**:

- Week 2: Component flattening complete
- Week 4: Dependency analysis complete

**Deliverables**:

- Flattened component structure
- Dependency diagram
- Feasibility assessment

### Phase 2: Domain Organization (Weeks 5-8)

**Goal**: Organize components into domains

**Patterns**:

1. Apply Pattern 5: Create Component Domains
2. Refactor namespaces for domain alignment

**Milestones**:

- Week 6: Domains identified
- Week 8: Namespace refactoring complete

**Deliverables**:

- Domain map
- Refactored component namespaces
- Domain documentation

### Phase 3: Service Extraction (Weeks 9-16)

**Goal**: Extract domains to domain services

**Patterns**:

1. Apply Pattern 6: Create Domain Services
2. Extract services incrementally

**Milestones**:

- Week 12: First domain service extracted
- Week 16: All domain services extracted

**Deliverables**:

- Domain services deployed
- API boundaries defined
- Service documentation

Prioritized Work Plan

## Prioritized Work Plan

### High Priority (Do First)

1. **Complete Component Flattening** (Priority: 9/10)
   - Risk: Low
   - Value: High (enables domain grouping)
   - Dependencies: None
   - Effort: 2 weeks

2. **Dependency Analysis** (Priority: 8/10)
   - Risk: Low
   - Value: High (validates feasibility)
   - Dependencies: Component flattening
   - Effort: 1 week

### Medium Priority (Do Next)

3. **Domain Identification** (Priority: 7/10)
   - Risk: Medium
   - Value: High (enables service extraction)
   - Dependencies: Dependency analysis
   - Effort: 2 weeks

### Low Priority (Do Later)

4. **Service Extraction** (Priority: 5/10)
   - Risk: High
   - Value: High (final goal)
   - Dependencies: Domain identification
   - Effort: 8 weeks

Architecture Stories

## Architecture Stories

### Story 1: Flatten Ticket Components

**As an architect**, I need to flatten the Ticket component hierarchy
to support better component organization
so that components exist only as leaf nodes.

**Acceptance Criteria**:

- [ ] No orphaned classes in root namespaces
- [ ] All components are leaf nodes
- [ ] Component structure validated

**Estimate**: 5 story points
**Priority**: High
**Dependencies**: None

### Story 2: Identify Component Domains

**As an architect**, I need to group components into logical domains
to support service-based architecture
so that components can be extracted to domain services.

**Acceptance Criteria**:

- [ ] All components assigned to domains
- [ ] Domain boundaries validated with stakeholders
- [ ] Domain map created

**Estimate**: 8 story points
**Priority**: High
**Dependencies**: Component flattening complete

Progress Dashboard

## Decomposition Progress Dashboard

### Pattern Completion Status

| Pattern                    | Status         | Progress | Blocker                 |
| -------------------------- | -------------- | -------- | ----------------------- |
| Identify & Size Components | ✅ Complete    | 100%     | None                    |
| Gather Common Components   | ✅ Complete    | 100%     | None                    |
| Flatten Components         | ⚠️ In Progress | 60%      | None                    |
| Determine Dependencies     | ❌ Not Started | 0%       | Waiting on flattening   |
| Create Domains             | ❌ Not Started | 0%       | Waiting on dependencies |
| Create Domain Services     | ❌ Not Started | 0%       | Waiting on domains      |

### Story Completion Status

**Completed**: 5 stories (25%)
**In Progress**: 3 stories (15%)
**Not Started**: 12 stories (60%)

### Key Metrics

- Components Identified: 75
- Components Refactored: 45 (60%)
- Domains Created: 0
- Services Extracted: 0

Analysis Checklist

Current State Assessment:

  • Reviewed component inventory
  • Checked common component analysis
  • Assessed component structure
  • Reviewed dependency analysis
  • Checked domain identification
  • Assessed service extraction status

Pattern Identification:

  • Identified which patterns are complete
  • Identified which patterns are in progress
  • Identified which patterns need to be applied
  • Checked pattern dependencies

Prioritization:

  • Assessed risk for each pattern
  • Assessed value for each pattern
  • Assessed dependencies
  • Calculated priority scores

Roadmap Creation:

  • Defined phases
  • Assigned patterns to phases
  • Set milestones
  • Estimated timeline

Story Generation:

  • Created architecture stories
  • Added acceptance criteria
  • Estimated effort
  • Prioritized stories

Progress Tracking:

  • Set up tracking mechanism
  • Defined metrics
  • Created dashboard
  • Identified blockers

Implementation Notes

Roadmap Templates

Simple Roadmap (for small projects):

  • Phase 1: Analysis (2-4 weeks)
  • Phase 2: Refactoring (4-6 weeks)
  • Phase 3: Extraction (8-12 weeks)

Detailed Roadmap (for large projects):

  • Phase 1: Analysis & Preparation (4-8 weeks)
  • Phase 2: Domain Organization (4-6 weeks)
  • Phase 3: Service Extraction (12-16 weeks)
  • Phase 4: Optimization (4-8 weeks)

Prioritization Matrix

Use a 2x2 matrix for prioritization:

High Value, Low Risk    | High Value, High Risk
(Do First)              | (Do Carefully)
────────────────────────┼──────────────────────
Low Value, Low Risk     | Low Value, High Risk
(Do Later)              | (Avoid/Defer)

Story Estimation

Use story points or time estimates:

Story Points (Fibonacci):

  • 1: Trivial (few hours)
  • 2: Simple (1 day)
  • 3: Small (2-3 days)
  • 5: Medium (1 week)
  • 8: Large (2 weeks)
  • 13: Very Large (3+ weeks)

Time Estimates:

  • Small: 1-3 days
  • Medium: 1-2 weeks
  • Large: 2-4 weeks
  • Very Large: 1+ month

Best Practices

Do's ✅

  • Start with analysis patterns (Patterns 1-4)
  • Prioritize low-risk, high-value work
  • Create architecture stories for tracking
  • Set clear milestones and success criteria
  • Track progress regularly
  • Adjust roadmap based on learnings
  • Collaborate with stakeholders on priorities

Don'ts ❌

  • Don't skip analysis patterns
  • Don't start service extraction too early
  • Don't ignore dependencies between patterns
  • Don't create unrealistic timelines
  • Don't skip progress tracking
  • Don't forget to validate with stakeholders
  • Don't proceed without feasibility assessment

Integration with Other Skills

This skill coordinates the use of other decomposition skills:

  1. Component Identification & Sizing → Foundation for planning
  2. Common Domain Component Detection → Identifies consolidation work
  3. Component Flattening → Prepares for domain grouping
  4. Component Dependency Analysis → Validates feasibility
  5. Domain Identification & Grouping → Enables service extraction
  6. Decomposition Planning & Roadmap (this skill) → Coordinates everything

Next Steps

After creating the roadmap:

  1. Review with Stakeholders - Get buy-in on plan
  2. Start Phase 1 - Begin with analysis patterns
  3. Track Progress - Monitor completion and blockers
  4. Adjust as Needed - Update roadmap based on learnings
  5. Celebrate Milestones - Recognize progress

Notes

  • Roadmaps should be living documents, updated regularly
  • Prioritization may change as you learn more
  • Dependencies between patterns must be respected
  • Feasibility assessment is critical before proceeding
  • Stakeholder collaboration is essential for success
  • Progress tracking helps identify issues early

平台分布

Codex

36.39%
按下载量换算345

Claude

28.14%
按下载量换算267

Cursor

18.51%
按下载量换算176

Gemini CLI

9.7%
按下载量换算92

安全审计

暂无安全审计结果可展示。

权限和风险

权限未标注

当前来源未能明确判断权限范围,默认进入异常复核队列。

安装前确认

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

继续浏览同类 Skills