@rexeus/agentic 0.3.1

package/assets/opencode/commands/agentic-pr.md

@@ -0,0 +1,226 @@
+---
+description: "Create or update a Pull Request with a well-crafted title and description."
+agent: "lead"
+---
+
+<!-- Generated by pnpm run sync:opencode-commands -->
+
+# Pull Request
+
+Create a new Pull Request or update an existing one. Analyzes all commits and
+the full diff to generate a Conventional Commits title and a structured
+description that tells reviewers exactly what changed and why.
+
+**Usage:**
+
+- `/agentic-pr` — create or update a PR for the current branch
+- `/agentic-pr --base develop` — target a specific base branch
+- `/agentic-pr --draft` — create as Draft PR (work in progress, not yet review-ready)
+- `/agentic-pr --update` — force-update an existing PR's title and description
+
+## Rules
+
+- **Follow Conventional Commits** for the PR title — consistent with `/agentic-commit`.
+- **Never merge.** This command creates or updates PRs. It never merges them.
+- **Never force-push.** If the branch needs pushing, use a normal push.
+- **Respect existing reviews.** When updating a PR that has reviews or comments,
+  warn the user before overwriting the description.
+
+## Workflow
+
+### Step 1: Detect State
+
+Run these in parallel:
+
+```bash
+git branch --show-current
+```
+
+```bash
+git rev-parse --abbrev-ref --symbolic-full-name @{upstream} 2>/dev/null
+```
+
+```bash
+gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'
+```
+
+```bash
+gh pr view --json number,title,body,url,state,reviews,isDraft 2>/dev/null
+```
+
+Determine:
+
+- **Current branch** — if on the default branch, stop: "You're on the default
+  branch. Create a feature branch first."
+- **Remote tracking** — is the branch pushed?
+- **Existing PR** — does a PR already exist for this branch?
+- **Default branch** — what is the repo's default branch?
+
+### Step 2: Determine Base Branch
+
+Use this priority:
+
+1. If `$ARGUMENTS` contains `--base <branch>` — use that branch.
+2. If an existing PR exists — use that PR's base branch.
+3. Otherwise — use the repo's default branch.
+
+Present the base branch to the user:
+
+> "PR targets `main` — does that look right?"
+
+Only wait for confirmation if the base branch seems unusual (e.g., not `main`
+or `develop`). For the default branch, proceed unless the user intervenes.
+
+### Step 3: Verify Push State
+
+Check whether the local branch is up-to-date with its remote:
+
+```bash
+git rev-parse HEAD
+git rev-parse @{upstream} 2>/dev/null
+```
+
+**If no upstream exists**, stop and tell the user:
+
+> "Branch `feature/token-refresh` has no remote tracking branch.
+> Push it first: `git push -u origin feature/token-refresh`"
+
+**If local is ahead of remote** (unpushed commits), stop and tell the user:
+
+> "Branch has unpushed commits. Push first: `git push`"
+
+**If diverged**, stop and tell the user to reconcile.
+
+**Never push.** Pushing is the user's responsibility. Only proceed to Step 4
+when local and remote are in sync.
+
+### Step 4: Analyze Changes
+
+Run in parallel:
+
+```bash
+git log <base>..HEAD --oneline
+```
+
+```bash
+git log <base>..HEAD --format="%s%n%n%b" --no-merges
+```
+
+```bash
+git diff <base>...HEAD --stat
+```
+
+```bash
+git diff <base>...HEAD
+```
+
+Read the full diff carefully. Understand:
+
+- **What changed** — files created, modified, deleted
+- **Why it changed** — derive intent from commit messages and code context
+- **Scope** — is this a single feature, a bugfix, a refactor, or multiple things?
+- **Breaking changes** — any API changes, removed exports, schema migrations?
+- **Related issues** — any `#123` references in commits or code comments?
+
+For large diffs (50+ files), focus on the commit messages and diff stat first,
+then read the most significant file changes.
+
+### Step 5: Generate Title and Description
+
+**Title** — Conventional Commits format, max 100 characters:
+
+```
+<type>[optional scope][optional !]: <description>
+```
+
+- Derive the type from the changes (feat, fix, refactor, docs, chore, etc.)
+- Scope is optional — use it when the changes are focused on one module
+- Imperative mood, lowercase, no period
+
+**Description** — structured, scannable, reviewer-friendly:
+
+```markdown
+## Summary
+
+<1-3 sentences: what this PR does and why. Not how — the diff shows how.>
+
+## Changes
+
+- <grouped by concern, each bullet is a concrete change>
+- <reference specific files when helpful>
+- <note any non-obvious design decisions>
+
+## Breaking Changes
+
+<only include this section if there are breaking changes>
+- <what breaks and how to migrate>
+
+## Test Plan
+
+- <how to verify this works>
+- <what tests were added or should be run>
+- <edge cases covered>
+```
+
+**Rules for the description:**
+
+- Write for the reviewer, not for yourself. They haven't seen this code before.
+- Lead with the WHY, not the WHAT. The diff shows what changed.
+- Be specific. "Updated auth logic" is useless. "Added token expiry check
+  to prevent stale sessions from bypassing rate limits" is useful.
+- If commits reference issues, add them naturally in the Summary
+  (e.g., "Fixes #234").
+- Don't pad with filler. If the change is small, the description should be small.
+
+### Step 6: Present and Confirm
+
+**For a new PR:**
+
+Show:
+
+1. The full title
+2. The full description
+3. Whether it will be created as a draft
+4. The base branch
+
+Wait for approval. The user may edit the title, description, or both.
+
+**For an existing PR update:**
+
+Show:
+
+1. Current title → proposed title
+2. Current description → proposed description (or a summary of what changed)
+3. Whether the PR has existing reviews (warn if so)
+
+Wait for approval.
+
+### Step 7: Execute
+
+**Create new PR:**
+
+```bash
+gh pr create --title "<title>" --body "$(cat <<'EOF'
+<description>
+EOF
+)" [--draft]
+```
+
+**Update existing PR:**
+
+```bash
+gh pr edit <number> --title "<title>" --body "$(cat <<'EOF'
+<description>
+EOF
+)"
+```
+
+Report the result with the PR URL.
+
+### Step 8: Follow-up
+
+After creating or updating, suggest next steps if relevant:
+
+- "PR created: <url>"
+- If draft: "Draft PR created. When ready for review: `gh pr ready`"
+- If the reviewer/tester pipeline hasn't run: suggest `/agentic-review`

