jumbo-cli 2.0.1 → 2.0.3

package/assets/skills/refine-jumbo-goals/SKILL.md

@@ -1,156 +1,156 @@
----
-name: refine-jumbo-goals
-description: Use when Jumbo goals need refinement before implementation. Curates relations to project entities so the implementing agent receives optimal architectural context.
----
-
-# Refine Jumbo Goals
-
-**Prompt:** Refine one or more Jumbo goals by registering comprehensive relations to project entities so that an autonomous agent has optimal context for correct implementation.
-
-## Why Refinement Matters
-
-When `jumbo goal start` is run, the goal's registered relations determine what context is assembled and provided to the implementing agent. Missing relations mean missing constraints, patterns, or domain knowledge. Irrelevant relations waste tokens and dilute focus. Thorough refinement is the single highest-leverage activity for autonomous goal execution quality.
-
-## Protocol
-
-### 1. Initiate Refinement
-
-```bash
-jumbo goal refine --id <goal-id>
-```
-
-Review the goal's objective, criteria, and scope.
-
-### 2. Explore All Project Entities
-
-You MUST explore ALL entity categories to build a complete picture of available entities:
-
-```bash
-jumbo invariants list
-jumbo guidelines list
-jumbo decisions list
-jumbo dependencies list
-jumbo architecture view
-```
-
-For **components**, use targeted searches instead of dumping the full list. Extract keywords from the goal's objective and criteria, then search:
-
-```bash
-# Search by name (substring or wildcard)
-jumbo components search --name "Auth*"
-jumbo components search --name "*Gateway"
-
-# Search by type
-jumbo components search --type service
-jumbo components search --type lib
-
-# Free-text search across description and responsibility
-jumbo components search --query "event handling"
-
-# Compact output for quick discovery (id, name, type only)
-jumbo components search --output compact --type service
-
-# Combine filters (AND logic)
-jumbo components search --name "*Controller" --type service
-```
-
-Run multiple targeted searches derived from the goal's domain. Only fall back to `jumbo components list` if searches are insufficient to identify all relevant components.
-
-Do not skip any entity category. Every category is a potential source of implementation context.
-
-### 3. Evaluate Every Entity Against the Goal
-
-For each entity returned, ask: **"Will the implementing agent need to know about this to execute correctly?"**
-
-Only register relations that are directly relevant. Do not register entities that are tangentially related or that add context without actionable value.
-
-Evaluate systematically by category:
-
-- **Invariants**: Which non-negotiable constraints does this implementation touch, cross, or risk violating?
-- **Guidelines**: Which coding standards, testing requirements, or process practices apply?
-- **Decisions**: Which architectural decisions inform, motivate, or constrain this change?
-- **Components**: Which system components will be created, modified, deleted, or depended upon?
-- **Dependencies**: Which external libraries are involved in the implementation?
-
-### 4. Register Relations
-
-For every relevant entity, register a relation:
-
-```bash
-jumbo relation add \
-  --from-type goal \
-  --from-id <goal-id> \
-  --to-type <entity-type> \
-  --to-id <entity-id> \
-  --relation-type <type> \
-  --description "<why this relation matters for implementation>"
-```
-
-**Relation types:**
-
-| Type | Use When |
-|------|----------|
-| `involves` | Implementation will modify or directly interact with this entity |
-| `uses` | Implementation depends on or references this entity |
-| `must-respect` | Implementation must adhere to this constraint or decision |
-| `follows` | Implementation must follow this practice or standard |
-| `implements` | Implementation applies or realizes this architectural decision |
-
-**Description quality is critical.** The description is what the implementing agent reads. It must explain the specific relevance to this goal, not just restate the entity's title.
-
-- BAD: "Related to this invariant"
-- BAD: "Must follow this guideline"
-- GOOD: "Removal must not leave orphaned registrations or broken import paths across layer boundaries"
-- GOOD: "Ensure the read-side query path remains intact after removing the old handler"
-
-### 5. Update Goal Metadata
-
-During entity exploration, you may discover:
-- Additional files that belong in scope
-- Files that should be created or modified
-- Risk of scope creep
-- Success criteria that need updating
-- Applicable refactoring skills to reference in criteria (prefix with `skill:`)
-- Registered goals that should be added as prerequisites or follow-ups
-
-Update the goal accordingly:
-
-```bash
-jumbo goal update --id <goal-id> \
-  --criteria "Updated criteria" \
-  --scope-in "additional/file/path.ts" \
-  --scope-out "namespace/" "a/file/to-not-touch.ts" \
-  --previous-goal <previous-goal-id> \
-  --next-goal <next-goal-id> \
-  --prerequisite-goals <goalIds...>
-```
-
-### 6. Verify Completeness
-
-Before approving, verify ALL of the following:
-
-- [ ] Every entity category was explored (no categories skipped)
-- [ ] Relevant invariants are linked (most goals require 2+ invariant relations)
-- [ ] Testing-related guidelines are linked (almost every goal has testing implications)
-- [ ] Architectural decisions that inform or constrain the approach are linked
-- [ ] All components being modified, created, deleted, or depended upon are linked
-- [ ] Every relation description explains the specific relevance, not just the entity name
-- [ ] Goal criteria and scope reflect any discoveries made during refinement
-- [ ] The goal has at least 5 relations total (fewer suggests incomplete analysis)
-
-### 7. Approve Refinement
-
-Only after completing all verification checks:
-
-```bash
-jumbo goal refine --id <goal-id> --approve
-```
-
-## Rules
-
-1. **Never approve with fewer than 5 relations** unless the goal is trivially scoped. If you cannot find 5 relevant entities, re-examine your analysis.
-2. **Never skip an entity category.** Explore all entity types every time. For components, prefer targeted `jumbo components search` queries over `jumbo components list`. Entity registrations change between sessions.
-3. **Never write vague descriptions.** Every relation description must be actionable guidance for the implementing agent.
-4. **Always link testing guidelines.** Implementation without testing context produces untested code.
-5. **Always link components that prove safety.** When deleting or replacing code, link the replacement component so the agent can verify the change is safe.
-6. **Treat skill references as first-class criteria.** If a refactoring skill applies, add `skill:<skill-name>` to the goal's criteria so the implementing agent loads it.
+---
+name: refine-jumbo-goals
+description: Use when Jumbo goals need refinement before implementation. Curates relations to project entities so the implementing agent receives optimal architectural context.
+---
+
+# Refine Jumbo Goals
+
+**Prompt:** Refine one or more Jumbo goals by registering comprehensive relations to project entities so that an autonomous agent has optimal context for correct implementation.
+
+## Why Refinement Matters
+
+When `jumbo goal start` is run, the goal's registered relations determine what context is assembled and provided to the implementing agent. Missing relations mean missing constraints, patterns, or domain knowledge. Irrelevant relations waste tokens and dilute focus. Thorough refinement is the single highest-leverage activity for autonomous goal execution quality.
+
+## Protocol
+
+### 1. Initiate Refinement
+
+```bash
+jumbo goal refine --id <goal-id>
+```
+
+Review the goal's objective, criteria, and scope.
+
+### 2. Explore All Project Entities
+
+You MUST explore ALL entity categories to build a complete picture of available entities:
+
+```bash
+jumbo invariants list
+jumbo guidelines list
+jumbo decisions list
+jumbo dependencies list
+jumbo architecture view
+```
+
+For **components**, use targeted searches instead of dumping the full list. Extract keywords from the goal's objective and criteria, then search:
+
+```bash
+# Search by name (substring or wildcard)
+jumbo components search --name "Auth*"
+jumbo components search --name "*Gateway"
+
+# Search by type
+jumbo components search --type service
+jumbo components search --type lib
+
+# Free-text search across description and responsibility
+jumbo components search --query "event handling"
+
+# Compact output for quick discovery (id, name, type only)
+jumbo components search --output compact --type service
+
+# Combine filters (AND logic)
+jumbo components search --name "*Controller" --type service
+```
+
+Run multiple targeted searches derived from the goal's domain. Only fall back to `jumbo components list` if searches are insufficient to identify all relevant components.
+
+Do not skip any entity category. Every category is a potential source of implementation context.
+
+### 3. Evaluate Every Entity Against the Goal
+
+For each entity returned, ask: **"Will the implementing agent need to know about this to execute correctly?"**
+
+Only register relations that are directly relevant. Do not register entities that are tangentially related or that add context without actionable value.
+
+Evaluate systematically by category:
+
+- **Invariants**: Which non-negotiable constraints does this implementation touch, cross, or risk violating?
+- **Guidelines**: Which coding standards, testing requirements, or process practices apply?
+- **Decisions**: Which architectural decisions inform, motivate, or constrain this change?
+- **Components**: Which system components will be created, modified, deleted, or depended upon?
+- **Dependencies**: Which external libraries are involved in the implementation?
+
+### 4. Register Relations
+
+For every relevant entity, register a relation:
+
+```bash
+jumbo relation add \
+  --from-type goal \
+  --from-id <goal-id> \
+  --to-type <entity-type> \
+  --to-id <entity-id> \
+  --relation-type <type> \
+  --description "<why this relation matters for implementation>"
+```
+
+**Relation types:**
+
+| Type | Use When |
+|------|----------|
+| `involves` | Implementation will modify or directly interact with this entity |
+| `uses` | Implementation depends on or references this entity |
+| `must-respect` | Implementation must adhere to this constraint or decision |
+| `follows` | Implementation must follow this practice or standard |
+| `implements` | Implementation applies or realizes this architectural decision |
+
+**Description quality is critical.** The description is what the implementing agent reads. It must explain the specific relevance to this goal, not just restate the entity's title.
+
+- BAD: "Related to this invariant"
+- BAD: "Must follow this guideline"
+- GOOD: "Removal must not leave orphaned registrations or broken import paths across layer boundaries"
+- GOOD: "Ensure the read-side query path remains intact after removing the old handler"
+
+### 5. Update Goal Metadata
+
+During entity exploration, you may discover:
+- Additional files that belong in scope
+- Files that should be created or modified
+- Risk of scope creep
+- Success criteria that need updating
+- Applicable refactoring skills to reference in criteria (prefix with `skill:`)
+- Registered goals that should be added as prerequisites or follow-ups
+
+Update the goal accordingly:
+
+```bash
+jumbo goal update --id <goal-id> \
+  --criteria "Updated criteria" \
+  --scope-in "additional/file/path.ts" \
+  --scope-out "namespace/" "a/file/to-not-touch.ts" \
+  --previous-goal <previous-goal-id> \
+  --next-goal <next-goal-id> \
+  --prerequisite-goals <goalIds...>
+```
+
+### 6. Verify Completeness
+
+Before approving, verify ALL of the following:
+
+- [ ] Every entity category was explored (no categories skipped)
+- [ ] Relevant invariants are linked (most goals require 2+ invariant relations)
+- [ ] Testing-related guidelines are linked (almost every goal has testing implications)
+- [ ] Architectural decisions that inform or constrain the approach are linked
+- [ ] All components being modified, created, deleted, or depended upon are linked
+- [ ] Every relation description explains the specific relevance, not just the entity name
+- [ ] Goal criteria and scope reflect any discoveries made during refinement
+- [ ] The goal has at least 5 relations total (fewer suggests incomplete analysis)
+
+### 7. Approve Refinement
+
+Only after completing all verification checks:
+
+```bash
+jumbo goal refine --id <goal-id> --approve
+```
+
+## Rules
+
+1. **Never approve with fewer than 5 relations** unless the goal is trivially scoped. If you cannot find 5 relevant entities, re-examine your analysis.
+2. **Never skip an entity category.** Explore all entity types every time. For components, prefer targeted `jumbo components search` queries over `jumbo components list`. Entity registrations change between sessions.
+3. **Never write vague descriptions.** Every relation description must be actionable guidance for the implementing agent.
+4. **Always link testing guidelines.** Implementation without testing context produces untested code.
+5. **Always link components that prove safety.** When deleting or replacing code, link the replacement component so the agent can verify the change is safe.
+6. **Treat skill references as first-class criteria.** If a refactoring skill applies, add `skill:<skill-name>` to the goal's criteria so the implementing agent loads it.

