@activade/open-workflows 1.0.0

package/dist/skills/doc-sync.d.ts

@@ -0,0 +1 @@
+export declare const DOC_SYNC = "---\nname: doc-sync\ndescription: Keep documentation in sync with code changes. Analyzes PR diffs and updates relevant docs using native write and bash tools.\nlicense: MIT\nmetadata:\n  trigger: pull_request\n  tools: write, bash, read, glob\n---\n\n## What I Do\n\nAnalyze pull request changes and update documentation to reflect code changes. Uses native OpenCode tools (`write`, `bash`) instead of custom commit tools.\n\n## Workflow\n\n1. **Gather PR context**:\n   ```bash\n   gh pr view <number> --json files,title,body,headRefOid\n   ```\n\n2. **Create todo list**: One item per changed file using `todowrite`\n\n3. **Analyze each file**:\n   - Mark todo as `in_progress`\n   - Identify user-visible changes (APIs, config, behavior)\n   - Note which documentation might need updates\n   - Mark todo as `completed`\n\n4. **After ALL files analyzed**:\n   - Identify affected documentation files\n   - Read current content of each doc file\n   - Plan minimal, precise updates\n\n5. **Update documentation**: Use `write` tool for each file needing changes\n\n6. **Commit and push**: Use `bash` tool for git operations\n\n## Documentation Scope\n\nCheck these locations first:\n- `README.md` at repository root\n- Files under `docs/` directory\n- API documentation if present\n- Configuration examples\n- Other markdown files at root\n\n## What to Update\n\n| Code Change | Documentation Update |\n|-------------|---------------------|\n| New feature | Add documentation |\n| Changed behavior | Update existing docs |\n| Removed feature | Remove or mark deprecated |\n| New config option | Document option and defaults |\n| Changed API | Update examples and usage |\n\n## Committing Changes\n\nAfter updating documentation files with `write`, commit using `bash`:\n\n```bash\ngit add README.md docs/\ngit commit -m \"[skip ci] docs: <description of changes>\"\ngit push\n```\n\n**Important**: The `[skip ci]` prefix prevents infinite workflow loops.\n\n## Style Guidelines\n\n- Keep documentation concise and accurate\n- Match existing tone and formatting\n- Prefer targeted edits over large rewrites\n- Ensure code examples are syntactically correct\n- Don't invent features not present in the code\n\n## No Changes Needed\n\nIf the existing documentation is already accurate:\n- Do NOT create an empty commit\n- Do NOT call any git commands\n- Simply report that no documentation updates were required\n- Explain briefly why the docs are already correct\n\n## Common Mistakes to Avoid\n\n- Do NOT update docs unrelated to the PR\n- Do NOT start editing before completing all file analyses\n- Do NOT generate marketing-style or overly verbose content\n- Do NOT change code examples unless the underlying code changed\n- Do NOT duplicate information across multiple files\n- Do NOT commit with an empty file list\n\n## Example Workflow\n\n1. PR changes `src/config/options.ts` to add new `timeout` option\n2. Analyze: user-visible config change\n3. Check `README.md` and `docs/configuration.md`\n4. Update `docs/configuration.md` with new option description\n5. Commit: `[skip ci] docs: add timeout configuration option`\n";

package/dist/skills/index.d.ts

@@ -0,0 +1,10 @@
+export { PR_REVIEW } from './pr-review';
+export { ISSUE_LABEL } from './issue-label';
+export { DOC_SYNC } from './doc-sync';
+export { RELEASE_NOTES } from './release-notes';
+export interface SkillDefinition {
+    name: string;
+    content: string;
+}
+export declare const SKILLS: Record<string, SkillDefinition>;
+export declare const SKILL_NAMES: (keyof typeof SKILLS)[];

package/dist/skills/issue-label.d.ts

