openhermes 2.8.0 → 4.0.0

package/harness/commands/doctor.md

@@ -1,42 +0,0 @@
----
-description: Run OpenCode openhermes health diagnostics
-agent: OpenHermes
-subtask: true
----
-
-# Doctor Command
-
-Run full OpenCode openhermes diagnostics. $ARGUMENTS
-
-## Your Task
-
-1. Load the opencode-doctor skill: `skill({ name: "opencode-doctor" })`
-2. Follow its instructions to validate:
-   - Config syntax (opencode.json valid JSON)
-   - Provider connectivity (LM Studio at http://127.0.0.1:1234/v1)
-   - Cache state (memory records, recall cache)
-    - Auth file integrity
-3. Report results with any fix suggestions
-
-## Automated Checks
-
-Run these commands and report results:
-
-!opencode debug config
-!opencode debug info
-!opencode debug paths
-
-## Report Format
-
-| Check | Result | Issue |
-|-------|--------|-------|
-| Config JSON | PASS/FAIL | |
-| Provider | PASS/FAIL | |
-| Memory MCP | PASS/FAIL | |
-| Plugins | PASS/FAIL | |
-| Skills | PASS/FAIL | |
-
-## After Diagnosis
-
-If issues found: propose fixes, wait for approval, apply.
-If clean: report "OpenHermes: HEALTHY."

package/harness/commands/eval.md

@@ -1,89 +0,0 @@
----
-description: Run evaluation against acceptance criteria
-agent: planner
-subtask: true
----
-
-# Eval Command
-
-Evaluate implementation against acceptance criteria: $ARGUMENTS
-
-## Your Task
-
-Run structured evaluation to verify the implementation meets requirements.
-
-## Evaluation Framework
-
-### Grader Types
-
-1. **Binary Grader** - Pass/Fail
-   - Does it work? Yes/No
-   - Good for: feature completion, bug fixes
-
-2. **Scalar Grader** - Score 0-100
-   - How well does it work?
-   - Good for: performance, quality metrics
-
-3. **Rubric Grader** - Category scores
-   - Multiple dimensions evaluated
-   - Good for: comprehensive review
-
-## Evaluation Process
-
-### Step 1: Define Criteria
-
-```
-Acceptance Criteria:
-1. [Criterion 1] - [weight]
-2. [Criterion 2] - [weight]
-3. [Criterion 3] - [weight]
-```
-
-### Step 2: Run Tests
-
-For each criterion:
-- Execute relevant test
-- Collect evidence
-- Score result
-
-### Step 3: Calculate Score
-
-```
-Final Score = Σ (criterion_score × weight) / total_weight
-```
-
-### Step 4: Report
-
-## Evaluation Report
-
-### Overall: [PASS/FAIL] (Score: X/100)
-
-### Criterion Breakdown
-
-| Criterion | Score | Weight | Weighted |
-|-----------|-------|--------|----------|
-| [Criterion 1] | X/10 | 30% | X |
-| [Criterion 2] | X/10 | 40% | X |
-| [Criterion 3] | X/10 | 30% | X |
-
-### Evidence
-
-**Criterion 1: [Name]**
-- Test: [what was tested]
-- Result: [outcome]
-- Evidence: [screenshot, log, output]
-
-### Recommendations
-
-[If not passing, what needs to change]
-
-## Pass@K Metrics
-
-For non-deterministic evaluations:
-- Run K times
-- Calculate pass rate
-- Report: "Pass@K = X/K"
-
----
-
-**TIP**: Use eval for acceptance testing before marking features complete.

package/harness/commands/go-build.md

@@ -1,87 +0,0 @@
----
-description: Fix Go build and vet errors
-agent: build-go
-subtask: true
----
-
-# Go Build Command
-
-Fix Go build, vet, and compilation errors: $ARGUMENTS
-
-## Your Task
-
-1. **Run go build**: `go build ./...`
-2. **Run go vet**: `go vet ./...`
-3. **Fix errors** one by one
-4. **Verify fixes** don't introduce new errors
-
-## Common Go Errors
-
-### Import Errors
-```
-imported and not used: "package"
-```
-**Fix**: Remove unused import or use `_` prefix
-
-### Type Errors
-```
-cannot use x (type T) as type U
-```
-**Fix**: Add type conversion or fix type definition
-
-### Undefined Errors
-```
-undefined: identifier
-```
-**Fix**: Import package, define variable, or fix typo
-
-### Vet Errors
-```
-printf: call has arguments but no formatting directives
-```
-**Fix**: Add format directive or remove arguments
-
-## Fix Order
-
-1. **Import errors** - Fix or remove imports
-2. **Type definitions** - Ensure types exist
-3. **Function signatures** - Match parameters
-4. **Vet warnings** - Address static analysis
-
-## Build Commands
-
-```bash
-# Build all packages
-go build ./...
-
-# Build with race detector
-go build -race ./...
-
-# Build for specific OS/arch
-GOOS=linux GOARCH=amd64 go build ./...
-
-# Run go vet
-go vet ./...
-
-# Run staticcheck
-staticcheck ./...
-
-# Format code
-gofmt -w .
-
-# Tidy dependencies
-go mod tidy
-```
-
-## Verification
-
-After fixes:
-```bash
-go build ./...    # Should succeed
-go vet ./...      # Should have no warnings
-go test ./...     # Tests should pass
-```
-
----
-
-**IMPORTANT**: Fix errors only. No refactoring, no improvements. Get the build green with minimal changes.

package/harness/commands/go-review.md

@@ -1,71 +0,0 @@
----
-description: Go code review for idiomatic patterns
-agent: review-go
-subtask: true
----
-
-# Go Review Command
-
-Review Go code for idiomatic patterns and best practices: $ARGUMENTS
-
-## Your Task
-
-1. **Analyze Go code** for idioms and patterns
-2. **Check concurrency** - goroutines, channels, mutexes
-3. **Review error handling** - proper error wrapping
-4. **Verify performance** - allocations, bottlenecks
-
-## Review Checklist
-
-### Idiomatic Go
-- [ ] Package naming (lowercase, no underscores)
-- [ ] Variable naming (camelCase, short)
-- [ ] Interface naming (ends with -er)
-- [ ] Error naming (starts with Err)
-
-### Error Handling
-- [ ] Errors are checked, not ignored
-- [ ] Errors wrapped with context (`fmt.Errorf("...: %w", err)`)
-- [ ] Sentinel errors used appropriately
-- [ ] Custom error types when needed
-
-### Concurrency
-- [ ] Goroutines properly managed
-- [ ] Channels buffered appropriately
-- [ ] No data races (use `-race` flag)
-- [ ] Context passed for cancellation
-- [ ] WaitGroups used correctly
-
-### Performance
-- [ ] Avoid unnecessary allocations
-- [ ] Use `sync.Pool` for frequent allocations
-- [ ] Prefer value receivers for small structs
-- [ ] Buffer I/O operations
-
-### Code Organization
-- [ ] Small, focused packages
-- [ ] Clear dependency direction
-- [ ] Internal packages for private code
-- [ ] Godoc comments on exports
-
-## Report Format
-
-### Idiomatic Issues
-- [file:line] Issue description
-  Suggestion: How to fix
-
-### Error Handling Issues
-- [file:line] Issue description
-  Suggestion: How to fix
-
-### Concurrency Issues
-- [file:line] Issue description
-  Suggestion: How to fix
-
-### Performance Issues
-- [file:line] Issue description
-  Suggestion: How to fix
-
----
-
-**TIP**: Run `go vet` and `staticcheck` for additional automated checks.

package/harness/commands/harness-audit.md

@@ -1,90 +0,0 @@
----
-description: Run a self-evaluation audit of the OpenHermes harness
-agent: harness-optimizer
-subtask: true
----
-
-# Harness Audit Command
-
-Run a self-evaluation audit of the OpenHermes harness and return a prioritized scorecard.
-
-## Usage
-
-`/harness-audit [scope] [--format text|json] [--root path]`
-
-- `scope` (optional): `repo` (default), `hooks`, `skills`, `commands`, `agents`
-- `--format`: output style (`text` default, `json` for automation)
-- `--root`: audit a specific path instead of the current working directory
-
-## Self-Evaluation Checklist
-
-Evaluate each category by inspecting the harness files directly. No external script needed.
-
-### 1. Tool Coverage (0-10)
-- [ ] Commands exist for all subagent types
-- [ ] Each command has correct frontmatter (description, agent, subtask)
-- [ ] Agent mapping table is complete and accurate
-- [ ] Language-specific agents exist (Go, Rust)
-- [ ] All command files are discoverable
-
-### 2. Context Efficiency (0-10)
-- [ ] Commands are concise (under 100 lines each)
-- [ ] No redundant or overlapping command content
-- [ ] Delegation instructions are clear
-- [ ] Subagent handoffs minimize context overhead
-- [ ] Templates provide structured output formats
-
-### 3. Quality Gates (0-10)
-- [ ] verify.md has comprehensive checklist
-- [ ] quality-gate.md covers lint/type/build
-- [ ] test-coverage.md has meaningful targets
-- [ ] eval.md has structured scoring framework
-- [ ] checkpoint.md enables state tracking
-
-### 4. Memory Persistence (0-10)
-- [ ] Memory tools documented (ohc_save/ohc_get/ohc_list/ohc_latest/ohc_search)
-- [ ] Checkpoint command references memory persistence
-- [ ] Mistake/audit logging workflow documented
-- [ ] Recall cache strategy defined
-
-### 5. Eval Coverage (0-10)
-- [ ] eval.md supports binary/scalar/rubric grading
-- [ ] Acceptance criteria framework in place
-- [ ] Pass@K metrics for non-deterministic evals
-- [ ] Evaluation report format defined
-
-### 6. Security Guardrails (0-10)
-- [ ] verify.md includes security checklist items
-- [ ] No hardcoded secrets guidance present
-- [ ] Input validation guidance included
-- [ ] SQL injection / XSS risks addressed
-
-### 7. Cost Efficiency (0-10)
-- [ ] model-route.md has budget tiers
-- [ ] Model routing heuristic defined
-- [ ] Subagent usage reduces main-context tokens
-- [ ] Compression workflow documented
-
-## Output Contract
-
-Return:
-
-1. `overall_score` out of `max_score` (70 for `repo`; smaller for scoped audits)
-2. Category scores and concrete findings
-3. Failed checks with exact file paths
-4. Top 3 actions to improve
-5. Suggested commands to apply next
-
-## Example Result
-
-```text
-Harness Audit (repo): 66/70
-- Tool Coverage: 10/10 (10/10 pts)
-- Context Efficiency: 9/10 (9/10 pts)
-- Quality Gates: 10/10 (10/10 pts)
-
-Top 3 Actions:
-1) [Security Guardrails] Add preflight security guard instructions in verify.md.
-2) [Tool Coverage] Ensure all subagent types have corresponding command files.
-3) [Eval Coverage] Add evaluation templates and examples.
-```

package/harness/commands/learn.md

@@ -1,37 +0,0 @@
----
-description: Create a new skill from recent work patterns
-agent: OpenHermes
-subtask: true
----
-
-# Learn Command
-
-Create a new reusable skill from recent work patterns. $ARGUMENTS
-
-## Your Task
-
-1. **Search backlog** for pending skill candidates:
-   - Use `ohc_search` with query="skill-candidate" classes=["backlog"]
-   - If $ARGUMENTS is non-empty, narrow search to that topic
-2. **Analyze the candidate** — what pattern did the session reveal?
-3. **Create the skill**:
-   - Load the skill-creator skill: `skill({ name: "skill-creator" })`
-   - Follow its instructions to create a new SKILL.md
-   - Target: `%USERPROFILE%\.config\opencode\skills\<name>\SKILL.md`
-   - Naming: lowercase, hyphenated, descriptive
-4. **Close the backlog entry**: `ohc_save(class="backlog", id="<candidate-id>", data={..., status:"closed"})`
-5. **Report**: What skill was created, where, and what it does
-
-## Skill Requirements
-
-- name: lowercase-hyphenated, 1-64 chars
-- description: 1-1024 chars, specific enough for agent to know when to load
-- Must include frontmatter with name + description
-- Must include: what it does, when to use it, step-by-step workflow
-
-## Report Format
-
-**Skill Created**: `<name>`
-**Path**: `%USERPROFILE%\.config\opencode\skills\<name>\SKILL.md`
-**Purpose**: [one-line summary]
-**Trigger words**: [when agent should load this skill]

package/harness/commands/loop-start.md

@@ -1,38 +0,0 @@
----
-description: Start a managed autonomous loop pattern with safety defaults
-agent: loop-operator
-subtask: true
----
-
-# Loop Start Command
-
-Start a managed autonomous loop pattern with safety defaults.
-
-## Usage
-
-`/loop-start [pattern] [--mode safe|fast]`
-
-- `pattern`: `sequential`, `continuous-pr`, `rfc-dag`, `infinite`
-- `--mode`:
-  - `safe` (default): strict quality gates and checkpoints
-  - `fast`: reduced gates for speed
-
-## Flow
-
-1. Confirm repository state and branch strategy.
-2. Select loop pattern and model tier strategy.
-3. Enable required hooks/profile for the chosen mode.
-4. Create loop plan and write runbook under `.opencode/plans/`.
-5. Print commands to start and monitor the loop.
-
-## Required Safety Checks
-
-- Verify tests pass before first loop iteration.
-- Ensure `OH_HOOK_PROFILE` is not disabled globally.
-- Ensure loop has explicit stop condition.
-
-## Arguments
-
-$ARGUMENTS:
-- `<pattern>` optional (`sequential|continuous-pr|rfc-dag|infinite`)
-- `--mode safe|fast` optional

package/harness/commands/loop-status.md

@@ -1,30 +0,0 @@
----
-description: Inspect active loop state, progress, and failure signals
-agent: OpenHermes
-subtask: true
----
-
-# Loop Status Command
-
-Inspect active loop state, progress, and failure signals.
-
-## Usage
-
-`/loop-status [--watch]`
-
-## What to Report
-
-- active loop pattern
-- current phase and last successful checkpoint
-- failing checks (if any)
-- estimated time/cost drift
-- recommended intervention (continue/pause/stop)
-
-## Watch Mode
-
-When `--watch` is present, refresh status periodically and surface state changes.
-
-## Arguments
-
-$ARGUMENTS:
-- `--watch` optional

package/harness/commands/memory-search.md

@@ -1,37 +0,0 @@
----
-description: Search openhermes memory with LLM summarization
-agent: OpenHermes
-subtask: true
----
-
-# Memory Search Command
-
-Search openhermes memory for: $ARGUMENTS
-
-## Your Task
-
-1. Call `ohc_search` with query="$ARGUMENTS" to get raw results
-2. Summarize the top 5 results with natural language interpretation
-3. Highlight patterns, recurring themes, and actionable insights
-4. Return a structured report
-
-## Report Format
-
-### Search: "$ARGUMENTS"
-
-**Top results** (by relevance score):
-
-| # | Class | Summary | Score |
-|---|-------|---------|-------|
-
-### Key Patterns
-
-[Extract 2-3 patterns from the results]
-
-### Actionable Insights
-
-- [What should be done based on these findings]
-
-### Recommended Next Query
-
-[Suggest a follow-up ohc_search query for deeper exploration]

package/harness/commands/model-route.md

@@ -1,32 +0,0 @@
----
-description: Recommend optimal model tier for the current task
-agent: OpenHermes
-subtask: true
----
-
-# Model Route Command
-
-Recommend the best model tier for the current task by complexity and budget.
-
-## Usage
-
-`/model-route [task-description] [--budget low|med|high]`
-
-## Routing Heuristic
-
-- `haiku`: deterministic, low-risk mechanical changes
-- `sonnet`: default for implementation and refactors
-- `opus`: architecture, deep review, ambiguous requirements
-
-## Required Output
-
-- recommended model
-- confidence level
-- why this model fits
-- fallback model if first attempt fails
-
-## Arguments
-
-$ARGUMENTS:
-- `[task-description]` optional free-text
-- `--budget low|med|high` optional

package/harness/commands/ohc.md

@@ -1,13 +0,0 @@
----
-description: OHC context management: /ohc status, /ohc compress [focus]
-agent: OpenHermes
-subtask: true
----
-
-# Ohc Command
-
-OHC context management — hook-handled.
-
-Run `/ohc status` to check context usage, `/ohc compress [targetTokens] [focus]` to free space.
-
-$ARGUMENTS

package/harness/commands/orchestrate.md

@@ -1,88 +0,0 @@
----
-description: Orchestrate multiple agents for complex tasks
-agent: planner
-subtask: true
----
-
-# Orchestrate Command
-
-Orchestrate multiple specialized agents for this complex task: $ARGUMENTS
-
-## Your Task
-
-1. **Analyze task complexity** and break into subtasks
-2. **Identify optimal agents** for each subtask
-3. **Create execution plan** with dependencies
-4. **Coordinate execution** - parallel where possible
-5. **Synthesize results** into unified output
-
-## Available Agents
-
-| Agent | Specialty | Use For |
-|-------|-----------|---------|
-| planner | Implementation planning | Complex feature design |
-| architect | System design | Architectural decisions |
-| code-reviewer | Code quality | Review changes |
-| security-reviewer | Security analysis | Vulnerability detection |
-| tdd-guide | Test-driven dev | Feature implementation |
-| build-error-resolver | Build fixes | TypeScript/build errors |
-| e2e-runner | E2E testing | User flow testing |
-| doc-updater | Documentation | Updating docs |
-| refactor-cleaner | Code cleanup | Dead code removal |
-| review-go | Go code | Go-specific review |
-| build-go | Go builds | Go build errors |
-| review-database | Database | Query optimization |
-
-## Orchestration Patterns
-
-### Sequential Execution
-```
-planner → tdd-guide → code-reviewer → security-reviewer
-```
-Use when: Later tasks depend on earlier results
-
-### Parallel Execution
-```
-┌→ security-reviewer
-planner →├→ code-reviewer
-└→ architect
-```
-Use when: Tasks are independent
-
-### Fan-Out/Fan-In
-```
-         ┌→ agent-1 ─┐
-planner →├→ agent-2 ─┼→ synthesizer
-         └→ agent-3 ─┘
-```
-Use when: Multiple perspectives needed
-
-## Execution Plan Format
-
-### Phase 1: [Name]
-- Agent: [agent-name]
-- Task: [specific task]
-- Depends on: [none or previous phase]
-
-### Phase 2: [Name] (parallel)
-- Agent A: [agent-name]
-  - Task: [specific task]
-- Agent B: [agent-name]
-  - Task: [specific task]
-- Depends on: Phase 1
-
-### Phase 3: Synthesis
-- Combine results from Phase 2
-- Generate unified output
-
-## Coordination Rules
-
-1. **Plan before execute** - Create full execution plan first
-2. **Minimize handoffs** - Reduce context switching
-3. **Parallelize when possible** - Independent tasks in parallel
-4. **Clear boundaries** - Each agent has specific scope
-5. **Single source of truth** - One agent owns each artifact
-
----
-
-**NOTE**: Complex tasks benefit from multi-agent orchestration. Simple tasks should use single agents directly.