opencode-froggy 0.5.1 → 0.7.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "opencode-froggy",
-  "version": "0.5.1",
+  "version": "0.7.0",
   "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

@@ -0,0 +1,51 @@
+---
+name: code-release
+description: >
+  Prepare and execute a release with version bumping, changelog updates, tags, and GitHub release creation.
+---
+
+# Code Release Skill
+
+## CRITICAL CONSTRAINT
+
+You MUST NOT change versions, tags, or publish without explicit user confirmation.
+Any destructive or remote action requires confirmation, including:
+- `git commit`
+- `git tag`
+- `git push`
+- `gh release create`
+
+## Step 1: Determine last released version
+
+1. Prefer the latest Git tag that matches `v<semver>`.
+2. If no matching tag exists, use the version in `package.json`.
+3. Collect commits since the last version (tag to `HEAD`).
+
+## Step 2: Propose version bump
+
+Analyze commits since the last version and recommend a semver bump:
+- **major**: breaking changes or incompatible behavior changes.
+- **minor**: new features with backward compatibility.
+- **patch**: fixes and internal changes only.
+
+Present the recommendation and ask the user to confirm before changing any files.
+
+## Step 3: Update release artifacts (after confirmation)
+
+- Update the version in `package.json`.
+- Update `CHANGELOG` with a new section for the version.
+- Summarize changes based on the commit range.
+- Preserve the existing changelog format.
+
+## Step 4: Tag and publish (after confirmation)
+
+- 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.

package/skill/code-review/SKILL.md

@@ -3,9 +3,6 @@ name: code-review
 description: >
   Review code changes for quality, correctness, and security. Load after receiving 
   a diff or before merging changes.
-use_when: >
-  Use this skill when the user asks for a code review, or when you need to analyze
-  changes for quality and correctness before they are committed or merged.
 ---
 
 # Code Review Skill

package/skill/code-simplify/SKILL.md

@@ -4,8 +4,9 @@ description: >
   Simplify code you just wrote or modified. Load after completing a feature, fix, or refactor 
   to improve clarity while preserving behavior.
 use_when: >
-  After ANY code modification (write, edit, refactor). Call BEFORE responding to user or
-  marking task complete.
+  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.
 ---
 
 # Code Simplification Skill