@@ -0,0 +1 @@
+export declare const ISSUE_LABEL = "---\nname: issue-label\ndescription: Automatically apply appropriate labels to GitHub issues based on content analysis. Uses existing labels when possible, creates new ones sparingly.\nlicense: MIT\nmetadata:\n  trigger: issues\n  tools: apply_labels\n---\n\n## What I Do\n\nAnalyze GitHub issue content and apply up to 3 appropriate labels to help maintainers triage and search issues effectively.\n\n## Workflow\n\n1. **Fetch issue details**: Get title, body, and existing labels\n   ```bash\n   gh issue view <number> --json title,body,labels\n   ```\n\n2. **Fetch repository labels**: List available labels\n   ```bash\n   gh label list --json name,description,color\n   ```\n\n3. **Analyze the issue**:\n   - Determine the main type: bug, feature, documentation, question, etc.\n   - Look for hints about complexity (good-first-issue candidate?)\n   - Match to existing labels\n\n4. **Select labels**: Choose up to 3 existing labels that best describe the issue\n\n5. **Create new labels**: Only if no existing labels fit (rare)\n\n6. **Apply**: Call `apply_labels` exactly once\n\n## Labeling Guidelines\n\n### Use Existing Labels\nPrefer existing labels over creating new ones. Check the repository's label taxonomy first.\n\n### Common Categories\n- `bug` - Something isn't working\n- `feature` or `feature-request` - New functionality\n- `enhancement` - Improvement to existing feature\n- `documentation` - Docs need updates\n- `question` - Needs clarification\n- `good-first-issue` - Good for newcomers\n\n### Label Naming Conventions (for new labels)\n- Lowercase letters only\n- Words separated by hyphens\n- 1-3 words, under 30 characters\n- Example: `needs-reproduction`, `breaking-change`\n\n## Using apply_labels\n\nCall exactly once with these arguments:\n\n| Argument | Type | Description |\n|----------|------|-------------|\n| `repository` | string | owner/repo format |\n| `issueNumber` | number | Issue number from task message |\n| `labels` | string[] | Array of existing label names (max 3) |\n| `newLabels` | array? | Optional: new labels to create first |\n| `explanation` | string | Brief reason for label choices |\n\n### New Label Format\n\nIf creating new labels (use sparingly):\n\n```json\n{\n  \"name\": \"needs-reproduction\",\n  \"color\": \"d93f0b\",\n  \"description\": \"Issue needs steps to reproduce\"\n}\n```\n\nColor is a hex string WITHOUT the leading `#`.\n\n## Decision Process\n\n1. **Read the issue carefully** - title and full body\n2. **Identify the primary type** - bug? feature? question?\n3. **Check for secondary aspects** - affects docs? good for beginners?\n4. **Match to existing labels** - prefer exact matches\n5. **If no match exists** - consider if a new label is truly needed\n6. **Write explanation** - brief justification for choices\n\n## Common Mistakes to Avoid\n\n- Do NOT apply more than 3 labels total\n- Do NOT create many highly specific labels unlikely to be reused\n- Do NOT apply labels that contradict the issue content\n- Do NOT overuse broad labels like `question` when specific ones exist\n- Do NOT create duplicate labels with slight name variations\n- Do NOT omit the explanation field\n\n## Example Explanation\n\nGood: \"Labeled as `bug` and `documentation` based on steps to reproduce and mention of incorrect docs\"\n\nBad: \"Applied some labels\"\n";

package/dist/skills/pr-review.d.ts

