/pr-buddy @0.6.0

you ❯ /pr-buddy 74 / \__ ( @\___ / O / (_____/ /_____/ U pr-buddy · let's walk through this one ───────────────────────────────────────────────────────────────── 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 ── station 1 · goal ──────────────────────────────────────────── cognitive debt ████████████ 100% unreviewed PR #74 — feat(skill): jira-ticket-automator v0.5.0 Author: @op · main ← feat/jira-ticket-automator difficulty: hard · +400 / -0 · 5 files 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. ── station 2 · architecture ──────────────────────────────────── cognitive debt ██████████░░ 83% goal discussed 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 ── station 3 · decisions ─────────────────────────────────────── cognitive debt ████████░░░░ 66% architecture mapped 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 ── station 4 · code tour ──────────────────────────────────────── cognitive debt ██████░░░░░░ 50% decisions probed Code tour ──────────────────────────────────────────────────────── ---skills/pgm/jira-ticket-automator |---- SKILL.md | · ## Pre-phase — fetch PR metadata and diff | · ## Phase 1 — Socratic walkthrough (stations 1–6) | · ## Phase 2 — Automated quality checks |---- references/jira-field-mapping.md · ## Epic link field · ## Issue type IDs · ## Confluence writeback pattern catalog.json · name: string · version: string · path: string ──────────────────────────────────────────────────────── 3 files · 9 signatures total Does this give you a clear enough picture of the code structure? [1] yes — move on to Station 5 · Risk (default) [2] go deeper — walk me through the most interesting function you ❯ 1 ── station 5 · risk ──────────────────────────────────────────── cognitive debt ████░░░░░░░░ 33% code tour done 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. ── station 6 · ownership ─────────────────────────────────────── cognitive debt ██░░░░░░░░░░ 17% risk identified Could you explain this PR to a teammate right now, confidently? What, if anything, are you still unsure about? you ❯ yes. next step ── review complete ───────────────────────────────────────────── cognitive debt ░░░░░░░░░░░░ 0% cleared Review Depth 8/10 · hard PR · substantive · tree checked ── 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) ── comment posted to PR #74 ───────────────────────────────────── ## [MANUAL REVIEW] 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] 🔴 catalog.json has wrong name, path, version — run build-index before merge 🔴 writeback silently skips when "* US CORP:" line is absent — duplicate US on re-run 🔴 "already linked" check matches any Jira key in prose — silently skips issue creation 🟠 jira-field-mapping.md conflicts with SKILL.md on 3 points 🟠 issuetype ID "5" hardcoded — brittle across Jira instances 🟠 jira_create_issue_link failure leaves US orphaned from epic with no error logged 🟡 all 4 test-plan checkboxes unchecked; no catalog consistency test Verdict: Request changes · 3 blockers before merge