jdi-cli 0.1.0

package/runtimes/antigravity/skills/jdi-verify/SKILL.md

@@ -0,0 +1,159 @@
+---
+name: jdi-verify
+description: Runs phase quality gates via reviewer specialist. Build, tests, coverage, lint, security checks. Verdict APPROVED / APPROVED_WITH_WARNINGS / BLOCKED.
+argument_hint: "<phase_number>"
+runtime_intent:
+  invokes_agent: dynamic
+runtime_overrides:
+  claude:
+    allowed-tools: [Read, Bash, Grep, Glob, Agent]
+  copilot:
+    tools: [read, grep, glob, terminal]
+  opencode:
+    subtask: true
+    model: anthropic/claude-sonnet-4-20250514
+  antigravity:
+    triggers:
+      - "/jdi-verify"
+      - "verify phase {N}"
+---
+
+<objective>
+Verifies the phase was delivered correctly. Runs gates defined in the project's reviewer specialist. Verdict blocks or releases the ship.
+</objective>
+
+<arguments>
+- `phase_number` (required)
+</arguments>
+
+<process>
+
+### Step 1: Validation
+```bash
+test -d .jdi/ || { echo "Not a JDI project."; exit 1; }
+
+# Verify reviewer exists
+ls .jdi/agents/jdi-reviewer-*.md 2>/dev/null | head -1 || {
+  echo "Reviewer missing. /jdi-bootstrap."
+  exit 1
+}
+
+# Verify phase was executed
+ls .jdi/phases/{NN}*/SUMMARY.md 2>/dev/null || {
+  echo "Phase {N} not executed. /jdi-do {N}."
+  exit 1
+}
+
+# Context budget warm-up (does not block)
+JDI_LIB="$(dirname "$(command -v jdi 2>/dev/null || echo /usr/local/bin/jdi)")/../lib"
+if [ -f "$JDI_LIB/jdi-monitor.sh" ]; then
+  bash "$JDI_LIB/jdi-monitor.sh" .jdi/PROJECT.md .jdi/DECISIONS.md .jdi/phases/{NN}*/PLAN.md .jdi/phases/{NN}*/SUMMARY.md || true
+fi
+# Windows: pwsh -File "$JDI_LIB/jdi-monitor.ps1" -Paths @(...)
+```
+
+### Step 2: Resolve reviewer specialist(s)
+
+```bash
+REVIEWERS=$(grep -oE 'jdi-reviewer-[a-z0-9-]+' .jdi/reviewers.md | sort -u)
+REVIEWER_COUNT=$(echo "$REVIEWERS" | wc -l)
+echo "Reviewers registered: $REVIEWER_COUNT"
+```
+
+**Single-stack** (`REVIEWER_COUNT == 1`): one reviewer, normal flow.
+**Multi-stack** (`REVIEWER_COUNT > 1`): chain reviewers in registry order. Each writes its own REVIEW segment; aggregate verdict = worst-case (1 BLOCK = overall BLOCK).
+
+### Step 3: Spawn reviewer(s)
+
+**Single-stack:**
+```
+Agent(
+  subagent_type="${REVIEWERS}",
+  description="Verify phase {N}",
+  prompt="phase={N}, mode=verify"
+)
+```
+
+**Multi-stack:** spawn each reviewer in sequence (NOT parallel — build/test commands may conflict on ports, locks, output dirs):
+
+```
+for REVIEWER in $REVIEWERS:
+  Agent(
+    subagent_type="$REVIEWER",
+    description="Verify phase {N} ({REVIEWER})",
+    prompt="phase={N}, mode=verify, reviewer_segment=${REVIEWER}"
+  )
+  # Each reviewer appends to .jdi/phases/{NN-slug}/REVIEW.md under section
+  # "## Reviewer: {REVIEWER}" with its own gate results and verdict
+```
+
+Each reviewer scopes its gates to its `file_glob` (from frontmatter `scope.file_glob`). Coverage threshold enforced only on files matching the glob.
+
+Reviewers are read-only. Wait for completion before next.
+
+### Step 4: Read aggregate verdict
+
+```bash
+test -f .jdi/phases/{NN}*/REVIEW.md || { echo "REVIEW.md not created"; exit 1; }
+
+# Collect all per-reviewer verdicts
+VERDICTS=$(grep -oE 'Verdict:\*\* (APPROVED|APPROVED_WITH_WARNINGS|BLOCKED)' .jdi/phases/{NN}*/REVIEW.md | awk '{print $2}')
+
+# Worst-case wins: BLOCK > WARNINGS > APPROVED
+if echo "$VERDICTS" | grep -q BLOCKED; then
+  VERDICT=BLOCKED
+elif echo "$VERDICTS" | grep -q APPROVED_WITH_WARNINGS; then
+  VERDICT=APPROVED_WITH_WARNINGS
+else
+  VERDICT=APPROVED
+fi
+
+# For single-stack, this collapses to the single reviewer's verdict — backward compatible.
+```
+
+### Step 5: Update STATE
+
+```markdown
+current_phase: {N}
+phase_status: {verified|blocked}
+phase_verdict: {APPROVED|APPROVED_WITH_WARNINGS|BLOCKED}
+next_step: {if APPROVED or WITH_WARNINGS: /jdi-ship {N}; if BLOCKED: fix and /jdi-do {N} again}
+```
+
+```bash
+git add .jdi/phases/{NN-slug}/REVIEW.md .jdi/STATE.md
+git commit -m "docs({NN-slug}): verify phase ({VERDICT})"
+```
+
+### Step 6: Confirm
+
+**APPROVED:**
+```
+Phase {N}: APPROVED. Next: /jdi-ship {N}
+```
+
+**APPROVED_WITH_WARNINGS:**
+```
+Phase {N}: APPROVED_WITH_WARNINGS ({count} warnings).
+REVIEW.md: .jdi/phases/{NN-slug}/REVIEW.md
+Next: /jdi-ship {N} (or fix first)
+```
+
+**BLOCKED:**
+```
+Phase {N}: BLOCKED ({count} blockers). REVIEW.md: .jdi/phases/{NN-slug}/REVIEW.md
+Fix → /jdi-do {N} → /jdi-verify {N}
+```
+
+</process>
+
+<gates>
+- pre: SUMMARY.md exists + reviewer registered in .jdi/reviewers.md
+- post: REVIEW.md created + STATE updated
+</gates>
+
+<errors>
+- Reviewer missing -> /jdi-bootstrap
+- SUMMARY missing -> /jdi-do
+- Reviewer fails -> show error, keep state, suggest retry
+</errors>