@@ -0,0 +1 @@
+export declare const PR_REVIEW = "---\nname: pr-review\ndescription: AI-powered pull request code review focusing on correctness, security, stability, and maintainability. Posts structured findings via submit_review tool.\nlicense: MIT\nmetadata:\n  trigger: pull_request\n  tools: submit_review\n---\n\n## What I Do\n\nReview pull request changes systematically and post findings as a sticky PR comment using the `submit_review` tool.\n\n## Workflow\n\n1. **Gather context**: Use GitHub CLI to get PR metadata\n   ```bash\n   gh pr view <number> --json files,title,body,headRefOid\n   ```\n\n2. **Create todo list**: One item per changed file using `todowrite`\n\n3. **Analyze each file**:\n   - Mark todo as `in_progress`\n   - Read the file diff and surrounding context\n   - Note issues (correctness, security, stability, maintainability)\n   - Mark todo as `completed`\n\n4. **Synthesize review**: After ALL files are analyzed, determine verdict and summary\n\n5. **Submit**: Call `submit_review` exactly once with all findings\n\n## Review Priorities\n\nFocus on these areas in order of importance:\n\n1. **Correctness** - Logic errors, broken control flow, off-by-one errors, incorrect conditions\n2. **Security** - Injection vulnerabilities, auth issues, secrets in code, unsafe deserialization\n3. **Stability** - Error handling, race conditions, resource leaks, null/undefined cases\n4. **Maintainability** - Clarity, naming, violations of local conventions\n\nOnly flag style issues when they hide bugs or cause real confusion.\n\n## Using submit_review\n\nCall exactly once with these arguments:\n\n| Argument | Type | Description |\n|----------|------|-------------|\n| `repository` | string | owner/repo format (from git remote) |\n| `pullNumber` | number | PR number from task message |\n| `commitSha` | string | headRefOid from PR metadata |\n| `summary` | string | 1-3 sentence overall assessment |\n| `verdict` | string | `approve` or `request_changes` |\n| `issues` | array | List of findings |\n\nEach issue in the array needs:\n\n| Field | Type | Description |\n|-------|------|-------------|\n| `file` | string | File path from the diff |\n| `line` | number | Line number on the NEW (right) side |\n| `severity` | string | `critical`, `high`, `medium`, or `low` |\n| `title` | string | Short description (~80 chars) |\n| `explanation` | string | Why this matters, what's wrong |\n| `suggestion` | string? | Optional: replacement code only, no prose |\n\n## Verdict Rules\n\n- Use `request_changes` if there are ANY medium, high, or critical issues\n- Use `approve` if there are only low-severity issues or no issues at all\n- The verdict must be consistent with the worst severity in the issues array\n\n## Common Mistakes to Avoid\n\n- Do NOT call `submit_review` more than once\n- Do NOT use line numbers from the left (old) side of the diff\n- Do NOT skip the per-file todo workflow\n- Do NOT guess repository, PR number, or commit SHA - derive from git/gh commands\n- Do NOT include JSON fragments in summary or explanation fields\n- Do NOT put prose like \"change to:\" in the suggestion field\n\n## Example Issue\n\n```json\n{\n  \"file\": \"src/auth/login.ts\",\n  \"line\": 42,\n  \"severity\": \"high\",\n  \"title\": \"SQL injection vulnerability in user lookup\",\n  \"explanation\": \"User input is concatenated directly into the SQL query without sanitization. An attacker could inject malicious SQL to bypass authentication or extract data.\",\n  \"suggestion\": \"const user = await db.query('SELECT * FROM users WHERE email = $1', [email])\"\n}\n```\n";

package/dist/skills/release-notes.d.ts

