Defame1297/holocron
0
0
Fork 0
Code Issues 14 Pull Requests Actions Packages Projects Releases 3 Wiki Activity

fix(kyberforge/gitea): correct Status dispatch and issue create enrichment

Browse Source 
Status now calls list_issues + list_pull_requests in parallel instead
of passing a non-existent type parameter to list_issues. Stale type
reference in Gotchas removed.

Issue create now infers labels from conversation context (Kind/*/
Priority/*/Status/*) before the write call, resolving names to IDs
via label_read first.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
Defame1297
2026-06-25 18:59:06 +00:00
parent b9c73cc0b2
commit b0d132f59a
1 changed files with 11 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
plugins/kyberforge/skills/gitea/SKILL.md
View File

@@ -18,7 +18,7 @@ metadata:
## Gotchas
- **Label writes take IDs, reads return names.** `issue_write` (add_labels, replace_labels) requires `labels: [3, 7]` (numeric IDs). Issue and PR responses return `labels: ["bug", "enhancement"]` (name strings). These are never interchangeable. Always call `label_read method: "list_repo_labels"` first and resolve names → IDs before any label write.
- **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 both unless you pass `type: "issues"` or `type: "pulls"`. Check `is_pull` on a single-item `issue_read` response to determine the type.
- **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: <numeric id>`. 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.
@@ -62,15 +62,23 @@ Route on the first argument:
### Status (default)
Call `list_issues` twice in parallel — once with `type: "issues"` and once with `type: "pulls"`, both `state: "open"`. Report as two sections.
Call `list_issues state: "open"` and `list_pull_requests state: "open"` in parallel. `list_issues` does not accept a `type` parameter — it returns issues only. `list_pull_requests` returns PRs. Report as two sections.
### issue (create)
Extract title and body from conversation context. Use the most recent task, bug description, grill output, or explicit statement. If no body text is available from context, fall back to empty string. Fire immediately — no confirmation step.
**Label inference (do this before the create call):**
1. Call `label_read method: "list_repo_labels"` to get all available labels with their IDs.
2. From conversation context, infer which labels apply:
- Issue type → `Kind/*`: bug reports → `Kind/Bug`; new capabilities → `Kind/Feature`; improvements → `Kind/Enhancement`; docs → `Kind/Documentation`; security → `Kind/Security`
- Urgency signals → `Priority/*`: "blocking", "critical", "urgent" → `Priority/Critical`; "soon", "high priority" → `Priority/High`; default → `Priority/Medium`
- Explicit blocking → `Status/Blocked`
3. Resolve inferred label names to IDs from the label list. **Labels require numeric IDs — never pass name strings to `issue_write`.** If no labels can be confidently inferred, omit the `labels` parameter entirely rather than guessing.
Set `ref` to the current branch name (`git branch --show-current`) if a branch is already checked out for this work.
Call `issue_write method: "create" title: <extracted> body: <extracted or ""> ref: <current-branch-if-applicable>`.
Call `issue_write method: "create" title: <extracted> body: <extracted or ""> labels: [<inferred IDs or omit>] ref: <current-branch-if-applicable>`.
### issue <N>