package/assets/opencode/commands/agentic-review.md

@@ -0,0 +1,119 @@
+---
+description: "Independent multi-agent code review. Reviews different aspects in parallel with specialized agents."
+agent: "lead"
+---
+
+<!-- Generated by pnpm run sync:opencode-commands -->
+
+# Review
+
+Run an independent, multi-agent code review. Different agents examine different
+aspects of the code in parallel for thorough, unbiased analysis.
+
+**When to use this vs `/agentic-verify`:**
+Use **review** when you want a focused code review — finding bugs, security
+issues, and convention violations. Use **verify** when you want a full pre-ship
+quality gate that also runs tests and checks for simplification opportunities.
+
+**Usage:**
+
+- `/agentic-review` — will ask what to review
+- `/agentic-review 42` — review PR #42
+- `/agentic-review --staged` — review staged changes
+- `/agentic-review --branch` — review current branch vs base
+- `/agentic-review --commits=3` — review the last 3 commits
+
+## Workflow
+
+### Step 1: Determine Scope
+
+Parse `$ARGUMENTS` to determine what to review:
+
+- **Number** → PR review via `gh pr diff <number>`
+- **`--staged`** → staged changes via `git diff --cached`
+- **`--branch`** → branch diff. Detect the default branch dynamically via
+  `git symbolic-ref refs/remotes/origin/HEAD`, then `git diff <base>...HEAD`
+- **`--commits=N`** → recent commits via `git diff HEAD~N...HEAD`
+- **No arguments** → Ask the user:
+  "What should I review? Options:
+  1. A pull request (provide PR number)
+  2. Staged changes (--staged)
+  3. Current branch vs main (--branch)
+  4. Recent commits (--commits=N)"
+
+Do NOT guess. If the scope is unclear, ask.
+
+### Step 2: Gather Context
+
+Collect in parallel:
+
+- The diff (from the determined scope)
+- CLAUDE.md files in the repository and affected directories
+- PR description and comments (if reviewing a PR)
+- Recent commit messages for context
+
+If the diff is empty, report "Nothing to review." and stop.
+
+### Step 3: Parallel Review
+
+Launch 3 review agents in parallel, each with the full diff and context:
+
+**Agent 1: Correctness Review** (reviewer agent)
+Focus: Logic errors, bugs, null access, race conditions, missing error handling.
+Lens: Correctness + Security + Plan Alignment from the reviewer's review lenses.
+
+**Agent 2: Convention Review** (reviewer agent)
+Focus: Naming, structure, patterns, CLAUDE.md compliance, code style.
+Lens: Conventions + Quality Patterns from the reviewer's review lenses.
+
+**Agent 3: Test Coverage Assessment** (tester agent, assessment mode)
+Focus: Are the changes adequately tested? What edge cases are missing?
+Mode: Read-only assessment. Do NOT write tests — only assess and report gaps.
+This overrides the tester's default write mode for this specific use case.
+
+Each agent scores findings with confidence (0-100). Threshold: 80.
+
+### Step 4: Synthesize
+
+Collect findings from all 3 agents. Deduplicate (same issue found by
+multiple agents counts once, with the highest confidence score).
+
+### Step 5: Output
+
+```
+## Code Review
+
+**Scope:** <what was reviewed>
+**Files:** <count>
+**Findings:** <count> (<critical> critical, <warnings> warnings, <suggestions> suggestions)
+
+### Critical
+**[Critical | 95]** `file:line` — description
+Why: explanation
+
+### Warnings
+**[Warning | 85]** `file:line` — description
+Why: explanation
+
+### Suggestions
+**[Suggestion | 82]** `file:line` — description
+
+### Test Coverage
+- Covered: <what's tested>
+- Gaps: <what's missing>
+- Recommended: <specific tests to add>
+
+---
+**Confidence threshold: 80.** Lower-confidence findings were excluded.
+To address findings: `/agentic-develop continue`
+```
+
+### False Positive Policy
+
+Do NOT flag:
+
+- Pre-existing issues not in the current diff
+- Style preferences not in CLAUDE.md or conventions skill
+- Issues linters or type checkers catch automatically
+- Runtime-dependent speculative issues
+- Explicitly suppressed issues (ignore comments)

