diff --git a/plugins/bin/.claude-plugin/plugin.json b/plugins/bin/.claude-plugin/plugin.json index f997088..52e862a 100644 --- a/plugins/bin/.claude-plugin/plugin.json +++ b/plugins/bin/.claude-plugin/plugin.json @@ -8,5 +8,5 @@ "keywords": [], "license": "MIT", "name": "bin", - "version": "1.0.4" + "version": "1.0.5" } diff --git a/plugins/bin/plugin.json b/plugins/bin/plugin.json index 62381fa..ac57fff 100644 --- a/plugins/bin/plugin.json +++ b/plugins/bin/plugin.json @@ -12,5 +12,5 @@ "skills": [ "skills/" ], - "version": "1.0.4" + "version": "1.0.5" } diff --git a/plugins/bin/skills/gitea/SKILL.md b/plugins/bin/skills/gitea/SKILL.md index 736f9ef..a6203aa 100644 --- a/plugins/bin/skills/gitea/SKILL.md +++ b/plugins/bin/skills/gitea/SKILL.md @@ -11,7 +11,7 @@ description: > no config required. Do not use for releases, CI/Actions, wiki, file operations, notifications, or package management — those are out of scope. compatibility: Requires Gitea MCP server configured in ~/.claude.json with write:issue and write:repository token scopes. Requires git remote "origin" pointing to the Gitea instance. -allowed-tools: Bash mcp__gitea__list_issues mcp__gitea__search_issues mcp__gitea__issue_read mcp__gitea__issue_write mcp__gitea__label_read mcp__gitea__label_write mcp__gitea__milestone_read mcp__gitea__milestone_write mcp__gitea__list_pull_requests mcp__gitea__pull_request_read mcp__gitea__pull_request_write mcp__gitea__list_branches mcp__gitea__create_branch +allowed-tools: Bash mcp__gitea__list_issues mcp__gitea__issue_read mcp__gitea__issue_write mcp__gitea__label_read mcp__gitea__label_write mcp__gitea__milestone_read mcp__gitea__milestone_write mcp__gitea__list_pull_requests mcp__gitea__pull_request_read mcp__gitea__pull_request_write mcp__gitea__list_branches mcp__gitea__create_branch metadata: category: integration --- @@ -22,7 +22,7 @@ metadata: - **Issues and PRs share a number space.** `#5` might be an issue or a PR — there is only one counter per repo. `list_issues` returns issues only — it has no `type` parameter. Use `list_pull_requests` separately for PRs. Check `is_pull` on a single-item `issue_read` response to determine whether a number refers to an issue or PR. - **Milestone write takes ID, not title.** `issue_write` takes `milestone: `. The title is not accepted. In `issue_read` responses the milestone is `{id, title}`, but in `pull_request_read` responses it's a bare title string — you cannot recover the ID from a PR response. Call `milestone_read method: "list"` and match by title if you need the ID from a PR context. - **`get_me` is unavailable** with the current token (`write:issue, write:repository` only — `read:user` is missing). Owner and repo must always be derived from the git remote, never from `get_me` or `list_my_repos`. -- **Issues are not auto-closed when a PR merges.** Unlike GitHub, Gitea does not close linked issues on merge. Close explicitly with `issue_write method: "update" state: "closed"` after merging. +- **Merging a PR does not itself close linked issues — but a commit message landing on the default branch can.** Gitea has no GitHub-style "merge triggers close" event. It does, however, parse closing keywords (`Fixes #N`, `Closes #N`) in commit messages pushed to the default branch. A regular (non-squash) merge preserves each original commit message, so if any of those commits says `Fixes #N`, the issue auto-closes at merge time — confirmed empirically (PR #64 auto-closed #63 this way, before any explicit `issue_write` call was made). This skill's own `pr merge` dispatch defaults to `merge_style: "squash"` (Step 3), which rewrites history into one commit — whether the keyword survives depends on what message that squash commit ends up with, so squash-merged PRs are the case most likely to still need an explicit close. Always call `issue_read method: "get"` to check current state before manually closing after a merge — closing an already-closed issue is a harmless no-op, but don't assume a manual close is always needed. - **Pagination is manual.** List tools return one page at a time — no auto-pagination. When building complete datasets (e.g. all labels for name→ID mapping), iterate `page: 1, 2, ...` until result count < `per_page`. - **`pull_request_read method: "get"` returns `review_scomments`, not `review_comments`.** This is a source-level typo in gitea-mcp v1.3.0. Do not access `review_comments` — it will always be undefined. Use `review_scomments`. - **Cross-repo fork PRs require `head` as `"fork-owner:branch-name"`.** A bare branch name causes Gitea to search the base repo and return 422. The `pr create` dispatch assumes same-repo PRs (bare branch name). For fork-based PRs, pass `head` explicitly in the `owner:branch` format. @@ -125,6 +125,8 @@ First call `pull_request_read method: "get_status" pull_number: `. If CI stat Then call `pull_request_write method: "merge" pull_number: merge_style: "squash" delete_branch: true`. To use a different merge style, the user must specify it explicitly. +Squashing rewrites history into one commit — whether a linked issue's closing keyword survives depends on what message that squash commit ends up with. After merging, call `issue_read method: "get"` on any issue referenced by the PR to check whether it auto-closed before deciding whether to close it explicitly (see the auto-close gotcha above). + ### milestone create Call `milestone_write method: "create" title: <title>`. Report the created milestone ID — it will be needed for assigning issues. diff --git a/plugins/kyberforge/.claude-plugin/plugin.json b/plugins/kyberforge/.claude-plugin/plugin.json index d1f1479..5894989 100644 --- a/plugins/kyberforge/.claude-plugin/plugin.json +++ b/plugins/kyberforge/.claude-plugin/plugin.json @@ -8,5 +8,5 @@ "keywords": [], "license": "MIT", "name": "kyberforge", - "version": "1.2.1" + "version": "1.2.2" } diff --git a/plugins/kyberforge/plugin.json b/plugins/kyberforge/plugin.json index 6684331..1225684 100644 --- a/plugins/kyberforge/plugin.json +++ b/plugins/kyberforge/plugin.json @@ -13,5 +13,5 @@ "skills": [ "skills/" ], - "version": "1.2.1" + "version": "1.2.2" } diff --git a/plugins/kyberforge/skills/agent-audit/SKILL.md b/plugins/kyberforge/skills/agent-audit/SKILL.md index 9218158..894a823 100644 --- a/plugins/kyberforge/skills/agent-audit/SKILL.md +++ b/plugins/kyberforge/skills/agent-audit/SKILL.md @@ -4,9 +4,12 @@ description: > Use when the user wants to review an agent definition they wrote, says "audit this agent", "check if my agent follows best practices", "review my agent file", or wants to know if an agent pair is ready to ship — even if they don't use the word "audit". - Audits a Claude Code .md and Copilot .agent.md agent file pair across five dimensions: - structural validation, provider safety, description quality, body quality, and pair - consistency — plus provenance chain validation. Produces a compact findings report + Also invoke proactively after directly hand-editing an agent file pair outside + agent-author — an unaudited hand-edit is the same risk as unreviewed code. + Audits a Claude Code .md and Copilot .agent.md agent file pair across six dimensions: + structural validation, provider safety, description quality, body quality, comment + discipline, and pair consistency — plus provenance chain validation. Produces a + compact findings report (findings only, no PASS noise) with Why and Fix per finding. Do not use to fix agent files — use /agent-author instead. Do not use to audit SKILL.md files — use /skill-audit instead. diff --git a/plugins/kyberforge/skills/agent-audit/scripts/validate-provenance.sh b/plugins/kyberforge/skills/agent-audit/scripts/validate-provenance.sh index 99c4e84..2b6e2fc 100755 --- a/plugins/kyberforge/skills/agent-audit/scripts/validate-provenance.sh +++ b/plugins/kyberforge/skills/agent-audit/scripts/validate-provenance.sh @@ -14,6 +14,7 @@ Arguments: Exit codes: 0 All checks passed (or nothing to validate, or not plugin scope) 1 One or more checks failed + 2 Script error (unrecognized file extension — expected .md or .agent.md) Checks performed: 0 source_keys present in agent pair but sources.md absent diff --git a/plugins/kyberforge/skills/plugin-author/SKILL.md b/plugins/kyberforge/skills/plugin-author/SKILL.md index 8f66245..91fb0d8 100644 --- a/plugins/kyberforge/skills/plugin-author/SKILL.md +++ b/plugins/kyberforge/skills/plugin-author/SKILL.md @@ -34,6 +34,7 @@ metadata: - `displayName` is a CC platform field — Copilot has no equivalent. Do not add it to the Copilot manifest. - `skills`, `agents`, `hooks`, `mcpServers` are declared in the Copilot manifest by convention — Copilot requires explicit path declarations while CC auto-discovers content from the plugin root. Both platforms support these fields; omit them from the CC manifest by convention. - Agent files in a plugin's `agents/` directory silently ignore `hooks`, `mcpServers`, and `permissionMode` frontmatter fields. +- `claude plugin validate --strict` auto-discovers every `.md` file directly under `agents/` and treats it as an agent definition requiring frontmatter — this is independent of the manifest. An explicit `agents` array listing only the real agent files does not suppress the scan; unlisted `.md` files in the same directory still fail validation (tested empirically — see ADR-0010). Any non-agent file (notes, provenance records, READMEs) must live outside `agents/` — e.g. at the plugin root — regardless of what the manifest declares. ## Route diff --git a/plugins/kyberforge/skills/skill-audit/SKILL.md b/plugins/kyberforge/skills/skill-audit/SKILL.md index d6f3762..eac4a0f 100644 --- a/plugins/kyberforge/skills/skill-audit/SKILL.md +++ b/plugins/kyberforge/skills/skill-audit/SKILL.md @@ -4,6 +4,8 @@ description: > Use when the user wants to review a skill they wrote, says "audit this skill", "check if my skill follows best practices", "review my SKILL.md", or wants to know if a skill is ready to ship — even if they don't use the word "audit". + Also invoke proactively after directly hand-editing a skill's files outside + skill-author — an unaudited hand-edit is the same risk as unreviewed code. Audits a skill directory against the agentskills.io specification — structural checks plus qualitative review of description quality, body discipline, patterns, formatting, file structure, scripts, and internal consistency, plus a provenance