@@ -0,0 +1 @@
+export declare const RELEASE_NOTES = "---\nname: release-notes\ndescription: Analyze commits since last release, determine semantic version bump, publish to npm, and create GitHub release with notes.\nlicense: MIT\nmetadata:\n  trigger: workflow_dispatch\n  tools: bun_release, github_release\n---\n\n## What I Do\n\nAutomate the release process: analyze commits, determine version, publish to npm, and create a GitHub release with generated notes.\n\n## Workflow\n\nUse `todowrite` to create and track these steps:\n\n1. **Get current version** from `package.json`\n2. **Find previous release tag** using git\n3. **List commits since last tag**\n4. **Fetch merged pull requests** in that range\n5. **Determine version bump type** (major/minor/patch)\n6. **Generate release notes**\n7. **Call `bun_release`** to publish to npm\n8. **Call `github_release`** to create GitHub release\n\n## Gathering Context\n\n```bash\n# Get current version\ncat package.json | jq -r '.version'\n\n# Find previous tag\ngit describe --tags --abbrev=0\n\n# List commits since tag\ngit log <prev-tag>..HEAD --oneline\n\n# Get merged PRs\ngh pr list --state merged --base main --json number,title,author\n```\n\n## Version Determination\n\nUse semantic versioning based on commit analysis:\n\n### MAJOR bump (x.0.0)\n- Commits containing \"BREAKING CHANGE\" in body\n- Commits starting with `feat!:` or `fix!:` (with `!`)\n- API removals or incompatible interface changes\n\n### MINOR bump (x.y.0)\n- Commits starting with `feat:` or `feat(`\n- New functionality that doesn't break existing behavior\n\n### PATCH bump (x.y.z)\n- Commits starting with `fix:`, `perf:`, `refactor:`, `docs:`, `chore:`\n- Any other commits not matching above patterns\n\n### Rules\n- If ANY commit requires MAJOR \u2192 bump major, reset minor and patch to 0\n- Else if ANY commit requires MINOR \u2192 bump minor, reset patch to 0\n- Else \u2192 bump patch only\n\n## Release Notes Format\n\nInclude only user-facing changes. Each note should follow:\n\n```\n<description> [#<issue>] [#<pr>] @<author>\n```\n\n**Include:**\n- New features\n- Bug fixes\n- Performance improvements\n- Important config/doc updates\n\n**Exclude:**\n- Pure dependency bumps\n- Version bump commits\n- Formatting-only changes\n- Reverts that undo previous changes\n- Merge commits\n\n### Example Notes\n- Add retry logic to GitHub API calls #42 @alice\n- Fix label creation for special characters #38 @bob\n- Improve error messages for auth failures @carol\n\n## Using bun_release (Call FIRST)\n\nPublishes to npm. Call before `github_release`.\n\n| Argument | Type | Description |\n|----------|------|-------------|\n| `version` | string | New version (e.g., \"1.2.3\" or \"v1.2.3\") |\n\nWhat it does:\n1. Runs `bun pm version` to update package.json\n2. Pushes commit and tag to remote\n3. Runs `bun publish --access public`\n\n## Using github_release (Call SECOND)\n\nCreates GitHub release. Call only after `bun_release` succeeds.\n\n| Argument | Type | Description |\n|----------|------|-------------|\n| `repository` | string | owner/repo format |\n| `tag` | string | Version with \"v\" prefix (e.g., \"v1.2.3\") |\n| `notes` | string[] | Array of release notes (without \"- \" prefix) |\n| `title` | string? | Optional: release title (defaults to tag) |\n| `prerelease` | boolean? | Set true for -alpha, -beta, -rc versions |\n| `draft` | boolean? | Set true to create as draft |\n\n## Special Cases\n\n### No Commits Since Last Tag\n- Report to user that no release is needed\n- Do NOT call either tool\n\n### No Previous Tag (First Release)\n- Analyze all commits in repository\n- Use version from package.json or default to 0.1.0\n\n### bun_release Fails\n- Do NOT call github_release\n- Report the error to user\n- The publish must succeed before creating GitHub release\n\n## Common Mistakes to Avoid\n\n- Do NOT call `github_release` before `bun_release` succeeds\n- Do NOT guess repository name - derive from git/gh commands\n- Do NOT forget the \"v\" prefix on the tag for `github_release`\n- Do NOT include version bump commits in release notes\n- Do NOT include merge commits in release notes\n- Do NOT forget author handles (@username) in release notes\n- Do NOT skip the todo list workflow\n- Do NOT create a release when there are no new commits\n";

package/dist/tools/apply-labels/index.d.ts

@@ -0,0 +1,2 @@
+import { type ToolDefinition } from '@opencode-ai/plugin/tool';
+export declare const applyLabelsTool: ToolDefinition;

package/dist/tools/apply-labels/schema.d.ts

@@ -0,0 +1,12 @@
+import { z } from 'zod';
+export declare const ApplyLabelsSchema: z.ZodObject<{
+    repository: z.ZodString;
+    issueNumber: z.ZodNumber;
+    labels: z.ZodArray<z.ZodString>;
+    newLabels: z.ZodOptional<z.ZodArray<z.ZodObject<{
+        name: z.ZodString;
+        color: z.ZodString;
+        description: z.ZodString;
+    }, z.core.$strip>>>;
+    explanation: z.ZodString;
+}, z.core.$strip>;

package/dist/tools/bun-release/index.d.ts

@@ -0,0 +1,2 @@
+import { type ToolDefinition } from '@opencode-ai/plugin/tool';
+export declare const bunReleaseTool: ToolDefinition;

package/dist/tools/bun-release/schema.d.ts

@@ -0,0 +1,4 @@
+import { z } from 'zod';
+export declare const BunReleaseSchema: z.ZodObject<{
+    version: z.ZodString;
+}, z.core.$strip>;

package/dist/tools/github-release/index.d.ts

@@ -0,0 +1,2 @@
+import { type ToolDefinition } from '@opencode-ai/plugin/tool';
+export declare const githubReleaseTool: ToolDefinition;

package/dist/tools/github-release/schema.d.ts

