@frenchtoastman/oh-my-groundcontrol 0.0.11 → 0.0.13

package/README.md

@@ -86,7 +86,7 @@ The principles driving our agent behavior are extracted directly from the [NASA
 
 ---
 
-### 01. Contractor: The Lead Systems Engineer
+### 01. Groundcontrol: The Lead Systems Engineer
 
 <table>
   <tr>
@@ -94,7 +94,7 @@ The principles driving our agent behavior are extracted directly from the [NASA
       <sub><i>Designs the mission architecture.</i></sub>
     </td>
     <td width="70%" valign="top">
-      Operating from the engineering drafting boards, the Contractor 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.
+      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.
     </td>
   </tr>
   <tr>
@@ -104,7 +104,7 @@ The principles driving our agent behavior are extracted directly from the [NASA
   </tr>
   <tr>
     <td colspan="2">
-      <b>Prompt:</b> <a href="src/agents/contractor/index.ts"><code>contractor/index.ts</code></a>
+      <b>Prompt:</b> <a href="src/agents/groundcontrol/index.ts"><code>contractor/index.ts</code></a>
     </td>
   </tr>
   <tr>
@@ -116,7 +116,7 @@ The principles driving our agent behavior are extracted directly from the [NASA
 
 ---
 
-### 03. PreFlight: The Risk Analyst
+### 02. PreFlight: The Risk Analyst
 
 <table>
   <tr>
@@ -146,7 +146,7 @@ The principles driving our agent behavior are extracted directly from the [NASA
 
 ---
 
-### 04. Verification: The Launch Committer
+### 03. Verification: The Launch Committer
 
 <table>
   <tr>
@@ -183,7 +183,7 @@ The principles driving our agent behavior are extracted directly from the [NASA
 
 ---
 
-### 05. Orchestrator: The Flight Director
+### 04. Orchestrator: The Flight Director
 
 <table>
   <tr>
@@ -213,7 +213,7 @@ The principles driving our agent behavior are extracted directly from the [NASA
 
 ---
 
-### 06. Explorer: The Telemetry Scout
+### 05. Explorer: The Telemetry Scout
 
 <table>
   <tr>
@@ -243,7 +243,7 @@ The principles driving our agent behavior are extracted directly from the [NASA
 
 ---
 
-### 07. Oracle: The Principal Architect
+### 06. Oracle: The Principal Architect
 
 <table>
   <tr>
@@ -273,7 +273,7 @@ The principles driving our agent behavior are extracted directly from the [NASA
 
 ---
 
-### 08. Librarian: The Data Archivist
+### 07. Librarian: The Data Archivist
 
 <table>
   <tr>
@@ -303,7 +303,7 @@ The principles driving our agent behavior are extracted directly from the [NASA
 
 ---
 
-### 09. Designer: The Interface Specialist
+### 08. Designer: The Interface Specialist
 
 <table>
   <tr>
@@ -333,7 +333,7 @@ The principles driving our agent behavior are extracted directly from the [NASA
 
 ---
 
-### 10. Fixer: The Systems Integrator
+### 09. Fixer: The Systems Integrator
 
 <table>
   <tr>

package/dist/index.js

@@ -20936,6 +20936,11 @@ var ORACLE_PROMPT = `You are Oracle - a strategic technical advisor.
 - Focus on strategy, not execution
 - Point to specific files/lines when relevant
 
+**Root Cause Analysis (5 Whys)**:
+- When investigating complex, recurring, or systemic bugs, explicitly execute a formal "5 Whys" Root Cause Analysis.
+- Present this as a numbered list, drilling down 5 layers past the symptom to identify the core architectural or process failure.
+- *Early Exit*: Do not use 5 Whys for simple syntax errors, obvious typos, or known external service outages.
+
 **NASA Guardrails (High-Reliability Mode)**:
 - **Destructive Pause**: Stop and request explicit user confirmation before irreversible actions (e.g., force pushing, bulk deletions).
 - **Pre-Flight Verification**: Always run linters/typechecks (\`bun run check:ci\`, \`bun run typecheck\`) to validate changes before concluding.
@@ -21437,6 +21442,15 @@ Architecture | Research]
 
 ---
 
+## INTERNAL REASONING: INVISIBLE 5 WHYS
+
+When gathering requirements or defining scope, adopt a "5 Whys" mindset to uncover the root intent behind a user's request (e.g., if they ask for a caching layer, determine if the root issue is an N+1 query).
+- **MUST**: Use internal Chain-of-Thought (or careful lateral questioning) to drill down up to 5 layers deep to find the true requirement.
+- **MUST NOT**: Literally ask the user "Why?" repeatedly. Do not badger the user.
+- **EXIT STRATEGY**: If the root cause is obvious, or if the user explicitly demands immediate execution ("just build it"), abort the probing and proceed with current context.
+
+---
+
 ## CRITICAL RULES
 
 **NEVER**:
@@ -21556,6 +21570,11 @@ is enough.
 **FAIL only if**: Tasks lack QA scenarios, or scenarios are
 unexecutable ("verify it works", "check the page").
 
+### 5. Assumption Stress-Testing (Invisible 5 Whys)
+- Internally use a "5 Whys" approach to stress-test the plan's assumptions (e.g., "Why will this step succeed? Because the API is available. Why is it available?").
+- Use this strictly as an internal mental model to identify fragile logical leaps.
+- Do not output the 5 Whys in your response. Only flag a BLOCKER if the assumption fails critically.
+
 ---
 
 ## What You Do NOT Check
@@ -21719,6 +21738,8 @@ need figuring out. Fail only if zero context.
 **Critical blockers**: Missing info that would completely stop work,
 or contradictions. Minor ambiguities are NOT blockers.
 
+**Assumption stress-testing (Invisible 5 Whys)**: Internally use a 5 Whys approach to stress-test plan assumptions. Do not output the 5 Whys. Only flag if an assumption fails critically.
+
 **QA scenario executability**: Does each task have QA scenarios with
 tool + steps + expected results? Missing or vague QA scenarios are
 blockers.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@frenchtoastman/oh-my-groundcontrol",
-  "version": "0.0.11",
+  "version": "0.0.13",
   "description": "An OpenCode plugin for multi-agent orchestration for structured planning with NASA-style guardrails.",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",

package/src/skills/commit-protocol/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: commit-protocol
+description: Write concise commit messages with required type(scope) prefix based on current changes and user input.
+---
+
+# Commit Protocol Skill
+
+You enforce a strict, NASA-inspired "Traceability First" format for git commit messages.
+
+## When to Use
+
+**Always active.** You MUST use this exact format every time you create a git commit. 
+
+## Protocol Template
+
+All commits must exactly match the following structure. Pay strict attention to the character limits.
+
+```
+type(Component): <Brief, imperative summary under 50 chars>
+
+Description:
+<Brief 1-2 sentence explanation of why this change is necessary and what it accomplishes. Wrapped at 72 chars.>
+
+Changes:
+- <Change 1>
+- <Change 2>
+
+Traceability:
+- Traces to: [Issue # / REQ ID / None]
+```
+
+### 1. Type
+Must be one of the following:
+- `feat`: A new feature
+- `fix`: A bug fix
+- `docs`: Documentation only changes
+- `style`: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
+- `refactor`: A code change that neither fixes a bug nor adds a feature
+- `test`: Adding missing tests or correcting existing tests
+- `chore`: Changes to the build process or auxiliary tools and libraries such as documentation generation
+
+### 2. Component
+The module or component being modified. 
+- If modifying a specific component, use its name (e.g., `api`, `ui`, `auth`).
+- If the commit spans multiple components or is repository-wide, use `(global)` or `(core)`.
+
+### 3. Summary Line
+- Must use imperative mood ("Add feature", not "Added feature").
+- Must not end with a period.
+- Must be strictly under 50 characters (including the `type(Component): ` prefix).
+
+### 4. Description
+- Explain *why* the change is necessary and *what* it accomplishes.
+- Wrap text at 72 characters.
+
+### 5. Changes
+- A bulleted list of the specific technical changes made.
+
+### 6. Traceability
+- If resolving a specific issue or requirement, state it (e.g., `Issue #42` or `REQ-001`).
+- If no specific tracking ID exists, state `None`.
+
+## Examples
+
+### Good Example
+```
+fix(auth): Prevent token leak on session timeout
+
+Description:
+The previous implementation kept the JWT in memory after the session 
+timeout event fired, leaving a brief window where it could be extracted.
+
+Changes:
+- Cleared token state immediately on timeout event trigger
+- Added test coverage for session expiry cleanup
+
+Traceability:
+- Traces to: Issue #128
+```
+
+### Bad Example (Do Not Do This)
+```
+Fixed a bug in the auth system where tokens were leaking
+
+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.
+```
+*(Reason: Missing type, component, description block, bulleted changes, traceability, and summary exceeds 50 chars).*