/pr-buddy @0.4.2

you ❯ /pr-buddy 74 fetching PR #74 and diff… (silent pre-phase) identified entry point: skills/pgm/jira-ticket-automator/SKILL.md risk flag: catalog.json and INDEX.md look hand-edited / \__ ( @\___ / O / (_____/ /_____/ U ── station 1 · goal ──────────────────────────────────────────── Based on the title and description, what problem do you think this PR is solving? What's the outcome the author was aiming for? you ❯ there was a skill named jira-tickets-from-epic and this is renaming it to jira-ticket-automator, ALSO adding 5 new fixes/features: jira project ids, ticket naming, a perf improvement, some internal thing, new writeback to Confluence with the jira link, plus an MCP fix for windowsOS Exactly right. The rename signals it's now scoped specifically to the ACME+Confluence workflow. The 5 improvements are hardcoded learnings from a real run against ACME-1158 — the "happy path" became the spec. / \__ ( @\___ / O / (_____/ /_____/ U ── station 2 · architecture ──────────────────────────────────── Changed files (+400 / -0) ──────────────────────────────────────────────────────── skills/pgm/jira-ticket-automator/ SKILL.md +246 / -0 ← entry point README.md +77 / -0 ← human-facing docs references/ jira-field-mapping.md +55 / -0 ← field reference INDEX.md +1 / -0 ← catalog pointer catalog.json +21 / -0 ← catalog entry ──────────────────────────────────────────────────────── 2 dirs · 5 files · +400 / -0 total Which file is the entry point? Walk me through your mental model — how do these changes fit together? you ❯ the main thing should be SKILL.md — drives everything else Right. SKILL.md is the agent-executable definition that drives everything. The flow is linear: read epic → read Confluence pages → approval gate → create issues → write back to Confluence. The writeback (Phase 3.7) is the most interesting addition — it's what makes the skill idempotent on re-runs. File walkthrough [x] SKILL.md — entry point [ ] README.md — human-facing docs [ ] references/jira-field-mapping.md — field reference [ ] INDEX.md / catalog.json — registry / \__ ( @\___ / O / (_____/ /_____/ U ── station 3 · decisions ─────────────────────────────────────── File walkthrough [x] SKILL.md — entry point (discussed) [ ] README.md — human-facing docs [ ] references/jira-field-mapping.md — field reference ← focus [ ] INDEX.md / catalog.json — registry Three notable choices in the diff: 1. In SKILL.md: epic link via jira_create_issue_link, not customfield_10091 2. In SKILL.md: issuetype ID "5" hardcoded in additional_fields 3. In SKILL.md: Confluence writeback patches "* US CORP:" line in-place What would you have done differently, if anything? you ❯ 1. maybe customfield_10091 is project-specific and OP kept it flexible? 2. but then point 1 loses strength — the id IS fixed here 3. this feels like a possible bug 4. why jira-field-mapping.md? a .json would be more reliable than an LLM-parsed markdown file 1. Correct — customfield_10091 is screen-restricted in BIGPROJECT. jira_create_issue_link isn't a preference, it's a forced workaround. 2. Sharp catch. ID "5" assumes Sub-task type is 5 everywhere. Brittle. 3. Agreed — "* US CORP:" assumes that exact string. No fallback documented. 4. Strong point. The .md conflicts with SKILL.md (issuetype: Story vs User Story). A JSON file forces structure — harder to contradict. you ❯ also — is README.md necessary? might be duplicating other READMEs in the repo Valid — README.md duplicates SKILL.md almost entirely. The only unique content is the "How to invoke" examples. And there's an active bug: the file structure section still shows the old path skills/pgm/jira-tickets-from-epic/ you ❯ remind me which files we're looking at Changed files (+400 / -0) ──────────────────────────────────────────────────────── skills/pgm/jira-ticket-automator/ SKILL.md +246 / -0 ← entry point README.md +77 / -0 ← human-facing docs references/ jira-field-mapping.md +55 / -0 ← field reference INDEX.md +1 / -0 ← catalog pointer catalog.json +21 / -0 ← catalog entry ──────────────────────────────────────────────────────── Where were we — ready to go on? you ❯ yes / \__ ( @\___ / O / (_____/ /_____/ U ── station 4 · risk ──────────────────────────────────────────── If you had to name one thing that could go wrong with this PR in production — an edge case, a race condition, a missing test, a performance concern — what would it be? you ❯ removing a skill from catalog could be nasty on people's laptops… maybe safe since it's an internal repo Good instinct about catalog churn — but this PR has the opposite problem. catalog.json still says name: jira-tickets-from-epic, version: 0.1.0, path: skills/pgm/jira-tickets-from-epic/SKILL.md — none of which exist. Actual files landed under jira-ticket-automator/. SKILL.md says v0.5.0. Broken in three ways simultaneously: wrong name, wrong path, wrong version. Anyone running claude skill add gets a 404. Likely cause: catalog.json was hand-edited instead of running npm --prefix tools run build-index. / \__ ( @\___ / O / (_____/ /_____/ U ── station 5 · ownership ─────────────────────────────────────── Could you explain this PR to a teammate right now, confidently? What, if anything, are you still unsure about? you ❯ yes. next step / \__ ( @\___ / O / (_____/ /_____/ U ── phase 2 · automated checks (3 agents, parallel) ───────────── running code-reviewer, silent-failure-hunter, pr-test-analyzer… context from walkthrough passed as anchor (your findings, decisions noted) [CRITICAL] catalog.json / INDEX.md — wrong name, path, version. run build-index. [CRITICAL] Phase 3.7 writeback: no branch for missing "* US CORP:" line → idempotency guard silently broken, duplicate US on re-run [CRITICAL] "already linked" detection matches any [A-Z]+-[0-9]+ in prose → silent false-positive skips entire issue creation [HIGH] jira-field-mapping.md conflicts with SKILL.md on 3 points [HIGH] hardcoded issuetype ID "5" applied to all projects without check [HIGH] jira_create_issue_link failure leaves US orphaned from epic silently [GAP] all 4 test-plan checkboxes unchecked; no catalog consistency test ── comment posted to PR #74 ───────────────────────────────────── synthesizes walkthrough conversation + automated checks ↓ Goal: rename + upgrade jira-tickets-from-epic → jira-ticket-automator v0.5.0, baking in ACME-1158 learnings. Epic link via jira_create_issue_link because customfield_10091 is screen-restricted in BIGPROJECT — forced workaround. Main risk: writeback patches "* US CORP:" with no fallback — idempotency breaks. Automated: 3 CRITICALs (catalog broken, writeback silent fail, false-skip), 3 HIGHs (field-mapping conflicts, hardcoded ID, orphaned epic link), 1 GAP. Verdict: Request changes · 5 blockers before merge