@rexeus/agentic 0.3.1

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

@@ -0,0 +1,170 @@
+---
+description: "Start implementation of a planned feature or task. Runs the full pipeline from understanding through testing."
+agent: "lead"
+---
+
+<!-- Generated by pnpm run sync:opencode-commands -->
+
+# Develop
+
+Start implementation. This command runs the full development pipeline:
+understand → design → build → verify.
+
+**Usage:**
+
+- `/agentic-develop Implement the token refresh logic from the plan`
+- `/agentic-develop continue` — continue from where the last session left off
+
+## Prerequisites
+
+This command works best after `/agentic-plan` has produced an approved plan.
+If no plan exists, the command will create a lightweight plan first.
+
+## Workflow
+
+### Step 0: Create Progress Tracker
+
+Before starting any work, create a task list that maps the full pipeline
+for this task. Each task names the responsible agent and describes the
+concrete step. Example:
+
+1. "Scout the relevant modules" — scout (skip if already done)
+2. "Design implementation approach" — architect (skip if plan exists)
+3. "Implement feature X" — developer
+4. "Review implementation" — reviewer
+5. "Write and run tests" — tester
+6. "Refine if needed" — refiner (optional)
+
+Mark tasks `in_progress` as you start them and `completed` when done.
+Skip tasks that were already covered by a prior `/agentic-plan` run.
+
+### Step 1: Establish Context
+
+If `$ARGUMENTS` contains "continue":
+
+1. Check `git log --oneline -5` for recent commits
+2. Check `git diff` for unstaged changes (work in progress)
+3. Check `git diff --cached` for staged changes
+4. Present your understanding of the current state to the user for confirmation
+   before proceeding
+
+Otherwise, determine the task:
+
+- Is there an existing plan from `/agentic-plan`? Use it.
+- Is `$ARGUMENTS` a clear, self-contained task? Proceed directly.
+- Is the task ambiguous? Ask the user to clarify, or suggest running
+  `/agentic-plan` first.
+
+### Step 2: Reconnaissance (if needed)
+
+If the task touches unfamiliar code:
+
+1. Deploy **scout** to map the relevant modules
+2. If the scout returns insufficient context, ask the user for guidance
+3. Deploy **analyst** if the scout reveals complexity
+
+Skip this step if a recent `/agentic-plan` already covered the codebase.
+
+### Step 3: Design (if needed)
+
+If no architecture plan exists:
+
+1. Deploy **architect** to produce a lightweight implementation plan
+2. Present the plan to the user for approval
+3. Wait for confirmation before proceeding
+4. If the user rejects the plan, iterate on the design or ask for
+   clarification. Do not proceed to implementation without approval.
+
+Skip this step if `/agentic-plan` already produced an approved design.
+
+### Step 4: Implement
+
+Deploy **developer** with a briefing concrete enough that the developer
+can start coding immediately — no interpretation, no planning needed.
+
+**Required in every developer briefing:**
+
+1. **Implementation plan** — Pass through the architect's full plan, not a
+   summary. Must include: files to create/modify, interfaces/signatures,
+   implementation order, and edge cases to handle.
+2. **Scout report** — Codebase patterns, naming conventions, file structure.
+3. **Scope boundary** — What is in scope, what is explicitly out.
+4. **Test command** — How to run the test suite.
+
+**Rule of thumb:** If you can read your briefing and immediately know which
+file to open and what to type, it's concrete enough. If you'd need to
+"figure out the approach first" — it's too vague and the developer will
+plan instead of code.
+
+The developer implements incrementally. After each logical unit:
+
+- Verify the code compiles/parses
+- Run existing tests to catch regressions
+
+### Step 5: Verify
+
+Launch in parallel:
+
+**reviewer** — Analyze the implementation for:
+
+- Correctness, security, convention adherence
+- Alignment with the architecture plan
+- Confidence-scored findings (threshold 80)
+
+**tester** — Write and run tests for:
+
+- New functionality (unit tests)
+- Edge cases identified in the plan
+- Integration points
+
+### Step 6: Iterate
+
+If the reviewer or tester found issues:
+
+1. Summarize all findings for the user
+2. Ask whether to fix now or note for later
+3. If fixing: send the developer back with specific findings
+4. Re-run verification after fixes
+
+Repeat until the reviewer passes and tests are green,
+or the user decides to stop.
+
+### Step 7: Refine (optional)
+
+If the reviewer flagged complexity, deep nesting, or convoluted logic
+(severity Warning or above), or if the user requests simplification:
+
+1. Ask the user whether to simplify before committing
+2. If yes: deploy the **refiner** with the reviewer's findings and the
+   current file list
+3. The refiner simplifies incrementally, verifying tests after each change
+4. Re-run the **tester** to confirm nothing broke
+
+Skip this step if the code is already clean and the reviewer had no
+complexity-related findings.
+
+### Step 8: Summary
+
+When complete, present:
+
+```
+## Development Summary
+
+### What was built
+<brief description>
+
+### Files changed
+- `path/file.ts` — created / modified (what changed)
+
+### Test results
+- X tests written, all passing
+- Coverage: X% for new code
+
+### Review findings
+- X issues found, X fixed, X deferred
+
+### Next steps
+- <any remaining work or follow-up tasks>
+```
+
+Suggest running `/agentic-commit` to commit the changes.

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

