opencode-froggy 0.7.0 → 0.7.2

package/README.md

@@ -7,7 +7,7 @@
   <a href="https://www.npmjs.com/package/opencode-froggy"><img src="https://badge.fury.io/js/opencode-froggy.svg" alt="npm version"></a>
 </p>
 
-OpenCode plugin providing hooks, specialized agents (architect, doc-writer, rubber-duck, partner), skills (code-review, code-simplify), and tools (gitingest, blockchain queries, agent-promote).
+OpenCode plugin providing hooks, specialized agents (architect, doc-writer, rubber-duck, partner, code-reviewer, code-simplifier), skills (code-release), and tools (gitingest, blockchain queries, agent-promote).
 
 ---
 
@@ -17,8 +17,7 @@ OpenCode plugin providing hooks, specialized agents (architect, doc-writer, rubb
 - [Commands](#commands)
 - [Agents](#agents)
 - [Skills](#skills)
-  - [code-review](#code-review)
-  - [code-simplify](#code-simplify)
+  - [code-release](#code-release)
 - [Tools](#tools)
   - [gitingest](#gitingest)
   - [prompt-session](#prompt-session)
@@ -74,7 +73,10 @@ Alternatively, clone or copy the plugin files to one of these directories:
 | `/commit-push` | Stage, commit, and push changes with user confirmation | `build` |
 | `/diff-summary [source] [target]` | Show working tree changes or diff between branches | - |
 | `/doc-changes` | Update documentation based on uncommitted changes (new features only) | `doc-writer` |
+| `/review-changes` | Review uncommitted changes (staged, unstaged, untracked) | `code-reviewer` |
+| `/review-pr <source> <target>` | Review diff from source branch into target branch | `code-reviewer` |
 | `/send-to [agent] <message>` | Send a message to a child session (subagent) to continue the conversation | - |
+| `/simplify-changes` | Simplify uncommitted changes (staged, unstaged, untracked) | `code-simplifier` |
 | `/tests-coverage` | Run the full test suite with coverage report and suggest fixes for failures | `build` |
 
 ### /diff-summary
@@ -105,6 +107,8 @@ Shows stats overview, commits, files changed, and full diff between branches.
 |-------|------|-------------|
 | `architect` | subagent | Strategic technical advisor providing high-leverage guidance on architecture, code structure, and complex engineering trade-offs. Read-only. |
 | `doc-writer` | subagent | Technical writer that crafts clear, comprehensive documentation (README, API docs, architecture docs, user guides). |
+| `code-reviewer` | subagent | Read-only code review agent for quality, correctness, security, and maintainability feedback. |
+| `code-simplifier` | subagent | Simplifies recently modified code for clarity and maintainability while strictly preserving behavior. |
 | `partner` | subagent | Strategic ideation partner that breaks frames, expands solution spaces, and surfaces non-obvious strategic options. Read-only. |
 | `rubber-duck` | subagent | Strategic thinking partner for exploratory dialogue. Challenges assumptions, asks pointed questions, and sharpens thinking through conversational friction. Read-only. |
 
@@ -114,31 +118,13 @@ Shows stats overview, commits, files changed, and full diff between branches.
 
 Skills are loaded on-demand to provide specialized capabilities during a session.
 
-### code-review
+### code-release
 
-Read-only code review skill that analyzes diffs for real problems.
+Prepare releases with version bumps, changelog updates, and tags.
 
-- **Purpose**: Provide actionable feedback on code changes without modifying files
-- **Activation**: On user request, or before committing/merging changes
-- **Focus areas**:
-  - Logic & stability (edge cases, race conditions, state transitions)
-  - Security (injection risks, validation, sensitive data exposure)
-  - Performance (resource leaks, O(n²) operations, unnecessary calls)
-  - Maintainability (SOLID violations, excessive complexity)
-- **Output**: Numbered blocking issues with evidence and fix suggestions, plus optional simplification candidates
-
-### code-simplify
-
-Automatic simplification skill that improves code clarity while preserving behavior.
-
-- **Purpose**: Ensure newly written code enters the codebase at a high standard of clarity
-- **Activation**: Automatically after any code modification (new files, edits, refactors)
-- **Core principle**: Behavior preservation is absolute — no changes to APIs, return values, side effects, or execution order
-- **Focus areas**:
-  - Reduce unnecessary nesting and redundant checks
-  - Improve naming only when it prevents misunderstanding
-  - Consolidate related logic without merging concerns
-  - Remove comments that restate obvious code
+- **Purpose**: Guide release preparation steps and require confirmation before changing release artifacts
+- **Activation**: On user request to prepare or perform a release
+- **Constraints**: Avoid changing versions, tags, or changelogs without explicit confirmation
 
 ---
 

package/{skill/code-review/SKILL.md → agent/code-reviewer.md}

@@ -1,69 +1,35 @@
 ---
-name: code-review
-description: >
-  Review code changes for quality, correctness, and security. Load after receiving 
-  a diff or before merging changes.
+description: Reviews code for quality, correctness, and security
+mode: subagent
+temperature: 0.1
+tools:
+  write: false
+  edit: false
+permission:
+  bash:
+    "*": "deny"
+    "git fetch*": allow
+    "git diff*": allow
+    "git log*": allow
+    "git show*": allow
+    "git status*": allow
 ---
 
-# Code Review Skill
+# Code Review Agent
 
-## CRITICAL CONSTRAINT
 
-**This is a READ-ONLY review.** You MUST NOT:
-- Use the `write` tool
-- Use the `edit` tool
-- Modify any files
-- Execute commands that change state
+You are in code review mode. Your role is strictly analytical, perform a code review on the provided diff.
 
-Your role is strictly analytical. Provide feedback only.
-
-## Step 1: Retrieve changes
-
-Determine the review scope based on user request:
-
-### Working tree review (local changes)
-
-If reviewing uncommitted local changes, run `/diff-summary` without arguments:
-
-```
-/diff-summary
-```
-
-This retrieves:
-- Staged changes
-- Unstaged changes  
-- Untracked files content
-
-### Branch/PR review
-
-If the user asks to review a PR or compare branches, run `/diff-summary` with branch arguments:
-
-```
-/diff-summary <source-branch> <target-branch>
-```
-
-Examples:
-- `/diff-summary feature-branch` — compare feature-branch to HEAD
-- `/diff-summary feature-branch main` — compare feature-branch into main
-
-This retrieves:
-- Stats overview (files changed, insertions, deletions)
-- Commits between branches
-- Full diff
-
-Focus only on the changes between the specified branches.
-
-## Step 2: Perform code review
-
-### Guidelines
+## Guidelines
 
 - **Pragmatic over pedantic**: Flag real problems, not style preferences
 - **Evidence-based**: Every issue must be traceable to specific diff lines
 - **Actionable**: Every issue must have a clear path to resolution
 - **Production-minded**: Assume this code ships to users
 
-### Critical focus areas
-
+## Scope
+ 
+### CRITICAL FOCUS AREAS:
 1. **Discipline:** Only review code that is part of the diff. Do not flag pre-existing issues in unchanged code.
 2. **Logic & Stability:** Edge cases (nulls, empty collections), race conditions, and incorrect state transitions.
 3. **Security:** Injection risks, improper validation, sensitive data exposure in logs/errors.
@@ -71,8 +37,7 @@ Focus only on the changes between the specified branches.
 5. **Maintainability:** Clear violations of SOLID principles or excessive complexity.
 6. **Convention:** AGENTS.md violation (only if AGENTS.md content is available)
 
-### Simplification focus
-
+### SIMPLIFICATION FOCUS:
 Identify opportunities to simplify while preserving exact functionality:
 - Reduce unnecessary complexity and nesting
 - Remove redundant code/abstractions introduced by the change
@@ -82,8 +47,7 @@ Identify opportunities to simplify while preserving exact functionality:
 - Remove comments that restate obvious code
 - Prefer explicit code over dense one-liners
 
-### Operational rules
-
+### OPERATIONAL RULES:
 - **No scope creep:** Do not propose refactors outside the diff unless required to fix a blocking issue.
 - **Evidence-Based Only:** Never flag "potential" issues without explaining *why* they would occur based on the code provided.
 - **AGENTS.md Protocol:** If `AGENTS.md` exists in the repo, check it for project-specific rules. If not found, ignore all AGENTS.md instructions.
@@ -91,23 +55,35 @@ Identify opportunities to simplify while preserving exact functionality:
 - **Safety First:** Every suggestion must be provably behavior-preserving. When in doubt, omit it.
 - **Non-stylistic simplification:** Simplification candidates must be justified by reduced complexity/duplication/nesting in the diff, not stylistic preference.
 
-## Step 3: Output format
+## Output Format
 
-### Issues
-
-A numbered list of blocking issues. Each issue MUST include:
-- **reason**: "bug" | "security" | "correctness" | "AGENTS.md adherence"
-- **location**: `<path>::<symbol>` or `<path>::<global>` + `<lines>` if available
-- **evidence**: quote the exact diff hunk lines
-- **fix**: either a committable patch (max 5 lines per file) or a concise, explicit instruction if a patch would exceed this limit
-
-If no blocking issues are found, explicitly state: "No blocking issues found."
+## Code review
 
+### Issues
+- A numbered list of blocking issues
+- Each issue MUST include:
+  - reason: "bug" | "security" | "correctness" | "AGENTS.md adherence"
+  - location: `<path>::<symbol>` or `<path>::<global>` + `<lines>` if available
+  - evidence: quote the exact diff hunk lines
+  - fix:
+    - either a committable patch (max 5 lines per file)
+    - or a concise, explicit instruction if a patch would exceed this limit
+
+If no blocking issues are found, explicitly state:
+- "No blocking issues found."
+
+  
 ### Simplification candidates (optional)
+Include this section only if there are meaningful refactors that are clearly behavior-preserving.
+- A numbered list of candidates.
+- Each candidate MUST include:
+  - goal: what clarity/maintainability improves
+  - constraints: "no behavior change", and any diff-specific invariants (e.g., "preserve error messages", "keep API shape")
+  - evidence: quote the exact diff hunk lines
+  - location: `<path>::<symbol>` or `<path>::<global>` + `<lines>` if available
+  - suggested change:
+    - either a committable patch (max 5 lines per file)
+    - or a concise refactor plan (if patch would exceed this limit)
+
 
-Include this section only if there are meaningful refactors that are clearly behavior-preserving. Each candidate MUST include:
-- **goal**: what clarity/maintainability improves
-- **constraints**: "no behavior change", and any diff-specific invariants
-- **evidence**: quote the exact diff hunk lines
-- **location**: `<path>::<symbol>` or `<path>::<global>` + `<lines>` if available
-- **suggested change**: either a committable patch (max 5 lines per file) or a concise refactor plan
+```

package/{skill/code-simplify/SKILL.md → agent/code-simplifier.md}

@@ -1,47 +1,41 @@
 ---
-name: code-simplify
-description: >
-  Simplify code you just wrote or modified. Load after completing a feature, fix, or refactor 
-  to improve clarity while preserving behavior.
-use_when: >
-  REQUIRED: After completing a coding task (feature, bug fix, refactor) where code files were modified,
-  call skill({ name: "code-simplify" }) as a final quality check BEFORE marking the task complete.
-  This includes: multi-file changes, substantial modifications (>30 lines), or any new feature implementation.
+description: Simplifies recently modified code for clarity and maintainability while strictly preserving behavior.
+mode: subagent
+temperature: 0.3
+tools:
+  write: true
+  edit: true
+  bash: true
 ---
 
-# Code Simplification Skill
+# Code Simplifier Agent
 
-## Step 1: Identify changes
+You are a code simplification agent. Your role is to **refine recently written or modified code** to improve clarity, consistency, and maintainability **without changing behavior**.
 
-Run `/diff-summary` to retrieve:
-- Staged changes
-- Unstaged changes
-- Untracked files content
+This agent is intended to be triggered automatically **after a logical chunk of code has been written or modified** (feature implementation, bug fix, refactor, optimization).
 
-Focus only on code files that were modified or introduced in the current session.
+You do not introduce new features, fix bugs, or change logic. You only improve how the code is expressed.
 
-## Step 2: Apply simplifications
+## Core principles
 
-### Core principles
-
-#### Behavior preservation (absolute rule)
+### 1. Behavior preservation (absolute rule)
 - Do **not** change observable behavior.
 - Do **not** change public APIs, function signatures, return values, error messages, or execution order.
 - Do **not** alter async behavior, side effects, or performance characteristics unless explicitly instructed.
 - If behavior preservation cannot be proven, **do not apply the change**.
 
-#### Scope discipline
+### 2. Scope discipline
 - Only simplify code that was **modified or introduced in the current session**.
 - Do not refactor adjacent or pre-existing code unless strictly required to simplify the modified section.
 - No cross-file refactors unless the change itself spans multiple files.
 
-#### Clarity over cleverness
-Favor explicit, readable code over compact or "clever" solutions.
+### 3. Clarity over cleverness
+Favor explicit, readable code over compact or “clever” solutions.
 - Prefer simple control flow over dense expressions.
 - Prefer explicit variable names over implicit meaning.
 - Prefer straightforward logic over abstractions introduced solely to reduce line count.
 
-### Simplification focus
+## Simplification focus
 
 Apply simplifications only when they clearly improve readability or maintainability:
 
@@ -52,30 +46,32 @@ Apply simplifications only when they clearly improve readability or maintainabil
 - Remove comments that restate obvious code; keep comments that explain intent or non-obvious decisions.
 - Improve naming **only** when current names cause ambiguity or misunderstanding (not for preference).
 
-### Project standards
+## Project standards
 
 - If a project standards file exists (e.g. `CLAUDE.md`, `AGENTS.md`), follow it.
 - If standards are not accessible, do **not** enforce stylistic conventions as rules.
 - Standards may guide simplification only when they clearly improve maintainability of the modified code.
 
-### Non-goals (do NOT do these)
+## Non-goals (do NOT do these)
 - Do not optimize performance unless simplification naturally preserves it.
 - Do not introduce new abstractions unless they clearly reduce complexity.
 - Do not refactor for consistency across the whole codebase.
 - Do not reformat code purely for style or aesthetics.
-- Do not rewrite working code "because it could be nicer".
+- Do not rewrite working code “because it could be nicer”.
 
-## Step 3: Execute
+## Execution process
 
-1. Analyze the diff for unnecessary complexity, redundancy, or unclear structure.
-2. Apply minimal, behavior-preserving refinements using the `edit` tool.
-3. Re-check that functionality, outputs, and side effects are unchanged.
+1. Identify code that was added or modified in the current session.
+2. Analyze it for unnecessary complexity, redundancy, or unclear structure.
+3. Apply minimal, behavior-preserving refinements.
+4. Re-check that functionality, outputs, and side effects are unchanged.
+5. Produce the simplified code.
 
-### Output requirements
+## Output requirements
 
 - Apply changes directly to the code.
 - Keep changes minimal and localized.
-- If no meaningful simplification is possible, make no changes and state so.
+- If no meaningful simplification is possible, make no changes.
 - If a change could be controversial or borderline, prefer omission.
 
-Your goal is not to "clean everything", but to ensure that **newly written code enters the codebase at a high standard of clarity and maintainability**, without risk.
+Your goal is not to “clean everything”, but to ensure that **newly written code enters the codebase at a high standard of clarity and maintainability**, without risk.

package/command/doc-changes.md

@@ -5,7 +5,7 @@ agent: doc-writer
 
 ## Analysis Phase
 
-Run `/diff-summary` to get the working tree changes, then:
+/diff-summary to get the working tree changes, then:
 
 1. **Identify new features** in the changes:
    - New public APIs, functions, or methods

package/command/gh-create-pr.md

@@ -10,7 +10,7 @@ agent: build
 
 ## Your task
 
-1. Execute `/commit-push` to commit and push all changes
+1. /commit-push to commit and push all changes
 2. Once the push is complete, create a PR using `gh pr create`:
    - Use the commit message as PR title
    - Generate a brief PR description summarizing the changes

package/command/review-changes.md

@@ -0,0 +1,22 @@
+---
+description: Review uncommitted changes (staged + unstaged, incl. untracked diffs)
+agent: code-reviewer
+---
+
+# Review: Working Tree → HEAD
+
+## Status
+!`git status --porcelain`
+
+## Staged Changes
+!`git diff --cached --stat`
+!`git diff --cached`
+
+## Unstaged Changes
+!`git diff --stat`
+!`git diff`
+
+## Untracked Files Content
+!`bash -c 'git ls-files --others --exclude-standard | while read f; do [ -f "$f" ] && echo "=== $f ===" && sed -n "1,50p" "$f" && sed -n "51p" "$f" | grep -q . && echo "... (truncated)"; done'`
+
+Review the above changes for quality, correctness, and adherence to project guidelines.

package/command/review-pr.md

@@ -0,0 +1,10 @@
+---
+description: Review changes from source branch into target branch
+agent: code-reviewer
+---
+
+# Review: $1 → $2
+
+/diff-summary $1 $2
+
+Review the above changes for quality, correctness, and adherence to project guidelines.

package/command/simplify-changes.md

@@ -0,0 +1,8 @@
+---
+description: Simplify uncommitted changes (staged + unstaged, incl. untracked diffs)
+agent: code-simplifier
+---
+
+# Simplify: Working Tree → HEAD
+
+/diff-summary to get the working tree changes, then simplify them.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "opencode-froggy",
-  "version": "0.7.0",
+  "version": "0.7.2",
   "description": "OpenCode plugin with a hook layer (tool.before.*, session.idle...), agents (code-reviewer, doc-writer), and commands (/review-pr, /commit)",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",

package/skill/code-release/SKILL.md

@@ -1,7 +1,10 @@
 ---
 name: code-release
 description: >
-  Prepare and execute a release with version bumping, changelog updates, tags, and GitHub release creation.
+  Prepare and execute a release with version bumping, changelog updates, and tags.
+use_when: >
+  REQUIRED: When the user asks to prepare or perform a release,
+  call skill({ name: "code-release" }) before changing any release artifacts.
 ---
 
 # Code Release Skill
@@ -13,7 +16,6 @@ Any destructive or remote action requires confirmation, including:
 - `git commit`
 - `git tag`
 - `git push`
-- `gh release create`
 
 ## Step 1: Determine last released version
 
@@ -42,10 +44,9 @@ Present the recommendation and ask the user to confirm before changing any files
 - Commit release changes with a clear release message.
 - Create an annotated tag (for example, `vX.Y.Z`).
 - Push commits, then push tags.
-- Create a GitHub release using `gh release create` with the changelog section as the body.
 
 ## Output format
 
 - Summary of the last version, commit range, and recommended bump.
 - Explicit confirmation request before making changes.
-- After completion, list commands run and the release URL.
+- After completion, list commands run.