@openorbit/skill 1.0.0
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/LICENSE +21 -0
- package/README.md +122 -0
- package/README.zh-CN.md +100 -0
- package/docs/architecture.md +139 -0
- package/docs/installation.md +77 -0
- package/docs/prerequisites.md +124 -0
- package/docs/workflow-reference.md +158 -0
- package/examples/sample-project/CLAUDE.md +93 -0
- package/examples/sample-project/README.md +123 -0
- package/package.json +26 -0
- package/skills/OpenOrbit/SKILL.md +263 -0
package/LICENSE
ADDED
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 ZK-Andy
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|
package/README.md
ADDED
|
@@ -0,0 +1,122 @@
|
|
|
1
|
+
# OpenOrbit -- Development Governance Compass
|
|
2
|
+
|
|
3
|
+
A meta-skill for OpenCode AI assistants that routes development tasks to the right workflow path automatically.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## What is OpenOrbit?
|
|
8
|
+
|
|
9
|
+
OpenOrbit is a governance compass, not a tool. It lives inside an OpenCode-powered AI agent and determines the optimal workflow for whatever task lands on its plate. When you ask for a new feature, a bug fix, or a quick change, OpenOrbit classifies the work and steers the agent through the right sequence of steps: propose, design, implement, review, verify, archive. It makes sure nothing gets skipped and nothing gets over-engineered.
|
|
10
|
+
|
|
11
|
+
The project bundles four engines that work together. openspec-cn defines what to do. oh-my-opencode orchestrates who does it. superpowers-zh enforces quality standards. dotnet-skills provides deep technical knowledge for implementation work.
|
|
12
|
+
|
|
13
|
+
---
|
|
14
|
+
|
|
15
|
+
## Features
|
|
16
|
+
|
|
17
|
+
- **Intelligent task routing.** Five workflow paths match the scope of the change. The system picks one automatically so the agent never wastes time on ceremony it does not need.
|
|
18
|
+
- **Four-engine architecture.** openspec-cn, oh-my-opencode, superpowers-zh, and dotnet-skills each own a layer. You can upgrade or replace any engine without touching the others.
|
|
19
|
+
- **Bilingual support.** The spec layer, commit messages, and code reviews all work in both English and Chinese. Teams can mix languages freely.
|
|
20
|
+
- **Quality gates at every stage.** Each workflow step has a verification gate: spec validation, architecture review, test-driven development, code review, and final verification before archive.
|
|
21
|
+
|
|
22
|
+
---
|
|
23
|
+
|
|
24
|
+
## Prerequisites
|
|
25
|
+
|
|
26
|
+
OpenOrbit requires an OpenCode-compatible AI environment and a Git-based project. Full setup details are in [docs/prerequisites.md](docs/prerequisites.md).
|
|
27
|
+
|
|
28
|
+
The four engines each have their own prerequisites:
|
|
29
|
+
|
|
30
|
+
- **openspec-cn** -- Workflow shell that defines the step sequence. See its documentation for the spec-driven workflow model.
|
|
31
|
+
- **oh-my-opencode** -- Execution orchestration layer. The Atlas/Sisyphus master agent dispatches tasks, supervises sub-agents, and runs reviews.
|
|
32
|
+
- **superpowers-zh** -- Quality gates for code review, commit conventions, documentation standards, and TDD workflows.
|
|
33
|
+
- **dotnet-skills** -- 159+ .NET domain skills covering ASP.NET Core, Blazor, EF Core, MAUI, WPF, testing, performance, and more.
|
|
34
|
+
|
|
35
|
+
---
|
|
36
|
+
|
|
37
|
+
## Quick Start
|
|
38
|
+
|
|
39
|
+
You have three ways to install OpenOrbit in your project. Pick the one that fits your setup.
|
|
40
|
+
|
|
41
|
+
### Direct copy
|
|
42
|
+
|
|
43
|
+
Clone the repository and copy the skill directory into your project.
|
|
44
|
+
|
|
45
|
+
```
|
|
46
|
+
git clone https://github.com/ZK-Andy/OpenOrbit.git
|
|
47
|
+
cp -r OpenOrbit/skills/OpenOrbit/ your-project/.opencode/skills/
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
### npm
|
|
51
|
+
|
|
52
|
+
Install the published package, then link or copy it to your skills directory.
|
|
53
|
+
|
|
54
|
+
```
|
|
55
|
+
npm install @openorbit/skill
|
|
56
|
+
cp -r node_modules/@openorbit/skill/dist your-project/.opencode/skills/OpenOrbit/
|
|
57
|
+
```
|
|
58
|
+
|
|
59
|
+
### Git submodule
|
|
60
|
+
|
|
61
|
+
Add the repository as a submodule and create a symlink or copy.
|
|
62
|
+
|
|
63
|
+
```
|
|
64
|
+
git submodule add https://github.com/ZK-Andy/OpenOrbit.git .openorbit
|
|
65
|
+
ln -s ../../.openorbit/skills/OpenOrbit .opencode/skills/OpenOrbit
|
|
66
|
+
```
|
|
67
|
+
|
|
68
|
+
On Windows, use a junction or copy instead of a symlink.
|
|
69
|
+
|
|
70
|
+
---
|
|
71
|
+
|
|
72
|
+
## How It Works
|
|
73
|
+
|
|
74
|
+
OpenOrbit classifies every incoming task by type and routes it through one of five workflow paths.
|
|
75
|
+
|
|
76
|
+
- **New feature with architecture decisions.** Full path: propose -> apply -> sync -> verify -> archive. The agent creates a proposal, generates specs and design docs, implements the code, syncs specs back to the main spec tree, verifies everything, and archives the change record.
|
|
77
|
+
|
|
78
|
+
- **Small feature with clear architecture.** Short path: propose -> apply -> archive. The agent proposes the change and moves straight to implementation, skipping the sync step because the spec impact is minimal.
|
|
79
|
+
|
|
80
|
+
- **Minimal change under 10 lines.** Fast-forward path: ff -> archive. The agent applies the change directly and archives it. No proposal, no spec, no design. Just the diff and a record.
|
|
81
|
+
|
|
82
|
+
- **Bug fix.** Fast-forward plus debugging: ff + systematic-debugging -> archive. The agent runs a structured debugging workflow, applies the fix, and archives it.
|
|
83
|
+
|
|
84
|
+
- **Exploration.** Explore path: explore -> (choose next path). The agent enters exploration mode to investigate a problem or clarify requirements, then picks one of the other paths once the picture is clear.
|
|
85
|
+
|
|
86
|
+
Every step in every path has a quality gate. The agent cannot proceed to the next step without passing verification.
|
|
87
|
+
|
|
88
|
+
---
|
|
89
|
+
|
|
90
|
+
## Project Structure
|
|
91
|
+
|
|
92
|
+
```
|
|
93
|
+
OpenOrbit/
|
|
94
|
+
├── .github/
|
|
95
|
+
│ └── ISSUE_TEMPLATE/ # Contribution issue templates
|
|
96
|
+
├── docs/
|
|
97
|
+
│ └── design/ # Architecture decision records
|
|
98
|
+
├── examples/
|
|
99
|
+
│ └── sample-project/ # Example project using OpenOrbit
|
|
100
|
+
├── skills/
|
|
101
|
+
│ └── OpenOrbit/ # The skill itself
|
|
102
|
+
│ ├── SKILL.md # Skill definition and invocation
|
|
103
|
+
│ └── ... # Supporting resources
|
|
104
|
+
├── README.md # This file
|
|
105
|
+
└── LICENSE # MIT License
|
|
106
|
+
```
|
|
107
|
+
|
|
108
|
+
---
|
|
109
|
+
|
|
110
|
+
## Contributing
|
|
111
|
+
|
|
112
|
+
Contributions are welcome. Please open an issue first to discuss what you would like to change. Pull requests should target the main branch and include a description of the change and its motivation.
|
|
113
|
+
|
|
114
|
+
All contributions are governed by the standards defined in the OpenOrbit workflow itself. Open an issue for feature requests, bug reports, or questions.
|
|
115
|
+
|
|
116
|
+
---
|
|
117
|
+
|
|
118
|
+
## License
|
|
119
|
+
|
|
120
|
+
[MIT](LICENSE)
|
|
121
|
+
|
|
122
|
+
Copyright (c) 2026 ZK-Andy
|
package/README.zh-CN.md
ADDED
|
@@ -0,0 +1,100 @@
|
|
|
1
|
+
# OpenOrbit — 开发治理罗盘
|
|
2
|
+
|
|
3
|
+
**Development Governance Compass**
|
|
4
|
+
|
|
5
|
+
OpenOrbit 是一个面向 OpenCode AI 助手的元技能(meta-skill)。它能自动将开发任务路由到最优工作流路径,让 AI 助手根据任务类型选择正确的工作流,而不是用一种方法处理所有场景。
|
|
6
|
+
|
|
7
|
+
OpenOrbit 不是一个工具,而是一个罗盘。它告诉你该走哪条路,而不是替你把路走完。
|
|
8
|
+
|
|
9
|
+
## 功能特性
|
|
10
|
+
|
|
11
|
+
- **智能任务路由** — 支持 5 种工作流路径,根据任务类型自动匹配最优流程
|
|
12
|
+
- **四引擎架构驱动** — 由 openspec-cn、oh-my-opencode、superpowers-zh 和 dotnet-skills 四套技术栈协同工作
|
|
13
|
+
- **中英双语支持** — 项目文档和技能说明同时提供中英文版本
|
|
14
|
+
- **各环节质量门禁** — 每个步骤都内置验证机制,确保产出质量
|
|
15
|
+
|
|
16
|
+
## 前置依赖
|
|
17
|
+
|
|
18
|
+
OpenOrbit 基于以下四个核心引擎运行:
|
|
19
|
+
|
|
20
|
+
- **openspec-cn** — 规范驱动的工作流外壳,管理提案、设计、任务和归档
|
|
21
|
+
- **oh-my-opencode** — 执行层编排引擎,负责任务分解和子 agent 调度
|
|
22
|
+
- **superpowers-zh** — 中文增强技能框架,提供 20 个开发技能
|
|
23
|
+
- **dotnet-skills** — .NET 领域知识库,包含 159 个专业技能
|
|
24
|
+
|
|
25
|
+
详细说明请参考 [前置依赖文档](docs/prerequisites.md)。
|
|
26
|
+
|
|
27
|
+
## 快速安装
|
|
28
|
+
|
|
29
|
+
OpenOrbit 提供三种安装方式,你可以根据使用场景选择最合适的一种。
|
|
30
|
+
|
|
31
|
+
### 方式一:直接复制
|
|
32
|
+
|
|
33
|
+
将 `skills/OpenOrbit/` 目录复制到你的 OpenCode 项目技能目录中:
|
|
34
|
+
|
|
35
|
+
```bash
|
|
36
|
+
cp -r skills/OpenOrbit/ <你的项目>/.opencode/skills/
|
|
37
|
+
```
|
|
38
|
+
|
|
39
|
+
### 方式二:npm 安装
|
|
40
|
+
|
|
41
|
+
```bash
|
|
42
|
+
npm install @openorbit/skill
|
|
43
|
+
```
|
|
44
|
+
|
|
45
|
+
安装后,在 OpenCode 配置中引用 `@openorbit/skill` 即可。
|
|
46
|
+
|
|
47
|
+
### 方式三:Git submodule
|
|
48
|
+
|
|
49
|
+
```bash
|
|
50
|
+
git submodule add https://github.com/ZK-Andy/OpenOrbit.git .openorbit
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
通过 submodule 方式可以获得最新的更新,便于长期维护。
|
|
54
|
+
|
|
55
|
+
## 工作原理
|
|
56
|
+
|
|
57
|
+
OpenOrbit 的核心是一个路由系统。它根据任务类型将请求分发到不同的工作流路径:
|
|
58
|
+
|
|
59
|
+
1. **新功能完整路径** — 适用于新增功能或模块。流程为:提案 -> 规约 -> 设计 -> 任务分解 -> 实现 -> 验证 -> 归档
|
|
60
|
+
2. **小功能快捷路径** — 适用于小范围修改或增量功能。跳过完整设计阶段,直接从规约进入实现
|
|
61
|
+
3. **极简修改** — 适用于文案调整、配置变更等微小改动。直接进入实现和验证
|
|
62
|
+
4. **Bug 修复** — 适用于缺陷修复。先使用 systematic-debugging 定位根因,再进入修复和验证
|
|
63
|
+
5. **探索模式** — 适用于需求不明确或需要调研的场景。通过 brainstorming 和 openspec-explore 进行探索
|
|
64
|
+
|
|
65
|
+
每种路径都包含对应的质量检查点,确保输出结果符合规范要求。
|
|
66
|
+
|
|
67
|
+
## 项目结构
|
|
68
|
+
|
|
69
|
+
```
|
|
70
|
+
OpenOrbit/
|
|
71
|
+
├── skills/ # 技能文件
|
|
72
|
+
│ └── OpenOrbit/ # OpenOrbit 核心技能
|
|
73
|
+
├── docs/ # 文档
|
|
74
|
+
│ ├── design/ # 设计文档
|
|
75
|
+
│ └── prerequisites.md # 前置依赖说明
|
|
76
|
+
├── examples/ # 使用示例
|
|
77
|
+
│ └── sample-project/ # 示例项目
|
|
78
|
+
├── .github/ # GitHub 配置文件
|
|
79
|
+
│ └── ISSUE_TEMPLATE/ # Issue 模板
|
|
80
|
+
├── package.json # npm 包配置
|
|
81
|
+
├── LICENSE # 许可证
|
|
82
|
+
├── README.md # 英文文档
|
|
83
|
+
└── README.zh-CN.md # 中文文档
|
|
84
|
+
```
|
|
85
|
+
|
|
86
|
+
## 贡献指南
|
|
87
|
+
|
|
88
|
+
欢迎参与 OpenOrbit 的开发。你可以通过以下方式贡献:
|
|
89
|
+
|
|
90
|
+
- 提交 Issue 报告问题或建议新功能
|
|
91
|
+
- 提交 Pull Request 改进代码或文档
|
|
92
|
+
- 完善项目中的技能文件和工作流定义
|
|
93
|
+
|
|
94
|
+
提交 PR 前请确保你的修改通过了现有的验证流程。关于更详细的贡献规范,请参考项目中的 Issue 模板和相关文档。
|
|
95
|
+
|
|
96
|
+
## 许可证
|
|
97
|
+
|
|
98
|
+
[MIT](LICENSE)
|
|
99
|
+
|
|
100
|
+
Copyright (c) 2026 ZK-Andy
|
|
@@ -0,0 +1,139 @@
|
|
|
1
|
+
# OpenOrbit Architecture
|
|
2
|
+
|
|
3
|
+
## Overview
|
|
4
|
+
|
|
5
|
+
OpenOrbit sits at the top of a four-engine stack. It is the routing layer -- the "compass" that directs development tasks to the correct workflow path through the layers below. Each layer has a clear, distinct responsibility, and together they form a complete spec-driven development pipeline.
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## Architecture Layers
|
|
10
|
+
|
|
11
|
+
```
|
|
12
|
+
┌──────────────────────────────────────────────────────────────────┐
|
|
13
|
+
│ OpenOrbit (Routing Layer) │
|
|
14
|
+
│ Task classification -> Workflow path selection -> Route dispatch │
|
|
15
|
+
│ (Routes tasks to the optimal path through the layers below) │
|
|
16
|
+
│ │
|
|
17
|
+
│ ┌──────────────────────────────────────────────────────────┐ │
|
|
18
|
+
│ │ openspec-cn (Workflow Shell) │ │
|
|
19
|
+
│ │ /opsx:propose -> /opsx:apply -> /opsx:sync -> /opsx: │ │
|
|
20
|
+
│ │ archive │ │
|
|
21
|
+
│ │ Defines WHAT to do -- proposal, specs, design, tasks │ │
|
|
22
|
+
│ │ │ │
|
|
23
|
+
│ │ ┌──────────────────────────────────────────────────┐ │ │
|
|
24
|
+
│ │ │ oh-my-opencode (Execution Orchestration) │ │ │
|
|
25
|
+
│ │ │ Atlas/Sisyphus master agent │ │ │
|
|
26
|
+
│ │ │ Reads tasks.md -> Decomposes modules -> │ │ │
|
|
27
|
+
│ │ │ Dispatches sub-agents -> Reviews output │ │ │
|
|
28
|
+
│ │ │ │ │ │
|
|
29
|
+
│ │ │ ┌────────────────────────────────────────┐ │ │ │
|
|
30
|
+
│ │ │ │ superpowers-zh + dotnet-skills │ │ │ │
|
|
31
|
+
│ │ │ │ (Quality Gates + Domain Knowledge) │ │ │ │
|
|
32
|
+
│ │ │ │ Sub-agent TDD cycle: │ │ │ │
|
|
33
|
+
│ │ │ │ Write tests -> Write code -> Self-review│ │ │ │
|
|
34
|
+
│ │ │ │ -> Submit │ │ │ │
|
|
35
|
+
│ │ │ │ Master review: same standards │ │ │ │
|
|
36
|
+
│ │ │ └────────────────────────────────────────┘ │ │ │
|
|
37
|
+
│ │ └──────────────────────────────────────────────────┘ │ │
|
|
38
|
+
│ └──────────────────────────────────────────────────────────┘ │
|
|
39
|
+
└──────────────────────────────────────────────────────────────────┘
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
---
|
|
43
|
+
|
|
44
|
+
### Layer 1: openspec-cn (Workflow Shell)
|
|
45
|
+
|
|
46
|
+
The topmost engine layer. openspec-cn defines the workflow sequence -- what to do at each step of a development task.
|
|
47
|
+
|
|
48
|
+
- **Purpose**: Defines the workflow sequence -- what to do at each step.
|
|
49
|
+
- **Artifacts**: proposal.md, design.md, specs/, tasks.md.
|
|
50
|
+
- **Commands**: /opsx:propose, /opsx:apply, /opsx:sync, /opsx:verify, /opsx:archive, /opsx:ff, /opsx:continue, /opsx:explore.
|
|
51
|
+
- **Key Principle**: Spec-driven development -- specs define expected behavior before implementation begins.
|
|
52
|
+
|
|
53
|
+
The full workflow for a new feature follows this path:
|
|
54
|
+
|
|
55
|
+
```
|
|
56
|
+
/opsx:propose -> /opsx:apply -> /opsx:sync -> /opsx:verify -> /opsx:archive
|
|
57
|
+
```
|
|
58
|
+
|
|
59
|
+
Smaller changes skip to a fast path:
|
|
60
|
+
|
|
61
|
+
```
|
|
62
|
+
/opsx:ff -> /opsx:sync -> /opsx:archive
|
|
63
|
+
```
|
|
64
|
+
|
|
65
|
+
---
|
|
66
|
+
|
|
67
|
+
### Layer 2: oh-my-opencode (Execution Orchestration)
|
|
68
|
+
|
|
69
|
+
The orchestration engine. oh-my-opencode manages who does what -- a master agent that decomposes tasks and dispatches work to sub-agents.
|
|
70
|
+
|
|
71
|
+
- **Purpose**: Orchestrates who does what -- master agent manages the entire execution.
|
|
72
|
+
- **Components**: Atlas (Master Orchestrator), Sisyphus-Junior (Task Executors), Specialized sub-agents.
|
|
73
|
+
- **Process**: Read tasks.md -> Decompose -> Dispatch -> Supervise -> Review.
|
|
74
|
+
- **Key Principle**: Master agent delegates, never writes code directly.
|
|
75
|
+
|
|
76
|
+
The master agent reads the tasks.md artifact produced by openspec-cn, decomposes it into independent modules, dispatches each module to a sub-agent, supervises execution, and reviews all output before merging.
|
|
77
|
+
|
|
78
|
+
---
|
|
79
|
+
|
|
80
|
+
### Layer 3: superpowers-zh (Quality Gates)
|
|
81
|
+
|
|
82
|
+
The quality enforcement layer. superpowers-zh provides a set of skills that enforce quality standards at every step of development.
|
|
83
|
+
|
|
84
|
+
- **Purpose**: Enforces quality standards at every step.
|
|
85
|
+
- **Skills**: brainstorming, chinese-code-review, chinese-commit-conventions, chinese-documentation, test-driven-development, systematic-debugging, verification-before-completion, and others.
|
|
86
|
+
- **Key Principle**: Every deliverable passes through a quality gate before proceeding.
|
|
87
|
+
|
|
88
|
+
Each sub-agent follows a strict TDD cycle guided by superpowers-zh:
|
|
89
|
+
|
|
90
|
+
1. Write tests first (test-driven-development)
|
|
91
|
+
2. Write code to pass tests
|
|
92
|
+
3. Self-review against quality standards (chinese-code-review, verification-before-completion)
|
|
93
|
+
4. Submit for master review
|
|
94
|
+
|
|
95
|
+
---
|
|
96
|
+
|
|
97
|
+
### Layer 4: dotnet-skills (Domain Knowledge)
|
|
98
|
+
|
|
99
|
+
The domain expertise layer. dotnet-skills provides deep .NET technical knowledge to power implementation quality.
|
|
100
|
+
|
|
101
|
+
- **Purpose**: Provides deep .NET technical expertise for implementation.
|
|
102
|
+
- **Coverage**: 159+ skills covering ASP.NET Core, EF Core, Blazor, MAUI, testing, code analysis, performance, architecture, and more.
|
|
103
|
+
- **Key Principle**: Domain-specific knowledge powers implementation quality.
|
|
104
|
+
|
|
105
|
+
When a sub-agent receives a task that involves, for example, creating an API endpoint, the system loads the relevant dotnet-skills (aspnet-core + minimal-apis) alongside superpowers-zh to guide implementation with proper patterns and conventions.
|
|
106
|
+
|
|
107
|
+
---
|
|
108
|
+
|
|
109
|
+
## Data Flow
|
|
110
|
+
|
|
111
|
+
The complete flow from task input to completion follows these stages:
|
|
112
|
+
|
|
113
|
+
1. **Classification**: User describes a task. OpenOrbit classifies it (new feature, small feature, bug fix, exploration, etc.).
|
|
114
|
+
|
|
115
|
+
2. **Routing**: OpenOrbit routes to the appropriate workflow path. Full path for new features, fast path for small changes, directed debug path for bugs.
|
|
116
|
+
|
|
117
|
+
3. **Spec Generation**: openspec-cn generates the required artifacts -- proposal, design, specs, tasks. This defines what needs to be built.
|
|
118
|
+
|
|
119
|
+
4. **Task Dispatch**: oh-my-opencode reads tasks.md, decomposes work into independent modules, and dispatches each to a sub-agent.
|
|
120
|
+
|
|
121
|
+
5. **TDD Execution**: Each sub-agent executes the TDD cycle using superpowers-zh quality gates and dotnet-skills domain knowledge. Write tests, write code, self-review, submit.
|
|
122
|
+
|
|
123
|
+
6. **Master Review**: The master agent reviews all sub-agent output against the same quality standards. Changes that fail review are sent back for fixes.
|
|
124
|
+
|
|
125
|
+
7. **Archive**: openspec-cn archives the completed change. Specs are synced to the main specification set. Work is complete.
|
|
126
|
+
|
|
127
|
+
---
|
|
128
|
+
|
|
129
|
+
## Design Principles
|
|
130
|
+
|
|
131
|
+
- **Separation of concerns**: Each layer has a clear, distinct responsibility. Routing, workflow, orchestration, quality, and domain knowledge do not overlap.
|
|
132
|
+
|
|
133
|
+
- **Incremental updates**: All changes are incremental. No full rewrites. Each change builds on the previous state of the system.
|
|
134
|
+
|
|
135
|
+
- **Quality gates**: Every step has verification built in. No deliverable moves forward without passing its quality gate.
|
|
136
|
+
|
|
137
|
+
- **Bilingual**: Chinese is the primary language for internal documentation and communication, with English annotations for technical terms and code.
|
|
138
|
+
|
|
139
|
+
- **Spec-driven**: Behavior is defined in specs before code is written. Implementation is measured against the spec.
|
|
@@ -0,0 +1,77 @@
|
|
|
1
|
+
# OpenOrbit Installation Guide
|
|
2
|
+
|
|
3
|
+
You can install OpenOrbit in three ways. Pick the one that fits your workflow.
|
|
4
|
+
|
|
5
|
+
## Method 1: Direct Copy from GitHub
|
|
6
|
+
|
|
7
|
+
Clone the repository and copy the skill into your project.
|
|
8
|
+
|
|
9
|
+
```bash
|
|
10
|
+
git clone https://github.com/ZK-Andy/OpenOrbit.git
|
|
11
|
+
cp -r OpenOrbit/skills/OpenOrbit/ your-project/.opencode/skills/
|
|
12
|
+
```
|
|
13
|
+
|
|
14
|
+
**Best for**: Users who want to customize the skill.
|
|
15
|
+
|
|
16
|
+
**Pros**: Full control. You can modify the skill directly.
|
|
17
|
+
|
|
18
|
+
**Cons**: Manual updates needed when the upstream changes.
|
|
19
|
+
|
|
20
|
+
## Method 2: npm Install
|
|
21
|
+
|
|
22
|
+
Install the package via npm, then copy or symlink the skill into your project.
|
|
23
|
+
|
|
24
|
+
```bash
|
|
25
|
+
npm install @openorbit/skill
|
|
26
|
+
# Copy the skill directory:
|
|
27
|
+
cp -r node_modules/@openorbit/skill/skills/ your-project/.opencode/skills/
|
|
28
|
+
# Or create a symlink:
|
|
29
|
+
ln -s node_modules/@openorbit/skill/skills/OpenOrbit your-project/.opencode/skills/OpenOrbit
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
**Best for**: npm-based projects.
|
|
33
|
+
|
|
34
|
+
**Pros**: Version management through npm. Easy to update, downgrade, or pin.
|
|
35
|
+
|
|
36
|
+
**Cons**: Requires npm.
|
|
37
|
+
|
|
38
|
+
## Method 3: Git Submodule
|
|
39
|
+
|
|
40
|
+
Add OpenOrbit as a git submodule and symlink the skill.
|
|
41
|
+
|
|
42
|
+
```bash
|
|
43
|
+
git submodule add https://github.com/ZK-Andy/OpenOrbit.git .openorbit
|
|
44
|
+
ln -s ../../.openorbit/skills/OpenOrbit .opencode/skills/OpenOrbit
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
**Best for**: Teams that want to pin a specific version in the repo.
|
|
48
|
+
|
|
49
|
+
**Pros**: Version is pinned in the repository. Updates are explicit and deliberate.
|
|
50
|
+
|
|
51
|
+
**Cons**: More complex setup. Everyone on the team needs to understand submodules.
|
|
52
|
+
|
|
53
|
+
## Verification
|
|
54
|
+
|
|
55
|
+
After installing, confirm the skill works:
|
|
56
|
+
|
|
57
|
+
1. Check the skill directory exists:
|
|
58
|
+
```bash
|
|
59
|
+
ls .opencode/skills/OpenOrbit/
|
|
60
|
+
```
|
|
61
|
+
2. Verify the SKILL.md file is present:
|
|
62
|
+
```bash
|
|
63
|
+
ls .opencode/skills/OpenOrbit/SKILL.md
|
|
64
|
+
```
|
|
65
|
+
3. In OpenCode, run `/OpenOrbit` to confirm it loads correctly.
|
|
66
|
+
|
|
67
|
+
## Platform Notes
|
|
68
|
+
|
|
69
|
+
**Windows users**: Use `copy` or `xcopy` instead of `cp`. For example:
|
|
70
|
+
|
|
71
|
+
```cmd
|
|
72
|
+
xcopy /E /I OpenOrbit\skills\OpenOrbit your-project\.opencode\skills\OpenOrbit
|
|
73
|
+
```
|
|
74
|
+
|
|
75
|
+
**Updating**: If you used the git clone method, run `git pull` in the OpenOrbit directory. For npm, run `npm update @openorbit/skill`.
|
|
76
|
+
|
|
77
|
+
**Troubleshooting**: If the skill does not load, check OpenCode's skill loading path configuration. Make sure `.opencode/skills/` is in the search path.
|
|
@@ -0,0 +1,124 @@
|
|
|
1
|
+
# Prerequisites
|
|
2
|
+
|
|
3
|
+
This document lists the four engines required to work on OpenOrbit. Each engine has a specific role in the development workflow. Install and verify all of them before contributing.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## 1. openspec-cn
|
|
8
|
+
|
|
9
|
+
- **Role**: Workflow shell -- defines WHAT to do (propose, specs, design, tasks)
|
|
10
|
+
- **Description**: Drives the spec-driven workflow with proposal, design, specs, and task generation. It structures the change lifecycle from proposal through verification and archival.
|
|
11
|
+
- **Installation**:
|
|
12
|
+
```bash
|
|
13
|
+
npm install -g openspec-cn
|
|
14
|
+
```
|
|
15
|
+
- **Verification**:
|
|
16
|
+
```bash
|
|
17
|
+
openspec-cn --version
|
|
18
|
+
```
|
|
19
|
+
- **Official**: https://github.com/org/openspec-cn
|
|
20
|
+
|
|
21
|
+
---
|
|
22
|
+
|
|
23
|
+
## 2. oh-my-opencode
|
|
24
|
+
|
|
25
|
+
- **Role**: Execution orchestration -- Atlas/Sisyphus master agent dispatches, supervises, and reviews sub-agents
|
|
26
|
+
- **Description**: Reads tasks.md from openspec-cn, decomposes into modules, dispatches to sub-agents, and reviews all output. It is the execution layer that turns specs into working code.
|
|
27
|
+
- **Installation**:
|
|
28
|
+
```bash
|
|
29
|
+
npm install -g oh-my-opencode
|
|
30
|
+
```
|
|
31
|
+
- **Verification**: Check that the skill is available in the OpenCode agent environment (e.g. by running a capability check or reviewing the agent's skill list).
|
|
32
|
+
- **Official**: https://github.com/org/oh-my-opencode
|
|
33
|
+
|
|
34
|
+
---
|
|
35
|
+
|
|
36
|
+
## 3. superpowers-zh
|
|
37
|
+
|
|
38
|
+
- **Role**: Quality gates -- Chinese-enhanced development skills (code review, commit conventions, documentation, TDD)
|
|
39
|
+
- **Description**: 20 skills covering brainstorming, code review, commit conventions, documentation, TDD, debugging, and more. These skills improve code quality and team collaboration for Chinese-speaking development teams.
|
|
40
|
+
- **Installation**: Copy the skills directory from the superpowers-zh repository to the project's `.opencode/skills/` directory.
|
|
41
|
+
```bash
|
|
42
|
+
git clone https://github.com/org/superpowers-zh.git
|
|
43
|
+
cp -r superpowers-zh/.opencode/skills/* .opencode/skills/
|
|
44
|
+
```
|
|
45
|
+
- **Verification**:
|
|
46
|
+
```bash
|
|
47
|
+
ls .opencode/skills/
|
|
48
|
+
```
|
|
49
|
+
The output should show skills like `brainstorming`, `chinese-code-review`, `chinese-commit-conventions`, `chinese-documentation`, `test-driven-development`, etc.
|
|
50
|
+
- **Official**: https://github.com/org/superpowers-zh
|
|
51
|
+
|
|
52
|
+
---
|
|
53
|
+
|
|
54
|
+
## 4. dotnet-skills
|
|
55
|
+
|
|
56
|
+
- **Role**: Domain knowledge -- 159+ .NET skills for implementation work
|
|
57
|
+
- **Description**: Covers ASP.NET Core, EF Core, Blazor, MAUI, testing (MSTest, xUnit, NUnit, TUnit), code analysis, performance profiling, code coverage, architecture, and many more topics. These skills provide the .NET-specific implementation knowledge needed to build OpenOrbit.
|
|
58
|
+
- **Installation**: Clone the repository to the `~/.claude/skills/` directory so the agent can discover them.
|
|
59
|
+
```bash
|
|
60
|
+
git clone https://github.com/org/dotnet-skills.git ~/.claude/skills/
|
|
61
|
+
```
|
|
62
|
+
- **Verification**:
|
|
63
|
+
```bash
|
|
64
|
+
ls ~/.claude/skills/ | head -20
|
|
65
|
+
```
|
|
66
|
+
The output should show .NET skills such as `aspnet-core`, `entity-framework-core`, `blazor`, `mstest`, `xunit`, `code-analysis`, etc.
|
|
67
|
+
- **Official**: https://github.com/org/dotnet-skills
|
|
68
|
+
|
|
69
|
+
---
|
|
70
|
+
|
|
71
|
+
## System Requirements
|
|
72
|
+
|
|
73
|
+
- **AI Environment**: OpenCode-compatible agent runtime (Claude Code, OpenClaw, or Cursor)
|
|
74
|
+
- **Project Setup**: Git-based project with the OpenOrbit repository cloned locally
|
|
75
|
+
- **Node.js**: Required for `openspec-cn` and `oh-my-opencode` (npm-based tools)
|
|
76
|
+
- **.NET SDK**: Required for `dotnet-skills` domain knowledge to be applicable
|
|
77
|
+
- **Network Access**: Required to clone the skill repositories and install npm packages
|
|
78
|
+
|
|
79
|
+
---
|
|
80
|
+
|
|
81
|
+
## Verification Checklist
|
|
82
|
+
|
|
83
|
+
After installing all four engines, run through this checklist to confirm everything is set up correctly.
|
|
84
|
+
|
|
85
|
+
| # | Check | Command / Action |
|
|
86
|
+
|---|-------|------------------|
|
|
87
|
+
| 1 | openspec-cn CLI works | `openspec-cn --version` |
|
|
88
|
+
| 2 | oh-my-opencode is installed | `npm list -g oh-my-opencode` |
|
|
89
|
+
| 3 | superpowers-zh skills are present | `ls .opencode/skills/` shows skill files |
|
|
90
|
+
| 4 | dotnet-skills are present | `ls ~/.claude/skills/` shows .NET skills |
|
|
91
|
+
| 5 | Workspace is clean | `git status` shows a clean working tree |
|
|
92
|
+
|
|
93
|
+
---
|
|
94
|
+
|
|
95
|
+
## Troubleshooting
|
|
96
|
+
|
|
97
|
+
### openspec-cn not found after installation
|
|
98
|
+
|
|
99
|
+
- Ensure Node.js and npm are installed and on your PATH.
|
|
100
|
+
- Try reinstalling: `npm uninstall -g openspec-cn && npm install -g openspec-cn`.
|
|
101
|
+
- On Windows, npm global binaries may require the npm global prefix to be in your PATH. Run `npm config get prefix` and verify the folder is in your PATH.
|
|
102
|
+
|
|
103
|
+
### oh-my-opencode not available in OpenCode
|
|
104
|
+
|
|
105
|
+
- Confirm the package installed successfully: `npm list -g oh-my-opencode`.
|
|
106
|
+
- Check that the OpenCode agent configuration points to the correct skill directories.
|
|
107
|
+
- Restart the OpenCode agent session after installation.
|
|
108
|
+
|
|
109
|
+
### superpowers-zh skills not showing up
|
|
110
|
+
|
|
111
|
+
- Verify the skills were copied to the correct path: `ls .opencode/skills/`.
|
|
112
|
+
- Each skill should be a directory containing a SKILL.md file. If the directory is empty or missing files, re-run the copy command.
|
|
113
|
+
- Make sure the `.opencode/skills/` directory exists in the project root. Create it if needed: `mkdir -p .opencode/skills`.
|
|
114
|
+
|
|
115
|
+
### dotnet-skills not visible to the agent
|
|
116
|
+
|
|
117
|
+
- Confirm the skills directory exists: `ls ~/.claude/skills/`.
|
|
118
|
+
- On Windows, `~` resolves to `C:\Users\<YourUsername>`. Verify the path is correct.
|
|
119
|
+
- If the directory is empty or the clone failed, try cloning again with a verbose flag: `GIT_TRACE=1 git clone https://github.com/org/dotnet-skills.git ~/.claude/skills/`.
|
|
120
|
+
|
|
121
|
+
### Version conflicts
|
|
122
|
+
|
|
123
|
+
- Keep all four engines on their latest stable versions.
|
|
124
|
+
- If you encounter unexpected behavior, run the verification commands above and check the official repositories for compatibility notes.
|
|
@@ -0,0 +1,158 @@
|
|
|
1
|
+
# OpenOrbit Workflow Reference
|
|
2
|
+
|
|
3
|
+
This document describes the 6 workflow paths available in OpenOrbit. Each path serves a different task type. Use the overview table below to pick the right path for your task.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## Overview Table
|
|
8
|
+
|
|
9
|
+
| Task Type | Workflow Path | Entry Command | Description |
|
|
10
|
+
|-----------|--------------|---------------|-------------|
|
|
11
|
+
| New feature (architecture decision) | Full path | `/opsx:propose` | propose -> apply -> sync -> verify -> archive |
|
|
12
|
+
| Small feature (clear architecture) | Short path | `/opsx:propose` | propose -> apply -> archive |
|
|
13
|
+
| Minimal change (<10 lines) | Fast-forward | `/opsx:ff` | ff -> archive |
|
|
14
|
+
| Bug fix | Bug fix | `/opsx:ff` | ff + systematic-debugging -> archive |
|
|
15
|
+
| Resume incomplete work | Continue | `/opsx:continue` | Resume from last checkpoint |
|
|
16
|
+
| Exploration | Explore | `/opsx:explore` | Investigate -> choose path |
|
|
17
|
+
|
|
18
|
+
---
|
|
19
|
+
|
|
20
|
+
## Detailed Path Descriptions
|
|
21
|
+
|
|
22
|
+
### 1. Full Path (New Features)
|
|
23
|
+
|
|
24
|
+
**When to use**: New features involving architecture decisions. Use this path when the feature requires design discussion, trade-off analysis, and structural changes across multiple components.
|
|
25
|
+
|
|
26
|
+
**Steps**:
|
|
27
|
+
|
|
28
|
+
1. `/opsx:propose` -- Generates proposal.md, design.md, specifications, and tasks.md. This single command produces the full artifact set needed to guide implementation.
|
|
29
|
+
|
|
30
|
+
2. `/opsx:apply` -- The master agent starts by routing design.md to an Oracle sub-agent for incremental review. The Oracle does not rewrite the design. It validates the design against project constraints and flags any gaps. After review, the master agent decomposes the tasks and dispatches them to sub-agents. Each sub-agent runs the full TDD cycle (RED -> GREEN -> REFACTOR -> VERIFY). The master agent reviews all sub-agent output before proceeding.
|
|
31
|
+
|
|
32
|
+
3. `/opsx:sync` -- Bidirectional sync between implementation and specifications. Updates the main specs to reflect changes made during implementation, and flags any spec items that were not fulfilled.
|
|
33
|
+
|
|
34
|
+
4. `/opsx:verify` -- Verifies that the implementation matches the specifications. Runs checks against the design and task definitions. This is the gate before archiving.
|
|
35
|
+
|
|
36
|
+
5. `/opsx:archive` -- Merges incremental changes back to the main specification files. The change branch or folder is finalized and closed.
|
|
37
|
+
|
|
38
|
+
**Notes**:
|
|
39
|
+
- Do not skip the Oracle review in step 2. It catches architectural drift early.
|
|
40
|
+
- The sync step is critical for maintainability. Treat it as mandatory.
|
|
41
|
+
- Use this path sparingly. Most tasks should use a shorter path.
|
|
42
|
+
|
|
43
|
+
---
|
|
44
|
+
|
|
45
|
+
### 2. Short Path (Small Features)
|
|
46
|
+
|
|
47
|
+
**When to use**: Small features where the architecture is clear and no major design decisions are needed. Use this path for self-contained changes that fit within existing boundaries.
|
|
48
|
+
|
|
49
|
+
**Steps**:
|
|
50
|
+
|
|
51
|
+
1. `/opsx:propose` -- Generates an incremental artifact set. Because the architecture is already clear, the proposal and design artifacts are lighter than in the full path.
|
|
52
|
+
|
|
53
|
+
2. `/opsx:apply` -- Skip the Oracle review. The master agent dispatches sub-agents directly. Each sub-agent runs the TDD cycle. The master agent reviews all output.
|
|
54
|
+
|
|
55
|
+
3. `/opsx:archive` -- Merge incremental changes to main specs. Since there was no sync step, the archive also handles any minor spec alignment.
|
|
56
|
+
|
|
57
|
+
**Notes**:
|
|
58
|
+
- The Oracle step is skipped because the architecture is already settled.
|
|
59
|
+
- If the feature grows in scope during apply, stop and switch to the full path.
|
|
60
|
+
- Verify the feature stays within its original boundary before archiving.
|
|
61
|
+
|
|
62
|
+
---
|
|
63
|
+
|
|
64
|
+
### 3. Fast-Forward (Minimal Changes)
|
|
65
|
+
|
|
66
|
+
**When to use**: Changes under 10 lines of code. This includes single-line fixes, comment corrections, minor config tweaks, and trivial refactors.
|
|
67
|
+
|
|
68
|
+
**Steps**:
|
|
69
|
+
|
|
70
|
+
1. `/opsx:ff` -- The master agent dispatches a single sub-agent for the full TDD loop (RED -> GREEN -> REFACTOR -> VERIFY). Because the change is minimal, the sub-agent handles it directly without parallel dispatch.
|
|
71
|
+
|
|
72
|
+
2. `/opsx:archive` -- Archive the change immediately. No sync or verify step needed because the change scope is trivial.
|
|
73
|
+
|
|
74
|
+
**Notes**:
|
|
75
|
+
- If the change exceeds 10 lines during implementation, stop and switch to the short or full path.
|
|
76
|
+
- Do not use this path for changes that touch multiple files or modify behavior logic.
|
|
77
|
+
- This path is also the fastest way to address code review comments that are purely cosmetic.
|
|
78
|
+
|
|
79
|
+
---
|
|
80
|
+
|
|
81
|
+
### 4. Bug Fix Path
|
|
82
|
+
|
|
83
|
+
**When to use**: Bug fixes of any size. This path forces a root cause analysis step before any code is written.
|
|
84
|
+
|
|
85
|
+
**Steps**:
|
|
86
|
+
|
|
87
|
+
1. `/opsx:ff` -- Start with the fast-forward command to set up the change context.
|
|
88
|
+
|
|
89
|
+
2. `systematic-debugging` -- Run the systematic debugging skill. This produces a root cause analysis document. Do not skip this step. The analysis defines the fix.
|
|
90
|
+
|
|
91
|
+
3. Sub-agent TDD -> fix -> `/opsx:archive` -- After the root cause is documented, a sub-agent runs the TDD cycle to implement the fix. Archive when done.
|
|
92
|
+
|
|
93
|
+
**Notes**:
|
|
94
|
+
- The systematic debugging step is mandatory. Fixing a bug without understanding the root cause leads to recurring issues.
|
|
95
|
+
- If the root cause reveals a larger design problem, switch to the full path.
|
|
96
|
+
- Always add a regression test in the TDD cycle. Without one, the same bug can reappear.
|
|
97
|
+
|
|
98
|
+
---
|
|
99
|
+
|
|
100
|
+
### 5. Continue Path
|
|
101
|
+
|
|
102
|
+
**When to use**: Resuming incomplete work from a previous session. Use this path when the master agent was interrupted mid-work (for example, due to context limits, session timeout, or manual stop).
|
|
103
|
+
|
|
104
|
+
**Steps**:
|
|
105
|
+
|
|
106
|
+
1. `/opsx:continue` -- The master agent reads the existing task state and restores the dispatch. Work resumes from the last checkpoint without redoing completed steps.
|
|
107
|
+
|
|
108
|
+
**Notes**:
|
|
109
|
+
- The continue command restores task state automatically. You do not need to specify which task to resume.
|
|
110
|
+
- If the change artifacts have been cleaned up, you may need to restart from `/opsx:propose` or `/opsx:ff`.
|
|
111
|
+
- After continuing, always verify the restored state before dispatching new sub-agents.
|
|
112
|
+
|
|
113
|
+
---
|
|
114
|
+
|
|
115
|
+
### 6. Explore Path
|
|
116
|
+
|
|
117
|
+
**When to use**: When you need to understand the codebase before committing to a workflow path. Use this path for unfamiliar code, third-party integrations, or when the task scope is unclear.
|
|
118
|
+
|
|
119
|
+
**Steps**:
|
|
120
|
+
|
|
121
|
+
1. `/opsx:explore` -- Enter explore mode. The master agent investigates the codebase, gathers context, and clarifies requirements with the user.
|
|
122
|
+
|
|
123
|
+
2. Choose another path -- After exploration, pick one of the other 5 paths based on what you learned.
|
|
124
|
+
|
|
125
|
+
**Notes**:
|
|
126
|
+
- Exploration does not produce artifacts. Its output is shared context that feeds into the next path.
|
|
127
|
+
- You can exit explore mode at any time by running a path command directly.
|
|
128
|
+
- Do not use the explore path for changes you already understand. It adds overhead without benefit.
|
|
129
|
+
|
|
130
|
+
---
|
|
131
|
+
|
|
132
|
+
## Sub-agent TDD Cycle Reference
|
|
133
|
+
|
|
134
|
+
Each sub-agent follows the same 4-step cycle:
|
|
135
|
+
|
|
136
|
+
| Phase | Action | Description |
|
|
137
|
+
|-------|--------|-------------|
|
|
138
|
+
| RED | Write a failing test | Express the expected behavior as a test before writing any implementation code. The test must fail initially. |
|
|
139
|
+
| GREEN | Write minimal code to pass | Implement the simplest code that makes the test pass. Do not optimize. Do not refactor. Just pass. |
|
|
140
|
+
| REFACTOR | Improve the code | Clean up the implementation and tests. Remove duplication, improve naming, and enforce style rules. The tests must stay green. |
|
|
141
|
+
| VERIFY | Run diagnostics and build | Run lsp_diagnostics, the full test suite, and the build. All must pass before the sub-agent reports completion. |
|
|
142
|
+
|
|
143
|
+
The cycle is non-negotiable. Every sub-agent must complete all 4 phases before submitting work to the master agent.
|
|
144
|
+
|
|
145
|
+
---
|
|
146
|
+
|
|
147
|
+
## Choosing the Right Path
|
|
148
|
+
|
|
149
|
+
When starting a task, ask these questions in order:
|
|
150
|
+
|
|
151
|
+
1. Do I understand the codebase area? If no -> use **Explore** path.
|
|
152
|
+
2. Is the change under 10 lines? If yes -> use **Fast-forward** path.
|
|
153
|
+
3. Is this a bug fix? If yes -> use **Bug fix** path.
|
|
154
|
+
4. Is the architecture clear? If no -> use **Full** path.
|
|
155
|
+
5. Is the feature small and self-contained? If yes -> use **Short** path.
|
|
156
|
+
6. Am I resuming previous work? If yes -> use **Continue** path.
|
|
157
|
+
|
|
158
|
+
This decision tree covers all cases. When in doubt, prefer the path that adds more structure.
|
|
@@ -0,0 +1,93 @@
|
|
|
1
|
+
<!-- THIS IS A SAMPLE CONFIGURATION FILE for demonstration purposes. Copy and adapt to your project. -->
|
|
2
|
+
<!-- ====== CLAUDE.md - Sample Configuration for OpenOrbit ====== -->
|
|
3
|
+
<!-- This is an EXAMPLE configuration. Adapt paths for your project. -->
|
|
4
|
+
|
|
5
|
+
# Sample Project
|
|
6
|
+
|
|
7
|
+
This is a sample .NET project configured with the OpenOrbit development workflow.
|
|
8
|
+
|
|
9
|
+
## Prerequisites
|
|
10
|
+
|
|
11
|
+
See [docs/prerequisites.md](../docs/prerequisites.md) for detailed installation instructions.
|
|
12
|
+
|
|
13
|
+
<!-- ====== Four Engines ====== -->
|
|
14
|
+
|
|
15
|
+
<!--
|
|
16
|
+
The four engines work together:
|
|
17
|
+
1. openspec-cn — Workflow shell (define WHAT to do)
|
|
18
|
+
2. oh-my-opencode — Execution orchestration (who does what)
|
|
19
|
+
3. superpowers-zh — Quality gates (Chinese-enhanced)
|
|
20
|
+
4. dotnet-skills — Domain knowledge (159+ .NET skills)
|
|
21
|
+
-->
|
|
22
|
+
|
|
23
|
+
<!--
|
|
24
|
+
openspec-cn commands:
|
|
25
|
+
/opsx:propose → /opsx:apply → /opsx:sync → /opsx:verify → /opsx:archive
|
|
26
|
+
-->
|
|
27
|
+
|
|
28
|
+
<!--
|
|
29
|
+
OpenOrbit skill registration:
|
|
30
|
+
The OpenOrbit skill is available at .opencode/skills/OpenOrbit/SKILL.md
|
|
31
|
+
Run /OpenOrbit in OpenCode to start the development governance compass.
|
|
32
|
+
-->
|
|
33
|
+
|
|
34
|
+
<!-- ====== Task Routing (OpenOrbit) ====== -->
|
|
35
|
+
|
|
36
|
+
<!--
|
|
37
|
+
OpenOrbit classifies incoming tasks and routes them through the appropriate
|
|
38
|
+
workflow path. The routing logic works as follows:
|
|
39
|
+
|
|
40
|
+
New feature (complex, multi-step):
|
|
41
|
+
/opsx:propose → /opsx:apply → /opsx:sync → /opsx:verify → /opsx:archive
|
|
42
|
+
Use this when the task requires spec writing, design review, and
|
|
43
|
+
multi-module implementation.
|
|
44
|
+
|
|
45
|
+
Small change (quick, well-understood):
|
|
46
|
+
/opsx:ff → /opsx:sync → /opsx:archive
|
|
47
|
+
Use this for minor enhancements or well-scoped changes that need no
|
|
48
|
+
separate proposal phase.
|
|
49
|
+
|
|
50
|
+
Bug fix:
|
|
51
|
+
/opsx:ff + systematic-debugging → /opsx:archive
|
|
52
|
+
Use this when the change is purely a bug fix. Load the debugging skill
|
|
53
|
+
alongside the fast-forward path to diagnose root cause before fixing.
|
|
54
|
+
|
|
55
|
+
Resume unfinished work:
|
|
56
|
+
/opsx:continue
|
|
57
|
+
Use this to pick up where a previous implementation left off.
|
|
58
|
+
-->
|
|
59
|
+
|
|
60
|
+
<!-- ====== AI Agent Instructions ====== -->
|
|
61
|
+
|
|
62
|
+
<!--
|
|
63
|
+
When a development task comes in:
|
|
64
|
+
1. Classify the task type (new feature, small change, bug fix, etc.)
|
|
65
|
+
2. Follow the appropriate OpenOrbit workflow path from the routing table
|
|
66
|
+
3. Load matching skills from the four engines as specified in the workflow
|
|
67
|
+
4. Apply quality gates: TDD for implementation, code review after
|
|
68
|
+
-->
|
|
69
|
+
|
|
70
|
+
<!-- ====== Project-Specific Conventions ====== -->
|
|
71
|
+
|
|
72
|
+
<!--
|
|
73
|
+
.NET SDK version: 8.0+ or 9.0+
|
|
74
|
+
Test framework: xUnit or MSTest (match existing project convention)
|
|
75
|
+
Code style: Follow .editorconfig at repo root
|
|
76
|
+
Commit style: Conventional Commits (see docs/commits.md)
|
|
77
|
+
-->
|
|
78
|
+
|
|
79
|
+
<!-- ====== OpenOrbit Skill Reference ====== -->
|
|
80
|
+
|
|
81
|
+
<!--
|
|
82
|
+
The OpenOrbit skill (.opencode/skills/OpenOrbit/SKILL.md) provides:
|
|
83
|
+
- Development governance compass
|
|
84
|
+
- Workflow path selection
|
|
85
|
+
- Quality standard definitions
|
|
86
|
+
- Onboarding and review templates
|
|
87
|
+
|
|
88
|
+
To load the skill in OpenCode, run:
|
|
89
|
+
/OpenOrbit
|
|
90
|
+
|
|
91
|
+
This will display the governance compass and guide you to the correct
|
|
92
|
+
workflow for your task type.
|
|
93
|
+
-->
|
|
@@ -0,0 +1,123 @@
|
|
|
1
|
+
# Sample Project -- OpenOrbit in Action
|
|
2
|
+
|
|
3
|
+
This is a minimal example project showing how to set up and use the OpenOrbit skill in a .NET project. It demonstrates the project structure and configuration needed to get the full OpenOrbit development governance workflow running.
|
|
4
|
+
|
|
5
|
+
The project itself contains no application code. It is a configuration-only skeleton that illustrates how OpenOrbit integrates with an OpenCode-powered AI environment and the four-engine stack.
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## Prerequisites
|
|
10
|
+
|
|
11
|
+
Before using OpenOrbit, make sure your environment meets the requirements described in the [main project prerequisites](../../docs/prerequisites.md). In summary:
|
|
12
|
+
|
|
13
|
+
- **OpenCode-compatible AI environment.** The AI agent that loads OpenOrbit must support the skill framework.
|
|
14
|
+
- **.NET SDK (8.0+ or 9.0+).** Required for any .NET project work that OpenOrbit orchestrates.
|
|
15
|
+
- **The four engines.** OpenOrbit coordinates these tools. Each must be installed and available:
|
|
16
|
+
- openspec-cn -- Workflow shell (propose, spec, design, task, archive)
|
|
17
|
+
- oh-my-opencode -- Execution orchestration (master agent dispatches and reviews sub-agents)
|
|
18
|
+
- superpowers-zh -- Quality gates (20 Chinese-enhanced development skills)
|
|
19
|
+
- dotnet-skills -- Domain knowledge (159+ .NET skills)
|
|
20
|
+
|
|
21
|
+
---
|
|
22
|
+
|
|
23
|
+
## Getting Started
|
|
24
|
+
|
|
25
|
+
1. **Install OpenOrbit** in your project. Follow the [installation guide](../../docs/installation.md) to copy or link the skill into your `.opencode/skills/` directory.
|
|
26
|
+
|
|
27
|
+
2. **Copy the skill.** The command below copies the OpenOrbit skill from the repository into this project:
|
|
28
|
+
|
|
29
|
+
```bash
|
|
30
|
+
cp -r ../../skills/OpenOrbit .opencode/skills/OpenOrbit
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
On Windows, use `xcopy` instead:
|
|
34
|
+
|
|
35
|
+
```cmd
|
|
36
|
+
xcopy /E /I ..\..\skills\OpenOrbit .opencode\skills\OpenOrbit
|
|
37
|
+
```
|
|
38
|
+
|
|
39
|
+
3. **Configure CLAUDE.md.** Create or update the `CLAUDE.md` file at the project root. This file tells the AI agent which skills are available and how to use them. See the CLAUDE.md configuration section below.
|
|
40
|
+
|
|
41
|
+
4. **Verify the setup.** Run `/OpenOrbit` in OpenCode. The agent should respond with available workflow paths and classify your project correctly.
|
|
42
|
+
|
|
43
|
+
---
|
|
44
|
+
|
|
45
|
+
## Project Structure
|
|
46
|
+
|
|
47
|
+
This is the minimal directory layout for a project using OpenOrbit:
|
|
48
|
+
|
|
49
|
+
```
|
|
50
|
+
sample-project/
|
|
51
|
+
├── .opencode/
|
|
52
|
+
│ └── skills/
|
|
53
|
+
│ └── OpenOrbit/ # The skill (copied or linked here)
|
|
54
|
+
│ └── SKILL.md
|
|
55
|
+
├── .github/ISSUE_TEMPLATE/ # OpenOrbit's community templates
|
|
56
|
+
├── docs/ # OpenOrbit's documentation
|
|
57
|
+
├── src/
|
|
58
|
+
│ └── SampleApp/ # Your .NET application code
|
|
59
|
+
├── tests/
|
|
60
|
+
│ └── SampleApp.Tests/ # Your test project
|
|
61
|
+
├── CLAUDE.md # AI agent configuration
|
|
62
|
+
└── README.md # This file
|
|
63
|
+
```
|
|
64
|
+
|
|
65
|
+
Two things to note:
|
|
66
|
+
|
|
67
|
+
- The `.opencode/skills/OpenOrbit/` directory is the skill itself. It can be a copy, a symlink, or a git submodule. The skill loading conventions of your AI environment determine which approach works best.
|
|
68
|
+
- The `src/` and `tests/` directories are where your actual .NET code lives. OpenOrbit does not dictate the internal structure of these folders. Any standard .NET project layout works.
|
|
69
|
+
|
|
70
|
+
---
|
|
71
|
+
|
|
72
|
+
## CLAUDE.md Configuration
|
|
73
|
+
|
|
74
|
+
The `CLAUDE.md` file at the project root tells the AI agent which skills are loaded and how to navigate them. A minimal configuration looks like this:
|
|
75
|
+
|
|
76
|
+
```markdown
|
|
77
|
+
# Sample Project
|
|
78
|
+
|
|
79
|
+
This project uses OpenOrbit for development governance.
|
|
80
|
+
|
|
81
|
+
## Available Skills
|
|
82
|
+
|
|
83
|
+
- **OpenOrbit**: Development governance compass. Routes tasks to the right workflow path automatically.
|
|
84
|
+
|
|
85
|
+
## How to Use
|
|
86
|
+
|
|
87
|
+
When starting a task, run `/OpenOrbit` to classify the work. The agent will suggest a workflow path based on the scope of the change.
|
|
88
|
+
|
|
89
|
+
For new features, follow the full workflow: propose, design, implement, review, verify, archive.
|
|
90
|
+
|
|
91
|
+
For small changes, use the fast path. OpenOrbit will skip unnecessary steps.
|
|
92
|
+
|
|
93
|
+
For bug fixes, OpenOrbit routes to the debug-first workflow with systematic debugging.
|
|
94
|
+
```
|
|
95
|
+
|
|
96
|
+
The actual `CLAUDE.md` in this directory contains the full configuration that references all four engines. Adjust the content to match the engines you have installed.
|
|
97
|
+
|
|
98
|
+
---
|
|
99
|
+
|
|
100
|
+
## Usage
|
|
101
|
+
|
|
102
|
+
Once OpenOrbit is installed and configured, interacting with it is straightforward:
|
|
103
|
+
|
|
104
|
+
1. **Start a task** by describing what you want to do. For example: "Add a new API endpoint for user registration."
|
|
105
|
+
|
|
106
|
+
2. **Run `/OpenOrbit`** to classify the task. The agent reads the skill and maps your request to the correct workflow path:
|
|
107
|
+
- Full path for new features (propose, design, implement, review, verify, archive)
|
|
108
|
+
- Fast path for small changes (implement, verify, archive)
|
|
109
|
+
- Debug path for bug fixes (debug, fix, verify, archive)
|
|
110
|
+
|
|
111
|
+
3. **Follow the suggested workflow.** The agent walks through each step in sequence. Quality gates at each stage make sure nothing is skipped.
|
|
112
|
+
|
|
113
|
+
4. **Repeat for each new task.** OpenOrbit re-evaluates the scope every time, so it adapts to whatever you throw at it.
|
|
114
|
+
|
|
115
|
+
---
|
|
116
|
+
|
|
117
|
+
## Learn More
|
|
118
|
+
|
|
119
|
+
- [OpenOrbit Installation Guide](../../docs/installation.md) -- Detailed installation instructions for all platforms
|
|
120
|
+
- [Prerequisites](../../docs/prerequisites.md) -- Full engine setup guide
|
|
121
|
+
- [Architecture](../../docs/architecture.md) -- How the four engines work together
|
|
122
|
+
- [Workflow Reference](../../docs/workflow-reference.md) -- All workflow paths and their steps
|
|
123
|
+
- [OpenOrbit Skill](.opencode/skills/OpenOrbit/SKILL.md) -- The skill definition loaded by this project
|
package/package.json
ADDED
|
@@ -0,0 +1,26 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "@openorbit/skill",
|
|
3
|
+
"version": "1.0.0",
|
|
4
|
+
"description": "OpenOrbit — Development Governance Compass. A meta-skill that routes development tasks to the optimal workflow path, powered by openspec-cn, oh-my-opencode, superpowers-zh, and dotnet-skills.",
|
|
5
|
+
"files": [
|
|
6
|
+
"skills/",
|
|
7
|
+
"docs/",
|
|
8
|
+
"examples/",
|
|
9
|
+
"README.md",
|
|
10
|
+
"README.zh-CN.md",
|
|
11
|
+
"LICENSE"
|
|
12
|
+
],
|
|
13
|
+
"license": "MIT",
|
|
14
|
+
"repository": {
|
|
15
|
+
"type": "git",
|
|
16
|
+
"url": "git+https://github.com/ZK-Andy/OpenOrbit.git"
|
|
17
|
+
},
|
|
18
|
+
"keywords": [
|
|
19
|
+
"openorbit",
|
|
20
|
+
"development-governance",
|
|
21
|
+
"opencode",
|
|
22
|
+
"skill",
|
|
23
|
+
"compass"
|
|
24
|
+
],
|
|
25
|
+
"author": "ZK-Andy"
|
|
26
|
+
}
|
|
@@ -0,0 +1,263 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: OpenOrbit
|
|
3
|
+
description: Development Governance Compass — automatically routes development tasks to the optimal workflow path. 开发治理罗盘 — 自动将开发任务路由到最优工作流路径。
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# OpenOrbit — 开发治理罗盘 (Development Governance Compass)
|
|
7
|
+
|
|
8
|
+
> **Version**: 1.0.0
|
|
9
|
+
> **Requires**: openspec-cn, oh-my-opencode, superpowers-zh, dotnet-skills
|
|
10
|
+
|
|
11
|
+
## 前置依赖 (Prerequisites)
|
|
12
|
+
|
|
13
|
+
OpenOrbit 是一个元技能(meta-skill),协调以下四个引擎协同工作:
|
|
14
|
+
|
|
15
|
+
| 引擎 (Engine) | 作用 (Role) |
|
|
16
|
+
|---------------|-------------|
|
|
17
|
+
| **openspec-cn** | 工作流外壳 — 定义"做什么":提案、规约、设计、任务、归档 |
|
|
18
|
+
| **oh-my-opencode** | 执行层编排 — 主 agent (Atlas/Sisyphus) 分解任务、分发子 agent、监督审核 |
|
|
19
|
+
| **superpowers-zh** | 中文增强技能框架 — 提供 20 个开发技能(brainstorming、TDD、代码审查等) |
|
|
20
|
+
| **dotnet-skills** | .NET 领域知识库 — 159 个专业技能(ASP.NET Core、EF Core、MAUI 等) |
|
|
21
|
+
|
|
22
|
+
请确保目标项目已安装以上四个引擎。详见 [前置依赖文档](../../docs/prerequisites.md)。
|
|
23
|
+
|
|
24
|
+
## 概述 (Overview)
|
|
25
|
+
|
|
26
|
+
OpenOrbit 是一个开发治理罗盘。它帮助你面对不同开发任务自动指向最佳工作流路径。底层由 openspec-cn、oh-my-opencode、superpowers-zh、dotnet-skills 四引擎驱动。openspec-cn 做工作流外壳(定义做什么),oh-my-opencode 做执行层编排(主 agent 分发任务监督审核),superpowers-zh + dotnet-skills 联合提供全流程质量门禁。
|
|
27
|
+
|
|
28
|
+
## 何时使用 (When to Use)
|
|
29
|
+
|
|
30
|
+
### 适用场景 (Appropriate Scenarios)
|
|
31
|
+
|
|
32
|
+
- 初始化一个新的 .NET 项目,需要规范驱动的开发流程 (Setting up a new .NET project with spec-driven workflow)
|
|
33
|
+
- 接手使用了这四引擎的项目,需要理解工作流和目录结构 (Inheriting a project using these four engines)
|
|
34
|
+
- 计划新功能,不确定走完整路径还是快捷路径 (Planning a new feature, unsure which workflow path to take)
|
|
35
|
+
- 配置 CI/CD,需要理解各环节的验证点 (Configuring CI/CD, need to understand validation gates)
|
|
36
|
+
- 团队需要统一开发流程规范 (Team needs standardized development workflow)
|
|
37
|
+
|
|
38
|
+
### 不适用的场景 (Inappropriate Scenarios)
|
|
39
|
+
|
|
40
|
+
- 已有稳定的非 openspec 工作流,无迁移必要 (Already has a stable non-openspec workflow with no migration need)
|
|
41
|
+
- 纯前端项目(无 .NET 代码)— dotnet-skills 不适用 (Pure frontend project with no .NET code)
|
|
42
|
+
- 单人快速原型阶段 — 流程可能偏重 (Solo rapid prototyping where processes may be too heavy)
|
|
43
|
+
- 需要严格的 Git 分支管理工作流 — 请使用 chinese-git-workflow (Requires strict Git branch management)
|
|
44
|
+
- 项目尚处于探索/调研阶段,无需完整实现 (Project still in exploration/research phase)
|
|
45
|
+
|
|
46
|
+
## 架构分层 (Architecture Layers)
|
|
47
|
+
|
|
48
|
+
```
|
|
49
|
+
┌──────────────────────────────────────────────────────────────────────────┐
|
|
50
|
+
│ openspec-cn(工作流外壳 / Workflow Shell) │
|
|
51
|
+
│ /opsx:propose → /opsx:apply → /opsx:sync → /opsx:verify → /opsx:archive │
|
|
52
|
+
│ (定义"做什么"——提案、规约、设计、任务 / Defines WHAT to do) │
|
|
53
|
+
│ │
|
|
54
|
+
│ ┌──────────────────────────────────────────────────────────────────┐ │
|
|
55
|
+
│ │ oh-my-opencode(执行层编排 / Execution Orchestration) │ │
|
|
56
|
+
│ │ Atlas/Sisyphus 主 agent(Master Agent) │ │
|
|
57
|
+
│ │ 读取 tasks.md → 分解模块 → 分发子 agent → 审核 │ │
|
|
58
|
+
│ │ (Read tasks.md → Decompose → Dispatch sub-agents → Review) │ │
|
|
59
|
+
│ │ │ │
|
|
60
|
+
│ │ ┌───────────────────────────────────────────────────────┐ │ │
|
|
61
|
+
│ │ │ superpowers-zh + dotnet-skills(质量门禁 / Quality Gate)│ │ │
|
|
62
|
+
│ │ │ 子 agent TDD 循环 (Sub-agent TDD cycle): │ │ │
|
|
63
|
+
│ │ │ 写测试 → 写代码 → 自审查 → 提交 │ │ │
|
|
64
|
+
│ │ │ (Write test → Write code → Self-review → Commit) │ │ │
|
|
65
|
+
│ │ │ 主 agent 审查:同样标准审核产出 │ │ │
|
|
66
|
+
│ │ │ (Master agent reviews with same standards) │ │ │
|
|
67
|
+
│ │ └───────────────────────────────────────────────────────┘ │ │
|
|
68
|
+
│ └──────────────────────────────────────────────────────────────────┘ │
|
|
69
|
+
└──────────────────────────────────────────────────────────────────────────┘
|
|
70
|
+
```
|
|
71
|
+
|
|
72
|
+
## 核心工作流 (Core Workflow)
|
|
73
|
+
|
|
74
|
+
不同的变更类型走不同的路径。OpenOrbit 提供 5+1 种路径选择:
|
|
75
|
+
|
|
76
|
+
```
|
|
77
|
+
需求来了 (Requirement arrives)
|
|
78
|
+
│
|
|
79
|
+
├── 新功能(涉及架构决策 / New feature, involves architecture decisions)
|
|
80
|
+
│ ├── /opsx:propose → 生成 proposal + design + specs + tasks
|
|
81
|
+
│ ├── /opsx:apply
|
|
82
|
+
│ │ ├── 主 agent 启动 → Oracle 子 agent 增量审核 design.md
|
|
83
|
+
│ │ │ (Master agent starts → Oracle sub-agent incrementally reviews design.md)
|
|
84
|
+
│ │ ├── 主 agent 分解 tasks → 分发子 agent(并行 TDD 编码)
|
|
85
|
+
│ │ │ (Master agent decomposes tasks → distributes to sub-agents for parallel TDD)
|
|
86
|
+
│ │ └── 主 agent 审核所有子 agent 产出
|
|
87
|
+
│ │ (Master agent reviews all sub-agent output)
|
|
88
|
+
│ ├── /opsx:sync → 双向同步实现 vs 规约 (Bidirectional sync implementation vs specs)
|
|
89
|
+
│ ├── /opsx:verify
|
|
90
|
+
│ └── /opsx:archive → 合并增量到主规约 (Merge deltas into main specs)
|
|
91
|
+
│
|
|
92
|
+
├── 小功能(架构清晰 / Small feature, architecture is clear)
|
|
93
|
+
│ ├── /opsx:ff → 增量制品集 (Incremental artifact set)
|
|
94
|
+
│ ├── /opsx:apply → 跳过 Oracle → 分发子 agent → 审核
|
|
95
|
+
│ │ (Skip Oracle → dispatch sub-agents → review)
|
|
96
|
+
│ └── /opsx:archive
|
|
97
|
+
│
|
|
98
|
+
├── 极简修改(< 10 行 / Minimal change, < 10 lines)
|
|
99
|
+
│ └── /opsx:ff → 子 agent TDD → /opsx:archive
|
|
100
|
+
│
|
|
101
|
+
├── Bug 修复 (Bug fix)
|
|
102
|
+
│ ├── /opsx:ff
|
|
103
|
+
│ ├── systematic-debugging(English: systematic debugging)→ 定位根因
|
|
104
|
+
│ │ (Identify root cause)
|
|
105
|
+
│ └── 子 agent TDD → /opsx:archive
|
|
106
|
+
│
|
|
107
|
+
├── 继续未完成的工作 (Continue incomplete work)
|
|
108
|
+
│ └── /opsx:continue → 主 agent 恢复任务分发
|
|
109
|
+
│ (Master agent resumes task distribution)
|
|
110
|
+
│
|
|
111
|
+
└── 需要先理解代码库 (Need to understand the codebase first)
|
|
112
|
+
└── /opsx:explore → 再走其他路径 (Then proceed with another path)
|
|
113
|
+
```
|
|
114
|
+
|
|
115
|
+
## 子 agent TDD 循环 (Sub-agent TDD Cycle)
|
|
116
|
+
|
|
117
|
+
每个子 agent 拿到一个模块任务后,内部的编码循环遵循严格的 TDD 纪律:
|
|
118
|
+
|
|
119
|
+
```
|
|
120
|
+
子 agent 收到模块任务 (Sub-agent receives module task)
|
|
121
|
+
│
|
|
122
|
+
├── ① 写测试 — RED(Write failing tests)
|
|
123
|
+
│ test-driven-development(English: test-driven development)
|
|
124
|
+
│ + dotnet-test-frameworks(English: .NET test frameworks)
|
|
125
|
+
│ → 编写失败的测试,定义期望行为 (Write failing tests, define expected behavior)
|
|
126
|
+
│
|
|
127
|
+
├── ② 写代码 — GREEN(Write minimal code to pass)
|
|
128
|
+
│ test-driven-development(English: test-driven development)
|
|
129
|
+
│ + 对应领域 dotnet-skill(English: corresponding domain .NET skill)
|
|
130
|
+
│ → 实现刚好让测试通过的最小代码 (Implement minimal code to pass tests)
|
|
131
|
+
│
|
|
132
|
+
├── ③ 自审查 — REFACTOR(Self-review and refactor)
|
|
133
|
+
│ chinese-code-review(English: Chinese code review standards)
|
|
134
|
+
│ + code-analysis(English: .NET SDK code analysis)
|
|
135
|
+
│ + format(English: dotnet format)
|
|
136
|
+
│ → 检查代码质量、架构合规、性能、安全 (Check quality, architecture, performance, security)
|
|
137
|
+
│
|
|
138
|
+
└── ④ 验证 + 提交 — VERIFY(Verify and commit)
|
|
139
|
+
verification-before-completion(English: verification before completion)
|
|
140
|
+
+ chinese-commit-conventions(English: Chinese commit conventions)
|
|
141
|
+
→ 运行验证命令 → 确认通过 → 提交 (Run verification → Confirm pass → Commit)
|
|
142
|
+
```
|
|
143
|
+
|
|
144
|
+
## 质量标准 (Quality Standards)
|
|
145
|
+
|
|
146
|
+
六个规范标准由 OpenOrbit(superpowers-zh + dotnet-skills)联合定义:
|
|
147
|
+
|
|
148
|
+
| 规范 (Standard) | superpowers-zh 技能 | dotnet-skills 技能 |
|
|
149
|
+
|-----------------|---------------------|-------------------|
|
|
150
|
+
| 提交 (Commit) | chinese-commit-conventions | format |
|
|
151
|
+
| 代码 (Code) | chinese-code-review | code-analysis + format |
|
|
152
|
+
| 注释 (Comments) | chinese-documentation | code-analysis (XML Doc) |
|
|
153
|
+
| 架构 (Architecture) | chinese-code-review | architecture + code-analysis |
|
|
154
|
+
| 测试 (Test) | test-driven-development | dotnet-test-frameworks |
|
|
155
|
+
| 文档 (Documentation) | chinese-documentation | code-analysis |
|
|
156
|
+
|
|
157
|
+
## 快速参考 (Quick Reference)
|
|
158
|
+
|
|
159
|
+
### 目录结构 (Directory Structure)
|
|
160
|
+
|
|
161
|
+
一个标准的使用 OpenOrbit 的项目目录结构如下:
|
|
162
|
+
|
|
163
|
+
```
|
|
164
|
+
project-root/
|
|
165
|
+
├── .opencode/
|
|
166
|
+
│ └── skills/
|
|
167
|
+
│ └── OpenOrbit/ # OpenOrbit 技能定义
|
|
168
|
+
│ └── SKILL.md # 本文件
|
|
169
|
+
├── openspec/
|
|
170
|
+
│ ├── config.yaml # openspec-cn 配置
|
|
171
|
+
│ ├── specs/ # 主规约目录 (Master specs)
|
|
172
|
+
│ │ ├── architecture.md
|
|
173
|
+
│ │ └── ...
|
|
174
|
+
│ └── changes/ # 变更目录 (Change artifacts)
|
|
175
|
+
│ └── <change-id>/
|
|
176
|
+
│ ├── proposal.md # 提案
|
|
177
|
+
│ ├── design.md # 设计文档
|
|
178
|
+
│ ├── tasks.md # 任务分解
|
|
179
|
+
│ └── specs/ # 增量规约 (Delta specs)
|
|
180
|
+
├── .claude/
|
|
181
|
+
│ └── skills/ # Claude 技能目录
|
|
182
|
+
├── CLAUDE.md # 项目配置 (含 OpenOrbit 引用)
|
|
183
|
+
└── src/ # 源代码
|
|
184
|
+
```
|
|
185
|
+
|
|
186
|
+
### 质量门禁与验证 (Quality Gates)
|
|
187
|
+
|
|
188
|
+
| 阶段 (Phase) | 验证工具 (Verification Tool) | 检查内容 (Checks) |
|
|
189
|
+
|--------------|------------------------------|-------------------|
|
|
190
|
+
| TDD 写测试 | lsp_diagnostics | 测试代码无编译错误 |
|
|
191
|
+
| TDD 写代码 | lsp_diagnostics + dotnet build | 代码编译通过 |
|
|
192
|
+
| 自审查 | chinese-code-review | 代码质量、架构合规 |
|
|
193
|
+
| 验证 | verification-before-completion | 测试通过、构建通过 |
|
|
194
|
+
| 归档前 | /opsx:verify | 实现与规约一致 |
|
|
195
|
+
|
|
196
|
+
### 可用命令 (Available Commands)
|
|
197
|
+
|
|
198
|
+
| 命令 (Command) | 用途 (Purpose) |
|
|
199
|
+
|----------------|----------------|
|
|
200
|
+
| `/opsx:propose` | 提案新变更,生成 proposal + design + specs + tasks |
|
|
201
|
+
| `/opsx:apply` | 实现变更中的任务,启动主 agent 分发 |
|
|
202
|
+
| `/opsx:ff` | 快速创建变更并生成所有产出物 |
|
|
203
|
+
| `/opsx:continue` | 继续处理未完成的变更 |
|
|
204
|
+
| `/opsx:sync` | 同步增量规约到主规约 |
|
|
205
|
+
| `/opsx:verify` | 验证实现与变更产出物一致 |
|
|
206
|
+
| `/opsx:archive` | 归档已完成的变更 |
|
|
207
|
+
| `/opsx:explore` | 进入探索模式,构思想法、调查问题 |
|
|
208
|
+
|
|
209
|
+
## 初始化指南 (Initialization Guide)
|
|
210
|
+
|
|
211
|
+
在新项目中初始化 OpenOrbit 工作流:
|
|
212
|
+
|
|
213
|
+
1. **安装四引擎**:
|
|
214
|
+
- 确保 openspec-cn CLI 已安装并可用 (`openspec-cn --version`)
|
|
215
|
+
- 确保 oh-my-opencode 在主 agent 环境中已配置
|
|
216
|
+
- 确保 superpowers-zh 技能框架已加载到项目 `.opencode/skills/` 目录
|
|
217
|
+
- 确保 dotnet-skills 已安装到 `~/.claude/skills/`(159 个技能)
|
|
218
|
+
|
|
219
|
+
2. **复制技能定义**:
|
|
220
|
+
```bash
|
|
221
|
+
# 将 OpenOrbit 技能复制到项目
|
|
222
|
+
cp -r skills/OpenOrbit/ <你的项目>/.opencode/skills/OpenOrbit/
|
|
223
|
+
```
|
|
224
|
+
|
|
225
|
+
3. **初始化 openspec-cn**:
|
|
226
|
+
```bash
|
|
227
|
+
cd <你的项目>
|
|
228
|
+
openspec-cn init
|
|
229
|
+
```
|
|
230
|
+
|
|
231
|
+
4. **配置 CLAUDE.md**:在项目根目录的 `CLAUDE.md` 中添加 OpenOrbit 引用:
|
|
232
|
+
```markdown
|
|
233
|
+
<!-- OpenOrbit 开发治理罗盘 -->
|
|
234
|
+
<!-- openspec-cn v1.3.1 已初始化 -->
|
|
235
|
+
<!-- skill: OpenOrbit -->
|
|
236
|
+
```
|
|
237
|
+
|
|
238
|
+
5. **验证安装**:运行 `/OpenOrbit` 命令检查配置状态。
|
|
239
|
+
|
|
240
|
+
## 常见错误 (Common Errors)
|
|
241
|
+
|
|
242
|
+
| 错误 (Error) | 原因 (Cause) | 解决 (Solution) |
|
|
243
|
+
|--------------|--------------|-----------------|
|
|
244
|
+
| "openspec-cn: command not found" | openspec-cn CLI 未安装 | `npm install -g openspec-cn` 或按项目文档安装 |
|
|
245
|
+
| "缺少 superpowers-zh 技能" | superpowers-zh 未复制到项目 | 将 `.opencode/skills/` 目录从 superpowers-zh 项目复制过来 |
|
|
246
|
+
| "dotnet build 失败" | .NET SDK 版本不匹配或依赖未恢复 | 检查 `global.json`,运行 `dotnet restore` |
|
|
247
|
+
| "/opsx:apply 找不到 tasks.md" | 未先运行 `/opsx:propose` 或 `/opsx:ff` | 先运行提案或快速创建命令生成产出物 |
|
|
248
|
+
| "子 agent 审核不通过" | 代码未达到质量标准 | 检查质量标准表,运行 `chinese-code-review` 和 `code-analysis` |
|
|
249
|
+
| "changes 目录冲突" | 多人同时修改同一变更 | 使用 `/opsx:continue` 恢复,或归档冲突变更后重建 |
|
|
250
|
+
|
|
251
|
+
## 相关技能 (Related Skills)
|
|
252
|
+
|
|
253
|
+
- `brainstorming`(English: brainstorming)— 创造性工作前的需求分析与设计探索
|
|
254
|
+
- `test-driven-development`(English: test-driven development)— 测试先行的开发方法论
|
|
255
|
+
- `chinese-code-review`(English: Chinese code review standards)— 中文代码审查规范
|
|
256
|
+
- `chinese-commit-conventions`(English: Chinese commit conventions)— 中文 Git 提交规范
|
|
257
|
+
- `chinese-documentation`(English: Chinese documentation standards)— 中文技术文档写作规范
|
|
258
|
+
- `verification-before-completion`(English: verification before completion)— 完成前验证机制
|
|
259
|
+
- `systematic-debugging`(English: systematic debugging)— 系统化调试方法论
|
|
260
|
+
- `subagent-driven-development`(English: sub-agent driven development)— 子 agent 驱动的开发模式
|
|
261
|
+
- `dispatching-parallel-agents` — 并行 agent 分发
|
|
262
|
+
- `writing-plans`(English: writing plans)— 多步骤任务规划
|
|
263
|
+
- `finishing-a-development-branch`(English: finishing a development branch)— 开发分支收尾
|