@@ -0,0 +1,165 @@
+---
+description: "Plan a new feature or task. Critically evaluates requirements, presents options, and produces an implementation plan."
+agent: "lead"
+---
+
+<!-- Generated by pnpm run sync:opencode-commands -->
+
+# Plan
+
+Plan a new feature or task. This command challenges assumptions, explores
+options, and produces a concrete plan — before any code is written.
+
+**Usage:**
+
+- `/agentic-plan Add user authentication with OAuth`
+- `/agentic-plan Refactor the payment module for multi-currency support`
+
+## Philosophy
+
+The most expensive bugs are wrong assumptions made before the first line of code.
+This command exists to catch them. Your job is to be the critical thinker who
+asks the hard questions BEFORE the team starts building.
+
+## Workflow
+
+### Step 1: Understand the Request
+
+Read `$ARGUMENTS` carefully. If no arguments were provided, ask the user
+what they want to build.
+
+This is the most critical step. A brilliant plan for the wrong problem is
+worthless. Your job is to be a **critical thinking partner** — not a
+yes-machine that immediately starts planning.
+
+#### 1a: Clarify
+
+Ask questions until the problem is crystal clear:
+
+- **What exactly should change?** Get specific. "Improve performance" is not
+  a requirement — "Reduce API response time from 2s to 200ms" is.
+- **What's the success criteria?** How will we know it's done? What does
+  "done" look like?
+- **Who is this for?** End users? Other developers? An internal system?
+- **What's the context?** Why now? What triggered this? Is there urgency?
+- **What are the constraints?** Budget, time, tech stack, backwards compatibility?
+
+#### 1b: Challenge
+
+Play devil's advocate. Respectfully but firmly question the idea:
+
+- **Is this the right problem?** Or is it a symptom of a deeper issue?
+- **Do we actually need this?** What's the cost of NOT doing it?
+- **What could go wrong?** What are the risks, failure modes, unintended consequences?
+- **Is there a simpler way?** Could we achieve 80% of the value with 20% of the effort?
+- **What are we giving up?** Every feature has opportunity cost. What won't we build?
+- **Have we seen this pattern before?** Does the codebase already solve a similar
+  problem we can learn from?
+
+#### 1c: Confirm Understanding
+
+Restate the problem in your own words. Include:
+
+- The core problem being solved
+- The key constraints
+- What success looks like
+- Anything explicitly out of scope
+
+**Do NOT proceed until the user confirms your understanding.** If they
+correct you, update and confirm again. This loop can take multiple rounds.
+
+### Step 2: Reconnaissance
+
+Deploy the **scout** to map relevant areas of the codebase:
+
+- What exists today that relates to this feature?
+- What patterns does the codebase use?
+- What constraints exist (framework, language, architecture)?
+
+If the scout reveals complexity, deploy the **analyst** to trace
+the relevant code paths in depth.
+
+### Step 3: Present Options
+
+Deploy the **architect** to design 2-3 approaches. For each option, present:
+
+```
+## Option A: <name>
+
+**Approach:** What this option does and how it works.
+
+**Pros:**
+- ...
+
+**Cons:**
+- ...
+
+**Effort:** Low / Medium / High
+
+**Risk:** Low / Medium / High
+
+**Fits existing patterns:** Yes / No — explanation.
+```
+
+**Always present at least 2 options.** If there seems to be only one way,
+think harder — there's always a trade-off worth exploring.
+
+Include a recommendation, but make it clear this is YOUR recommendation
+and the user decides.
+
+### Step 4: User Decision
+
+Wait for the user to choose an option or provide feedback.
+Do NOT proceed to implementation planning without explicit user choice.
+
+If the user has questions or wants to modify an option, iterate.
+This step can take multiple rounds — that's the point.
+
+### Step 5: Implementation Plan
+
+Once the user approves an approach, produce a concrete plan:
+
+```
+## Implementation Plan: <feature>
+
+### Overview
+<1-2 sentences describing the chosen approach>
+
+### Files to Create
+- `path/file.ts` — purpose
+
+### Files to Modify
+- `path/file.ts` — what changes and why
+
+### Implementation Steps
+1. <step> — <why this order>
+2. <step>
+3. <step>
+
+### Edge Cases
+- <case> — how to handle
+
+### Testing Strategy
+- Unit tests for: ...
+- Integration tests for: ...
+
+### Open Questions
+- <anything still unresolved>
+```
+
+Present the plan for final approval.
+
+### Step 6: Transition to Development
+
+Once the plan is approved, ask the user directly:
+
+> "The plan is ready. Any questions, or shall we start building?"
+
+- If the user has questions — answer them, iterate on the plan.
+- If the user says go — **transition seamlessly into the develop pipeline.**
+  Do NOT wait for them to manually invoke `/agentic-develop`. You have the
+  plan, the context, and the scout findings. Proceed directly:
+  1. Create a progress tracking task list based on the implementation steps
+  2. Start with Step 4 of the develop workflow (Implement), since planning
+     and reconnaissance are already done
+  3. Continue through verification, iteration, and summary as normal

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

