@caddis/cli 0.4.18 → 0.4.19

package/bundles/antigravity-plugin/skills/mmr/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: mmr
+description: Multi-Model Review & Runner (MMR) — run an ad-hoc task in an isolated multi-lane sandbox with rate-limit failover, test gates, and second-vendor review, or run a fast cross-model review on a diff
+---
+
+# /caddis:mmr — Multi-Model Review & Runner
+
+Execute an ad-hoc task across model lanes (GLM-5.3 → Codex Sol → Claude) inside an isolated
+git worktree with automated test gates and second-vendor review (DeepSeek). Destroys the worktree
+immediately on completion (zero worktree leaks) and leaves the output on a clean branch with a
+simple Verdict Card.
+
+When invoked without a task prompt (or with a git range), `/mmr` runs a direct cross-model diff review.
+
+## Natural Language Triggers
+You can trigger MMR naturally without typing the full slash command:
+- *"Run this on another lane: &lt;task&gt;"* &rarr; `/mmr "<task>"`
+- *"Try this with multilane: &lt;task&gt;"* &rarr; `/mmr "<task>"`
+- *"Keep it"* / *"Keep the changes"* &rarr; `/mmr keep`
+- *"Drop it"* / *"Discard the attempt"* &rarr; `/mmr drop`
+- *"Check mmr status"* / *"Which lanes are ready?"* &rarr; `/mmr status`
+- *"Review this diff with mmr"* &rarr; `/mmr`
+
+---
+
+## Commands
+
+### 1. Run an Ad-Hoc Task
+```bash
+python scripts/caddis_adhoc.py run "<task description>" [--type backend|tests|docs|ui|hard]
+# Shorthand:
+python scripts/caddis_adhoc.py "<task description>"
+```
+- **Sandbox Isolation:** Creates an ephemeral 1-phase plan at `.caddis/orchestrator/adhoc/<slug>.md`.
+- **Pre-flight Checks:** Verifies dirty tree and API keys. Warns if local edits exist.
+- **Failover Cascade:** Automatically cascades from GLM to Codex to Claude if a lane is out of budget.
+- **Local Test Gates:** Runs project test gates before review.
+- **Cross-Vendor Review:** DeepSeek or GLM reviews the diff.
+- **Immediate Worktree Cleanup:** Stashes/commits results to `lane/adhoc-<slug>` and immediately removes the worktree. Zero open worktrees remain.
+- **Verdict Card:** Prints PASS/FAIL summary with diff stats and next actions.
+
+### 2. Keep the Result
+```bash
+python scripts/caddis_adhoc.py keep
+```
+- Keeps the output branch `lane/adhoc-<slug>`.
+- **Main Branch Protection:** If you are on `main` or `master`, direct merge is disabled to protect trunk. Recommends running `/ship-pr`.
+- If on a feature branch and the working tree is clean, provides squash-merge instructions.
+
+### 3. Drop the Result
+```bash
+python scripts/caddis_adhoc.py drop
+```
+- Deletes the branch `lane/adhoc-<slug>`.
+- Deletes the ephemeral plan file and run logs.
+- Workspace remains clean and untouched.
+
+### 4. Check Status
+```bash
+python scripts/caddis_adhoc.py status
+```
+- Displays API key readiness for all lanes (`Anthropic`, `DeepSeek`, `GLM`, `OpenAI`).
+- Shows the latest task status, model used, and gates/review verdicts.
+- Lists any unmerged `lane/adhoc-*` branches.
+
+### 5. Review Diff Only
+```bash
+python scripts/caddis_adhoc.py review [--range <range>]
+# Shorthand (no args):
+python scripts/caddis_adhoc.py
+```
+- Fast cross-model review of working tree or git range (e.g., `origin/main..HEAD`).
+
+---
+
+## Tool Resolution
+Resolve `caddis_adhoc.py` deterministically:
+```bash
+if [ -f "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_adhoc.py" ]; then
+  TOOL="${CLAUDE_PLUGIN_ROOT}/scripts/caddis_adhoc.py"
+elif [ -f "scripts/caddis_adhoc.py" ]; then
+  TOOL="scripts/caddis_adhoc.py"
+else
+  echo "caddis_adhoc.py not found — report this and stop."
+  exit 3
+fi
+```

package/bundles/antigravity-plugin-extras/plugin.json

@@ -1,5 +1,5 @@
 {
   "name": "caddis-extras",
-  "version": "1.3.29",
+  "version": "1.3.30",
   "description": "caddis-extras — the long-tail skills for the Antigravity (agy) caddis plugin; install alongside caddis for the full set."
 }

package/bundles/antigravity-plugin-extras/skills/_registry.md

@@ -61,6 +61,8 @@
 | Architecture Document | `architecture-document/` | Generate professional enterprise-grade HLD and LLD documents from the living Architecture.md. Outputs DOCX (editable) or PPTX (executive summary) using existing document skills. |
 | Doc Coauthoring | `doc-coauthoring/` | Guide users through a structured workflow for co-authoring documentation. Use when user wants to write documentation, proposals, technical specs, decision docs, or similar structured content. This workflow helps users efficiently transfer context, refine content through iteration, and verify the doc works for readers. Trigger when user mentions writing docs, creating proposals, drafting specs, or similar documentation tasks. |
 | Documentation Analyzer | `documentation-analyzer/` | Analyze codebases, explain code functionality, and generate comprehensive documentation. Use when documenting a project, creating README files, or understanding complex code. |
