ワンクリックでManusで任意のスキルを実行

始める

task-dep-analysis

スター134

フォーク10

更新日2026年7月3日 04:33

任务依赖分析 — dev-plan 任务表的依赖关系建模、关键路径计算、环检测、Sprint 分组。仅处理任务依赖，不含代码模块依赖。

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

lync-cyber

lync-cyber/CataForge

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

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

能力边界

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

输入规范

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

输出规范

环检测结果(通过/失败 + 循环路径)
拓扑排序(有效执行顺序)
关键路径(基于复杂度权重)
Sprint分组建议(按拓扑层级和并行度)
落盘: 上述产物经 §执行流程写入 dev-plan 文档对应章节（依赖图 Mermaid → dev-plan#§2、关键路径与 Sprint 分组 → dev-plan#§4）

执行流程

Step 1: 提取依赖数据

数据源（自动）:

优先经图谱取依赖边 — 用 context 的 query 分支把"列出所有任务依赖边（T→T）"翻译为只读追溯查询并执行，返回的 src→dst 对直接拼成 --edges "T-001→T-002,..."，无需再读 Markdown。
回退读文档 — 追溯后端不可用时，从 dev-plan#§1 Sprint 任务表（任务 ID + 依赖列）、§2 依赖图（文本 DAG，T-001 ─→ T-002）、任务卡 depends_on 字段提取，合并去重成边列表。

任一路径都必须输出边列表（(src, dst) 元组），交给 Step 2 的脚本。

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]

脚本功能:

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

输出: --format json（默认且唯一）输出 JSON 结构化分析数据。依赖图的 Mermaid 可视化由 cataforge viz tasks --format mermaid --edges "..." 产出（同一图算法、同一关键路径高亮）。

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"]]
}

cataforge viz tasks --format 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. 使用 cataforge viz tasks --format mermaid --edges "..." 获取 Mermaid 依赖图
2. 通过 cataforge context write-narrative 将 Mermaid 图写入 dev-plan §2（包裹在 ```mermaid 代码块中）
3. 使用 cataforge skill run task-dep-analysis -- --format json 获取关键路径和 Sprint 分组数据
4. 将关键路径信息写入 dev-plan#§4

Anti-Patterns

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

效率策略

使用确定性Python脚本执行图算法，不依赖LLM推理

このリポジトリの他の Skills

同じリポジトリ

framework-walkthrough

lync-cyber/CataForge

项目走查 — 在隔离沙盒中以指定执行模式（缺省 standard 全阶段）把一个小型示例项目跑通整条 SDLC 工作流（初始化→核心执行链路→分支→异常→终止清理），逐路径观察各阶段/门禁/降级/恢复的真实行为，产出『框架本身 + 走查流程本身』两类改进建议，并把走查流程自身的改进经自更新协议回灌本 skill 迭代。与 framework-review 形成动静对偶：后者静态审元资产，本 skill 动态端到端自测。当用户想验证一次框架部署是否真能跑通、为非 Claude-Code 平台做行为级冒烟、或自测 workflow-framework-generator 生成的框架时使用。

2026-07-17134

testing

lync-cyber/CataForge

测试 — 测试策略规划、测试编写与执行、覆盖率分析、缺陷记录。当需要规划测试策略、编写或执行测试套件、分析覆盖率或记录缺陷时使用。本 skill 不改源码（缺陷修复由 debug 负责），单任务 RED/GREEN 单元测试由 tdd-engine 负责，testing 聚焦集成/E2E 与覆盖盲区补充。

2026-07-17134

code-review

lync-cyber/CataForge

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

2026-07-16134

context

lync-cyber/CataForge

统一上下文 I/O — 按需读取章节/实体、查询追溯关系、生成与写入、门禁校验。文档生命周期的单一入口；后端(知识图谱/文件)由框架按配置方案透明路由,调用方只表达意图。按操作分支见 references/。

2026-07-16134

feature-walkthrough

lync-cyber/CataForge

功能走查 — 对交付项目的功能实现做验收式动态走查，两层正交判定：①功能是否兑现 spec（missing/drift/bug/pass）；②代码本身是否健康（复用 COMMON-RULES §统一问题分类体系的 code category）。用真实数据路径起真实服务复现，专捞门禁全绿仍漏的跨模块集成缝隙。当项目功能交付后需验收、Sprint 发布前做功能级复核、或用户要求走查某功能域时使用。与 framework-walkthrough 动静对偶：后者在沙盒自测框架 SDLC，本 skill 验收交付项目的功能实现。

2026-07-16134

framework-review

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-07-16134

name	task-dep-analysis
description	任务依赖分析 — dev-plan 任务表的依赖关系建模、关键路径计算、环检测、Sprint 分组。仅处理任务依赖，不含代码模块依赖。
argument-hint	<DEV-PLAN文档路径>
suggested-tools	file_read, file_grep, shell_exec
depends	[]
disable-model-invocation	false
user-invocable	true

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

能力边界

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

输入规范

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

输出规范

环检测结果(通过/失败 + 循环路径)
拓扑排序(有效执行顺序)
关键路径(基于复杂度权重)
Sprint分组建议(按拓扑层级和并行度)
落盘: 上述产物经 §执行流程写入 dev-plan 文档对应章节（依赖图 Mermaid → dev-plan#§2、关键路径与 Sprint 分组 → dev-plan#§4）

执行流程

Step 1: 提取依赖数据

数据源（自动）:

优先经图谱取依赖边 — 用 context 的 query 分支把"列出所有任务依赖边（T→T）"翻译为只读追溯查询并执行，返回的 src→dst 对直接拼成 --edges "T-001→T-002,..."，无需再读 Markdown。
回退读文档 — 追溯后端不可用时，从 dev-plan#§1 Sprint 任务表（任务 ID + 依赖列）、§2 依赖图（文本 DAG，T-001 ─→ T-002）、任务卡 depends_on 字段提取，合并去重成边列表。

任一路径都必须输出边列表（(src, dst) 元组），交给 Step 2 的脚本。

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]

脚本功能:

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

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"]]
}

cataforge viz tasks --format 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. 使用 cataforge viz tasks --format mermaid --edges "..." 获取 Mermaid 依赖图
2. 通过 cataforge context write-narrative 将 Mermaid 图写入 dev-plan §2（包裹在 ```mermaid 代码块中）
3. 使用 cataforge skill run task-dep-analysis -- --format json 获取关键路径和 Sprint 分组数据
4. 将关键路径信息写入 dev-plan#§4

Anti-Patterns

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

效率策略

使用确定性Python脚本执行图算法，不依赖LLM推理