Skills: breakdown — generate issues from specs/*.md with routing labels #54
Labels
No labels
area:agents
area:dashboard
area:database
area:design
area:design-review
area:flows
area:infra
area:meta
area:security
area:sessions
area:webhook
area:workdir
security
type:bug
type:chore
type:meta
type:user-story
No milestone
No project
No assignees
1 participant
dev
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
charles/claude-hooks#54
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
User story
As a maintainer, I want to drop a
spec.mdin a repo'sspecs/folder and, via a/breakdownslash-command comment on a tracking issue, have boss read the spec, generate a user-story-format issue per section (with labels likearea:*,type:user-story, andsecuritywhere warranted), so that routing (A3) can then sendsecurity-labeled PRs to a senior reviewer instance automatically.Context
No skill currently drives this — the CLAUDE.md convention for well-structured user stories is applied manually by the interactive operator via the MCP. Automating it enables spec → issues → typed-review loops without human authoring of each ticket.
Trigger choice: slash-command on an issue comment. Explicit, no ambiguity, scoped. Alternatives (push-webhook on
specs/**changes, issue labels) defer for now.Acceptance criteria
New skill
skills/breakdown.md— instructs boss to:specs/*.mdin the repo (via forgejo-mcpget_file_contentagainst the repo root + directory listing).As a <role>, I want <capability>, so that <outcome>), acceptance criteria grouped by sub-section, out-of-scope list, references list, dependencies footer.type:user-storyalways.area:<slug>per existing repo convention (read the label list first; don't invent newarea:*labels — log a warning and skip if the spec implies one that doesn't exist).securitywhen the spec section mentions authentication, authorization, crypto / key material, secrets, session tokens, SSRF / injection / XSS patterns. Mechanical keyword-match; over-tag is fine, under-tag is the failure mode.devfor typical implementation,bossfor architecture-heavy work the spec explicitly flags as senior).specs/<file>.md. Security-labeled: #B."Dispatch path
issue_commentevents (new event handler insrc/webhook-handlers.ts). When the comment body starts with/breakdownand the commenter is a configured trusted user (owner + any agent — NOT arbitrary Forgejo users), dispatch abreakdowntask to thebosspool.buildTaskRequest(existing helper) extended for the breakdown flow: the skill isbreakdown, the prompt interpolates{{repo}},{{tracking_issue_number}}, and{{trigger_comment_body}}./breakdowncomments are ignored (no dispatch, webhook returns 200).Security label as A3 fodder
securityon an issue means any PR that closes that issue inherits the label (via Forgejo'sCloses #Nresolution), and A3's reviewer routing picks thereviewer-securityinstance on that PR. So the skill authoring quality directly affects review-model cost.Tests
issue_comment:/breakdownfrom trusted user dispatches;/breakdownfrom random user → 200 + skip log; non-slash comment → 200 + skip log.Manual verification
specs/hello.md(2–3 sections, one mentioning "authentication"), comment/breakdownon a tracking issue. Confirm:securitylabel.reviewer-securityinstance exists withmatch_labels: ["security"], a PR that closes the security issue gets routed to that reviewer instance per A3's log line.Out of scope
securitylabel.References
Dependencies
main(after A3 lands).