@@ -0,0 +1,9 @@
+import { z } from 'zod';
+export declare const GithubReleaseSchema: z.ZodObject<{
+    repository: z.ZodString;
+    tag: z.ZodString;
+    notes: z.ZodArray<z.ZodString>;
+    title: z.ZodOptional<z.ZodString>;
+    prerelease: z.ZodOptional<z.ZodBoolean>;
+    draft: z.ZodOptional<z.ZodBoolean>;
+}, z.core.$strip>;

package/dist/tools/index.d.ts

@@ -0,0 +1,2 @@
+import type { Hooks } from '@opencode-ai/plugin';
+export declare const tools: NonNullable<Hooks['tool']>;

package/dist/tools/submit-review/index.d.ts

@@ -0,0 +1,2 @@
+import { type ToolDefinition } from '@opencode-ai/plugin/tool';
+export declare const submitReviewTool: ToolDefinition;

package/dist/tools/submit-review/schema.d.ts

@@ -0,0 +1,24 @@
+import { z } from 'zod';
+export declare const SubmitReviewSchema: z.ZodObject<{
+    repository: z.ZodString;
+    pullNumber: z.ZodNumber;
+    commitSha: z.ZodString;
+    summary: z.ZodString;
+    verdict: z.ZodEnum<{
+        approve: "approve";
+        request_changes: "request_changes";
+    }>;
+    issues: z.ZodArray<z.ZodObject<{
+        file: z.ZodString;
+        line: z.ZodNumber;
+        severity: z.ZodEnum<{
+            critical: "critical";
+            high: "high";
+            medium: "medium";
+            low: "low";
+        }>;
+        title: z.ZodString;
+        explanation: z.ZodString;
+        suggestion: z.ZodOptional<z.ZodString>;
+    }, z.core.$strip>>;
+}, z.core.$strip>;

package/dist/tools/utils/retry.d.ts

@@ -0,0 +1,7 @@
+export interface RetryOptions {
+    maxRetries?: number;
+    baseDelay?: number;
+    signal?: AbortSignal;
+}
+export declare function withRetry<T>(fn: () => Promise<T>, opts?: RetryOptions): Promise<T>;
+export declare function checkAborted(signal?: AbortSignal): void;

package/package.json

@@ -0,0 +1,61 @@
+{
+  "name": "@activade/open-workflows",
+  "version": "1.0.0",
+  "description": "OpenCode plugin with skills for AI-powered GitHub workflows: PR reviews, issue labeling, doc sync, and releases",
+  "keywords": [
+    "opencode",
+    "opencode-plugin",
+    "opencode-skills",
+    "github",
+    "ai",
+    "code-review",
+    "automation",
+    "pr-review",
+    "issue-labeling"
+  ],
+  "author": "activadee",
+  "license": "MIT",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/activadee/open-workflows.git"
+  },
+  "type": "module",
+  "main": "./dist/index.js",
+  "types": "./dist/index.d.ts",
+  "bin": {
+    "open-workflows": "./dist/cli/index.js"
+  },
+  "exports": {
+    ".": {
+      "types": "./dist/index.d.ts",
+      "import": "./dist/index.js"
+    }
+  },
+  "files": [
+    "dist",
+    "README.md",
+    "LICENSE"
+  ],
+  "scripts": {
+    "clean": "rm -rf dist",
+    "build": "bun run clean && bun build src/index.ts --outdir dist --target bun --format esm -e @opencode-ai/plugin -e @opencode-ai/plugin/tool --minify && bun build src/cli/index.ts --outdir dist/cli --target bun --format esm --minify && bun x tsc --declaration --emitDeclarationOnly --outDir dist",
+    "dev": "bun run build --watch",
+    "typecheck": "tsc --noEmit",
+    "test": "bun run build && bun test",
+    "prepublishOnly": "bun run clean && bun run build && bun run typecheck"
+  },
+  "dependencies": {
+    "@clack/prompts": "^0.10.0",
+    "@opencode-ai/plugin": "^1.0.204",
+    "picocolors": "^1.1.1",
+    "zod": "~4.1.8"
+  },
+  "devDependencies": {
+    "@types/node": "^22.0.0",
+    "bun-types": "latest",
+    "typescript": "^5.6.0"
+  },
+  "engines": {
+    "node": ">=18.0.0"
+  }
+}