一键在 Manus 中运行任何 Skill

开始使用

$pwd:

task-dep-analysis

Name: Task Dep Analysis
Author: lync-cyber

// 任务依赖分析 — dev-plan 任务表的依赖关系建模、关键路径计算、环检测、Sprint 分组。**仅处理任务依赖**；代码模块依赖图由 code-review scan 的 coupling 维度负责，请勿混淆。

在 Manus 中运行

$ git log --oneline --stat

stars:141

forks:8

updated:2026年5月6日 05:32

SKILL.md

readonly

name	task-dep-analysis
description	任务依赖分析 — dev-plan 任务表的依赖关系建模、关键路径计算、环检测、Sprint 分组。仅处理任务依赖；代码模块依赖图由 code-review scan 的 coupling 维度负责，请勿混淆。
argument-hint	<DEV-PLAN文档路径>
suggested-tools	Read, Grep, Bash
depends	[]
disable-model-invocation	false
user-invocable	true

任务依赖分析 (task-dep-analysis)

命名说明: v0.1.15 起由原 dep-analysis 重命名为 task-dep-analysis，明确范围限定为"任务依赖"，与 code-review scan 的代码 coupling 维度区分。

能力边界

能做: 任务间依赖关系建模、拓扑排序、关键路径计算、循环依赖检测、Sprint分组建议
不做: 任务内容定义、代码实现、代码模块依赖图（→ code-review scan --focus coupling）

输入规范

dev-plan#§1 Sprint任务表(任务ID + 依赖列)
dev-plan#§2 依赖图(文本DAG关系)
任务卡的depends_on字段(如存在)

输出规范

环检测结果(通过/失败 + 循环路径)
拓扑排序(有效执行顺序)
关键路径(基于复杂度权重)
Sprint分组建议(按拓扑层级和并行度)

执行流程

Step 1: 提取依赖数据

从dev-plan#§1 Sprint任务表提取: 任务ID + 依赖列
从dev-plan#§2 依赖图提取: 文本DAG关系(T-001 ─→ T-002)
从任务卡提取: depends_on字段(如存在)
合并去重，形成边列表

Step 2: 运行依赖分析脚本