@@ -0,0 +1,190 @@
+---
+description: "Iterative codebase harmonization. Discovers patterns, finds inconsistencies, and unifies code across files."
+agent: "lead"
+---
+
+<!-- Generated by pnpm run sync:opencode-commands -->
+
+# Polish
+
+Iterative codebase harmonization. This command discovers the patterns your
+project already uses, finds where files diverge, and systematically unifies
+everything — same voice, same structure, same quality across every file.
+
+**Designed for the loop.** Run it, review the changes, clear context, run again.
+Each pass finds fewer issues until the codebase converges.
+
+**Usage:**
+
+- `/agentic-polish src/services/` — polish a specific area
+- `/agentic-polish services and repositories` — polish by concept
+- `/agentic-polish` — will ask what to polish
+- `/agentic-polish --dry-run` — discovery + plan only, no changes
+
+## Philosophy
+
+Consistency is not about rules — it's about voice. When every file reads like it
+was written by the same developer, the codebase becomes navigable by intuition.
+You know where things are before you look. You know how they work before you read.
+
+This is not `/agentic-review` (which finds issues in a diff) and not
+`/agentic-simplify` (which reduces complexity within code). Polish compares
+**peer files against each other** and unifies them toward a single voice.
+
+## Workflow
+
+### Step 1: Determine Scope
+
+Parse `$ARGUMENTS` to understand what to polish:
+
+- **File path** → polish that file against its peers
+- **Directory** → polish all files in that area
+- **Concept** (e.g., "services", "hooks", "components") → scout for relevant files
+- **`--dry-run`** → run Discovery + Synthesis only, skip Execute
+- **No arguments** → Ask the user:
+  "What should I polish? Options:
+  1. A specific directory (provide path)
+  2. An architectural layer (e.g., 'services', 'components', 'hooks')
+  3. The entire repository
+  4. Discovery only (`--dry-run` for analysis without changes)"
+
+### Step 2: Discovery
+
+Deploy 4 agents in parallel. Each brings a different lens — independent
+analysis, no cross-contamination between agents.
+
+**Scout 1 — Structure Map:**
+
+> Map the file structure within `<scope>`. For each file group (e.g., services,
+> components, hooks, utils), report: file names, naming patterns, export
+> patterns, file sizes (lines), and directory organization. Facts only.
+
+**Scout 2 — Quantitative Profile:**
+
+> Measure the code within `<scope>`. For each file, report: number of
+> functions/methods, function lengths (lines), parameter counts, nesting
+> depth, import counts. Present as a table. Facts only.
+
+**Analyst 1 — Pattern Extraction:**
+
+> Analyze the code within `<scope>` and extract the patterns currently in
+> use. Document: how are similar files structured? What conventions are
+> followed? What is the common shape of a service / component / hook /
+> repository? Produce a **Pattern Catalog** — the project's current voice.
+
+**Analyst 2 — Cross-File Comparison:**
+
+> Compare files of the same type within `<scope>`. For each group of peer
+> files (e.g., all services, all components), identify: where do they
+> diverge in structure, naming, error handling, or approach? Where is code
+> duplicated? Where do patterns contradict? Produce an **Inconsistency Report**.
+
+### Step 3: Codebase Portrait
+
+Synthesize the 4 reports into a unified view:
+
+```
+## Codebase Portrait: <scope>
+
+### Current Patterns
+<The project's voice — what conventions and structures are actually used>
+
+### Inconsistencies
+
+**High** — Patterns that fundamentally differ between peer files:
+- ...
+
+**Medium** — Structural differences, naming inconsistencies:
+- ...
+
+**Low** — Minor formatting, ordering differences:
+- ...
+
+### Duplication
+<Code that appears in multiple places and should be extracted>
+
+### Recommended Standard
+<For each file group: the pattern that should become the norm,
+based on what the majority already does or what the best example does>
+
+### Estimated Scope
+- Files to change: <count>
+- Nature: <what kinds of changes>
+```
+
+Present the Codebase Portrait to the user. **Wait for approval before proceeding.**
+
+If `--dry-run` was specified, stop here. The portrait IS the deliverable.
+
+### Step 4: Unification Plan
+
+Deploy the **architect** with the Codebase Portrait:
+
+> Design a unification plan for `<scope>`. The Codebase Portrait shows the
+> current patterns and inconsistencies. Produce a concrete plan: which
+> pattern becomes the standard for each file group, which files need changes,
+> and in what order (dependencies first, leaf files last). Group changes
+> logically so each group can be verified independently.
+
+Present the plan to the user. **Wait for approval.**
+
+### Step 5: Execute
+
+Deploy the **developer** with:
+
+- The full architect plan (not a summary)
+- The Pattern Catalog from Analyst 1 (so the developer matches the voice)
+- The scout reports (for codebase context)
+- Clear scope boundaries
+- Test command
+
+The developer works group by group. After each logical group:
+
+1. Run tests to catch regressions
+2. Verify the changes match the approved pattern
+
+If the scope is large, check in with the user between groups.
+
+### Step 6: Verify
+
+Launch in parallel:
+
+**reviewer** — Check that the changes are consistent with the approved pattern
+and don't introduce bugs. Compare modified files against the Pattern Catalog.
+
+**tester** — Confirm all tests pass and no behavior changed.
+
+If the reviewer finds regressions toward inconsistency, send the developer
+back with specific findings. Re-verify after fixes.
+
+### Step 7: Convergence Report
+
+```
+## Polish Report: <scope>
+
+### Changes Applied
+- Files modified: <count>
+- Nature: <summary of what was unified>
+
+### Consistency
+- Before: <X inconsistencies across Y file groups>
+- After: <X inconsistencies remaining>
+
+### What Was Unified
+1. **<category>** — <what changed and why>
+2. ...
+
+### What Remains
+- <areas that were out of scope or need a separate pass>
+- <deeper structural issues that require design decisions>
+
+### Convergence
+<One of:>
+- "Significant inconsistencies remain. Another pass is recommended."
+- "Minor inconsistencies remain. One more pass should reach convergence."
+- "No significant inconsistencies detected. Codebase is harmonized."
+
+### Next Steps
+- <If more passes needed>: "Clear context and run `/agentic-polish <scope>` again."
+- <If harmonized>: "Ready for `/agentic-commit`."
+```