@frenchtoastman/oh-my-groundcontrol 0.0.12 → 0.0.14
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/README.md +50 -331
- package/dist/index.js +10 -7
- package/package.json +1 -1
- package/src/skills/commit-protocol/SKILL.md +87 -0
package/README.md
CHANGED
|
@@ -1,70 +1,77 @@
|
|
|
1
|
-
|
|
2
|
-
<p><i>Houston, we have a solution. Nine specialized agents stand by at mission control, each a master of their operational domain. They await your command to clear the launchpad, assemble the flight systems, and achieve what no single engineer could build alone.</i></p>
|
|
3
|
-
<p><b>Open Multi Agent Suite</b> · Mix any models · Auto delegate tasks</p>
|
|
4
|
-
</div>
|
|
1
|
+
# oh-my-groundcontrol: Open Multi-Agent Suite
|
|
5
2
|
|
|
6
|
-
|
|
3
|
+
## Abstract
|
|
4
|
+
`oh-my-groundcontrol` is an advanced multi-agent orchestration plugin for OpenCode, engineered to distribute complex software development tasks across specialized language models. Operating under strict procedural constraints inspired by NASA technical standards, this suite minimizes architectural drift, enforces validation protocols, and optimizes for quality, speed, and computational efficiency.
|
|
7
5
|
|
|
8
|
-
|
|
6
|
+
By categorizing AI agents into distinct operational domains (e.g., planning, risk analysis, codebase reconnaissance, and implementation), the system ensures high-reliability outputs suitable for mission-critical software engineering environments.
|
|
9
7
|
|
|
10
|
-
|
|
8
|
+
## Core Architecture
|
|
9
|
+
|
|
10
|
+
The architecture delegates responsibilities to nine domain-specific subagents, segmented into two primary functional groups: **Planning & Verification** and **Execution & Integration**.
|
|
11
|
+
|
|
12
|
+
### Planning & Verification Systems
|
|
13
|
+
- **Groundcontrol (Lead Systems Engineer)**: Conducts requirements gathering and strategic planning. Generates decision-complete work schematics. (Prompt: `groundcontrol/index.ts`)
|
|
14
|
+
- **PreFlight (Risk Analyst)**: Performs pre-planning anomaly detection. Identifies logical ambiguities and failure points prior to execution. (Prompt: `pre-flight.ts`)
|
|
15
|
+
- **Verification (Launch Committer)**: Serves as the ultimate quality assurance gatekeeper. Verifies execution plans against constraints before authorization. (Prompt: `verification.ts`)
|
|
16
|
+
|
|
17
|
+
### Execution & Integration Systems
|
|
18
|
+
- **Orchestrator (Flight Director)**: The central command node. Routes tasks dynamically to specialized subagents. (Prompt: `orchestrator.ts`)
|
|
19
|
+
- **Explorer (Telemetry Scout)**: Dedicated to parallel codebase search, utilizing AST, grep, and glob protocols. (Prompt: `explorer.ts`)
|
|
20
|
+
- **Oracle (Principal Architect)**: Strategic advisor for complex debugging, long-term trade-offs, and deep system refactoring. (Prompt: `oracle.ts`)
|
|
21
|
+
- **Librarian (Data Archivist)**: Retrieves and synthesizes external API references and official documentation. (Prompt: `librarian.ts`)
|
|
22
|
+
- **Designer (Interface Specialist)**: Focuses exclusively on UI/UX aesthetics, visual consistency, and interaction design. (Prompt: `designer.ts`)
|
|
23
|
+
- **Fixer (Systems Integrator)**: Parallel execution engine for rapid code implementation based on precise specifications. (Prompt: `fixer.ts`)
|
|
24
|
+
|
|
25
|
+
## Operational Guidelines
|
|
26
|
+
|
|
27
|
+
### Standard Installation
|
|
28
|
+
|
|
29
|
+
Execute the following command to install the plugin suite:
|
|
11
30
|
|
|
12
31
|
```bash
|
|
13
32
|
bunx @frenchtoastman/oh-my-groundcontrol@latest install
|
|
14
33
|
```
|
|
15
34
|
|
|
16
|
-
|
|
35
|
+
### Advanced Configuration (Free Models & Hybrid Modes)
|
|
36
|
+
|
|
37
|
+
The installer can refresh and automatically assign OpenCode free models directly, or run in a hybrid configuration combining OpenCode free models with external providers (OpenAI, Kimi, Antigravity, Chutes).
|
|
17
38
|
|
|
18
39
|
```bash
|
|
19
40
|
bunx @frenchtoastman/oh-my-groundcontrol@latest install --no-tui --kimi=yes --openai=yes --antigravity=yes --chutes=yes --opencode-free=yes --opencode-free-model=auto --tmux=no --skills=yes
|
|
20
41
|
```
|
|
21
42
|
|
|
22
|
-
|
|
43
|
+
Following installation, authenticate your OpenCode session:
|
|
23
44
|
|
|
24
45
|
```bash
|
|
25
46
|
opencode auth login
|
|
26
47
|
```
|
|
27
48
|
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
OpenCode free-model mode uses `opencode models --refresh --verbose`, filters to free `opencode/*` models, and applies coding-first selection:
|
|
31
|
-
- OpenCode-only mode can use multiple OpenCode free models across agents.
|
|
32
|
-
- Hybrid mode can combine OpenCode free models with OpenAI, Kimi, and/or Antigravity.
|
|
33
|
-
- In hybrid mode, `designer` stays on the external provider mapping.
|
|
34
|
-
- Chutes mode auto-selects primary/support models with daily-cap awareness (300/2000/5000).
|
|
49
|
+
Verify agent connectivity by running `ping all agents` within the OpenCode terminal.
|
|
35
50
|
|
|
36
|
-
>
|
|
51
|
+
> **Note on Model Customization:** The active model matrix is fully configurable. Edit `~/.config/opencode/oh-my-groundcontrol.json` (or `.jsonc`) to override agent-to-model assignments manually.
|
|
37
52
|
|
|
38
|
-
### For
|
|
53
|
+
### For AI Agents / LLMs
|
|
39
54
|
|
|
40
|
-
|
|
55
|
+
To instruct an external coding agent to utilize this suite, paste this block into the agent's prompt:
|
|
41
56
|
|
|
42
57
|
```
|
|
43
58
|
Install and configure by following the instructions here:
|
|
44
59
|
https://raw.githubusercontent.com/frenchtoasters/oh-my-groundcontrol/refs/heads/master/README.md
|
|
45
60
|
```
|
|
46
61
|
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
**Additional guides:**
|
|
50
|
-
- **[Antigravity Setup](docs/antigravity.md)** - Complete guide for Antigravity provider configuration
|
|
51
|
-
- **[Tmux Integration](docs/tmux-integration.md)** - Real-time agent monitoring with tmux
|
|
62
|
+
*Operational Note:* It is highly recommended to add `.groundcontrol/` to your project's `.gitignore` file to exclude generated flight plans from version control systems.
|
|
52
63
|
|
|
53
|
-
|
|
64
|
+
## Verification & Validation (V&V) Procedures
|
|
54
65
|
|
|
55
|
-
|
|
66
|
+
Our execution pipelines are strictly governed by protocols modeled on the NASA Technical Standards System to ensure maximal software assurance.
|
|
56
67
|
|
|
57
|
-
|
|
68
|
+
1. **Destructive Pause (NASA-STD-8739.8B):** Agents must halt and request explicit user authorization before executing irreversible actions, such as force-pushing to remote repositories or bulk file deletions.
|
|
69
|
+
2. **Pre-Flight Verification (NASA-HDBK-8739.19-3):** Agents are required to execute continuous integration checks (`bun run check:ci`, `bun run typecheck`) to validate syntactic and structural integrity prior to mission conclusion.
|
|
70
|
+
3. **Atomic Checkpoints (NASA-HDBK-8739.18):** Stable codebase states must be committed prior to the initiation of widespread architectural refactors.
|
|
71
|
+
4. **Escalation Protocol (NASA-STD-7009B):** In the event an automated verification process fails three or more consecutive times, agents must abort automated remediation attempts and escalate to the human operator for guidance.
|
|
58
72
|
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
1. **Destructive Pause (NASA-STD-8739.8B):** Stop and request explicit user confirmation before irreversible actions (e.g., force pushing, bulk deletions).
|
|
62
|
-
2. **Pre-Flight Verification (NASA-HDBK-8739.19-3):** Always run linters and typechecks (`bun run check:ci`, `bun run typecheck`) to validate changes before concluding.
|
|
63
|
-
3. **Atomic Checkpoints (NASA-HDBK-8739.18):** Commit stable states before initiating widespread refactors.
|
|
64
|
-
4. **Escalation Protocol (NASA-STD-7009B):** If an automated check fails 3+ times, stop guessing and ask the user for guidance.
|
|
65
|
-
|
|
66
|
-
#### Source Documentation
|
|
67
|
-
The principles driving our agent behavior are extracted directly from the [NASA Technical Standards System](https://standards.nasa.gov):
|
|
73
|
+
### Source Standards Documentation
|
|
74
|
+
The principles governing our agent behaviors are extracted directly from the [NASA Technical Standards System](https://standards.nasa.gov):
|
|
68
75
|
|
|
69
76
|
- [NASA-STD-7009B](https://standards.nasa.gov/standard/nasa/nasa-std-7009): Standard for Models and Simulations
|
|
70
77
|
- [NASA-STD-8739.8B](https://standards.nasa.gov/standard/nasa/nasa-std-87398): Software Assurance and Software Safety Standard
|
|
@@ -77,302 +84,14 @@ The principles driving our agent behavior are extracted directly from the [NASA
|
|
|
77
84
|
- [NASA-HDBK-1004](https://standards.nasa.gov/standard/nasa/nasa-hdbk-1004): Data Requirements Descriptions (DRDs) for Software
|
|
78
85
|
- [NASA-HDBK-1009A](https://standards.nasa.gov/standard/nasa/nasa-hdbk-1009): Software Error Causes
|
|
79
86
|
|
|
80
|
-
|
|
81
|
-
|
|
82
|
-
### The Flight Directors
|
|
83
|
-
|
|
84
|
-
*Those who plan, perceive, and verify before the launch sequence begins.*
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
---
|
|
88
|
-
|
|
89
|
-
### 01. Groundcontrol: The Lead Systems Engineer
|
|
90
|
-
|
|
91
|
-
<table>
|
|
92
|
-
<tr>
|
|
93
|
-
<td width="30%" align="center" valign="top">
|
|
94
|
-
<sub><i>Designs the mission architecture.</i></sub>
|
|
95
|
-
</td>
|
|
96
|
-
<td width="70%" valign="top">
|
|
97
|
-
Operating from the engineering drafting boards, Groundcontrol shapes the mission blueprint before a single line of code is written. They conduct rigorous requirements gathering, consult on system constraints, and deliver decision-complete schematics to ensure the objective is achievable. No system is built without their approved plan.
|
|
98
|
-
</td>
|
|
99
|
-
</tr>
|
|
100
|
-
<tr>
|
|
101
|
-
<td colspan="2">
|
|
102
|
-
<b>Role:</b> <code>Strategic planning and requirements gathering</code>
|
|
103
|
-
</td>
|
|
104
|
-
</tr>
|
|
105
|
-
<tr>
|
|
106
|
-
<td colspan="2">
|
|
107
|
-
<b>Prompt:</b> <a href="src/agents/groundcontrol/index.ts"><code>contractor/index.ts</code></a>
|
|
108
|
-
</td>
|
|
109
|
-
</tr>
|
|
110
|
-
<tr>
|
|
111
|
-
<td colspan="2">
|
|
112
|
-
<b>Recommended Models:</b> <code>openai/gpt-5.2-codex</code> <code>kimi-for-coding/k2p5</code>
|
|
113
|
-
</td>
|
|
114
|
-
</tr>
|
|
115
|
-
</table>
|
|
116
|
-
|
|
117
|
-
---
|
|
118
|
-
|
|
119
|
-
### 02. PreFlight: The Risk Analyst
|
|
120
|
-
|
|
121
|
-
<table>
|
|
122
|
-
<tr>
|
|
123
|
-
<td width="30%" align="center" valign="top">
|
|
124
|
-
<sub><i>Identifies anomalies before ignition.</i></sub>
|
|
125
|
-
</td>
|
|
126
|
-
<td width="70%" valign="top">
|
|
127
|
-
PreFlight acts as the primary safety and risk analysis officer. Before the flight plan is authorized, they examine it for latent bugs, unresolved ambiguities, and catastrophic edge cases. They uncover the hidden pitfalls buried in the requirements and detect failure points that would cause a critical abort mid-mission.
|
|
128
|
-
</td>
|
|
129
|
-
</tr>
|
|
130
|
-
<tr>
|
|
131
|
-
<td colspan="2">
|
|
132
|
-
<b>Role:</b> <code>Pre-planning analysis and risk detection</code>
|
|
133
|
-
</td>
|
|
134
|
-
</tr>
|
|
135
|
-
<tr>
|
|
136
|
-
<td colspan="2">
|
|
137
|
-
<b>Prompt:</b> <a href="src/agents/pre-flight.ts"><code>pre-flight.ts</code></a>
|
|
138
|
-
</td>
|
|
139
|
-
</tr>
|
|
140
|
-
<tr>
|
|
141
|
-
<td colspan="2">
|
|
142
|
-
<b>Recommended Models:</b> <code>openai/gpt-5.2-codex</code> <code>kimi-for-coding/k2p5</code>
|
|
143
|
-
</td>
|
|
144
|
-
</tr>
|
|
145
|
-
</table>
|
|
146
|
-
|
|
147
|
-
---
|
|
148
|
-
|
|
149
|
-
### 03. Verification: The Launch Committer
|
|
150
|
-
|
|
151
|
-
<table>
|
|
152
|
-
<tr>
|
|
153
|
-
<td width="30%" align="center" valign="top">
|
|
154
|
-
<sub><i>The final go/no-go for launch.</i></sub>
|
|
155
|
-
</td>
|
|
156
|
-
<td width="70%" valign="top">
|
|
157
|
-
Stationed at the final checkpoint, Verification holds the ultimate authority on launch readiness. No plan proceeds to execution without their strict clearance. They run every procedure through a rigorous checklist, ensuring zero blockers and absolute precision. If the telemetry is off, the plan is returned. There are no shortcuts past Verification.
|
|
158
|
-
</td>
|
|
159
|
-
</tr>
|
|
160
|
-
<tr>
|
|
161
|
-
<td colspan="2">
|
|
162
|
-
<b>Role:</b> <code>Plan verification and quality assurance</code>
|
|
163
|
-
</td>
|
|
164
|
-
</tr>
|
|
165
|
-
<tr>
|
|
166
|
-
<td colspan="2">
|
|
167
|
-
<b>Prompt:</b> <a href="src/agents/verification.ts"><code>verification.ts</code></a>
|
|
168
|
-
</td>
|
|
169
|
-
</tr>
|
|
170
|
-
<tr>
|
|
171
|
-
<td colspan="2">
|
|
172
|
-
<b>Recommended Models:</b> <code>openai/gpt-5.2-codex</code> <code>kimi-for-coding/k2p5</code>
|
|
173
|
-
</td>
|
|
174
|
-
</tr>
|
|
175
|
-
</table>
|
|
176
|
-
|
|
177
|
-
---
|
|
178
|
-
|
|
179
|
-
### The Engineering Teams
|
|
180
|
-
|
|
181
|
-
*Those who explore, advise, and execute once the plan is authorized.*
|
|
182
|
-
|
|
183
|
-
|
|
184
|
-
---
|
|
185
|
-
|
|
186
|
-
### 04. Orchestrator: The Flight Director
|
|
187
|
-
|
|
188
|
-
<table>
|
|
189
|
-
<tr>
|
|
190
|
-
<td width="30%" align="center" valign="top">
|
|
191
|
-
<sub><i>Commands the mission from the central console.</i></sub>
|
|
192
|
-
</td>
|
|
193
|
-
<td width="70%" valign="top">
|
|
194
|
-
When the flight plan is cleared, the Orchestrator takes the central console. They command the workflow, delegating tasks to the specialized engineering teams. They balance execution speed, code quality, and computational cost with the precision of a seasoned mission commander.
|
|
195
|
-
</td>
|
|
196
|
-
</tr>
|
|
197
|
-
<tr>
|
|
198
|
-
<td colspan="2">
|
|
199
|
-
<b>Role:</b> <code>Master delegator and strategic coordinator</code>
|
|
200
|
-
</td>
|
|
201
|
-
</tr>
|
|
202
|
-
<tr>
|
|
203
|
-
<td colspan="2">
|
|
204
|
-
<b>Prompt:</b> <a href="src/agents/orchestrator.ts"><code>orchestrator.ts</code></a>
|
|
205
|
-
</td>
|
|
206
|
-
</tr>
|
|
207
|
-
<tr>
|
|
208
|
-
<td colspan="2">
|
|
209
|
-
<b>Recommended Models:</b> <code>kimi-for-coding/k2p5</code> <code>openai/gpt-5.2-codex</code>
|
|
210
|
-
</td>
|
|
211
|
-
</tr>
|
|
212
|
-
</table>
|
|
213
|
-
|
|
214
|
-
---
|
|
215
|
-
|
|
216
|
-
### 05. Explorer: The Telemetry Scout
|
|
217
|
-
|
|
218
|
-
<table>
|
|
219
|
-
<tr>
|
|
220
|
-
<td width="30%" align="center" valign="top">
|
|
221
|
-
<sub><i>Navigates the deepest system paths.</i></sub>
|
|
222
|
-
</td>
|
|
223
|
-
<td width="70%" valign="top">
|
|
224
|
-
The Explorer is a rapid-response data retrieval specialist. They traverse massive codebases to map unchartered modules, scan for legacy patterns, and retrieve critical context that would take an engineer days to find manually. No file remains unfound, no configuration unrecognized.
|
|
225
|
-
</td>
|
|
226
|
-
</tr>
|
|
227
|
-
<tr>
|
|
228
|
-
<td colspan="2">
|
|
229
|
-
<b>Role:</b> <code>Codebase reconnaissance</code>
|
|
230
|
-
</td>
|
|
231
|
-
</tr>
|
|
232
|
-
<tr>
|
|
233
|
-
<td colspan="2">
|
|
234
|
-
<b>Prompt:</b> <a href="src/agents/explorer.ts"><code>explorer.ts</code></a>
|
|
235
|
-
</td>
|
|
236
|
-
</tr>
|
|
237
|
-
<tr>
|
|
238
|
-
<td colspan="2">
|
|
239
|
-
<b>Recommended Models:</b> <code>cerebras/zai-glm-4.7</code> <code>google/gemini-3-flash</code> <code>openai/gpt-5.1-codex-mini</code>
|
|
240
|
-
</td>
|
|
241
|
-
</tr>
|
|
242
|
-
</table>
|
|
243
|
-
|
|
244
|
-
---
|
|
245
|
-
|
|
246
|
-
### 06. Oracle: The Principal Architect
|
|
247
|
-
|
|
248
|
-
<table>
|
|
249
|
-
<tr>
|
|
250
|
-
<td width="30%" align="center" valign="top">
|
|
251
|
-
<sub><i>The ultimate technical authority.</i></sub>
|
|
252
|
-
</td>
|
|
253
|
-
<td width="70%" valign="top">
|
|
254
|
-
The Oracle is the senior advisor for mission-critical architectural decisions. They understand the long-term impact of deep system refactors and complex dependencies. When you hit a roadblock that threatens the entire stack, the Oracle provides the definitive guidance needed to recover and advance.
|
|
255
|
-
</td>
|
|
256
|
-
</tr>
|
|
257
|
-
<tr>
|
|
258
|
-
<td colspan="2">
|
|
259
|
-
<b>Role:</b> <code>Strategic advisor and debugger of last resort</code>
|
|
260
|
-
</td>
|
|
261
|
-
</tr>
|
|
262
|
-
<tr>
|
|
263
|
-
<td colspan="2">
|
|
264
|
-
<b>Prompt:</b> <a href="src/agents/oracle.ts"><code>oracle.ts</code></a>
|
|
265
|
-
</td>
|
|
266
|
-
</tr>
|
|
267
|
-
<tr>
|
|
268
|
-
<td colspan="2">
|
|
269
|
-
<b>Recommended Models:</b> <code>openai/gpt-5.2-codex</code> <code>kimi-for-coding/k2p5</code>
|
|
270
|
-
</td>
|
|
271
|
-
</tr>
|
|
272
|
-
</table>
|
|
273
|
-
|
|
274
|
-
---
|
|
275
|
-
|
|
276
|
-
### 07. Librarian: The Data Archivist
|
|
277
|
-
|
|
278
|
-
<table>
|
|
279
|
-
<tr>
|
|
280
|
-
<td width="30%" align="center" valign="top">
|
|
281
|
-
<sub><i>Retrieves the official documentation.</i></sub>
|
|
282
|
-
</td>
|
|
283
|
-
<td width="70%" valign="top">
|
|
284
|
-
The Librarian maintains the external knowledge base. They scan official documentation, recent API changes, and trusted open-source examples to provide the exact specifications required for implementation. They ensure that all external integrations meet the latest official standards.
|
|
285
|
-
</td>
|
|
286
|
-
</tr>
|
|
287
|
-
<tr>
|
|
288
|
-
<td colspan="2">
|
|
289
|
-
<b>Role:</b> <code>External knowledge retrieval</code>
|
|
290
|
-
</td>
|
|
291
|
-
</tr>
|
|
292
|
-
<tr>
|
|
293
|
-
<td colspan="2">
|
|
294
|
-
<b>Prompt:</b> <a href="src/agents/librarian.ts"><code>librarian.ts</code></a>
|
|
295
|
-
</td>
|
|
296
|
-
</tr>
|
|
297
|
-
<tr>
|
|
298
|
-
<td colspan="2">
|
|
299
|
-
<b>Recommended Models:</b> <code>google/gemini-3-flash</code> <code>openai/gpt-5.1-codex-mini</code>
|
|
300
|
-
</td>
|
|
301
|
-
</tr>
|
|
302
|
-
</table>
|
|
303
|
-
|
|
304
|
-
---
|
|
305
|
-
|
|
306
|
-
### 08. Designer: The Interface Specialist
|
|
307
|
-
|
|
308
|
-
<table>
|
|
309
|
-
<tr>
|
|
310
|
-
<td width="30%" align="center" valign="top">
|
|
311
|
-
<sub><i>Polishes the user experience.</i></sub>
|
|
312
|
-
</td>
|
|
313
|
-
<td width="70%" valign="top">
|
|
314
|
-
The Designer is focused purely on human-computer interaction and visual polish. They craft the interfaces, components, and layouts that users actually see. In a world of raw data and logic, they ensure the final product is intuitive, responsive, and seamlessly functional.
|
|
315
|
-
</td>
|
|
316
|
-
</tr>
|
|
317
|
-
<tr>
|
|
318
|
-
<td colspan="2">
|
|
319
|
-
<b>Role:</b> <code>UI/UX implementation and visual excellence</code>
|
|
320
|
-
</td>
|
|
321
|
-
</tr>
|
|
322
|
-
<tr>
|
|
323
|
-
<td colspan="2">
|
|
324
|
-
<b>Prompt:</b> <a href="src/agents/designer.ts"><code>designer.ts</code></a>
|
|
325
|
-
</td>
|
|
326
|
-
</tr>
|
|
327
|
-
<tr>
|
|
328
|
-
<td colspan="2">
|
|
329
|
-
<b>Recommended Models:</b> <code>google/gemini-3-flash</code>
|
|
330
|
-
</td>
|
|
331
|
-
</tr>
|
|
332
|
-
</table>
|
|
333
|
-
|
|
334
|
-
---
|
|
335
|
-
|
|
336
|
-
### 09. Fixer: The Systems Integrator
|
|
337
|
-
|
|
338
|
-
<table>
|
|
339
|
-
<tr>
|
|
340
|
-
<td width="30%" align="center" valign="top">
|
|
341
|
-
<sub><i>Writes the code, tightens the bolts.</i></sub>
|
|
342
|
-
</td>
|
|
343
|
-
<td width="70%" valign="top">
|
|
344
|
-
The Fixer is the dedicated execution engine. When the plan is finalized and the architecture is set, the Fixer writes the implementation. They are the hands-on developers who turn the blueprint into functional, robust software capable of passing all launch parameters.
|
|
345
|
-
</td>
|
|
346
|
-
</tr>
|
|
347
|
-
<tr>
|
|
348
|
-
<td colspan="2">
|
|
349
|
-
<b>Role:</b> <code>Fast implementation specialist</code>
|
|
350
|
-
</td>
|
|
351
|
-
</tr>
|
|
352
|
-
<tr>
|
|
353
|
-
<td colspan="2">
|
|
354
|
-
<b>Prompt:</b> <a href="src/agents/fixer.ts"><code>fixer.ts</code></a>
|
|
355
|
-
</td>
|
|
356
|
-
</tr>
|
|
357
|
-
<tr>
|
|
358
|
-
<td colspan="2">
|
|
359
|
-
<b>Recommended Models:</b> <code>cerebras/zai-glm-4.7</code> <code>google/gemini-3-flash</code> <code>openai/gpt-5.1-codex-mini</code>
|
|
360
|
-
</td>
|
|
361
|
-
</tr>
|
|
362
|
-
</table>
|
|
363
|
-
|
|
364
|
-
---
|
|
365
|
-
|
|
366
|
-
## 📚 Documentation
|
|
367
|
-
|
|
368
|
-
- **[Quick Reference](docs/quick-reference.md)** - Presets, Skills, MCPs, Tools, Configuration
|
|
369
|
-
- **[Installation Guide](docs/installation.md)** - Detailed installation and troubleshooting
|
|
370
|
-
- **[Cartography Skill](docs/cartography.md)** - Custom skill for repository mapping + codemap generation
|
|
371
|
-
- **[Antigravity Setup](docs/antigravity.md)** - Complete guide for Antigravity provider configuration
|
|
372
|
-
- **[Tmux Integration](docs/tmux-integration.md)** - Real-time agent monitoring with tmux
|
|
87
|
+
## Reference Documentation
|
|
373
88
|
|
|
374
|
-
|
|
89
|
+
- [Quick Reference](docs/quick-reference.md): Presets, Skills, MCPs, Tools, Configuration
|
|
90
|
+
- [Installation Guide](docs/installation.md): Detailed installation and troubleshooting
|
|
91
|
+
- [Cartography Skill](docs/cartography.md): Custom skill for repository mapping + codemap generation
|
|
92
|
+
- [Antigravity Setup](docs/antigravity.md): Complete guide for Antigravity provider configuration
|
|
93
|
+
- [Tmux Integration](docs/tmux-integration.md): Real-time agent monitoring with tmux
|
|
375
94
|
|
|
376
|
-
##
|
|
95
|
+
## License
|
|
377
96
|
|
|
378
97
|
MIT
|
package/dist/index.js
CHANGED
|
@@ -21078,7 +21078,10 @@ Can tasks run simultaneously?
|
|
|
21078
21078
|
Balance: respect dependencies, avoid parallelizing what must be sequential.
|
|
21079
21079
|
|
|
21080
21080
|
## 5. Execute
|
|
21081
|
-
1.
|
|
21081
|
+
1. **MANDATORY: REGISTER TODO LIST IMMEDIATELY (NON-NEGOTIABLE)**
|
|
21082
|
+
- When executing a multi-step work plan or complex request, you MUST use the \`todowrite\` tool FIRST.
|
|
21083
|
+
- Do this exactly ONCE at the start of execution to prevent looping.
|
|
21084
|
+
- Do not begin delegation or implementation until the todo list is registered.
|
|
21082
21085
|
2. Fire parallel research/implementation
|
|
21083
21086
|
3. Delegate to specialists or do it yourself based on step 3
|
|
21084
21087
|
4. Integrate results
|
|
@@ -23164,13 +23167,13 @@ function createAutoUpdateCheckerHook(ctx, options = {}) {
|
|
|
23164
23167
|
const displayVersion = localDevVersion ?? cachedVersion;
|
|
23165
23168
|
if (localDevVersion) {
|
|
23166
23169
|
if (showStartupToast) {
|
|
23167
|
-
showToast(ctx, `
|
|
23170
|
+
showToast(ctx, `OM-Groundcontrol ${displayVersion} (dev)`, "Running in local development mode.", "info");
|
|
23168
23171
|
}
|
|
23169
23172
|
log("[auto-update-checker] Local development mode");
|
|
23170
23173
|
return;
|
|
23171
23174
|
}
|
|
23172
23175
|
if (showStartupToast) {
|
|
23173
|
-
showToast(ctx, `
|
|
23176
|
+
showToast(ctx, `OM-Groundcontrol ${displayVersion ?? "unknown"}`, "oh-my-groundcontrol is active.", "info");
|
|
23174
23177
|
}
|
|
23175
23178
|
runBackgroundUpdateCheck(ctx, autoUpdate).catch((err) => {
|
|
23176
23179
|
log("[auto-update-checker] Background update check failed:", err);
|
|
@@ -23203,14 +23206,14 @@ async function runBackgroundUpdateCheck(ctx, autoUpdate) {
|
|
|
23203
23206
|
}
|
|
23204
23207
|
log(`[auto-update-checker] Update available (${channel}): ${currentVersion} \u2192 ${latestVersion}`);
|
|
23205
23208
|
if (!autoUpdate) {
|
|
23206
|
-
showToast(ctx, `
|
|
23209
|
+
showToast(ctx, `OM-Groundcontrol ${latestVersion}`, `v${latestVersion} available. Restart to apply.`, "info", 8000);
|
|
23207
23210
|
log("[auto-update-checker] Auto-update disabled, notification only");
|
|
23208
23211
|
return;
|
|
23209
23212
|
}
|
|
23210
23213
|
if (pluginInfo.isPinned) {
|
|
23211
23214
|
const updated = updatePinnedVersion(pluginInfo.configPath, pluginInfo.entry, latestVersion);
|
|
23212
23215
|
if (!updated) {
|
|
23213
|
-
showToast(ctx, `
|
|
23216
|
+
showToast(ctx, `OM-Groundcontrol ${latestVersion}`, `v${latestVersion} available. Restart to apply.`, "info", 8000);
|
|
23214
23217
|
log("[auto-update-checker] Failed to update pinned version in config");
|
|
23215
23218
|
return;
|
|
23216
23219
|
}
|
|
@@ -23219,11 +23222,11 @@ async function runBackgroundUpdateCheck(ctx, autoUpdate) {
|
|
|
23219
23222
|
invalidatePackage(PACKAGE_NAME);
|
|
23220
23223
|
const installSuccess = await runBunInstallSafe(ctx);
|
|
23221
23224
|
if (installSuccess) {
|
|
23222
|
-
showToast(ctx, "
|
|
23225
|
+
showToast(ctx, "OM-Groundcontrol Updated!", `v${currentVersion} \u2192 v${latestVersion}
|
|
23223
23226
|
Restart OpenCode to apply.`, "success", 8000);
|
|
23224
23227
|
log(`[auto-update-checker] Update installed: ${currentVersion} \u2192 ${latestVersion}`);
|
|
23225
23228
|
} else {
|
|
23226
|
-
showToast(ctx, `
|
|
23229
|
+
showToast(ctx, `OM-Groundcontrol ${latestVersion}`, `v${latestVersion} available. Restart to apply.`, "info", 8000);
|
|
23227
23230
|
log("[auto-update-checker] bun install failed; update not installed");
|
|
23228
23231
|
}
|
|
23229
23232
|
}
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@frenchtoastman/oh-my-groundcontrol",
|
|
3
|
-
"version": "0.0.
|
|
3
|
+
"version": "0.0.14",
|
|
4
4
|
"description": "An OpenCode plugin for multi-agent orchestration for structured planning with NASA-style guardrails.",
|
|
5
5
|
"main": "dist/index.js",
|
|
6
6
|
"types": "dist/index.d.ts",
|
|
@@ -0,0 +1,87 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: commit-protocol
|
|
3
|
+
description: Write concise commit messages with required type(scope) prefix based on current changes and user input.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Commit Protocol Skill
|
|
7
|
+
|
|
8
|
+
You enforce a strict, NASA-inspired "Traceability First" format for git commit messages.
|
|
9
|
+
|
|
10
|
+
## When to Use
|
|
11
|
+
|
|
12
|
+
**Always active.** You MUST use this exact format every time you create a git commit.
|
|
13
|
+
|
|
14
|
+
## Protocol Template
|
|
15
|
+
|
|
16
|
+
All commits must exactly match the following structure. Pay strict attention to the character limits.
|
|
17
|
+
|
|
18
|
+
```
|
|
19
|
+
type(Component): <Brief, imperative summary under 50 chars>
|
|
20
|
+
|
|
21
|
+
Description:
|
|
22
|
+
<Brief 1-2 sentence explanation of why this change is necessary and what it accomplishes. Wrapped at 72 chars.>
|
|
23
|
+
|
|
24
|
+
Changes:
|
|
25
|
+
- <Change 1>
|
|
26
|
+
- <Change 2>
|
|
27
|
+
|
|
28
|
+
Traceability:
|
|
29
|
+
- Traces to: [Issue # / REQ ID / None]
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
### 1. Type
|
|
33
|
+
Must be one of the following:
|
|
34
|
+
- `feat`: A new feature
|
|
35
|
+
- `fix`: A bug fix
|
|
36
|
+
- `docs`: Documentation only changes
|
|
37
|
+
- `style`: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
|
|
38
|
+
- `refactor`: A code change that neither fixes a bug nor adds a feature
|
|
39
|
+
- `test`: Adding missing tests or correcting existing tests
|
|
40
|
+
- `chore`: Changes to the build process or auxiliary tools and libraries such as documentation generation
|
|
41
|
+
|
|
42
|
+
### 2. Component
|
|
43
|
+
The module or component being modified.
|
|
44
|
+
- If modifying a specific component, use its name (e.g., `api`, `ui`, `auth`).
|
|
45
|
+
- If the commit spans multiple components or is repository-wide, use `(global)` or `(core)`.
|
|
46
|
+
|
|
47
|
+
### 3. Summary Line
|
|
48
|
+
- Must use imperative mood ("Add feature", not "Added feature").
|
|
49
|
+
- Must not end with a period.
|
|
50
|
+
- Must be strictly under 50 characters (including the `type(Component): ` prefix).
|
|
51
|
+
|
|
52
|
+
### 4. Description
|
|
53
|
+
- Explain *why* the change is necessary and *what* it accomplishes.
|
|
54
|
+
- Wrap text at 72 characters.
|
|
55
|
+
|
|
56
|
+
### 5. Changes
|
|
57
|
+
- A bulleted list of the specific technical changes made.
|
|
58
|
+
|
|
59
|
+
### 6. Traceability
|
|
60
|
+
- If resolving a specific issue or requirement, state it (e.g., `Issue #42` or `REQ-001`).
|
|
61
|
+
- If no specific tracking ID exists, state `None`.
|
|
62
|
+
|
|
63
|
+
## Examples
|
|
64
|
+
|
|
65
|
+
### Good Example
|
|
66
|
+
```
|
|
67
|
+
fix(auth): Prevent token leak on session timeout
|
|
68
|
+
|
|
69
|
+
Description:
|
|
70
|
+
The previous implementation kept the JWT in memory after the session
|
|
71
|
+
timeout event fired, leaving a brief window where it could be extracted.
|
|
72
|
+
|
|
73
|
+
Changes:
|
|
74
|
+
- Cleared token state immediately on timeout event trigger
|
|
75
|
+
- Added test coverage for session expiry cleanup
|
|
76
|
+
|
|
77
|
+
Traceability:
|
|
78
|
+
- Traces to: Issue #128
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
### Bad Example (Do Not Do This)
|
|
82
|
+
```
|
|
83
|
+
Fixed a bug in the auth system where tokens were leaking
|
|
84
|
+
|
|
85
|
+
I went in and found that the JWT was staying in memory after the session timed out. I fixed it by clearing the state earlier. Also added some tests.
|
|
86
|
+
```
|
|
87
|
+
*(Reason: Missing type, component, description block, bulleted changes, traceability, and summary exceeds 50 chars).*
|