package/runtimes/antigravity/skills/kiss/SKILL.md

@@ -0,0 +1,169 @@
+---
+name: kiss
+description: KISS (Keep It Simple, Stupid). The simplest solution that solves the problem wins. Complexity only justified by real measured pain. Each layer/abstraction must pay its own cost. Applies in any language.
+triggers:
+  - "KISS"
+  - "keep simple"
+  - "over-engineering"
+  - "simplicity"
+---
+
+# Skill: KISS
+
+> Simplicity is the best design. Every complexity must pay its own cost.
+
+KISS is not "dumb code". It's **rejecting unjustified complexity**. Every interface, every layer, every abstraction has maintenance cost — only worth it if it solves real pain.
+
+## Rules
+
+### 1. Default is the simplest
+
+Ask before adding:
+- **Function** vs class vs framework?
+- **Variable** vs config vs feature flag?
+- **If/else** vs strategy pattern vs plugin system?
+- **Sync** vs async vs queue vs event bus?
+- **Inline** vs helper vs lib?
+
+Start with the leftmost. Only step up if there is a real requirement.
+
+### 2. Complexity must justify pain
+
+**Allowed:**
+- New pattern if it has 3+ real cases using it
+- Abstraction layer if it has 2+ implementations that exist today
+- Cache if measurement shows hot path
+- Async if there's unacceptable latency synchronous
+- Plugin system if there are confirmed external extenders
+
+**Forbidden:**
+- "Will scale later" without current requirement
+- "Other people might need it" without other people
+- "To make it generic" without 2nd use case
+- "Will look cleaner" trading 5 clear lines for 50 elegant ones
+- Enterprise pattern in small codebase (Repository + UoW + Mediator + CQRS for 10-controller app)
+
+### 3. Cognitive load is a real metric
+
+Code you read 10x and write 1x. Optimize for reading:
+- **Named variables** > composite expression
+- **Early return** > nested if/else
+- **Linear function** > jumps between callbacks
+- **Explicit types** > magical inference in large codebase
+- **Simple procedural code** > fancy OOP for 50 lines
+
+Rule: code that needs a comment explaining "why so complex" is too complex.
+
+### 4. Indicators of over-engineering
+
+Signs the code went over the line:
+
+- Interface with 1 implementation
+- Factory/Builder for something instantiated 1x
+- Generic <T> only used with 1 type
+- Config with a key that never changed
+- Abstraction layer that only encapsulates a call to another layer (pass-through)
+- Inheritance hierarchy > 2 levels
+- File with more setup than logic
+- Test that needs 30 lines of mock to run 5 lines of logic
+
+### 5. Refactor is the opposite direction
+
+Natural tendency: code grows in complexity. Refactoring = REMOVE complexity that no longer pays.
+
+Ask:
+- Does this layer still exist to solve a problem, or did it become tradition?
+- Does this abstraction have 2+ implementations today?
+- If I delete this, what breaks?
+- Can I solve it with 5 lines instead of 50?
+
+## Anti-patterns
+
+| Anti-pattern | Symptom |
+|---|---|
+| Interface + 1 implementation | `IUserService` + `UserService` (only 1) — delete the interface, use the class |
+| Generic `<T>` used with 1 type | `Repository<User>` but never `Repository<Order>` — concretize |
+| Factory for new() | `UserFactory.create()` that only does `return new User()` |
+| Config string that never changed | `MAX_RETRIES: 3` in config + nobody ever changed it — hardcode |
+| Inheritance > 2 levels | `BaseEntity -> AuditableEntity -> SoftDeletableEntity -> User` — flatten via composition |
+| Pass-through layer | `Controller -> Service -> Repository -> DbContext` where Service only calls Repository without logic — delete Service |
+| Enterprise pattern without demand | Mediator/CQRS in small app — replace with direct call |
+| Comment explaining "why so complex" | Code lost the war — refactor |
+| Mock setup > logic test | Test gets fragile; code under test is over-coupled |
+| Unused future-proof params | `(opts?: { future?: boolean })` without caller passing — remove |
+
+## Procedure
+
+### Doer (before writing)
+
+1. Ask: "What is the **simplest** version that meets the current requirement?"
+2. Write that version.
+3. Only step up complexity if you hit real pain.
+4. After writing, ask: "Can I delete any layer/parameter/abstraction without losing functionality?"
+
+### Reviewer (gate 5)
+
+Over-engineering heuristics:
+
+```bash
+# Interfaces with 1 implementation
+grep -RnE '^(public |export )?interface I?[A-Z]\w+' src/ | while read iface; do
+  name=$(echo "$iface" | grep -oE '[A-Z]\w+\b' | head -1)
+  count=$(grep -RnE "class \w+\s*:\s*$name|implements $name" src/ | wc -l)
+  [[ $count -eq 1 ]] && echo "WARN: $iface has only 1 implementation"
+done
+
+# Deep inheritance (> 2 levels)
+# (depends on stack — specific heuristic)
+
+# Very large or nested functions
+grep -cE '^\s{20,}\S' src/**/*  # lines with 20+ spaces = deep nesting
+```
+
+Match -> WARN with suggestion to simplify.
+
+## Inputs
+
+- Diff/content of the file
+- Context: codebase size (over-engineering is relative)
+
+## Outputs
+
+Does NOT produce a file. Modifies judgement.
+
+## Examples
+
+### Example 1: Interface with 1 impl
+
+Wrong:
+```typescript
+interface ILogger { log(msg: string): void }
+class ConsoleLogger implements ILogger { log(msg) { console.log(msg) } }
+const logger: ILogger = new ConsoleLogger()
+```
+
+Right (KISS):
+```typescript
+function log(msg: string) { console.log(msg) }
+// or
+class Logger { static log(msg: string) { console.log(msg) } }
+```
+
+Add interface when 2nd impl arrives, not before.
+
+### Example 2: Pass-through service
+
+Wrong:
+```csharp
+public class UserService {
+  public User GetById(int id) => _repo.GetById(id);  // only calls repo
+}
+```
+
+Right: use `_repo` directly in the controller. Add Service when there is real logic (validation, multi-step, transaction, event).
+
+### Example 3: Hardcodable config
+
+Wrong: `appsettings.json -> "MaxItemsPerPage": 50` that nobody ever changed in 2 years.
+
+Right: `const MAX_ITEMS_PER_PAGE = 50` in the code. Move back to config if some client actually needs to customize.