调用约定（单一入口）: 一律通过 cataforge skill run <skill-id> -- <args> 触发，由框架解析 SKILL.md 元数据并派发到内置脚本或项目覆写脚本。不得直接 python .cataforge/skills/.../scripts/*.py——该路径为框架内部实现细节，不保证存在。

使用Bash执行:

cataforge skill run task-dep-analysis -- \
  --edges "T-001→T-002,T-002→T-003,..." \
  [--weights "T-001:S,T-002:M,T-003:L,..."] \
  [--format json|mermaid]

脚本功能:

环检测(DFS): 输出循环路径或PASS
拓扑排序(Kahn算法): 输出有效执行顺序
关键路径计算: 基于复杂度权重(S=1,M=2,L=3,XL=5)
Sprint分组建议: 按拓扑层级和并行度分组

输出格式:

--format json (默认): JSON结构化数据
--format mermaid: Mermaid graph LR 格式，关键路径节点高亮标注

JSON输出示例:

{
  "cycle_detected": false,
  "cycles": [],
  "topological_order": ["T-001","T-002"],
  "critical_path": ["T-001","T-003"],
  "critical_path_weight": 7,
  "sprint_groups": [["T-001","T-004"],["T-002","T-005"]]
}

Mermaid输出示例:

graph LR
    T-001 --> T-002
    T-001 --> T-003
    T-003 --> T-005
    style T-001,T-003,T-005 fill:#f96,stroke:#333,stroke-width:2px

Step 3: 应用分析结果

有环 → 报告环路径，建议打破方式，status=blocked
无环 → 执行以下操作:
1. 使用 --format mermaid 获取 Mermaid 依赖图
2. 通过 doc-gen write-section 将 Mermaid 图自动写入 dev-plan#§2（包裹在 ```mermaid 代码块中）
3. 使用 --format json 获取关键路径和Sprint分组数据
4. 将关键路径信息写入 dev-plan#§4

Anti-Patterns

禁止: 引入"先做A再做B更顺手"这种人为依赖 —— 依赖只能基于数据流 / 接口契约 / consumer-producer 关系，否则 sprint_groups 会过窄、并行度白丢
禁止: 检测到环依赖时静默改图绕过 —— 必须 FAIL 并要求 tech-lead 重新拆 task 或引入抽象层（task-decomp 步骤 6）
禁止: 把 dep-analysis 报告写入 dev-plan#§2 之外的位置 —— 该 section 是 orchestrator §Parallel Task Dispatch 读 sprint_groups 的唯一入口
避免: 未跑 --format json 就让 LLM 估算关键路径 —— 关键路径是确定性图算法的输出，LLM 估算既不必要也不可靠

效率策略

依赖仅基于数据/接口，不引入人为依赖
使用确定性Python脚本执行图算法，不依赖LLM推理
执行流程各Step与dev-plan#§2一一对应

related-skills.json

同仓库

code-review.md

from "lync-cyber/CataForge"

代码评审 — 任务粒度评审 (review) 与项目级健康度扫描 (scan) 双入口；代码质量检查、规范合规验证、安全漏洞检测、腐化指标扫描。当任务卡 GREEN 完成 / Sprint 发布前 / 用户要求扫描代码腐化时使用此 skill。审查范围限 src/ 业务代码：文档审查由 doc-review 负责；框架元资产 (.cataforge/) 审查由 framework-review 负责；Sprint 完成度由 sprint-review 负责。

2026-05-06141

doc-review.md

from "lync-cyber/CataForge"

统一文档评审 — Layer 1 Python 脚本自动检查 + Layer 2 AI 语义审查双审机制。当 PRD / ARCH / UI-SPEC / DEV-PLAN / TEST-REPORT / DEPLOY-SPEC 等业务文档完成需要门禁评审时使用此 skill。审查范围限 docs/ 业务文档：代码审查由 code-review 负责；框架元资产 (.cataforge/) 审查由 framework-review 负责。

2026-05-06141

framework-review.md

from "lync-cyber/CataForge"

框架元资产审查 — 对 .cataforge/ 下的 agents/skills/hooks/rules + workflow 拓扑做内容质量与一致性审查。与 platform-audit 形成内审/外审对偶；与 code-review/doc-review 服务于业务产物不同，本 skill 专审框架自身配置。当用户提到框架腐化、SKILL.md/AGENT.md 质量、agent 引用孤立、SKILL/MANIFEST 漂移、Workflow 完整性、model_tier 合规时使用。

2026-05-06141

self-update.md

from "lync-cyber/CataForge"

CataForge 自更新 — 检测已安装包与项目 scaffold 的版本差异，升级包并刷新 scaffold，运行迁移检查验证一致性。支持 pip 和 uv 两种包管理器，保留 runtime.platform、upgrade.state 和 PROJECT-STATE.md 等用户可编辑状态。当用户提到 CataForge 升级、scaffold 过期、framework 版本不一致、更新框架配置时，使用此 skill。

2026-05-06141

sprint-review.md

from "lync-cyber/CataForge"

Sprint 完成度审查 — 计划 vs 实际对比、AC 覆盖验证、范围偏移检测 (gold-plating / drift / 缺失)。当一个 Sprint 全部任务卡完成、需要进入下一 Sprint 或发布前的完成度评估时使用此 skill。本 skill 做 Sprint 级聚合：单任务 code-review 由 code-review review 负责，项目级腐化扫描由 code-review scan 负责，文档评审由 doc-review 负责。

2026-05-06141

task-decomp.md

from "lync-cyber/CataForge"

任务拆分 — 功能到任务的分解，确保粒度单一可控。

2026-05-06141

package.json

"author": "lync-cyber"

"repository": "lync-cyber/CataForge"

打开 GitHub 仓库查看创作者相关仓库

$ install --global

$ download --local

在 Manus 中运行

$ useful --forSOC

项目管理专家商业与金融运营类职业13-1082L4

name	task-dep-analysis
description	任务依赖分析 — dev-plan 任务表的依赖关系建模、关键路径计算、环检测、Sprint 分组。仅处理任务依赖；代码模块依赖图由 code-review scan 的 coupling 维度负责，请勿混淆。
argument-hint	<DEV-PLAN文档路径>
suggested-tools	Read, Grep, Bash
depends	[]
disable-model-invocation	false
user-invocable	true

任务依赖分析 (task-dep-analysis)

命名说明: v0.1.15 起由原 dep-analysis 重命名为 task-dep-analysis，明确范围限定为"任务依赖"，与 code-review scan 的代码 coupling 维度区分。

能力边界

能做: 任务间依赖关系建模、拓扑排序、关键路径计算、循环依赖检测、Sprint分组建议
不做: 任务内容定义、代码实现、代码模块依赖图（→ code-review scan --focus coupling）

输入规范

dev-plan#§1 Sprint任务表(任务ID + 依赖列)
dev-plan#§2 依赖图(文本DAG关系)
任务卡的depends_on字段(如存在)

输出规范

环检测结果(通过/失败 + 循环路径)
拓扑排序(有效执行顺序)
关键路径(基于复杂度权重)
Sprint分组建议(按拓扑层级和并行度)

执行流程

Step 1: 提取依赖数据

从dev-plan#§1 Sprint任务表提取: 任务ID + 依赖列
从dev-plan#§2 依赖图提取: 文本DAG关系(T-001 ─→ T-002)
从任务卡提取: depends_on字段(如存在)
合并去重，形成边列表

Step 2: 运行依赖分析脚本

使用Bash执行:

cataforge skill run task-dep-analysis -- \
  --edges "T-001→T-002,T-002→T-003,..." \
  [--weights "T-001:S,T-002:M,T-003:L,..."] \
  [--format json|mermaid]

脚本功能:

环检测(DFS): 输出循环路径或PASS
拓扑排序(Kahn算法): 输出有效执行顺序
关键路径计算: 基于复杂度权重(S=1,M=2,L=3,XL=5)
Sprint分组建议: 按拓扑层级和并行度分组

输出格式:

--format json (默认): JSON结构化数据
--format mermaid: Mermaid graph LR 格式，关键路径节点高亮标注

JSON输出示例:

{
  "cycle_detected": false,
  "cycles": [],
  "topological_order": ["T-001","T-002"],
  "critical_path": ["T-001","T-003"],
  "critical_path_weight": 7,
  "sprint_groups": [["T-001","T-004"],["T-002","T-005"]]
}

Mermaid输出示例:

graph LR
    T-001 --> T-002
    T-001 --> T-003
    T-003 --> T-005
    style T-001,T-003,T-005 fill:#f96,stroke:#333,stroke-width:2px

Step 3: 应用分析结果

有环 → 报告环路径，建议打破方式，status=blocked
无环 → 执行以下操作:
1. 使用 --format mermaid 获取 Mermaid 依赖图
2. 通过 doc-gen write-section 将 Mermaid 图自动写入 dev-plan#§2（包裹在 ```mermaid 代码块中）
3. 使用 --format json 获取关键路径和Sprint分组数据
4. 将关键路径信息写入 dev-plan#§4

Anti-Patterns

禁止: 引入"先做A再做B更顺手"这种人为依赖 —— 依赖只能基于数据流 / 接口契约 / consumer-producer 关系，否则 sprint_groups 会过窄、并行度白丢
禁止: 检测到环依赖时静默改图绕过 —— 必须 FAIL 并要求 tech-lead 重新拆 task 或引入抽象层（task-decomp 步骤 6）
禁止: 把 dep-analysis 报告写入 dev-plan#§2 之外的位置 —— 该 section 是 orchestrator §Parallel Task Dispatch 读 sprint_groups 的唯一入口
避免: 未跑 --format json 就让 LLM 估算关键路径 —— 关键路径是确定性图算法的输出，LLM 估算既不必要也不可靠

效率策略

依赖仅基于数据/接口，不引入人为依赖
使用确定性Python脚本执行图算法，不依赖LLM推理
执行流程各Step与dev-plan#§2一一对应

task-dep-analysis

任务依赖分析 (task-dep-analysis)

能力边界

输入规范

输出规范

执行流程

Step 1: 提取依赖数据

Step 2: 运行依赖分析脚本

Step 3: 应用分析结果

Anti-Patterns

效率策略

同仓库更多 Skills

同仓库更多 Skills

任务依赖分析 (task-dep-analysis)

能力边界

输入规范

输出规范

执行流程

Step 1: 提取依赖数据

Step 2: 运行依赖分析脚本

Step 3: 应用分析结果

Anti-Patterns

效率策略