package/assets/opencode/commands/agentic-simplify.md

@@ -0,0 +1,123 @@
+---
+description: "Simplify existing code. Reduces complexity, improves readability, and removes unnecessary abstractions — without changing behavior."
+agent: "lead"
+---
+
+<!-- Generated by pnpm run sync:opencode-commands -->
+
+# Simplify
+
+Simplify existing code. This command takes working code and distills it
+to its essence — fewer moving parts, same behavior, clearer intent.
+
+**Usage:**
+
+- `/agentic-simplify src/auth/session.ts` — simplify a specific file
+- `/agentic-simplify src/payments/` — simplify a module
+- `/agentic-simplify the checkout flow` — simplify by concept
+
+## Philosophy
+
+Elegance is achieved not when there is nothing left to add, but when there
+is nothing left to take away. This command exists to turn working code into
+_inevitable_ code — so clear that no one would think to write it differently.
+
+## Workflow
+
+### Step 1: Determine Scope
+
+Parse `$ARGUMENTS` to understand what to simplify:
+
+- **File path** → simplify that file
+- **Directory** → simplify the module
+- **Concept** → scout for relevant files, then simplify
+- **No arguments** → Ask the user:
+  "What should I simplify? Options:
+  1. A specific file (provide path)
+  2. A module or directory
+  3. Recent changes (`--recent` for last commit's files)
+  4. Complexity hotspots (`--hotspots` for auto-detection)"
+
+If `--recent` is specified, get changed files from `git diff HEAD~1 --name-only`.
+
+If `--hotspots` is specified, deploy the **scout** to identify files with
+high nesting, long functions, or excessive complexity.
+
+### Step 2: Understand Before Simplifying
+
+Deploy the **analyst** to study the target code:
+
+- What is this code's purpose?
+- How does data flow through it?
+- What are the dependencies and callers?
+- Where is the accidental complexity vs. essential complexity?
+
+This step is critical. You cannot simplify what you do not understand.
+Accidental complexity can be removed. Essential complexity cannot.
+
+### Step 3: Establish Baseline
+
+Before any changes:
+
+1. Run the full test suite — record the result
+2. Note line counts for files in scope
+3. Identify the specific complexities to address
+
+If tests are not passing before you start, **stop**. Report the failing
+tests and ask the user how to proceed. Never simplify broken code.
+
+### Step 4: Simplify
+
+Deploy the **refiner** with:
+
+- The analyst's findings (from step 2)
+- The baseline metrics (from step 3)
+- Clear scope boundaries
+
+The refiner works incrementally — one simplification at a time,
+verifying tests after each change.
+
+### Step 5: Verify
+
+Deploy the **tester** to confirm:
+
+- All existing tests still pass
+- No behavior has changed
+- Edge cases are still covered
+
+If the tester finds regressions, send the refiner back to revert
+the problematic simplification.
+
+### Step 6: Summary
+
+When complete, present:
+
+```
+## Simplification Summary
+
+### Scope
+<what was simplified>
+
+### Before → After
+- Lines: <before> → <after> (<net change>)
+- Files touched: <count>
+
+### Simplifications
+1. **<description>** — `path/file.ts`
+   <what changed and why it's simpler>
+
+2. **<description>** — ...
+
+### Preserved
+- All <count> tests passing
+- No behavior changes
+
+### Left Alone
+- <areas considered but intentionally untouched, with reasoning>
+
+### Next Steps
+- <any follow-up work or deeper simplifications the user could consider>
+```
+
+Suggest running `/agentic-review --staged` to verify the simplifications,
+then `/agentic-commit` to commit them.

package/assets/opencode/commands/agentic-verify.md

@@ -0,0 +1,193 @@
+---
+description: "Run a multi-agent quality gate on current changes. Checks correctness, complexity, and tests in parallel."
+agent: "lead"
+---
+
+<!-- Generated by pnpm run sync:opencode-commands -->
+
+# Verify
+
+Pre-ship quality gate. Deploys three parallel agents to answer one question:
+**are these changes ready to ship?**
+
+**When to use this vs `/agentic-review`:**
+Use **verify** as the final check before committing or creating a PR — it runs
+correctness review, complexity analysis, AND tests together. Use **review** for
+a focused code review without running tests or checking complexity.
+
+**Usage:**
+
+- `/agentic-verify` — verify all changes on the current branch vs. default branch
+- `/agentic-verify --staged` — verify only staged changes
+- `/agentic-verify --base develop` — verify against a specific base branch
+
+## What It Checks
+
+Three agents run in parallel, each with a different lens:
+
+| Agent                      | Focus                                                         | Mode            |
+| -------------------------- | ------------------------------------------------------------- | --------------- |
+| **Reviewer** (correctness) | Bugs, security, conventions                                   | Read-only       |
+| **Reviewer** (complexity)  | Simplification opportunities, over-engineering, readability   | Read-only       |
+| **Tester**                 | Run existing tests — or write tests if none cover the changes | Write or Assess |
+
+## Rules
+
+- **Never modify source code.** This command verifies. It does not fix.
+  The tester may create test files, but source code is untouched.
+- **Never skip agents.** All three run, every time. A partial quality gate
+  is a false quality gate.
+- **Present findings honestly.** Don't soften blocking issues. Don't inflate
+  advisory notes. Signal over noise.
+
+## Workflow
+
+### Step 1: Detect Scope
+
+Run in parallel:
+
+```bash
+git branch --show-current
+```
+
+```bash
+gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name' 2>/dev/null || echo 'main'
+```
+
+```bash
+git diff --stat
+```
+
+```bash
+git diff --cached --stat
+```
+
+Determine the scope:
+
+- If `$ARGUMENTS` contains `--staged` — scope is staged changes only
+  (`git diff --cached`)
+- If `$ARGUMENTS` contains `--base <branch>` — scope is diff against
+  that branch (`git diff <branch>...HEAD`)
+- Otherwise — scope is diff against the repo's default branch
+  (`git diff <default>...HEAD`)
+
+If there are no changes in scope, report "Nothing to verify." and stop.
+
+### Step 2: Gather Context
+
+```bash
+git diff <scope> --stat
+```
+
+```bash
+git diff <scope>
+```
+
+```bash
+git log <base>..HEAD --oneline
+```
+
+Read the full diff. Identify:
+
+- Which files changed and how
+- Which test files exist for the changed code
+- Whether the project has a test runner configured (`package.json` scripts,
+  test config files)
+
+### Step 3: Deploy Agents
+
+Launch all three in parallel. Brief each precisely:
+
+**Reviewer 1 — Correctness:**
+
+> Scope: <changed files>. Diff baseline: <base branch or staged>.
+> Context: <summary of what changed and why, derived from commits>.
+> **Focus: correctness, security, and convention adherence.**
+> Ignore complexity and style preferences — the other reviewer handles that.
+
+**Reviewer 2 — Complexity:**
+
+> Scope: <changed files>. Diff baseline: <base branch or staged>.
+> Context: <summary of what changed and why, derived from commits>.
+> **Focus: complexity and simplification opportunities.** Flag:
+> over-engineering, unnecessary abstractions, functions that do too much,
+> deep nesting, code that could be simpler without losing clarity.
+> Do NOT flag style preferences. Only flag genuine complexity.
+
+**Tester:**
+
+Determine mode based on test coverage:
+
+- Test files exist for the changed code → `mode: assess` (analyze gaps,
+  run existing tests)
+- No test files cover the changed code → `mode: write` (create tests,
+  then run them)
+- Mixed (some covered, some not) → `mode: write` (fill the gaps)
+
+> Files changed: <list>. Test command: <from package.json or config>.
+> Test framework: <detected>. Mode: <write or assess>.
+> Dev notes: <brief context about what changed>.
+
+### Step 4: Synthesize Results
+
+When all three agents return:
+
+1. **Deduplicate** — If both reviewers flag the same issue, report it once
+   with the higher severity.
+
+2. **Categorize findings:**
+   - **Blocking** — Bugs, security issues, test failures. Must fix before shipping.
+   - **Warning** — Significant concerns. Should fix, but not necessarily now.
+   - **Advisory** — Suggestions, minor improvements. Nice to fix.
+
+3. **Produce the Quality Report:**
+
+```markdown
+## Quality Report: <scope description>
+
+**Verdict:** PASS | FAIL | CONDITIONAL
+
+### Blocking
+
+- <findings that must be fixed — empty if none>
+
+### Warnings
+
+- <findings that should be fixed — empty if none>
+
+### Advisory
+
+- <suggestions and minor improvements — empty if none>
+
+### Simplification Opportunities
+
+- <complexity reviewer's findings — empty if code is clean>
+
+### Test Results
+
+- Tests run: <count> passed, <count> failed
+- Tests written: <count new tests, if tester was in write mode>
+- Coverage gaps: <remaining gaps identified>
+
+### Verdict Reasoning
+
+<1-2 sentences explaining the verdict>
+```
+
+### Step 5: Verdict
+
+- **PASS** — No blocking findings. Tests green. Ship it.
+- **FAIL** — Blocking findings or test failures. List what needs fixing.
+- **CONDITIONAL** — Warnings only, no blockers. Present findings and let
+  the user decide.
+
+### Step 6: Suggest Next Steps
+
+Based on the verdict:
+
+- **PASS** → "All green. Ready for `/agentic-commit` or `/agentic-pr`."
+- **FAIL** → "These findings need fixing. Should I send the developer to
+  address them?" (If yes, transition to developer with specific findings.)
+- **CONDITIONAL** → "Warnings but no blockers. Fix now or ship as-is?"
+- **Simplification findings** → "Simplification opportunities detected.
+  `/agentic-simplify` can handle these."