package/runtimes/antigravity/skills/solid/SKILL.md

@@ -0,0 +1,272 @@
+---
+name: solid
+description: SOLID. Robert C. Martin's 5 OO design principles - SRP, OCP, LSP, ISP, DIP. Applicable in any language with types/classes/interfaces (C#, Java, TS, Python, Go, Rust, Kotlin, Swift, etc). Direct summary + anti-patterns + detection heuristics.
+triggers:
+  - "SOLID"
+  - "SOLID principles"
+  - "SRP OCP LSP ISP DIP"
+  - "OO design"
+---
+
+# Skill: SOLID
+
+5 design principles — **S**ingle Responsibility, **O**pen/Closed, **L**iskov Substitution, **I**nterface Segregation, **D**ependency Inversion.
+
+Applicable in any language with classes or interfaces. In FP/procedural, principles map to modules and functions (SRP: 1 function 1 responsibility; ISP: minimal parameters; DIP: dependency injection via parameter).
+
+## S - Single Responsibility Principle (SRP)
+
+> A class/module must have **1 reason to change**.
+
+**1 reason = 1 stakeholder or 1 axis of change**, not "1 action".
+
+`UserService` that does auth + persistence + sends email violates — there are 3 reasons to change (security team changes auth, DBA changes persistence, marketing changes email).
+
+### Violation symptoms
+- Class with generic name (`Manager`, `Helper`, `Service`, `Util`)
+- Methods without thematic coherence
+- Multiple imports of unrelated libraries (DB + email + crypto in the same class)
+- Diff of one class affects separate domains in different sprints
+
+### Fix
+Extract responsibilities into separate classes:
+- `UserAuthenticator` (auth)
+- `UserRepository` (persistence)
+- `UserNotifier` (email)
+
+Compose in a coordinator if needed, but each piece has 1 reason.
+
+## O - Open/Closed Principle (OCP)
+
+> Open for **extension**, closed for **modification**.
+
+Adding new behavior shouldn't require editing tested code. Use polymorphism, strategy, plugins, or config — not infinite if/else.
+
+### Violation symptoms
+- `switch (type)` that grows with every new feature
+- `if (provider === "x") ... else if ... else if ...`
+- Each new feature edits N existing classes instead of adding 1 new one
+
+### Fix
+- **Strategy pattern**: each case becomes an impl of an interface
+- **Polymorphism**: subclass override instead of external switch
+- **Registry**: `registry.register("x", handler)` — new feature just adds
+- **Visitor**: for closed type hierarchies
+
+### When to ignore
+OCP is aspirational, not absolute. Apply at points of **known** variation (payment strategies are multiple), don't speculate (KISS + YAGNI).
+
+## L - Liskov Substitution Principle (LSP)
+
+> Subtype must be **substitutable** for the supertype without breaking behavior.
+
+If `Bird` has method `fly()`, `Penguin extends Bird` violates LSP — penguin doesn't fly. Caller receiving `Bird` breaks when it receives `Penguin`.
+
+### Violation symptoms
+- Subclass that **throws exception** on inherited method ("not supported")
+- Subclass that **strengthens precondition** (`base accepts >= 0`, sub accepts `> 0`)
+- Subclass that **weakens postcondition** (base guarantees "sorted", sub doesn't guarantee)
+- Caller needs `if (instanceof Subtype)` to handle a special case
+
+### Fix
+- Rethink hierarchy: `Penguin` isn't a flying `Bird`, it's a `Bird` that walks. Create `FlyingBird : Bird` and `Penguin : Bird` without fly.
+- Composition over inheritance: prefer composed interfaces over deep hierarchies.
+- Refactor to capabilities: `Flyable`, `Swimmable`, `Walkable` (overlap with ISP).
+
+## I - Interface Segregation Principle (ISP)
+
+> Clients should not be forced to depend on interfaces they **do not use**.
+
+Big interfaces ("fat interfaces") force impls to stub meaningless methods (throwing NotImplemented), and callers to import broad dependencies.
+
+### Violation symptoms
+- Interface with 15 methods, each caller uses 2-3
+- Impl with several methods throwing `throw new NotImplementedException()`
+- Huge test mock to use 1 method of the interface
+
+### Fix
+Split into smaller, cohesive interfaces:
+```
+IFileReader { read() }
+IFileWriter { write() }
+// callers pick the subset they need
+```
+
+In FP/Go, same principle: minimal parameters, structural typing doesn't force implementing everything.
+
+## D - Dependency Inversion Principle (DIP)
+
+> High-level modules **do not** depend on low-level. Both depend on **abstractions**.
+
+Business logic doesn't care about "PostgreSQL", "AWS S3", "SendGrid". It cares about abstractions (`UserRepository`, `BlobStorage`, `EmailSender`). Concrete implementations live in outer layers.
+
+### Violation symptoms
+- Domain class imports `pg`, `aws-sdk`, `sendgrid`, `axios`
+- Business logic testable only with real infra (DB up, S3 mocked, etc)
+- Swapping provider requires rewriting business logic
+
+### Fix
+- **Dependency injection** (constructor / property / parameter)
+- Define interfaces in the domain module; impls live in infra/adapter layer (overlap with Hexagonal/Clean Architecture)
+- Composition root injects the right impl
+
+### DIP != IoC container
+DIP is a principle. IoC container is **one** tool. You can apply DIP with manual constructor, simple factory, or parameter injection — no framework.
+
+## Summary of the 5
+
+| Letter | Focus | Key question |
+|---|---|---|
+| **S** | Unit cohesion | How many reasons to change this class/module? (>1 = violates) |
+| **O** | Stability against extension | Does adding a new feature edit tested code or add new code? |
+| **L** | Inheritance contract | Does replacing parent with child break any caller? |
+| **I** | Interface size | Does every impl/caller use all methods? |
+| **D** | Direction of dependency | Does domain import infra or does infra import domain? |
+
+## General anti-patterns
+
+| Anti-pattern | Principle violated |
+|---|---|
+| `God class` with 30+ heterogeneous methods | SRP |
+| `switch (kind)` in N callers, grows with each feature | OCP |
+| Subclass with `throw NotSupportedException()` | LSP |
+| `IRepository` with 20 generic methods | ISP |
+| Domain service importing concrete ORM | DIP |
+| Inheritance > 3 levels | LSP + SRP (usually) |
+| Constructor with 8+ parameters | SRP (too many responsibilities) |
+| Util class with 50 unrelated functions | SRP |
+
+## Procedure
+
+### Doer
+
+Before creating class/module/interface:
+- **SRP**: describe in 1 sentence. If you need "and", split.
+- **ISP**: list expected callers. Does each one need **all** methods? If not, split.
+- **DIP**: what does this depend on? Concretions (DB, HTTP, FS) -> inject as abstraction.
+
+Before subclassing:
+- **LSP**: does substitution by parent work in all callers? If not, wrong hierarchy.
+
+Before adding `if/switch` at a growing point:
+- **OCP**: is strategy/registry worth it?
+
+### Reviewer (gate 5)
+
+```bash
+# SRP — very large classes
+find src/ -name '*.cs' -o -name '*.ts' -o -name '*.py' | while read f; do
+  loc=$(wc -l < "$f")
+  [[ $loc -gt 400 ]] && echo "WARN SRP: $f has $loc lines, possible god class"
+done
+
+# OCP — big switches on hot paths
+grep -RnE 'switch\s*\(' src/ | head
+# (manually: evaluate if it grows with each feature)
+
+# LSP — NotImplemented in subclass
+grep -RnE 'NotImplemented|UnsupportedOperation|throw new.*not (implemented|supported)' src/
+
+# ISP — giant interfaces
+grep -RnA50 '^(public |export )?interface' src/ | grep -cE '^\s+\w+\s*\(' | sort -rn
+# count > 10 methods -> WARN
+
+# DIP — domain module importing concretions
+grep -RnE 'from.*pg|from.*aws-sdk|using Npgsql|using AWSSDK' src/domain/ src/core/
+```
+
+Relevant match -> WARN with principle cited.
+
+## Inputs
+
+- Diff/content of the file
+- Project structure (to detect domain vs infra)
+
+## Outputs
+
+Does NOT produce a file. Modifies judgement.
+
+## Examples
+
+### Example 1: SRP violated
+
+Wrong:
+```csharp
+public class OrderService {
+  public Order Create(...) { /* validate + save + email + log + audit */ }
+}
+```
+
+5 reasons to change.
+
+Right:
+```csharp
+public class OrderValidator { }
+public class OrderRepository { }
+public class OrderNotifier { }
+public class OrderService {
+  public Order Create(...) {
+    _validator.Validate(...)
+    var order = _repo.Save(...)
+    _notifier.Notify(order)
+    return order;
+  }
+}
+```
+
+### Example 2: OCP violated
+
+Wrong:
+```typescript
+function calcDiscount(type: string, amount: number) {
+  if (type === "vip") return amount * 0.2
+  else if (type === "newcomer") return amount * 0.1
+  else if (type === "blackfriday") return amount * 0.5
+  return 0
+}
+```
+
+Each new type edits this function.
+
+Right:
+```typescript
+const strategies: Record<string, (amount: number) => number> = {
+  vip: a => a * 0.2,
+  newcomer: a => a * 0.1,
+  blackfriday: a => a * 0.5,
+}
+function calcDiscount(type: string, amount: number) {
+  return strategies[type]?.(amount) ?? 0
+}
+```
+
+New type: register in `strategies`, don't touch `calcDiscount`.
+
+### Example 3: DIP violated
+
+Wrong:
+```python
+# domain/order.py
+import psycopg2
+class OrderService:
+  def get(self, id):
+    conn = psycopg2.connect(...)
+    ...
+```
+
+Domain coupled to Postgres.
+
+Right:
+```python
+# domain/order.py
+class OrderService:
+  def __init__(self, repo: OrderRepository):  # abstraction
+    self._repo = repo
+  def get(self, id): return self._repo.get(id)
+
+# infra/postgres_order_repo.py
+class PostgresOrderRepository(OrderRepository):
+  def get(self, id): ...  # concrete impl
+```
+
+Domain doesn't know Postgres exists.