package/assets/skills/reject-jumbo-goal/SKILL.md

@@ -1,58 +1,58 @@
----
-name: reject-jumbo-goal
-description: Use when a Jumbo goal fails QA review and needs to be returned for rework. Records review issues and routes the goal back to the implementing agent with actionable feedback.
----
-
-# Reject Jumbo Goal
-
-**Prompt:** Reject a Jumbo goal that failed QA review, recording the specific issues found so the implementing agent can address them and restart.
-
-## Why Rejection Quality Matters
-
-When a goal is rejected, the implementing agent receives the review issues as its primary guidance for rework. Vague or incomplete rejection feedback causes wasted rework cycles — the agent guesses at what's wrong, fixes the wrong things, and resubmits with the same issues. Precise, actionable rejection feedback is the fastest path to a passing review.
-
-## Protocol
-
-### 1. Document Review Issues
-
-Before rejecting, ensure you have a clear, specific list of every issue found during QA review. Each issue must be:
-
-- **Specific**: Reference exact files, functions, or behaviors that are wrong.
-- **Actionable**: Describe what needs to change, not just what's wrong.
-- **Traceable**: Link back to the success criterion, invariant, or guideline that was violated.
-
-### 2. Reject the Goal
-
-```bash
-jumbo goal reject --id <goal-id> --issues "<detailed review issues>"
-```
-
-The rejection output confirms:
-- The goal ID and objective
-- The goal's status (returned to a reworkable state)
-- The review issues recorded for the implementing agent
-
-### 3. Communicate Next Steps
-
-After rejection, the implementing agent should:
-
-1. Address every review issue documented in the rejection.
-2. Restart the goal to reload context:
-   ```bash
-   jumbo goal start --id <goal-id>
-   ```
-3. Re-implement the fixes within the original scope and constraints.
-4. Resubmit for review:
-   ```bash
-   jumbo goal submit --id <goal-id>
-   ```
-
-If a next goal is queued, its ID will be displayed for reference, but the rejected goal takes priority.
-
-## Rules
-
-1. **Never reject without specific issues.** Every rejection must include actionable feedback the implementing agent can act on.
-2. **Never combine rejection with rework.** The rejecting agent reviews; the implementing agent fixes. Do not attempt both roles.
-3. **Always reference violated criteria.** Tie each issue back to a success criterion, invariant, or guideline so the implementing agent understands the standard.
-4. **Keep issues structured.** Use numbered or bulleted lists. One issue per point. No walls of text.
-5. **Never reject for out-of-scope concerns.** Only reject for issues within the goal's defined scope and criteria.
+---
+name: reject-jumbo-goal
+description: Use when a Jumbo goal fails QA review and needs to be returned for rework. Records review issues and routes the goal back to the implementing agent with actionable feedback.
+---
+
+# Reject Jumbo Goal
+
+**Prompt:** Reject a Jumbo goal that failed QA review, recording the specific issues found so the implementing agent can address them and restart.
+
+## Why Rejection Quality Matters
+
+When a goal is rejected, the implementing agent receives the review issues as its primary guidance for rework. Vague or incomplete rejection feedback causes wasted rework cycles — the agent guesses at what's wrong, fixes the wrong things, and resubmits with the same issues. Precise, actionable rejection feedback is the fastest path to a passing review.
+
+## Protocol
+
+### 1. Document Review Issues
+
+Before rejecting, ensure you have a clear, specific list of every issue found during QA review. Each issue must be:
+
+- **Specific**: Reference exact files, functions, or behaviors that are wrong.
+- **Actionable**: Describe what needs to change, not just what's wrong.
+- **Traceable**: Link back to the success criterion, invariant, or guideline that was violated.
+
+### 2. Reject the Goal
+
+```bash
+jumbo goal reject --id <goal-id> --issues "<detailed review issues>"
+```
+
+The rejection output confirms:
+- The goal ID and objective
+- The goal's status (returned to a reworkable state)
+- The review issues recorded for the implementing agent
+
+### 3. Communicate Next Steps
+
+After rejection, the implementing agent should:
+
+1. Address every review issue documented in the rejection.
+2. Restart the goal to reload context:
+   ```bash
+   jumbo goal start --id <goal-id>
+   ```
+3. Re-implement the fixes within the original scope and constraints.
+4. Resubmit for review:
+   ```bash
+   jumbo goal submit --id <goal-id>
+   ```
+
+If a next goal is queued, its ID will be displayed for reference, but the rejected goal takes priority.
+
+## Rules
+
+1. **Never reject without specific issues.** Every rejection must include actionable feedback the implementing agent can act on.
+2. **Never combine rejection with rework.** The rejecting agent reviews; the implementing agent fixes. Do not attempt both roles.
+3. **Always reference violated criteria.** Tie each issue back to a success criterion, invariant, or guideline so the implementing agent understands the standard.
+4. **Keep issues structured.** Use numbered or bulleted lists. One issue per point. No walls of text.
+5. **Never reject for out-of-scope concerns.** Only reject for issues within the goal's defined scope and criteria.

