ironweave 1.1.2 → 1.1.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.cursor/rules/ironweave.mdc +12 -0
- package/{.windsurfrules → .windsurf/rules/ironweave.md} +4 -0
- package/bin/cli.js +10 -11
- package/package.json +5 -9
- package/skills/integration-test-design/SKILL.md +15 -0
- package/skills/orchestrator/SKILL.md +110 -7
- package/skills/orchestrator/references/parallel.md +20 -0
- package/skills/project-context/SKILL.md +46 -0
- package/skills/task-difficulty/SKILL.md +16 -1
- package/skills-en/integration-test-design/SKILL.md +15 -0
- package/skills-en/orchestrator/SKILL.md +110 -7
- package/skills-en/orchestrator/references/parallel.md +20 -0
- package/skills-en/project-context/SKILL.md +46 -0
- package/skills-en/task-difficulty/SKILL.md +16 -1
- package/.claude-plugin/plugin.json +0 -17
- package/.codex/INSTALL.md +0 -45
- package/.cursor-plugin/plugin.json +0 -19
- package/.opencode/INSTALL.md +0 -42
- package/gemini-extension.json +0 -6
- /package/{.clinerules → .clinerules/ironweave.md} +0 -0
- /package/{.cursorrules → .trae/rules/ironweave.md} +0 -0
|
@@ -0,0 +1,12 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Ironweave skills framework — orchestration, requirements, architecture, TDD, and quality gates
|
|
3
|
+
alwaysApply: true
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Ironweave
|
|
7
|
+
|
|
8
|
+
You have access to the Ironweave skills library — a complete software development workflow with built-in quality gates.
|
|
9
|
+
|
|
10
|
+
The **orchestrator** skill (`skills/orchestrator/SKILL.md`) is the main entry point. For any development task, start by reading it. The orchestrator automatically senses context, scores difficulty, selects the right route, and runs Plan → Execute → Validate → Deliver with quality gates.
|
|
11
|
+
|
|
12
|
+
All skills are in `skills/`, each with a `SKILL.md` containing instructions.
|
package/bin/cli.js
CHANGED
|
@@ -16,7 +16,7 @@ Usage:
|
|
|
16
16
|
|
|
17
17
|
Options:
|
|
18
18
|
--agent <name> Only install config for specific agent
|
|
19
|
-
(claude, copilot, cursor, windsurf, cline, codex, gemini, all)
|
|
19
|
+
(claude, copilot, cursor, windsurf, cline, trae, codex, gemini, all)
|
|
20
20
|
Default: all
|
|
21
21
|
--lang <lang> Language for skills: zh (Chinese, default) or en (English)
|
|
22
22
|
--skills-only Only copy skills/, skip agent config files
|
|
@@ -66,29 +66,28 @@ if (command === 'init') {
|
|
|
66
66
|
if (!skillsOnly) {
|
|
67
67
|
const agentFiles = {
|
|
68
68
|
claude: [
|
|
69
|
-
{ src: 'CLAUDE.md', dst: 'CLAUDE.md' }
|
|
70
|
-
{ src: '.claude-plugin', dst: '.claude-plugin', dir: true }
|
|
69
|
+
{ src: 'CLAUDE.md', dst: 'CLAUDE.md' }
|
|
71
70
|
],
|
|
72
71
|
copilot: [
|
|
73
72
|
{ src: '.github/copilot-instructions.md', dst: '.github/copilot-instructions.md' }
|
|
74
73
|
],
|
|
75
74
|
cursor: [
|
|
76
|
-
{ src: '.
|
|
77
|
-
{ src: '.cursor-plugin', dst: '.cursor-plugin', dir: true }
|
|
75
|
+
{ src: '.cursor/rules', dst: '.cursor/rules', dir: true }
|
|
78
76
|
],
|
|
79
77
|
windsurf: [
|
|
80
|
-
{ src: '.
|
|
78
|
+
{ src: '.windsurf/rules', dst: '.windsurf/rules', dir: true }
|
|
81
79
|
],
|
|
82
80
|
cline: [
|
|
83
|
-
{ src: '.clinerules', dst: '.clinerules' }
|
|
81
|
+
{ src: '.clinerules', dst: '.clinerules', dir: true }
|
|
82
|
+
],
|
|
83
|
+
trae: [
|
|
84
|
+
{ src: '.trae/rules', dst: '.trae/rules', dir: true }
|
|
84
85
|
],
|
|
85
86
|
codex: [
|
|
86
|
-
{ src: 'AGENTS.md', dst: 'AGENTS.md' }
|
|
87
|
-
{ src: '.codex', dst: '.codex', dir: true }
|
|
87
|
+
{ src: 'AGENTS.md', dst: 'AGENTS.md' }
|
|
88
88
|
],
|
|
89
89
|
gemini: [
|
|
90
|
-
{ src: 'GEMINI.md', dst: 'GEMINI.md' }
|
|
91
|
-
{ src: 'gemini-extension.json', dst: 'gemini-extension.json' }
|
|
90
|
+
{ src: 'GEMINI.md', dst: 'GEMINI.md' }
|
|
92
91
|
]
|
|
93
92
|
};
|
|
94
93
|
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "ironweave",
|
|
3
|
-
"version": "1.1.
|
|
3
|
+
"version": "1.1.3",
|
|
4
4
|
"description": "Agentic skills framework for AI coding agents — orchestrated workflows with adaptive routing, quality gates, and 17 composable skills.",
|
|
5
5
|
"keywords": [
|
|
6
6
|
"agent-skills",
|
|
@@ -38,15 +38,11 @@
|
|
|
38
38
|
"CLAUDE.md",
|
|
39
39
|
"AGENTS.md",
|
|
40
40
|
"GEMINI.md",
|
|
41
|
-
"
|
|
42
|
-
".
|
|
43
|
-
".
|
|
44
|
-
".
|
|
41
|
+
".cursor/",
|
|
42
|
+
".windsurf/",
|
|
43
|
+
".clinerules/",
|
|
44
|
+
".trae/",
|
|
45
45
|
".github/",
|
|
46
|
-
".claude-plugin/",
|
|
47
|
-
".cursor-plugin/",
|
|
48
|
-
".codex/",
|
|
49
|
-
".opencode/",
|
|
50
46
|
"README.md",
|
|
51
47
|
"README_CN.md",
|
|
52
48
|
"CONTRIBUTING.md",
|
|
@@ -33,6 +33,21 @@ graph TB
|
|
|
33
33
|
|
|
34
34
|
---
|
|
35
35
|
|
|
36
|
+
## 0. TDD 适用性判断
|
|
37
|
+
|
|
38
|
+
在设计测试策略之前,根据项目成熟度决定 TDD 的应用范围:
|
|
39
|
+
|
|
40
|
+
| 项目状态 | TDD 策略 | 原因 |
|
|
41
|
+
|--|--|--|
|
|
42
|
+
| 新项目(从零开始) | **全面 TDD** — 所有新代码先写测试 | 成本最低、收益最高,测试基础设施一次搭好 |
|
|
43
|
+
| 成熟项目 — 已有代码 | **不追溯补测试** | ROI 太低,除非该模块即将重构 |
|
|
44
|
+
| 成熟项目 — 新增/修改代码 | **新代码用 TDD** | 唯一低成本引入安全网的机会,渐进式提升覆盖率 |
|
|
45
|
+
| Bug 修复 | **必须写回归测试** | 回归测试是 bug fix 的核心产出,防止复现 |
|
|
46
|
+
|
|
47
|
+
> **原则**:不在遗留代码上做无意义的补测试运动,但每次改动都带测试,几个月后覆盖率自然上来。
|
|
48
|
+
|
|
49
|
+
---
|
|
50
|
+
|
|
36
51
|
## 1. 识别集成点
|
|
37
52
|
|
|
38
53
|
从时序设计中提取所有跨层/跨模块调用,标记测试级别:
|
|
@@ -1,14 +1,23 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: orchestrator
|
|
3
3
|
description: >-
|
|
4
|
-
|
|
4
|
+
项目开发全生命周期的流程编排器。接收用户输入后,先做输入分类(4 档),自适应感知项目上下文、评估任务难度、选择最优路径,编排 Plan→Execute→Validate→Deliver 四阶段并管理质量卡点和失败回流。
|
|
5
5
|
务必在以下场景使用本 skill:用户要开始一个新项目、接到一个新需求、要做一次完整的开发迭代、要从需求到交付走一遍完整流程,或者用户说"开始做"、"启动项目"、"这个需求怎么落地"、"帮我规划一下"、"从头到尾做一遍"。
|
|
6
6
|
当用户的意图是完成一个端到端的开发任务(而不是只做其中某一步),使用本 skill 来编排整个流程。如果用户只需要其中某一步(如只写需求文档),直接使用对应的专项 skill。
|
|
7
7
|
---
|
|
8
8
|
|
|
9
9
|
# Orchestrator — 流程编排器
|
|
10
10
|
|
|
11
|
-
接收用户输入 →
|
|
11
|
+
接收用户输入 → **输入分类** → 自适应上下文感知 → 评估难度 → **宏观澄清**(按需)→ **范围切片** → 选路径 → 逐 slice 编排四阶段 → 质量卡点 → 交付。
|
|
12
|
+
|
|
13
|
+
---
|
|
14
|
+
|
|
15
|
+
## 全局约束
|
|
16
|
+
|
|
17
|
+
以下两条规则贯穿所有阶段和 skill,不可豁免:
|
|
18
|
+
|
|
19
|
+
1. **证据锚定**:每个设计决策必须引用至少一条**项目上下文事实**作为依据。禁止仅用“业界最佳实践”或“通常建议”作为唯一理由。如果项目上下文中找不到支撑证据,必须明确标注“**假设**”。
|
|
20
|
+
2. **反向质疑**:推荐架构方案、技术选型或设计模式后,必须回答:**如果这个方案是错的,最可能的原因是什么?** 如果无法回答,说明理解不够深入,需要补充上下文。
|
|
12
21
|
|
|
13
22
|
---
|
|
14
23
|
|
|
@@ -16,9 +25,10 @@ description: >-
|
|
|
16
25
|
|
|
17
26
|
```mermaid
|
|
18
27
|
graph TB
|
|
19
|
-
INPUT["用户输入"] -->
|
|
28
|
+
INPUT["用户输入"] --> CLASS["输入分类<br>4 维度分析"]
|
|
29
|
+
CLASS --> CTX["自适应上下文感知<br>project-context"]
|
|
20
30
|
CTX --> SCORE["难度评估<br>task-difficulty"]
|
|
21
|
-
SCORE --> NEED_CL{"需求模糊<br>OR L4+?"}
|
|
31
|
+
SCORE --> NEED_CL{"分类=Grand<br>OR 需求模糊<br>OR L4+?"}
|
|
22
32
|
NEED_CL -->|"是"| CLARIFY["宏观澄清<br>requirement-qa(scope模式)<br>+ brainstorm(L4+)"]
|
|
23
33
|
NEED_CL -->|"否"| SLICE
|
|
24
34
|
CLARIFY --> SLICE["范围切片<br>scope-sizer"]
|
|
@@ -39,6 +49,7 @@ graph TB
|
|
|
39
49
|
NEXT -->|"否"| DONE["全部完成"]
|
|
40
50
|
|
|
41
51
|
style INPUT fill:#e8eaf6,stroke:#283593,color:#1a237e,stroke-width:2px
|
|
52
|
+
style CLASS fill:#ede7f6,stroke:#4527a0,color:#311b92,stroke-width:2px
|
|
42
53
|
style CTX fill:#e3f2fd,stroke:#1565c0,color:#0d47a1
|
|
43
54
|
style SCORE fill:#e3f2fd,stroke:#1565c0,color:#0d47a1
|
|
44
55
|
style NEED_CL fill:#fff3e0,stroke:#e65100,color:#bf360c
|
|
@@ -55,13 +66,94 @@ graph TB
|
|
|
55
66
|
|
|
56
67
|
---
|
|
57
68
|
|
|
58
|
-
##
|
|
69
|
+
## 0. 输入分类(Input Classification)
|
|
70
|
+
|
|
71
|
+
在触碰任何 skill 之前,仅基于**用户输入文本**做 4 维度分析,产出分类结果,驱动后续所有步骤选择适当的深度。
|
|
72
|
+
|
|
73
|
+
### 4 维度评估
|
|
74
|
+
|
|
75
|
+
| 维度 | 说明 | 低 → 高 |
|
|
76
|
+
|------|------|---------|
|
|
77
|
+
| **具体性** (Concreteness) | 用户指向的目标有多精确 | 具体文件/函数 → 某个模块 → 某个系统 → 宏观愿景 |
|
|
78
|
+
| **范围广度** (Scope Breadth) | 隐含涉及多少模块 | 单点 → 单模块 → 多模块 → 全系统 |
|
|
79
|
+
| **决策负载** (Decision Load) | 是否需要架构/策略层面的决策 | 无 → 少量 → 显著 → 关键 |
|
|
80
|
+
| **模糊度** (Ambiguity) | 还有多少东西未定义 | 全清晰 → 部分缺口 → 大量缺口 → 几乎未定义 |
|
|
59
81
|
|
|
60
|
-
|
|
82
|
+
### 4 档分类
|
|
83
|
+
|
|
84
|
+
```mermaid
|
|
85
|
+
graph TB
|
|
86
|
+
INPUT["用户输入文本"] --> DIM["4 维度评估<br>具体性 / 范围 / 决策 / 模糊度"]
|
|
87
|
+
DIM --> C1{"高具体 + 窄范围<br>+ 无决策 + 清晰?"}
|
|
88
|
+
C1 -->|"是"| PIN["Pinpoint 针对性"]
|
|
89
|
+
C1 -->|"否"| C2{"中等具体 + 有界<br>+ 少量决策 + 部分清晰?"}
|
|
90
|
+
C2 -->|"是"| BND["Bounded 有边界"]
|
|
91
|
+
C2 -->|"否"| C3{"抽象 + 宽范围<br>+ 有决策 + 有缺口?"}
|
|
92
|
+
C3 -->|"是"| CPX["Complex 复合型"]
|
|
93
|
+
C3 -->|"否"| GRD["Grand 宏大型"]
|
|
94
|
+
|
|
95
|
+
style INPUT fill:#e8eaf6,stroke:#283593,color:#1a237e,stroke-width:2px
|
|
96
|
+
style DIM fill:#ede7f6,stroke:#4527a0,color:#311b92
|
|
97
|
+
style PIN fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20
|
|
98
|
+
style BND fill:#fff9c4,stroke:#f9a825,color:#e65100
|
|
99
|
+
style CPX fill:#ffe0b2,stroke:#e65100,color:#bf360c
|
|
100
|
+
style GRD fill:#ffcdd2,stroke:#c62828,color:#b71c1c
|
|
101
|
+
```
|
|
102
|
+
|
|
103
|
+
| 分类 | 典型输入 | Context 策略 | 难度提示 | CLARIFY |
|
|
104
|
+
|------|---------|-------------|---------|---------|
|
|
105
|
+
| **Pinpoint** | "GET /api/users/123 返回 500"<br>"把登录按钮颜色改成蓝色" | **point-trace** | L1-L2 | 跳过 |
|
|
106
|
+
| **Bounded** | "给 user 模块加修改密码功能"<br>"优化订单列表的查询性能" | **focused-scan** | L2-L3 | 按需 |
|
|
107
|
+
| **Complex** | "增加支付模块,要对接微信和支付宝"<br>"把单体拆成前后端分离" | **broad-scan** | L3-L4 | 按需 |
|
|
108
|
+
| **Grand** | "做一个类似淘宝的电商平台"<br>"设计一个分布式事务框架" | **full-scan** | L4-L5 | **强制** |
|
|
109
|
+
|
|
110
|
+
### 用户覆盖
|
|
111
|
+
|
|
112
|
+
用户可在任何时刻用自然语言覆盖分类:"简单处理" → 降档,"认真做" → 升档。
|
|
113
|
+
|
|
114
|
+
---
|
|
115
|
+
|
|
116
|
+
## 1. 自适应上下文感知
|
|
117
|
+
|
|
118
|
+
根据输入分类结果,用 project-context 的**对应模式**获取项目信息。
|
|
119
|
+
|
|
120
|
+
### 4 种 Context 模式
|
|
121
|
+
|
|
122
|
+
| 模式 | 触发分类 | 做什么 | 产出 |
|
|
123
|
+
|------|---------|--------|------|
|
|
124
|
+
| **point-trace** | Pinpoint | 定位用户提及的目标点(文件/函数/错误) → 追溯 import/caller 依赖 → 检查同模块边界 | 目标点 + 直接关联文件列表 + 局部架构 |
|
|
125
|
+
| **focused-scan** | Bounded | 扫描目标模块 + 相邻模块 + 接口边界 | 目标模块详情 + 邻居模块概要 + API 边界 |
|
|
126
|
+
| **broad-scan** | Complex | 扫描全项目架构 + 模块关系 + 技术栈 | 完整项目结构 + 模块关系图 + 技术栈概要 |
|
|
127
|
+
| **full-scan** | Grand | 完整项目扫描(如果有代码仓库) + 领域分析 | 完整项目上下文 + 架构全貌 + 领域分析 |
|
|
128
|
+
|
|
129
|
+
```mermaid
|
|
130
|
+
graph TB
|
|
131
|
+
CLASS["输入分类结果"] --> MODE{"分类档位"}
|
|
132
|
+
MODE -->|"Pinpoint"| PT["point-trace<br>定位目标 → 追溯依赖链"]
|
|
133
|
+
MODE -->|"Bounded"| FS["focused-scan<br>目标模块 + 相邻模块"]
|
|
134
|
+
MODE -->|"Complex"| BS["broad-scan<br>全项目架构 + 模块关系"]
|
|
135
|
+
MODE -->|"Grand"| FULL["full-scan<br>完整扫描 + 领域分析"]
|
|
136
|
+
|
|
137
|
+
PT --> TYPE["判定项目类型"]
|
|
138
|
+
FS --> TYPE
|
|
139
|
+
BS --> TYPE
|
|
140
|
+
FULL --> TYPE
|
|
141
|
+
|
|
142
|
+
style CLASS fill:#ede7f6,stroke:#4527a0,color:#311b92,stroke-width:2px
|
|
143
|
+
style PT fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20
|
|
144
|
+
style FS fill:#fff9c4,stroke:#f9a825,color:#e65100
|
|
145
|
+
style BS fill:#ffe0b2,stroke:#e65100,color:#bf360c
|
|
146
|
+
style FULL fill:#ffcdd2,stroke:#c62828,color:#b71c1c
|
|
147
|
+
style TYPE fill:#e3f2fd,stroke:#1565c0,color:#0d47a1
|
|
148
|
+
```
|
|
149
|
+
|
|
150
|
+
### 项目类型判定
|
|
151
|
+
|
|
152
|
+
上下文感知完成后,判定项目类型(与分类无关,所有模式都做):
|
|
61
153
|
|
|
62
154
|
```mermaid
|
|
63
155
|
graph LR
|
|
64
|
-
CTX_START["
|
|
156
|
+
CTX_START["上下文感知完成"] --> HAS_CODE{"有代码仓库?"}
|
|
65
157
|
HAS_CODE -->|"无/空/仅脚手架"| NEW["A: 新项目"]
|
|
66
158
|
HAS_CODE -->|"有完整代码"| INTENT{"用户意图?"}
|
|
67
159
|
INTENT -->|"错误或异常"| BUG["C: Bug 修复"]
|
|
@@ -98,6 +190,7 @@ graph LR
|
|
|
98
190
|
|
|
99
191
|
| 条件 | 判定依据 |
|
|
100
192
|
|------|---------|
|
|
193
|
+
| 输入分类为 Grand | 输入分类阶段已判定为宏大型 — **强制触发** |
|
|
101
194
|
| 需求模糊/宽泛 | 用户输入未明确列出功能模块或具体范围 |
|
|
102
195
|
| 难度 L4+ | task-difficulty 评分 ≥ 7,架构方向会影响切片方式 |
|
|
103
196
|
|
|
@@ -105,6 +198,7 @@ graph LR
|
|
|
105
198
|
|
|
106
199
|
| 条件 | 示例 |
|
|
107
200
|
|------|------|
|
|
201
|
+
| 输入分类为 Pinpoint 或 Bounded | 已在分类阶段确认目标具体、范围有界 |
|
|
108
202
|
| 需求已经具体 | "在 user 模块加修改密码 API"、"GET /api/novels/123 返回 500" |
|
|
109
203
|
| 难度 L1-L3 | 简单任务,天然范围窄 |
|
|
110
204
|
|
|
@@ -208,6 +302,15 @@ graph TB
|
|
|
208
302
|
- **后续 slice**:Plan 阶段跳过全局性 skill,只执行 slice 级 skill(requirement-qa 针对本 slice 功能、spec-writing 只写本 slice 文档、api-contract-design 只做增量端点)
|
|
209
303
|
- **slice 间传递**:前一个 slice 的 Deliver 产出(docs/ + .cache/context.db)是后续 slice 的 Plan 输入
|
|
210
304
|
|
|
305
|
+
### 上下文窗口管理
|
|
306
|
+
|
|
307
|
+
Plan 阶段的顺序 skill 链会在上下文窗口中累积大量中间产出。为防止窗口溢出导致注意力衰减,遵循以下规则:
|
|
308
|
+
|
|
309
|
+
- **落盘即释放**:每个 skill 产出写入 docs/ 后,后续 skill 不应依赖窗口中"记住"的全文。需要引用前置产出时,**从文件读取**而非依赖窗口记忆
|
|
310
|
+
- **只保留摘要**:在窗口中仅保留每个 skill 的产出摘要(核心结论、关键决策、模块清单),完整文档查阅 docs/
|
|
311
|
+
- **Slice 边界是重置点**:进入新 Slice 时,从 docs/ + .cache/context.db 加载所需上下文,而非试图"记住"前一个 Slice 的全部内容
|
|
312
|
+
- **按需加载 SKILL.md**:每个 skill 的 SKILL.md 在调用该 skill 时读取,使用完毕后其详细指令不需要在窗口中持续保留
|
|
313
|
+
|
|
211
314
|
### Plan
|
|
212
315
|
|
|
213
316
|
读取命中的 route-{x}.md,按其中的 skill 编排执行 Plan。
|
|
@@ -68,3 +68,23 @@ graph TB
|
|
|
68
68
|
- 仅用于无需 AI 介入的 CLI 工具(安装、编译、测试执行、lint)
|
|
69
69
|
- 启动后主线程继续编写下一模块,稍后检查后台输出
|
|
70
70
|
- 后台进程失败不阻塞主线程,但结果需在 Validate 卡点前确认
|
|
71
|
+
|
|
72
|
+
## SubAgent 降级策略
|
|
73
|
+
|
|
74
|
+
当 Agent 宿主环境不支持 SubAgent(或 SubAgent 能力有限)时,所有 SubAgent 场景**退回主 Agent 串行执行**。架构设计保证不依赖 SubAgent 的并行性——SubAgent 是性能优化,不是功能前提。
|
|
75
|
+
|
|
76
|
+
### 降级映射
|
|
77
|
+
|
|
78
|
+
| SubAgent 场景 | 正常模式 | 降级模式 |
|
|
79
|
+
|--------------|---------|---------|
|
|
80
|
+
| brainstorm 多角色 | 6 个 SubAgent 并行扮演不同角色 | 主 Agent 依次扮演每个角色,串行输出各视角分析 |
|
|
81
|
+
| A+ Plan 三件套 | 3 个 SubAgent 并行(performance + complexity + observability) | 主 Agent 串行依次执行三个 skill |
|
|
82
|
+
| + 变体 Execute | 每个 task 由 fresh SubAgent 隔离执行 | 主 Agent 按 task 串行执行,在 task 间自行做上下文分隔(明确标注:"--- Task N 开始 ---") |
|
|
83
|
+
| Deliver 双写 | 2 个 SubAgent 并行(docs-output + project-context) | 主 Agent 先执行 docs-output,再执行 project-context |
|
|
84
|
+
|
|
85
|
+
### 降级检测
|
|
86
|
+
|
|
87
|
+
模型在首次需要 SubAgent 时检测宿主环境:
|
|
88
|
+
- 如果宿主提供 SubAgent/fork/spawn 能力 → 使用 SubAgent 模式
|
|
89
|
+
- 如果不提供 → 切换到降级模式,后续同一会话不再重复检测
|
|
90
|
+
- 降级不影响质量卡点——Plan Gate / Validate Gate 的检查规则完全一致
|
|
@@ -41,6 +41,52 @@ graph TD
|
|
|
41
41
|
|
|
42
42
|
## 核心能力(被动 API)
|
|
43
43
|
|
|
44
|
+
### 0. 上下文模式选择
|
|
45
|
+
|
|
46
|
+
被 orchestrator 调用时,根据输入分类结果选择对应的上下文获取模式:
|
|
47
|
+
|
|
48
|
+
| 模式 | 说明 | 扫描范围 | 产出 |
|
|
49
|
+
|------|------|---------|------|
|
|
50
|
+
| **point-trace** | 先定位再扩散 | 用户提及的目标点 → 追溯 import/caller → 同模块文件 | 目标点 + 直接关联文件 + 局部依赖链 |
|
|
51
|
+
| **focused-scan** | 聚焦模块 | 目标模块全量 + 相邻模块概要 + API 边界 | 模块详情 + 邻居概要 + 接口边界 |
|
|
52
|
+
| **broad-scan** | 广域扫描 | 全项目文件树 + 模块间依赖 + 技术栈 | 完整结构 + 模块关系 + 技术栈 |
|
|
53
|
+
| **full-scan** | 全量深度扫描 | 全项目 + 代码摘要 + 领域分析 | 完整上下文 + 架构全貌 |
|
|
54
|
+
|
|
55
|
+
```mermaid
|
|
56
|
+
graph TB
|
|
57
|
+
MODE{"上下文模式"} --> PT["point-trace<br>定位目标点"]
|
|
58
|
+
MODE --> FS["focused-scan<br>目标模块 + 邻居"]
|
|
59
|
+
MODE --> BS["broad-scan<br>全项目结构"]
|
|
60
|
+
MODE --> FULL["full-scan<br>全量深度"]
|
|
61
|
+
|
|
62
|
+
PT --> PT1["1. 根据用户输入定位目标文件/函数"]
|
|
63
|
+
PT1 --> PT2["2. 追溯 import/export 依赖链"]
|
|
64
|
+
PT2 --> PT3["3. 检查同模块内关联文件"]
|
|
65
|
+
PT3 --> PT4["4. 产出局部上下文"]
|
|
66
|
+
|
|
67
|
+
FS --> FS1["1. 识别目标模块目录"]
|
|
68
|
+
FS1 --> FS2["2. 扫描模块内全部文件"]
|
|
69
|
+
FS2 --> FS3["3. 识别相邻模块 + 接口边界"]
|
|
70
|
+
FS3 --> FS4["4. 产出模块级上下文"]
|
|
71
|
+
|
|
72
|
+
BS --> BS1["1. 扫描全项目文件树"]
|
|
73
|
+
BS1 --> BS2["2. 识别模块间依赖关系"]
|
|
74
|
+
BS2 --> BS3["3. 检测技术栈和构建配置"]
|
|
75
|
+
BS3 --> BS4["4. 产出项目级上下文"]
|
|
76
|
+
|
|
77
|
+
FULL --> FULL1["1. 全项目文件树 + 代码摘要"]
|
|
78
|
+
FULL1 --> FULL2["2. 模块关系 + 领域模型"]
|
|
79
|
+
FULL2 --> FULL3["3. 技术栈 + 架构模式识别"]
|
|
80
|
+
FULL3 --> FULL4["4. 产出完整上下文"]
|
|
81
|
+
|
|
82
|
+
style PT fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20
|
|
83
|
+
style FS fill:#fff9c4,stroke:#f9a825,color:#e65100
|
|
84
|
+
style BS fill:#ffe0b2,stroke:#e65100,color:#bf360c
|
|
85
|
+
style FULL fill:#ffcdd2,stroke:#c62828,color:#b71c1c
|
|
86
|
+
```
|
|
87
|
+
|
|
88
|
+
未被 orchestrator 调用时(独立使用),默认执行 broad-scan 模式。
|
|
89
|
+
|
|
44
90
|
### 1. init — 初始化
|
|
45
91
|
|
|
46
92
|
首次在项目中使用时调用。扫描项目文件结构,生成初始快照。
|
|
@@ -16,6 +16,7 @@ description: >-
|
|
|
16
16
|
```mermaid
|
|
17
17
|
graph LR
|
|
18
18
|
INPUT["用户输入<br/>任务描述"]
|
|
19
|
+
CLASS["输入分类提示<br/>Pinpoint/Bounded/<br>Complex/Grand"]
|
|
19
20
|
CTX["上下文追溯<br/>涉及的文件·模块·依赖"]
|
|
20
21
|
SCORE["多维度评分<br/>5个维度 × 1-5分"]
|
|
21
22
|
LEVEL["难度分级<br/>L1-L5"]
|
|
@@ -24,15 +25,29 @@ graph LR
|
|
|
24
25
|
OUT_BUMP["上浮一级"]
|
|
25
26
|
RESULT["输出<br/>难度报告"]
|
|
26
27
|
|
|
27
|
-
INPUT --> CTX --> SCORE --> LEVEL --> THROTTLE
|
|
28
|
+
INPUT --> CLASS --> CTX --> SCORE --> LEVEL --> THROTTLE
|
|
28
29
|
THROTTLE -->|"是,L1证据充分"| OUT_KEEP --> RESULT
|
|
29
30
|
THROTTLE -->|"否,存在不确定性"| OUT_BUMP --> RESULT
|
|
30
31
|
|
|
31
32
|
style INPUT fill:#e3f2fd,stroke:#1976d2
|
|
33
|
+
style CLASS fill:#ede7f6,stroke:#4527a0,color:#311b92
|
|
32
34
|
style THROTTLE fill:#fff3e0,stroke:#f57c00,stroke-width:2px
|
|
33
35
|
style RESULT fill:#e8f5e9,stroke:#388e3c
|
|
34
36
|
```
|
|
35
37
|
|
|
38
|
+
### 输入分类提示
|
|
39
|
+
|
|
40
|
+
被 orchestrator 调用时,接收输入分类结果作为评分校准参考(不替代评分):
|
|
41
|
+
|
|
42
|
+
| 输入分类 | 分数预期范围 | 说明 |
|
|
43
|
+
|---------|------------|------|
|
|
44
|
+
| Pinpoint | L1-L2 (1-4) | 分类提示为低难度区间,但评分仍可能突破(如目标点涉及复杂依赖链) |
|
|
45
|
+
| Bounded | L2-L3 (2-6) | 分类提示为中低区间 |
|
|
46
|
+
| Complex | L3-L4 (4-8) | 分类提示为中高区间 |
|
|
47
|
+
| Grand | L4-L5 (7-10) | 分类提示为高难度区间 |
|
|
48
|
+
|
|
49
|
+
如果实际评分与分类提示的预期范围偏差 > 2 级,须在难度报告中标注偏差原因。
|
|
50
|
+
|
|
36
51
|
## 难度等级
|
|
37
52
|
|
|
38
53
|
| 等级 | 名称 | 典型特征 | 示例 |
|
|
@@ -33,6 +33,21 @@ graph TB
|
|
|
33
33
|
|
|
34
34
|
---
|
|
35
35
|
|
|
36
|
+
## 0. TDD Applicability by Project Maturity
|
|
37
|
+
|
|
38
|
+
Before designing test strategy, determine TDD scope based on project maturity:
|
|
39
|
+
|
|
40
|
+
| Project State | TDD Strategy | Rationale |
|
|
41
|
+
|--|--|--|
|
|
42
|
+
| New project (greenfield) | **Full TDD** — all new code gets tests first | Lowest cost, highest ROI; test infrastructure set up once |
|
|
43
|
+
| Mature project — existing code | **Don't backfill tests** | ROI too low, unless the module is about to be refactored |
|
|
44
|
+
| Mature project — new/modified code | **TDD for new code** | Only low-cost opportunity to introduce a safety net; coverage improves incrementally |
|
|
45
|
+
| Bug fixes | **Regression test required** | Regression test is the core deliverable of a bug fix |
|
|
46
|
+
|
|
47
|
+
> **Principle**: Don't launch a pointless test-backfilling campaign on legacy code. Instead, bring tests with every change — coverage will naturally improve over months.
|
|
48
|
+
|
|
49
|
+
---
|
|
50
|
+
|
|
36
51
|
## 1. Identify Integration Points
|
|
37
52
|
|
|
38
53
|
Extract all cross-layer/cross-module calls from sequence design, marking test levels:
|
|
@@ -1,14 +1,23 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: orchestrator
|
|
3
3
|
description: >-
|
|
4
|
-
Full-lifecycle flow orchestrator for project development. Upon receiving user input, it
|
|
4
|
+
Full-lifecycle flow orchestrator for project development. Upon receiving user input, it first classifies the input (4 tiers), then adaptively senses project context, scores task difficulty, selects the optimal route, and orchestrates the Plan→Execute→Validate→Deliver four-phase pipeline with quality gates and failure reflow.
|
|
5
5
|
Use this skill when: the user wants to start a new project, receives a new requirement, needs a full development iteration, wants to go through the complete flow from requirements to delivery, or says things like "start building", "launch the project", "how to implement this requirement", "help me plan this", "do it end-to-end".
|
|
6
6
|
When the user's intent is to complete an end-to-end development task (rather than just one step), use this skill to orchestrate the entire flow. If the user only needs a specific step (e.g., just write requirement docs), use the corresponding specialized skill directly.
|
|
7
7
|
---
|
|
8
8
|
|
|
9
9
|
# Orchestrator — Flow Orchestrator
|
|
10
10
|
|
|
11
|
-
Receive user input →
|
|
11
|
+
Receive user input → **Input Classification** → Adaptive context sensing → Score difficulty → **Macro clarification** (if needed) → **Scope slicing** → Select route → Orchestrate four phases per slice → Quality gates → Deliver.
|
|
12
|
+
|
|
13
|
+
---
|
|
14
|
+
|
|
15
|
+
## Global Constraints
|
|
16
|
+
|
|
17
|
+
The following two rules apply across all phases and skills, no exceptions:
|
|
18
|
+
|
|
19
|
+
1. **Evidence Anchoring**: Every design decision must cite at least one **project context fact** as justification. Using only "industry best practice" or "generally recommended" as the sole rationale is prohibited. If no supporting evidence exists in the project context, it must be explicitly marked as "**Assumption**".
|
|
20
|
+
2. **Reverse Challenge**: After recommending an architecture, technology choice, or design pattern, you must answer: **If this recommendation is wrong, what is the most likely reason?** If you cannot answer, your understanding is insufficient — gather more context before proceeding.
|
|
12
21
|
|
|
13
22
|
---
|
|
14
23
|
|
|
@@ -16,9 +25,10 @@ Receive user input → Sense context → Score difficulty → **Macro-level clar
|
|
|
16
25
|
|
|
17
26
|
```mermaid
|
|
18
27
|
graph TB
|
|
19
|
-
INPUT["User Input"] -->
|
|
28
|
+
INPUT["User Input"] --> CLASS["Input Classification<br>4-Dimension Analysis"]
|
|
29
|
+
CLASS --> CTX["Adaptive Context Sensing<br>project-context"]
|
|
20
30
|
CTX --> SCORE["Difficulty Scoring<br>task-difficulty"]
|
|
21
|
-
SCORE --> NEED_CL{"
|
|
31
|
+
SCORE --> NEED_CL{"Classification=Grand<br>OR ambiguous<br>OR L4+?"}
|
|
22
32
|
NEED_CL -->|"Yes"| CLARIFY["Macro Clarification<br>requirement-qa(scope mode)<br>+ brainstorm(L4+)"]
|
|
23
33
|
NEED_CL -->|"No"| SLICE
|
|
24
34
|
CLARIFY --> SLICE["Scope Slicing<br>scope-sizer"]
|
|
@@ -39,6 +49,7 @@ graph TB
|
|
|
39
49
|
NEXT -->|"No"| DONE["All Complete"]
|
|
40
50
|
|
|
41
51
|
style INPUT fill:#e8eaf6,stroke:#283593,color:#1a237e,stroke-width:2px
|
|
52
|
+
style CLASS fill:#ede7f6,stroke:#4527a0,color:#311b92,stroke-width:2px
|
|
42
53
|
style CTX fill:#e3f2fd,stroke:#1565c0,color:#0d47a1
|
|
43
54
|
style SCORE fill:#e3f2fd,stroke:#1565c0,color:#0d47a1
|
|
44
55
|
style NEED_CL fill:#fff3e0,stroke:#e65100,color:#bf360c
|
|
@@ -55,13 +66,94 @@ graph TB
|
|
|
55
66
|
|
|
56
67
|
---
|
|
57
68
|
|
|
58
|
-
##
|
|
69
|
+
## 0. Input Classification
|
|
70
|
+
|
|
71
|
+
Before touching any skill, perform a 4-dimension analysis based solely on the **user's input text**, producing a classification result that drives all subsequent steps to choose the appropriate depth.
|
|
72
|
+
|
|
73
|
+
### 4-Dimension Assessment
|
|
74
|
+
|
|
75
|
+
| Dimension | Description | Low → High |
|
|
76
|
+
|-----------|-------------|------------|
|
|
77
|
+
| **Concreteness** | How precisely does the user point to a target | Specific file/function → A module → A system → Macro vision |
|
|
78
|
+
| **Scope Breadth** | How many modules are implicitly involved | Single point → Single module → Multi-module → Full system |
|
|
79
|
+
| **Decision Load** | Are architectural/strategic decisions required | None → Minor → Significant → Critical |
|
|
80
|
+
| **Ambiguity** | How much is still undefined | Fully clear → Some gaps → Major gaps → Mostly undefined |
|
|
81
|
+
|
|
82
|
+
### 4-Tier Classification
|
|
83
|
+
|
|
84
|
+
```mermaid
|
|
85
|
+
graph TB
|
|
86
|
+
INPUT["User Input Text"] --> DIM["4-Dimension Assessment<br>Concreteness / Scope / Decision / Ambiguity"]
|
|
87
|
+
DIM --> C1{"High concrete + Narrow<br>+ No decision + Clear?"}
|
|
88
|
+
C1 -->|"Yes"| PIN["Pinpoint"]
|
|
89
|
+
C1 -->|"No"| C2{"Medium concrete + Bounded<br>+ Minor decision + Partially clear?"}
|
|
90
|
+
C2 -->|"Yes"| BND["Bounded"]
|
|
91
|
+
C2 -->|"No"| C3{"Abstract + Wide<br>+ Decisions needed + Gaps?"}
|
|
92
|
+
C3 -->|"Yes"| CPX["Complex"]
|
|
93
|
+
C3 -->|"No"| GRD["Grand"]
|
|
94
|
+
|
|
95
|
+
style INPUT fill:#e8eaf6,stroke:#283593,color:#1a237e,stroke-width:2px
|
|
96
|
+
style DIM fill:#ede7f6,stroke:#4527a0,color:#311b92
|
|
97
|
+
style PIN fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20
|
|
98
|
+
style BND fill:#fff9c4,stroke:#f9a825,color:#e65100
|
|
99
|
+
style CPX fill:#ffe0b2,stroke:#e65100,color:#bf360c
|
|
100
|
+
style GRD fill:#ffcdd2,stroke:#c62828,color:#b71c1c
|
|
101
|
+
```
|
|
102
|
+
|
|
103
|
+
| Classification | Typical Input | Context Strategy | Difficulty Hint | CLARIFY |
|
|
104
|
+
|---------------|---------------|-----------------|----------------|---------|
|
|
105
|
+
| **Pinpoint** | "GET /api/users/123 returns 500"<br>"Change login button color to blue" | **point-trace** | L1-L2 | Skip |
|
|
106
|
+
| **Bounded** | "Add change-password feature to user module"<br>"Optimize order list query performance" | **focused-scan** | L2-L3 | As needed |
|
|
107
|
+
| **Complex** | "Add payment module integrating WeChat Pay and Alipay"<br>"Split monolith into frontend-backend separation" | **broad-scan** | L3-L4 | As needed |
|
|
108
|
+
| **Grand** | "Build an e-commerce platform like Amazon"<br>"Design a distributed transaction framework" | **full-scan** | L4-L5 | **Mandatory** |
|
|
109
|
+
|
|
110
|
+
### User Override
|
|
111
|
+
|
|
112
|
+
Users can override the classification at any time with natural language: "keep it simple" → downgrade, "do it thoroughly" → upgrade.
|
|
113
|
+
|
|
114
|
+
---
|
|
115
|
+
|
|
116
|
+
## 1. Adaptive Context Sensing
|
|
117
|
+
|
|
118
|
+
Based on the input classification result, use project-context's **corresponding mode** to gather project information.
|
|
119
|
+
|
|
120
|
+
### 4 Context Modes
|
|
121
|
+
|
|
122
|
+
| Mode | Triggered By | What It Does | Output |
|
|
123
|
+
|------|-------------|-------------|--------|
|
|
124
|
+
| **point-trace** | Pinpoint | Locate the target point (file/function/error) mentioned by user → trace import/caller dependencies → check same-module boundaries | Target point + directly related files + local dependency chain |
|
|
125
|
+
| **focused-scan** | Bounded | Scan target module + neighboring modules + interface boundaries | Target module details + neighbor summaries + API boundaries |
|
|
126
|
+
| **broad-scan** | Complex | Scan full project architecture + module relationships + tech stack | Complete project structure + module relationship map + tech stack summary |
|
|
127
|
+
| **full-scan** | Grand | Full project scan (if code repo exists) + domain analysis | Complete project context + architectural overview + domain analysis |
|
|
59
128
|
|
|
60
|
-
|
|
129
|
+
```mermaid
|
|
130
|
+
graph TB
|
|
131
|
+
CLASS["Classification Result"] --> MODE{"Classification Tier"}
|
|
132
|
+
MODE -->|"Pinpoint"| PT["point-trace<br>Locate target, trace dependencies"]
|
|
133
|
+
MODE -->|"Bounded"| FS["focused-scan<br>Target module + neighbors"]
|
|
134
|
+
MODE -->|"Complex"| BS["broad-scan<br>Full project architecture"]
|
|
135
|
+
MODE -->|"Grand"| FULL["full-scan<br>Complete deep scan"]
|
|
136
|
+
|
|
137
|
+
PT --> TYPE["Determine Project Type"]
|
|
138
|
+
FS --> TYPE
|
|
139
|
+
BS --> TYPE
|
|
140
|
+
FULL --> TYPE
|
|
141
|
+
|
|
142
|
+
style CLASS fill:#ede7f6,stroke:#4527a0,color:#311b92,stroke-width:2px
|
|
143
|
+
style PT fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20
|
|
144
|
+
style FS fill:#fff9c4,stroke:#f9a825,color:#e65100
|
|
145
|
+
style BS fill:#ffe0b2,stroke:#e65100,color:#bf360c
|
|
146
|
+
style FULL fill:#ffcdd2,stroke:#c62828,color:#b71c1c
|
|
147
|
+
style TYPE fill:#e3f2fd,stroke:#1565c0,color:#0d47a1
|
|
148
|
+
```
|
|
149
|
+
|
|
150
|
+
### Project Type Determination
|
|
151
|
+
|
|
152
|
+
After context sensing completes, determine project type (regardless of classification — all modes do this):
|
|
61
153
|
|
|
62
154
|
```mermaid
|
|
63
155
|
graph LR
|
|
64
|
-
CTX_START["
|
|
156
|
+
CTX_START["Context Sensing Complete"] --> HAS_CODE{"Has code repo?"}
|
|
65
157
|
HAS_CODE -->|"None/Empty/Scaffold only"| NEW["A: New Project"]
|
|
66
158
|
HAS_CODE -->|"Has substantial code"| INTENT{"User intent?"}
|
|
67
159
|
INTENT -->|"Error or anomaly"| BUG["C: Bug Fix"]
|
|
@@ -98,6 +190,7 @@ After difficulty scoring and before scope slicing, determine whether the require
|
|
|
98
190
|
|
|
99
191
|
| Condition | Criteria |
|
|
100
192
|
|-----------|---------|
|
|
193
|
+
| Input classified as Grand | Already determined as Grand type in classification phase — **mandatory trigger** |
|
|
101
194
|
| Vague/broad requirements | User input doesn't explicitly list feature modules or specific scope |
|
|
102
195
|
| Difficulty L4+ | task-difficulty score ≥ 7, architectural direction affects slicing approach |
|
|
103
196
|
|
|
@@ -105,6 +198,7 @@ After difficulty scoring and before scope slicing, determine whether the require
|
|
|
105
198
|
|
|
106
199
|
| Condition | Example |
|
|
107
200
|
|-----------|---------|
|
|
201
|
+
| Input classified as Pinpoint or Bounded | Already confirmed specific target and bounded scope in classification phase |
|
|
108
202
|
| Requirements already specific | "Add a change-password API to the user module", "GET /api/novels/123 returns 500" |
|
|
109
203
|
| Difficulty L1-L3 | Simple tasks, naturally narrow scope |
|
|
110
204
|
|
|
@@ -208,6 +302,15 @@ When multiple slices exist, execute them sequentially by dependency order. Each
|
|
|
208
302
|
- **Subsequent slices**: Plan phase skips global skills, only executes slice-level skills (requirement-qa targeting this slice's features, spec-writing only for this slice's docs, api-contract-design only for incremental endpoints)
|
|
209
303
|
- **Inter-slice handoff**: Previous slice's Deliver output (docs/ + .cache/context.db) becomes the next slice's Plan input
|
|
210
304
|
|
|
305
|
+
### Context Window Management
|
|
306
|
+
|
|
307
|
+
The Plan phase's sequential skill chain accumulates substantial intermediate output in the context window. To prevent window overflow and attention degradation, follow these rules:
|
|
308
|
+
|
|
309
|
+
- **Persist then release**: After each skill's output is written to docs/, subsequent skills should NOT rely on the full text being "remembered" in the window. When referencing prior output, **read from files** instead of relying on window memory
|
|
310
|
+
- **Keep only summaries**: Retain only each skill's output summary in the window (core conclusions, key decisions, module list); consult docs/ for full documents
|
|
311
|
+
- **Slice boundaries are reset points**: When entering a new Slice, load required context from docs/ + .cache/context.db rather than trying to "remember" everything from the previous Slice
|
|
312
|
+
- **Load SKILL.md on demand**: Each skill's SKILL.md is read when that skill is invoked; its detailed instructions do not need to persist in the window after use
|
|
313
|
+
|
|
211
314
|
### Plan
|
|
212
315
|
|
|
213
316
|
Read the matched route-{x}.md and execute Plan following its skill orchestration.
|
|
@@ -68,3 +68,23 @@ Used only in + variant Execute phase. Detailed rules -> read `references/execute
|
|
|
68
68
|
- Only for CLI tools requiring no AI involvement (install, compile, test execution, lint)
|
|
69
69
|
- After launching, main thread continues writing next module, checks background output later
|
|
70
70
|
- Background process failure doesn't block main thread, but results must be confirmed before Validate gate
|
|
71
|
+
|
|
72
|
+
## SubAgent Degradation Strategy
|
|
73
|
+
|
|
74
|
+
When the agent host environment does not support SubAgents (or has limited SubAgent capability), all SubAgent scenarios **fall back to main Agent sequential execution**. The architecture is designed to never depend on SubAgent parallelism — SubAgents are a performance optimization, not a functional prerequisite.
|
|
75
|
+
|
|
76
|
+
### Degradation Mapping
|
|
77
|
+
|
|
78
|
+
| SubAgent Scenario | Normal Mode | Degraded Mode |
|
|
79
|
+
|-------------------|-------------|---------------|
|
|
80
|
+
| brainstorm multi-role | 6 SubAgents in parallel playing different roles | Main Agent plays each role sequentially, outputting each perspective's analysis in turn |
|
|
81
|
+
| A+ Plan triple-skill | 3 SubAgents in parallel (performance + complexity + observability) | Main Agent executes all three skills sequentially |
|
|
82
|
+
| + variant Execute | Each task by fresh SubAgent with context isolation | Main Agent executes tasks sequentially, self-separating context between tasks (explicitly marking: "--- Task N Start ---") |
|
|
83
|
+
| Deliver dual-write | 2 SubAgents in parallel (docs-output + project-context) | Main Agent executes docs-output first, then project-context |
|
|
84
|
+
|
|
85
|
+
### Degradation Detection
|
|
86
|
+
|
|
87
|
+
The model detects the host environment when SubAgents are first needed:
|
|
88
|
+
- If the host provides SubAgent/fork/spawn capability → use SubAgent mode
|
|
89
|
+
- If not → switch to degraded mode; do not re-detect within the same session
|
|
90
|
+
- Degradation does not affect quality gates — Plan Gate / Validate Gate checks remain identical
|
|
@@ -41,6 +41,52 @@ graph TD
|
|
|
41
41
|
|
|
42
42
|
## Core Capabilities (Passive API)
|
|
43
43
|
|
|
44
|
+
### 0. Context Mode Selection
|
|
45
|
+
|
|
46
|
+
When called by the orchestrator, selects the corresponding context acquisition mode based on the input classification result:
|
|
47
|
+
|
|
48
|
+
| Mode | Description | Scan Scope | Output |
|
|
49
|
+
|------|-------------|-----------|--------|
|
|
50
|
+
| **point-trace** | Locate first, then expand | Target point mentioned by user → trace import/caller → same-module files | Target point + directly related files + local dependency chain |
|
|
51
|
+
| **focused-scan** | Focus on module | Target module full scan + neighboring module summaries + API boundaries | Module details + neighbor summaries + interface boundaries |
|
|
52
|
+
| **broad-scan** | Wide-area scan | Full project file tree + inter-module dependencies + tech stack | Complete structure + module relationships + tech stack |
|
|
53
|
+
| **full-scan** | Full deep scan | Full project + code summaries + domain analysis | Complete context + architectural overview |
|
|
54
|
+
|
|
55
|
+
```mermaid
|
|
56
|
+
graph TB
|
|
57
|
+
MODE{"Context Mode"} --> PT["point-trace<br>Locate target point"]
|
|
58
|
+
MODE --> FS["focused-scan<br>Target module + neighbors"]
|
|
59
|
+
MODE --> BS["broad-scan<br>Full project structure"]
|
|
60
|
+
MODE --> FULL["full-scan<br>Full depth"]
|
|
61
|
+
|
|
62
|
+
PT --> PT1["1. Locate target file/function from user input"]
|
|
63
|
+
PT1 --> PT2["2. Trace import/export dependency chain"]
|
|
64
|
+
PT2 --> PT3["3. Check related files within same module"]
|
|
65
|
+
PT3 --> PT4["4. Output local context"]
|
|
66
|
+
|
|
67
|
+
FS --> FS1["1. Identify target module directory"]
|
|
68
|
+
FS1 --> FS2["2. Scan all files within module"]
|
|
69
|
+
FS2 --> FS3["3. Identify neighboring modules + interface boundaries"]
|
|
70
|
+
FS3 --> FS4["4. Output module-level context"]
|
|
71
|
+
|
|
72
|
+
BS --> BS1["1. Scan full project file tree"]
|
|
73
|
+
BS1 --> BS2["2. Identify inter-module dependency relationships"]
|
|
74
|
+
BS2 --> BS3["3. Detect tech stack and build configuration"]
|
|
75
|
+
BS3 --> BS4["4. Output project-level context"]
|
|
76
|
+
|
|
77
|
+
FULL --> FULL1["1. Full project file tree + code summaries"]
|
|
78
|
+
FULL1 --> FULL2["2. Module relationships + domain model"]
|
|
79
|
+
FULL2 --> FULL3["3. Tech stack + architectural pattern recognition"]
|
|
80
|
+
FULL3 --> FULL4["4. Output complete context"]
|
|
81
|
+
|
|
82
|
+
style PT fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20
|
|
83
|
+
style FS fill:#fff9c4,stroke:#f9a825,color:#e65100
|
|
84
|
+
style BS fill:#ffe0b2,stroke:#e65100,color:#bf360c
|
|
85
|
+
style FULL fill:#ffcdd2,stroke:#c62828,color:#b71c1c
|
|
86
|
+
```
|
|
87
|
+
|
|
88
|
+
When not called by the orchestrator (standalone usage), defaults to broad-scan mode.
|
|
89
|
+
|
|
44
90
|
### 1. init — Initialize
|
|
45
91
|
|
|
46
92
|
Called on first use in a project. Scans project file structure, generates initial snapshot.
|
|
@@ -16,6 +16,7 @@ This Skill serves as a **throttle valve**: assess difficulty before execution, p
|
|
|
16
16
|
```mermaid
|
|
17
17
|
graph LR
|
|
18
18
|
INPUT["User Input<br/>Task Description"]
|
|
19
|
+
CLASS["Input Classification Hint<br/>Pinpoint/Bounded/<br>Complex/Grand"]
|
|
19
20
|
CTX["Context Tracing<br/>Files / Modules / Dependencies involved"]
|
|
20
21
|
SCORE["Multi-dimensional Scoring<br/>5 dimensions x 1-5 points"]
|
|
21
22
|
LEVEL["Difficulty Level<br/>L1-L5"]
|
|
@@ -24,15 +25,29 @@ graph LR
|
|
|
24
25
|
OUT_BUMP["Bump Up One Level"]
|
|
25
26
|
RESULT["Output<br/>Difficulty Report"]
|
|
26
27
|
|
|
27
|
-
INPUT --> CTX --> SCORE --> LEVEL --> THROTTLE
|
|
28
|
+
INPUT --> CLASS --> CTX --> SCORE --> LEVEL --> THROTTLE
|
|
28
29
|
THROTTLE -->|"Yes, L1 evidence sufficient"| OUT_KEEP --> RESULT
|
|
29
30
|
THROTTLE -->|"No, uncertainty exists"| OUT_BUMP --> RESULT
|
|
30
31
|
|
|
31
32
|
style INPUT fill:#e3f2fd,stroke:#1976d2
|
|
33
|
+
style CLASS fill:#ede7f6,stroke:#4527a0,color:#311b92
|
|
32
34
|
style THROTTLE fill:#fff3e0,stroke:#f57c00,stroke-width:2px
|
|
33
35
|
style RESULT fill:#e8f5e9,stroke:#388e3c
|
|
34
36
|
```
|
|
35
37
|
|
|
38
|
+
### Input Classification Hint
|
|
39
|
+
|
|
40
|
+
When called by the orchestrator, receives the input classification result as a scoring calibration reference (does not replace scoring):
|
|
41
|
+
|
|
42
|
+
| Input Classification | Expected Score Range | Notes |
|
|
43
|
+
|---------------------|---------------------|-------|
|
|
44
|
+
| Pinpoint | L1-L2 (1-4) | Hint is low-difficulty range, but scoring may exceed (e.g., target involves complex dependency chain) |
|
|
45
|
+
| Bounded | L2-L3 (2-6) | Hint is low-to-mid range |
|
|
46
|
+
| Complex | L3-L4 (4-8) | Hint is mid-to-high range |
|
|
47
|
+
| Grand | L4-L5 (7-10) | Hint is high-difficulty range |
|
|
48
|
+
|
|
49
|
+
If actual score deviates from the classification hint's expected range by > 2 levels, the deviation reason must be noted in the difficulty report.
|
|
50
|
+
|
|
36
51
|
## Difficulty Levels
|
|
37
52
|
|
|
38
53
|
| Level | Name | Typical Characteristics | Example |
|
|
@@ -1,17 +0,0 @@
|
|
|
1
|
-
{
|
|
2
|
-
"name": "ironweave",
|
|
3
|
-
"description": "Agentic skills framework for software development: orchestration, requirements, architecture, TDD, and quality gates",
|
|
4
|
-
"version": "1.0.0",
|
|
5
|
-
"homepage": "https://github.com/YuluoY/ironware",
|
|
6
|
-
"repository": "https://github.com/YuluoY/ironware",
|
|
7
|
-
"license": "MIT",
|
|
8
|
-
"keywords": [
|
|
9
|
-
"skills",
|
|
10
|
-
"orchestrator",
|
|
11
|
-
"tdd",
|
|
12
|
-
"architecture",
|
|
13
|
-
"quality-gates",
|
|
14
|
-
"workflows"
|
|
15
|
-
],
|
|
16
|
-
"hooks": "./hooks/hooks.json"
|
|
17
|
-
}
|
package/.codex/INSTALL.md
DELETED
|
@@ -1,45 +0,0 @@
|
|
|
1
|
-
# Installing Ironweave for Codex
|
|
2
|
-
|
|
3
|
-
## Installation
|
|
4
|
-
|
|
5
|
-
1. **Clone the repository:**
|
|
6
|
-
```bash
|
|
7
|
-
git clone https://github.com/YuluoY/ironware.git ~/.codex/ironweave
|
|
8
|
-
```
|
|
9
|
-
|
|
10
|
-
2. **Create the skills symlink:**
|
|
11
|
-
```bash
|
|
12
|
-
mkdir -p ~/.agents/skills
|
|
13
|
-
ln -s ~/.codex/ironweave/skills ~/.agents/skills/ironweave
|
|
14
|
-
```
|
|
15
|
-
|
|
16
|
-
**Windows (PowerShell):**
|
|
17
|
-
```powershell
|
|
18
|
-
New-Item -ItemType Directory -Force -Path "$env:USERPROFILE\.agents\skills"
|
|
19
|
-
cmd /c mklink /J "$env:USERPROFILE\.agents\skills\ironweave" "$env:USERPROFILE\.codex\ironweave\skills"
|
|
20
|
-
```
|
|
21
|
-
|
|
22
|
-
3. **Restart Codex** to discover the skills.
|
|
23
|
-
|
|
24
|
-
## Verify
|
|
25
|
-
|
|
26
|
-
```bash
|
|
27
|
-
ls -la ~/.agents/skills/ironweave
|
|
28
|
-
```
|
|
29
|
-
|
|
30
|
-
You should see a symlink pointing to the Ironweave skills directory.
|
|
31
|
-
|
|
32
|
-
## Updating
|
|
33
|
-
|
|
34
|
-
```bash
|
|
35
|
-
cd ~/.codex/ironweave && git pull
|
|
36
|
-
```
|
|
37
|
-
|
|
38
|
-
Skills update instantly through the symlink.
|
|
39
|
-
|
|
40
|
-
## Uninstalling
|
|
41
|
-
|
|
42
|
-
```bash
|
|
43
|
-
rm ~/.agents/skills/ironweave
|
|
44
|
-
rm -rf ~/.codex/ironweave
|
|
45
|
-
```
|
|
@@ -1,19 +0,0 @@
|
|
|
1
|
-
{
|
|
2
|
-
"name": "ironweave",
|
|
3
|
-
"displayName": "Ironweave",
|
|
4
|
-
"description": "Agentic skills framework for software development: orchestration, requirements, architecture, TDD, and quality gates",
|
|
5
|
-
"version": "1.0.0",
|
|
6
|
-
"homepage": "https://github.com/YuluoY/ironware",
|
|
7
|
-
"repository": "https://github.com/YuluoY/ironware",
|
|
8
|
-
"license": "MIT",
|
|
9
|
-
"keywords": [
|
|
10
|
-
"skills",
|
|
11
|
-
"orchestrator",
|
|
12
|
-
"tdd",
|
|
13
|
-
"architecture",
|
|
14
|
-
"quality-gates",
|
|
15
|
-
"workflows"
|
|
16
|
-
],
|
|
17
|
-
"skills": "./skills/",
|
|
18
|
-
"hooks": "./hooks/hooks-cursor.json"
|
|
19
|
-
}
|
package/.opencode/INSTALL.md
DELETED
|
@@ -1,42 +0,0 @@
|
|
|
1
|
-
# Installing Ironweave for OpenCode
|
|
2
|
-
|
|
3
|
-
## Prerequisites
|
|
4
|
-
|
|
5
|
-
- [OpenCode.ai](https://opencode.ai) installed
|
|
6
|
-
|
|
7
|
-
## Installation
|
|
8
|
-
|
|
9
|
-
Add ironweave to the `plugin` array in your `opencode.json` (global or project-level):
|
|
10
|
-
|
|
11
|
-
```json
|
|
12
|
-
{
|
|
13
|
-
"plugin": ["ironweave@git+https://github.com/YuluoY/ironware.git"]
|
|
14
|
-
}
|
|
15
|
-
```
|
|
16
|
-
|
|
17
|
-
Restart OpenCode. The plugin auto-installs and registers all skills.
|
|
18
|
-
|
|
19
|
-
## Usage
|
|
20
|
-
|
|
21
|
-
Use OpenCode's native `skill` tool:
|
|
22
|
-
|
|
23
|
-
```
|
|
24
|
-
use skill tool to list skills
|
|
25
|
-
use skill tool to load ironweave/orchestrator
|
|
26
|
-
```
|
|
27
|
-
|
|
28
|
-
## Updating
|
|
29
|
-
|
|
30
|
-
Ironweave updates automatically when you restart OpenCode.
|
|
31
|
-
|
|
32
|
-
To pin a specific version:
|
|
33
|
-
|
|
34
|
-
```json
|
|
35
|
-
{
|
|
36
|
-
"plugin": ["ironweave@git+https://github.com/YuluoY/ironware.git#v1.0.0"]
|
|
37
|
-
}
|
|
38
|
-
```
|
|
39
|
-
|
|
40
|
-
## Uninstalling
|
|
41
|
-
|
|
42
|
-
Remove the plugin entry from your `opencode.json` and restart OpenCode.
|
package/gemini-extension.json
DELETED
|
File without changes
|
|
File without changes
|