@glrs-dev/cli 0.0.1 → 0.1.1

package/dist/vendor/harness-opencode/dist/commands/prompts/init-deep.md

@@ -0,0 +1,196 @@
+---
+description: Generate hierarchical AGENTS.md files. Root plus complexity-scored subdirectories.
+---
+
+Generate or refresh hierarchical `AGENTS.md` files.
+
+**Arguments:** `$ARGUMENTS` — optional flags:
+- `--create-new` — read existing AGENTS.md files (capture context), then delete all, then regenerate from scratch
+- `--max-depth=N` — limit directory depth (default: 3)
+- `--dry-run` — produce the inclusion list + size estimates, but do not write files
+
+Default (no flags): update mode. Modify existing files in-place; create new ones where a directory's score warrants it.
+
+---
+
+## Phase 1 — Discovery + Analysis (concurrent)
+
+**Subagent choice: route to `@code-searcher` explicitly (not the built-in `general` subagent).** The code-searcher has Serena allowed and is prompted to use it first; the built-in `general` is more generic and may default to grep. When invoking via the task tool, specify the subagent name exactly.
+
+**Mandate Serena in each subagent prompt.** Don't just say "explore conventions" — tell them which Serena tool to call. Examples below include the explicit Serena call each subagent should use.
+
+Fire these in parallel via the task tool (they can run concurrently since they don't depend on each other):
+
+- `@code-searcher` — "Map project structure. Call `serena_get_symbols_overview` on `apps/` and `packages/` top-level directories to inventory module boundaries and symbol counts. Supplement with bash `find` for file counts per directory. Skip node_modules, dist, .next, .turbo, build, coverage, .serena."
+- `@code-searcher` — "Find entry points. Call `serena_find_symbol` for common entry-point names (index, main, App, page). Supplement with glob for apps/*/src/index.ts, apps/*/src/main.ts, apps/*/src/app/page.tsx, packages/*/src/index.ts. Return paths + the symbol kind (function, class, default export)."
+- `@code-searcher` — "Find project conventions. Read tsconfig files, eslint configs, prettier configs, turbo.json, pnpm-workspace.yaml, .*rc files. Report non-default settings only. This is config-file work — Serena isn't useful here; use `read` directly."
+- `@code-searcher` — "Find anti-patterns in existing AGENTS.md files: `find . -name AGENTS.md -not -path '*/node_modules/*'` then read each. Extract any NEVER/ALWAYS/DO NOT rules. Consolidate. This is markdown prose; use `grep` / `read`."
+- `@code-searcher` — "Find build/CI patterns: .github/workflows, .husky, scripts/sh, any Makefile. Use `read` — these are mostly YAML/shell. Report non-standard patterns only."
+- `@code-searcher` — "Find test patterns. Call `serena_find_symbol` for `describe`, `it`, `test`, `beforeEach` to measure test density per directory. Read vitest/jest/playwright configs via `read`. Report unique conventions only."
+
+While the subagents run, YOU do:
+
+### Structural bash analysis
+```bash
+# Directory depth + files per dir (top 30)
+find . -type d \
+  -not -path '*/node_modules/*' -not -path '*/.git/*' \
+  -not -path '*/dist/*' -not -path '*/.next/*' -not -path '*/.turbo/*' \
+  | awk -F/ '{print NF-1}' | sort -n | uniq -c
+
+find . -type f \
+  -not -path '*/node_modules/*' -not -path '*/.git/*' \
+  -not -path '*/dist/*' -not -path '*/.next/*' -not -path '*/.turbo/*' \
+  | sed 's|/[^/]*$||' | sort | uniq -c | sort -rn | head -30
+
+# Code concentration by extension
+find . -type f \( -name "*.ts" -o -name "*.tsx" -o -name "*.py" -o -name "*.go" -o -name "*.rs" \) \
+  -not -path '*/node_modules/*' -not -path '*/dist/*' \
+  | sed 's|/[^/]*$||' | sort | uniq -c | sort -rn | head -20
+
+# Existing AGENTS.md / CLAUDE.md
+find . -type f \( -name "AGENTS.md" -o -name "CLAUDE.md" \) -not -path '*/node_modules/*'
+```
+
+### Read every existing AGENTS.md
+Capture their contents into a per-path map. These are the manual authoring we must preserve (if update mode) or extract context from before deletion (if `--create-new`).
+
+### Serena symbol density (LSP-grade codemap) — REQUIRED
+
+For each candidate top-level directory (every `apps/*` and `packages/*`), call `serena_get_symbols_overview` with the directory path. Record:
+- Total symbol count per directory
+- Top 5 exports by name
+- Whether an `index.ts` entry point exists
+
+Then for the top-3 symbol-densest directories, call `serena_find_referencing_symbols` on their 1-2 most load-bearing exports to measure reference centrality across the repo.
+
+This data feeds the Phase 2 scoring (symbol density ×2, export count ×2, reference centrality ×3). Skipping Serena here means those three factors are zero, which collapses the score-based decision. **Do not skip.**
+
+### Dynamic agent scaling
+After bash analysis, if the project is large, spawn more `@code-searcher` tasks:
+
+| Factor | Threshold | Additional agents |
+|---|---|---|
+| Total source files | >500 | +1 per 500 |
+| Large files (>500 lines) | >10 | +1 focused on complexity hotspots |
+| Directory depth | ≥5 | +2 for deep exploration |
+| Monorepo packages | each | +1 per workspace package |
+
+For monorepos with many packages, spawn one more `@code-searcher` per major package (`apps/*`, `packages/*`, workspace members from `pnpm-workspace.yaml` / `package.json` `workspaces`).
+
+### Merge
+Collect results from all subagents + bash + Serena. Build a single consolidated view of the repo.
+
+---
+
+## Phase 2 — Score & Decide
+
+Score each candidate directory using these weighted factors:
+
+| Factor | Weight | High threshold | Source |
+|---|---|---|---|
+| File count | 3× | >20 | bash |
+| Subdirectory count | 2× | >5 | bash |
+| Code ratio (code files / total) | 2× | >70% | bash |
+| Unique patterns (own eslint/tsconfig/etc.) | 1× | has own config | code-searcher |
+| Module boundary (index.ts / main.py) | 2× | has entry | bash |
+| Symbol density | 2× | >30 symbols | Serena |
+| Export count | 2× | >10 exports | Serena |
+| Reference centrality (imports in other dirs) | 3× | >20 refs | Serena |
+
+**Decision:**
+- **Root (`.`)** — always create/update
+- **Score >15** — create/update AGENTS.md
+- **Score 8-15** — create if it's a distinct domain (distinct config OR distinct import-graph cluster); otherwise skip
+- **Score <8** — skip (parent covers)
+
+Produce the inclusion list:
+
+```
+[
+  { path: ".", type: "root", existing: true },
+  { path: "apps/api", score: 24, existing: true, reason: "API app, own tsconfig, high symbol density" },
+  { path: "packages/core", score: 22, existing: true, reason: "Shared domain logic, distinct import cluster" },
+  ...
+]
+```
+
+---
+
+## Phase 3 — Show the user + gate
+
+Before writing anything, print the inclusion list to the user with scores, existing-or-new, and estimated size (30-80 for subdirs, 50-150 for root). Ask: **"Proceed with this plan? (yes/edit/cancel)"**
+
+This is a deliberate gate. `/init-deep` is destructive-adjacent on `--create-new` and touches many files in update mode. Do NOT skip the confirmation.
+
+---
+
+## Phase 4 — Generate (parallel)
+
+On user approval:
+
+1. **Root first.** Write/Edit the root `AGENTS.md` yourself (not a subagent) — 50-150 lines covering: OVERVIEW, STRUCTURE (non-obvious purpose only), WHERE TO LOOK (task → location table), CODE MAP (top exports from Serena), CONVENTIONS (deviations from standard TS only), ANTI-PATTERNS (this project's NEVERs), UNIQUE STYLES, COMMANDS, NOTES.
+
+2. **Subdirectories in parallel.** For each non-root inclusion-list entry, delegate to `@agents-md-writer`:
+   ```
+   task(agents-md-writer, "Generate AGENTS.md for <directory>. Reason: <score breakdown>. Root AGENTS.md content (for dedup reference): <inlined>.")
+   ```
+   Fire them all at once.
+
+**Edit-vs-Write discipline:** If the target `AGENTS.md` already exists, use Edit (preserve manual additions). If not, Write. Never Write over an existing file.
+
+---
+
+## Phase 5 — Review & dedupe
+
+Once all writers have returned:
+
+- Read each generated/updated file
+- Remove any bullet that duplicates content from the parent AGENTS.md (exact text match or equivalent claim)
+- Trim to size caps (30-80 subdirs, 50-150 root)
+- Scan for verbose prose or generic advice ("this directory contains TypeScript code", "follow best practices") — delete
+- Delegate to `@plan-reviewer` for a final coherence pass if >5 files were written
+
+---
+
+## Report
+
+```
+=== /init-deep complete ===
+
+Mode: update | create-new
+Dirs analyzed: N
+AGENTS.md created: M
+AGENTS.md updated: K
+AGENTS.md skipped (low score): J
+
+Files:
+  [UPDATED] ./AGENTS.md (N lines)
+  [CREATED] ./packages/ui/AGENTS.md (N lines)
+  [UPDATED] ./packages/core/AGENTS.md (N lines)
+  ...
+
+Hierarchy:
+  ./AGENTS.md
+  ├── apps/api/AGENTS.md
+  ├── apps/web/AGENTS.md
+  └── packages/
+      ├── core/AGENTS.md
+      ├── ui/AGENTS.md
+      └── ...
+
+Suggested commit: chore: refresh per-directory AGENTS.md
+```
+
+---
+
+## Anti-patterns (things that fail this command)
+
+- **Static agent count** — must scale agents to project size (see dynamic scaling above).
+- **Sequential execution** — Phase 1 agents must fire concurrently.
+- **Ignoring existing** — always read existing AGENTS.md first, even on `--create-new` (to capture context before overwrite).
+- **Over-documenting** — not every directory gets an AGENTS.md. Score-gate is the whole point.
+- **Child duplicating parent** — Phase 5 dedup is mandatory, not optional.
+- **Generic content** — "use TypeScript strict mode" applies to every TS project; remove it.
+- **Verbose prose** — telegraphic. Bullets over paragraphs.
+- **Skipping the Phase 3 gate** — users must see the plan before you write files.

package/dist/vendor/harness-opencode/dist/commands/prompts/research.md

@@ -0,0 +1,27 @@
+---
+description: Deep codebase exploration via parallel subagents.
+---
+
+# /research — Research Command
+
+**Research Topic:** $ARGUMENTS
+
+## Behavior
+
+This command is a **thin delegator** to the `@research` agent.
+
+1. If no topic is provided, ask the user what they want to research.
+2. Otherwise, invoke the `@research` agent via the task tool with the user's topic.
+
+The `@research` agent handles all planning, parallel dispatch, gap review, iteration, and synthesis. Do NOT orchestrate research inline here.
+
+## Delegation Template
+
+```
+Task tool → @research agent:
+"Research query: {user's topic}
+
+Context: Invoked via /research command."
+```
+
+Wait for `@research` to complete and return its findings to the user.

package/dist/vendor/harness-opencode/dist/commands/prompts/review.md

@@ -0,0 +1,96 @@
+---
+description: Review an existing PR, current branch, staged changes, or a commit range. PRIME-driven, read-only, no file edits.
+---
+
+Review target: $ARGUMENTS
+
+You are the PRIME. This command is **read-only** — you will NOT modify files, run tests in a way that touches the filesystem, commit, push, or edit any plan. You produce a structured review report and stop.
+
+## 1. Resolve the target
+
+Classify the review target silently. Do NOT ask the user to clarify which form they meant — pick the most likely and proceed.
+
+- **Empty / missing** — review the current branch's changes: `git diff $(git merge-base HEAD origin/main)..HEAD` (all commits ahead of main) plus any uncommitted + staged changes (`git diff HEAD`).
+- **Number** (e.g. `1234`) or **merge-request URL** (GitHub PR, GitLab MR, Bitbucket PR, Gitea PR, …) — treat as a merge request. Fetch via whichever host CLI / MCP is available:
+  - **GitHub** (`gh` CLI or `github` MCP): `gh pr view <num> --json title,body,author,labels,files,baseRefName,headRefName` + `gh pr diff <num>`
+  - **GitLab** (`glab` CLI): `glab mr view <num>` + `glab mr diff <num>`
+  - **Bitbucket** (`bb` CLI) or **Gitea** (`tea` CLI): equivalent view/diff commands
+  - **No CLI available**: use `git remote -v` to detect the host, then fetch the patch over HTTPS (e.g., `curl` the PR's `.patch` URL on GitHub) and the metadata via the host's REST API if an auth token is in env
+  If the PR's head branch is checked out locally, also include any uncommitted changes (`git diff HEAD`).
+- **Commit SHA** (7+ hex chars) — review that single commit: `git show <sha>`.
+- **Range** (`A..B` or `A...B`) — review the commit range: `git diff <range>`.
+- **"staged"** — review staged changes only: `git diff --cached`.
+- **"HEAD"** — review the most recent commit only: `git show HEAD`.
+- **A file path** — review uncommitted + last commit touching that file: `git diff HEAD <path>` + `git log -1 -p <path>`.
+
+If the scope is ambiguous after the classifier (rare), make the most-likely pick and state it in your report's opening line.
+
+## 2. Gather context
+
+- **Branch name** → if it looks like it contains a ticket reference (e.g. `<team>/<TICKET>-<slug>`, `<team>-<NUM>`, `feature/<NUM>`, `<prefix>/<TICKET>-...`), try to fetch the underlying issue via any configured issue-tracker MCP. Probe in order: `linear`, `github`/`gh` CLI, `jira`/`atlassian`, other issue MCPs. Use the fetched title + description + acceptance criteria as the "intent" baseline the diff should satisfy. Do NOT ask the user which tracker — probe.
+- **PR description** (if target is a PR) → that's the intent baseline. Note: if the PR body contains a ticket reference (often linked in an "## Issue" / "Fixes:" / "Closes:" section), also try the tracker probe above for the richer source.
+- **No tracker issue, no PR description** → state "no stated intent captured" in the report; judge the diff on its own merits.
+- **Recently modified files in the diff** → for files > 200 lines, run `comment_check` to surface existing `@TODO`/`@FIXME`/`@HACK` context.
+- **Changed TS symbols** → use `serena_find_symbol` + `serena_find_referencing_symbols` on the top-3 most load-bearing symbol changes to measure blast radius. This is the single most important tool-preference for review work.
+
+## 3. Run the review
+
+Delegate to `@qa-reviewer` with:
+- The resolved target (e.g., "PR #1234" or "current branch ahead of main")
+- The intent baseline (tracker issue body + acceptance criteria, or PR description, or "no stated intent")
+- A directive: "Review this as PR-style adversarial analysis — not vs a specific plan. Output structured FAIL findings (file:line + specific issue) or PASS with summary."
+
+If `@qa-reviewer` returns `[PASS]`, accept it. If `[FAIL]`, that's your finding list.
+
+For any finding flagged as security-sensitive or architecture-level (new service boundary, new entity, new auth path, public API shape change), also delegate to `@architecture-advisor` for a second opinion. Include its recommendation in the report.
+
+## 4. Run automated checks inline
+
+- **Type check** (if the project uses a typed language): `tsc_check` on a TS project root, or the equivalent shell invocation (`mypy`, `cargo check`, `go vet`, etc.). Discover from `package.json` / `Cargo.toml` / `go.mod` / `pyproject.toml`.
+- **Lint** (on the specific files changed): `eslint_check` for JS/TS, or the project's configured linter (`ruff`, `golangci-lint`, `rubocop`, etc.). Read from the project's lint config / `CI.yml` / `package.json` scripts to discover the right invocation.
+- `todo_scan` with `onlyChanged: true` against the diff — surface any TODO/FIXME/HACK that was added
+
+Include the output of each in the report. Failures here are not auto-failures of the review (users may be WIP) but they should be surfaced. If the project isn't typed or has no configured linter, skip those lines and note "(not applicable)".
+
+## 5. Report
+
+Output format:
+
+```
+# Review: <target>
+
+## Intent
+<1-2 sentences from tracker issue / PR body, or "no stated intent captured">
+
+## Verdict
+[PASS] or [FAIL] or [PASS WITH CONCERNS]
+
+## Findings
+
+### Must fix (blocking)
+- `<file>:<line>` — <specific issue + suggested approach (not a patch)>
+
+### Should consider (non-blocking)
+- `<file>:<line>` — <concern>
+
+### Automated checks
+- Typecheck: <N errors | clean | not applicable>
+- Lint: <N issues | clean | not applicable>
+- New TODO/FIXME/HACK in diff: <list or none>
+
+### Blast radius
+- <symbol> → used in <N> places, changes are/aren't backwards-compatible
+
+## Architecture note
+<Only if @architecture-advisor was consulted. One paragraph summary.>
+```
+
+Keep findings specific and actionable. Avoid "consider adding tests" — instead, "no test covers the branch at <file>:<line> where <specific scenario>."
+
+## Hard rules
+
+- Read-only. NEVER commit, push, edit files, check out branches, or mutate anything.
+- If the target is a PR on a different branch and you need to see the code, use the host CLI's *diff* subcommand (e.g., `gh pr diff`, `glab mr diff`) — do NOT check out the PR branch locally (`gh pr checkout`, `git fetch + checkout`, etc.). The user's working tree is sacred.
+- One report at the end, not a running commentary.
+- Prefer `serena_find_referencing_symbols` over grep when measuring blast radius on TS code.
+- Do NOT ask the user clarifying questions unless the target genuinely can't be resolved. Pick the most-likely scope and state it.

package/dist/vendor/harness-opencode/dist/commands/prompts/ship.md

@@ -0,0 +1,104 @@
+---
+description: Finalize, commit, squash, push, and open a PR for QA-passed changes. Handles both single-commit and multi-commit (hybrid-autonomy) flows.
+---
+
+The plan at $ARGUMENTS has passed QA review. Ship it.
+
+**User invoking `/ship` IS the approval.** Execute the pipeline end-to-end without asking for per-step permission. Commits, pushes, and PR creation are not destructive — they're the whole point of this command. Only stop for genuinely unexpected states (see "Stop conditions" at the bottom).
+
+**The top-level "YOU MUST use the `question` tool for any clarification" rule is suspended for the duration of this command.** Invoke the `question` tool ONLY for the listed Stop conditions below — not for commit message wording, not for squash-vs-keep-separate, not for "push to origin?", not for "open a PR?". If you find yourself about to call `question`, check the Stop conditions list first; if your situation isn't on it, proceed silently.
+
+Report what you did in one compact message at the end with the PR URL. Do NOT narrate each step individually.
+
+## 1. Survey the working state
+
+Run in parallel:
+- `git status --short`
+- `git log --oneline origin/$(git rev-parse --abbrev-ref HEAD)..HEAD 2>/dev/null || git log $(git merge-base HEAD origin/main)..HEAD --oneline` — local commits ahead of origin (or ahead of main if branch is not pushed)
+- `git diff --stat`
+
+Classify the shape silently and proceed:
+- **Clean + no local commits** — nothing to ship; report "Nothing to ship — working tree clean and no local commits ahead of origin." and STOP.
+- **Dirty + no local commits** — Path A.
+- **Clean + local commits** — Path C.
+- **Dirty + local commits** — Path B.
+
+## 2. Commit / squash
+
+### Path A — single commit
+
+1. Derive a commit message:
+   - If a plan path was given on the command line and the file exists, read its `# <Title>` and `## Goal` to shape the message.
+   - If no plan, derive a title and paragraph from the diff itself (infer the `<type>`: feat / fix / chore / refactor / docs / test / perf).
+2. Format:
+   ```
+   <type>: <title>
+
+   <one paragraph summarizing what and why>
+
+   Plan: <plan-path>                  ← only if a plan path was given (absolute; e.g. ~/.glorious/opencode/<repo>/plans/<slug>.md)
+   ```
+3. `git add -u && git commit -m "<subject>" -m "<body>"` — do it. No confirmation prompt.
+
+### Path B — hybrid (local commits exist + uncommitted changes)
+
+1. Commit the uncommitted changes using Path A's message logic (one atomic commit of the remaining work).
+2. Squash all local commits into one:
+   - Determine base: `BASE=$(git merge-base HEAD origin/main)`
+   - Derive the final squash message from the plan (if given) or from the union of commit subjects.
+   - `git reset --soft "$BASE" && git commit -m "<subject>" -m "<body>"`
+3. No confirmation prompts. Just do it.
+
+### Path C — local commits only, no dirty changes
+
+- **Single local commit** → skip straight to push.
+- **Multiple local commits** → squash to one using Path B's squash sub-flow (derive message from plan / commit subjects).
+
+## 3. Push
+
+1. `BRANCH=$(git rev-parse --abbrev-ref HEAD)`
+2. `git push -u origin "$BRANCH"` — just do it. First push sets upstream automatically.
+3. On non-fast-forward or hook failure → STOP (see stop conditions).
+
+## 4. Open a PR
+
+1. Detect the git host from `git remote get-url origin`.
+2. Derive the PR body:
+   - If a plan path was given and the file exists → body is the plan contents (escape backticks/dollar signs/newlines for shell).
+   - Else → body is the commit's body (from `git log -1 --pretty=%b`).
+3. Create the PR:
+   - **GitHub**: `gh pr create --title "<subject>" --body "$(cat <path-or-tempfile>)"`
+   - **GitLab**: `glab mr create --title "<subject>" --description "$(cat <path-or-tempfile>)"`
+   - **Bitbucket**: `bb pr create --title "<subject>" --body "$(cat ...)"` (fall through if `bb` unavailable)
+   - **Gitea / Codeberg**: `tea pr create --title "<subject>" --description "$(cat ...)"`
+   - **Unknown host or no CLI**: construct and print the web URL (e.g., `https://<host>/<owner>/<repo>/compare/<base>...<head>?expand=1`). Report it so the user can open it manually.
+4. Report the PR URL.
+
+Prefer writing the body to a tempfile and using `--body-file` or `$(cat <tempfile>)` over inlining to dodge shell-escape bugs with backticks and dollar signs in plan content.
+
+## Final report
+
+One message, compact:
+
+```
+Shipped.
+- Commit: <subject> (<sha>)
+- Branch: <branch> → origin
+- PR: <url>
+```
+
+## Stop conditions
+
+Only stop and ask if:
+- **Non-fast-forward push** — someone else pushed to this branch; never force. Report and ask what to do.
+- **Pre-commit or pre-push hook failure** — NEVER use `--no-verify`. Report the hook output verbatim and ask the user. Fix the root cause if they direct you to.
+- **Working tree shape doesn't match any of the four classes above** (e.g., detached HEAD, merge in progress, rebase in progress) — report and ask.
+- **User has *unstaged* changes that look unrelated to the plan** — e.g., the plan says you're shipping a React refactor but the diff includes edits to unrelated files. Report the suspicious files and ask before committing them.
+
+## Hard rules
+
+- **Never** `git push --force` or `git push -f`. Permission-denied anyway. If non-fast-forward, stop and ask — the user decides.
+- **Never** `git reset --hard`. Use `git reset --soft` only, and only for the squash case in Path B/C.
+- **Never** use `--no-verify` or `--no-gpg-sign`. If a hook fails, stop and report.
+- **Never** merge a PR — that's always the user's call.
+- Everything else (commit, push, PR open, PR body write, upstream set) is a normal tool call. Just do it.

package/dist/vendor/harness-opencode/dist/index.d.ts

@@ -0,0 +1,21 @@
+import { Plugin } from '@opencode-ai/plugin';
+
+/**
+ * @glrs-dev/harness-plugin-opencode — OpenCode plugin entry point.
+ *
+ * Registers agents, commands, MCPs, tools, and skills at runtime via the
+ * OpenCode plugin `config` hook. Zero filesystem writes to user space.
+ *
+ * Skills are registered by pushing the bundled dist/skills/ directory onto
+ * config.skills.paths. OpenCode's scanner processes hardcoded paths first,
+ * then config.skills.paths last — so plugin-bundled skills win on name
+ * collision (plugin-wins precedence, empirically verified in Spike 1).
+ *
+ * Agents, commands, and MCPs use user-wins precedence:
+ *   input.agent = { ...ourAgents, ...(input.agent ?? {}) }
+ * so user's opencode.json overrides take effect.
+ */
+
+declare const plugin: Plugin;
+
+export { plugin as default };