package/assets/skills/review-jumbo-goal/SKILL.md

@@ -1,94 +1,94 @@
----
-name: review-jumbo-goal
-description: Use when a Jumbo goal needs QA review after implementation. Runs the review protocol, verifies every objective, criterion, and related entity constraint, and approves the goal for codification or rejects it with feedback.
----
-
-# Review Jumbo Goal
-
-**Prompt:** Review a completed Jumbo goal implementation against its objective, success criteria, scope, and all related architectural context. Approve the goal if no issue are found, otherwise document the issues and reject the goal.
-
-## Why Review Matters
-
-`jumbo goal review` assembles the goal's full context — objective, criteria, scope, architecture, components, decisions, invariants, and guidelines — into a QA verification prompt. A thorough review catches deviations before they compound. A lazy review lets defects ship.
-
-## Protocol
-
-### 1. Initiate Review
-
-```bash
-jumbo goal review --id <goal-id>
-```
-
-Read the entire output carefully. It contains the verification criteria assembled from the goal's relations.
-
-### 2. Verify Objective and Success Criteria
-
-For each success criterion listed in the output:
-
-1. Locate the implementation artifacts that satisfy it
-2. Read the relevant code
-3. Confirm the criterion is **fully** met — not partially, not approximately
-
-If ANY criterion is not met: add the issues to a list for feedback.
-
-### 3. Verify Scope Compliance
-
-If the review output includes scope sections:
-
-- **In Scope**: Confirm all work was done within the listed files/areas. No under-delivery.
-- **Out of Scope**: Confirm no work leaked into excluded areas. No over-delivery.
-
-If scope is violated: add the issues to the feedback list.
-
-### 4. Verify Architecture Alignment
-
-If the review output includes architecture:
-
-- **Organization style**: Do new namespaces and file names match the solution's architectural organization?
-- **Design patterns**: Were prescribed patterns applied where applicable?
-- **Principles**: Do all new artifacts reflect the listed principles?
-
-If architecture is misaligned: add the issues to the feedback list.
-
-### 5. Verify Related Entities
-
-For each category in the review output:
-
-- **Components**: Were all listed components properly considered? Are interactions correct?
-- **Dependencies**: Are dependency contracts respected?
-- **Decisions**: Is the implementation consistent with listed architectural decisions?
-- **Invariants**: Does the implementation adhere to every listed invariant? This is non-negotiable.
-- **Guidelines**: Does the implementation follow listed guidelines?
-
-If ANY entity constraint is violated: add the issues to the feedback list.
-
-### 6. Run Tests
-
-```bash
-npm test
-```
-
-All tests must pass. If tests fail: add the issues to the feedback list.
-
-### 7. Qualify or Re-Review
-
-**If ALL checks pass** (criteria, scope, architecture, entities, tests):
-
-```bash
-jumbo goal approve --id <goal-id>
-```
-
-**If ANY check failed**:
-
-```bash
-jumbo goal reject --id <goal-id> --audit-findings <list of issues>
-```
-
-
-## Rules
-
-1. **Never approve with unresolved failures.** Every criterion, invariant, and test must pass before approving.
-2. **Never skip entity categories.** Review output includes entities for a reason — each was registered during refinement as essential context.
-3. **Always run tests.** Implementation without passing tests is incomplete.
-4. **Document issues clearly.** When rejecting a goal, provide detailed feedback for each failure.
-5. **Read the code, don't assume.** Verify each criterion by reading actual implementation, not by recalling what you wrote.
+---
+name: review-jumbo-goal
+description: Use when a Jumbo goal needs QA review after implementation. Runs the review protocol, verifies every objective, criterion, and related entity constraint, and approves the goal for codification or rejects it with feedback.
+---
+
+# Review Jumbo Goal
+
+**Prompt:** Review a completed Jumbo goal implementation against its objective, success criteria, scope, and all related architectural context. Approve the goal if no issue are found, otherwise document the issues and reject the goal.
+
+## Why Review Matters
+
+`jumbo goal review` assembles the goal's full context — objective, criteria, scope, architecture, components, decisions, invariants, and guidelines — into a QA verification prompt. A thorough review catches deviations before they compound. A lazy review lets defects ship.
+
+## Protocol
+
+### 1. Initiate Review
+
+```bash
+jumbo goal review --id <goal-id>
+```
+
+Read the entire output carefully. It contains the verification criteria assembled from the goal's relations.
+
+### 2. Verify Objective and Success Criteria
+
+For each success criterion listed in the output:
+
+1. Locate the implementation artifacts that satisfy it
+2. Read the relevant code
+3. Confirm the criterion is **fully** met — not partially, not approximately
+
+If ANY criterion is not met: add the issues to a list for feedback.
+
+### 3. Verify Scope Compliance
+
+If the review output includes scope sections:
+
+- **In Scope**: Confirm all work was done within the listed files/areas. No under-delivery.
+- **Out of Scope**: Confirm no work leaked into excluded areas. No over-delivery.
+
+If scope is violated: add the issues to the feedback list.
+
+### 4. Verify Architecture Alignment
+
+If the review output includes architecture:
+
+- **Organization style**: Do new namespaces and file names match the solution's architectural organization?
+- **Design patterns**: Were prescribed patterns applied where applicable?
+- **Principles**: Do all new artifacts reflect the listed principles?
+
+If architecture is misaligned: add the issues to the feedback list.
+
+### 5. Verify Related Entities
+
+For each category in the review output:
+
+- **Components**: Were all listed components properly considered? Are interactions correct?
+- **Dependencies**: Are dependency contracts respected?
+- **Decisions**: Is the implementation consistent with listed architectural decisions?
+- **Invariants**: Does the implementation adhere to every listed invariant? This is non-negotiable.
+- **Guidelines**: Does the implementation follow listed guidelines?
+
+If ANY entity constraint is violated: add the issues to the feedback list.
+
+### 6. Run Tests
+
+```bash
+npm test
+```
+
+All tests must pass. If tests fail: add the issues to the feedback list.
+
+### 7. Qualify or Re-Review
+
+**If ALL checks pass** (criteria, scope, architecture, entities, tests):
+
+```bash
+jumbo goal approve --id <goal-id>
+```
+
+**If ANY check failed**:
+
+```bash
+jumbo goal reject --id <goal-id> --audit-findings <list of issues>
+```
+
+
+## Rules
+
+1. **Never approve with unresolved failures.** Every criterion, invariant, and test must pass before approving.
+2. **Never skip entity categories.** Review output includes entities for a reason — each was registered during refinement as essential context.
+3. **Always run tests.** Implementation without passing tests is incomplete.
+4. **Document issues clearly.** When rejecting a goal, provide detailed feedback for each failure.
+5. **Read the code, don't assume.** Verify each criterion by reading actual implementation, not by recalling what you wrote.