+| Hld | `hld/` | Generates High-Level Design (HLD) Markdown documentation and converts to Confluence Storage Format XHTML with inline PlantUML macros. |
+| Lld | `lld/` | Generates Lower-Level Design (LLD) Markdown documentation and converts to Confluence Storage Format XHTML with inline PlantUML macros. |
 | Naming Analyzer | `naming-analyzer/` | Suggest better variable, function, and class names based on context and conventions. |
 | Prd To Code | `prd-to-code/` | Transform PRD documents into working application code using a systematic 6-phase methodology. Use when starting projects from requirements or converting specs to implementation. |
 

package/bundles/antigravity-plugin-extras/skills/hld/SKILL.md

@@ -0,0 +1,100 @@
+---
+name: hld
+description: Generates High-Level Design (HLD) Markdown documentation and converts to Confluence Storage Format XHTML with inline PlantUML macros.
+---
+
+# High-Level Design (HLD) Authoring Skill
+
+## Overview
+This skill generates High-Level Design (HLD) documents for enterprise application fleet systems and converts them to Confluence Storage Format XHTML with self-contained, inline PlantUML (`<ac:structured-macro ac:name="plantuml">`) diagrams.
+
+## Scope and Boundary Principles (Strict)
+1. **High-Level Design Only:**
+   - Include: Business initiative goals, high-level architecture topology, user surfaces, high-level database references, security & network boundaries, and target state roadmap.
+   - **DO NOT INCLUDE:**
+     - Internal application API routes or controller implementation details.
+     - Stored procedure names, parameter lists, or SQL code.
+     - Low-level ETL batch scripts, job schedules, or internal script arguments.
+     - Low-level table schemas or physical column definitions.
+2. **Database Representation:**
+   - Mention the physical database host and database name.
+   - List high-level reporting summary tables or key domain mart entities only.
+   - Low-level tables and stored procedures belong strictly in the Lower-Level Design (LLD).
+3. **Sequence Diagrams:**
+   - Automated schedulers (such as Windows Task Scheduler or cron) must be depicted as system components or lifeline participants, **NEVER** as human actors.
+4. **Diagram Rendering and Orthogonal Connectors:**
+   - Diagrams are converted to native Confluence PlantUML macros (`<ac:structured-macro ac:name="plantuml">`) using `skinparam linetype ortho`.
+   - `skinparam linetype ortho` ensures that all arrows connecting boxes are strictly orthogonal (90-degree right angles, zero diagonal slants).
+   - PlantUML renders inline upon copy-paste into Confluence with zero attachment access errors.
+5. **No AI Traces and Clean STE:**
+   - The HLD must contain zero hints or traces of AI generation (no model names, tool mentions, or meta-notices in the Confluence HTML).
+   - Write in Simplified Technical English (ASD-STE100): short sentences, active voice, and clear technical descriptions.
+   - Executive Metadata is omitted from the Confluence HTML view (metadata belongs in LLD).
+
+## Standard HLD Document Structure (Markdown)
+Every HLD document must follow this standardized 7-section structure:
+
+```markdown
+---
+type: design
+status: current
+feature: <app>-hld
+creation-agent: caddis
+Original Author: Solutions Architecture
+Creation Date: <YYYY-MM-DDTHH:MM:SSZ>
+Creating Model: gemini-3.5-flash
+---
+
+# High-Level Architecture (HLA): <Application Name>
+
+## Document Information
+
+### Version History
+| Version | Date | Author | Description |
+|---|---|---|---|
+| 1.0 | <YYYY-MM-DD> | Solutions Architecture | Initial High-Level Architecture Draft |
+
+---
+
+## 1. Executive Summary
+- 1.1 Initiative Goal
+- 1.2 Solution Architecture Summary
+- 1.3 Business Value & Operational Outcomes
+
+## 2. Project Context and Scope
+- 2.1 Background
+- 2.2 Scope (In Scope / Out of Scope)
+- 2.3 Architecture Boundaries and Key Assumptions
+
+## 3. Solution Approach and Workflow
+- 3.1 Operational Process Flow (Mermaid flowchart)
+- 3.2 End-to-End Operational Sequence Diagram (Mermaid sequence diagram with system scheduler participant)
+
+## 4. Solution Architecture Landscape
+- 4.1 Solution Design and Architecture (Mermaid topology diagram)
+- 4.2 User Surfaces and Capabilities Overview (Summary table of primary operational interfaces)
+- 4.3 High-Level Data Model and Summary Mart (High-level summary entities only, no stored procedures or DDL)
+- 4.4 High-Level Data Flow and Integration (Mermaid data lineage flow)
+
+## 5. Security Architecture and Controls
+- 5.1 Identity and Access Management (Authentication seams, roles, authorization boundaries)
+- 5.2 Network Boundaries and Perimeter Controls (Subnets, ports, host environments)
+- 5.3 Data Protection and Privacy (Encryption, sensitive data handling)
+- 5.4 Auditability and Governance
+
+## 6. Target State Roadmap (Work In Progress)
+- 6.1 Enterprise Identity Evolution
+- 6.2 Automated Operational Integration
+
+## 7. Appendix
+- 7.1 Terms and Definitions
+- 7.2 Reference Documents
+```
+
+## Conversion Workflow
+1. Write the canonical HLD Markdown file to `docs/<app>/<app>-hld.md`.
+2. Run the conversion script:
+   ```bash
+   python scripts/convert_doc_to_confluence.py docs/<app>/<app>-hld.md --output docs/<app>/<app>-hld.html
+   ```
+3. Verify that the output validates as well-formed XML and contains `<ac:structured-macro ac:name="plantuml">` blocks with `skinparam linetype ortho`.