claude-dev-env 1.93.0 → 1.94.0

package/skills/pr-review-responder/SKILL.md

@@ -1,203 +0,0 @@
----
-name: pr-review-responder
-description: MANDATORY systematic protocol for responding to GitHub PR review comments. Use when addressing PR feedback, code review comments, or before pushing PR fixes. Triggers on "address feedback", "fix review comments", "respond to code review", "handle PR feedback", "reply to reviewer".
----
-@~/.claude/skills/pr-review-responder/EXAMPLES.md
-@~/.claude/skills/pr-review-responder/PRINCIPLES.md
-
-<EXTREMELY_IMPORTANT>
-# PR Review Responder
-
-**This skill is MANDATORY when responding to PR review comments.**
-
-IF you are addressing PR review feedback, YOU DO NOT HAVE A CHOICE. YOU MUST FOLLOW THIS PROTOCOL.
-
-**Why this matters:** A typical multi-commit PR with many review comments is easy to fumble. Missing even one comment forces another review round.
-
-## MANDATORY FIRST RESPONSE PROTOCOL
-
-Before doing ANYTHING:
-
-1. [ ] Fetch ALL review comments with `per_page=100` pagination
-2. [ ] Create TodoWrite checklist with ONE item per comment
-3. [ ] Fix comments ONE AT A TIME, marking complete as you go
-4. [ ] Draft reply for EVERY comment (DO NOT post directly)
-5. [ ] Create ONE review fix commit (DO NOT squash with original)
-6. [ ] Push — the git pre-push hook (installed via `npx claude-dev-env`) runs automatically
-7. [ ] Verify ALL draft replies are prepared
-
-**Responding WITHOUT completing this checklist = automatic failure.**
-
-## Critical Rules - NO EXCEPTIONS
-
-### Rule 1: Fetch ALL Comments First
-
-**NEVER start fixing without fetching every comment.**
-
-- [ ] FORBIDDEN: Assuming you know what the comments say
-- [ ] FORBIDDEN: Using default pagination (30 results, causes missed comments)
-- [x] REQUIRED: `pull_request_read(method="get_review_comments", pullNumber={pr_number}, owner="{owner}", repo="{repo}")`
-
-**WHY:** Missing comments forces extra review rounds. Default pagination (30) silently drops comments.
-
-### Rule 2: TodoWrite Checklist Before Any Fixes
-
-**NEVER make fixes without a checklist.**
-
-- [ ] FORBIDDEN: Fixing comments as you read them
-- [ ] FORBIDDEN: Bulk-updating todos after fixing multiple items
-- [x] REQUIRED: Create TodoWrite with one item per comment BEFORE any fix
-- [x] REQUIRED: Include BOTH fix items AND reply items
-
-**WHY:** Without a checklist, you WILL miss comments.
-
-Example checklist:
-```
-- [ ] Fix: src/views.py:45 - Use shared upload function
-- [ ] Fix: src/models.py:23 - Rename user_name to display_name
-- [ ] Reply: src/views.py:45 - Post inline response
-- [ ] Reply: src/models.py:23 - Post inline response
-```
-
-### Rule 3: Fix Systematically
-
-**NEVER skip ahead or bulk-update.**
-
-For each comment in TodoWrite:
-1. Read the comment
-2. Make the fix
-3. Mark todo item complete: `[x]`
-4. Verify fix addresses comment
-5. Move to next comment
-
-### Rule 4: Draft Replies for User Review
-
-**NEVER post comments directly. Draft them for user to review and post.**
-
-Format each draft reply:
-```
-DRAFT REPLIES (for user to post):
-================================
-
-Comment #1 (file.py:45 - "description"):
-Reply: Fixed: [specific description of what was changed]
-
-Comment #2 (file.py:67 - "description"):
-Reply: Fixed: [specific description of what was changed]
-```
-
-**Reply quality rules:**
-- Concise: One sentence maximum
-- Specific: Say WHAT changed, not just "fixed"
-- Actionable: Reviewer can verify the fix
-
-### Rule 5: Separate Review Fix Commit
-
-**NEVER squash review fixes into the original commit.**
-
-- [ ] FORBIDDEN: Amending the original commit with review fixes
-- [ ] FORBIDDEN: Multiple fix commits for the same review round
-- [x] REQUIRED: ONE new commit for all review fixes from this round
-
-**WHY:** Squashing shows the ENTIRE feature as new on GitHub instead of just the delta. Keeping commits separate lets the reviewer click the second commit to see exactly what changed.
-
-```bash
-git add [files]
-git commit -m "fix: address code review feedback
-
-- Fixed: [specific change 1]
-- Fixed: [specific change 2]
-
-Addresses review comments from PR #{number}"
-```
-
-### Rule 6: Pre-Push Gate Fires Automatically
-
-**The git pre-push hook (installed via `npx claude-dev-env`) runs automatically on every `git push`.** It covers lint, magic values, boolean naming, imports, and all code-rules enforcer checks — no manual invocation needed.
-
-- [ ] FORBIDDEN: Pushing without gate passing
-- [ ] FORBIDDEN: Manually handling draft conversion
-- [x] REQUIRED: Run `git push`; the pre-push hook fires and blocks if any check fails
-
-Use `/qbug` only when you want a full multi-loop PR audit with subagents after the PR is open — it is NOT a substitute for the pre-push gate and refuses when no PR exists yet.
-
-**WHY:** The pre-push hook catches ALL patterns reviewers flag: code style, draft status, commit structure. It fires automatically so nothing is missed.
-
-### Rule 7: Verify All Drafts Complete
-
-**NEVER declare success without matching draft count to comment count.**
-
-- Count of drafts must match count of comments
-- Each draft must reference a specific fix
-- Present drafts in clear format for user to copy
-
-## Common Rationalizations That Mean You're About To Fail
-
-- **"I know what the comments say, no need to fetch"** -> WRONG. Missing comments forces extra review rounds.
-- **"Let me fix this one quickly before making the checklist"** -> WRONG. Without checklist you will miss others.
-- **"I'll post the replies myself to save time"** -> WRONG. User controls what gets posted.
-- **"This is a small fix, I can squash it"** -> WRONG. Squashing hides the delta from reviewers.
-- **"Pre-push review is overkill for review fixes"** -> WRONG. The git pre-push hook catches style issues you introduced while fixing; it fires automatically on every push.
-
-</EXTREMELY_IMPORTANT>
-
----
-
-## Final Report Format
-
-Only after ALL validations pass:
-
-```
-PR Review Response Complete
-
-Fetched: {X} comments (with per_page=100)
-Fixed: {X} issues
-Pre-push hook: PASSED (fired automatically on git push)
-Draft replies: {X} prepared for user
-Commits: 2 (original + review fix, NOT squashed)
-
-TodoWrite checklist: 100% complete
-
-DRAFT REPLIES FOR USER TO POST:
-================================
-[List all draft replies here]
-
-PR #{number}: {url}
-
-Ready to push!
-```
-
-## Edge Cases
-
-**No review comments found:**
-Report with verification that per_page=100 was used.
-
-**Comments but no matching changes:**
-List the comments and their file locations, ask if fixes were forgotten.
-
-**PR already merged:**
-Cannot add review responses to merged PRs. Report error.
-
-## Response Format Rules
-
-**Good replies:**
-- Fixed: Removed wrapper function, using direct storage.upload_file()
-- Fixed: Extracted shared logic to utils/view_helpers.py
-- Fixed: Renamed user_name to display_name to avoid User.username conflict
-- Noted: Will handle in separate PR to avoid scope creep
-
-**Bad replies:**
-- "Fixed" (not specific)
-- "Done" (lazy)
-- "Addressed your comment" (tells reviewer nothing)
-
-## Requirements
-
-- GitHub MCP server (`plugin:github:github`) authenticated
-- Current branch must have an open PR
-- Git repository with remote on GitHub
-- Write access to repository
-
-## Remember
-
-This protocol prevents repeated review failures. Being systematic is NOT optional. Missing even ONE comment wastes everyone's time.

package/skills/pr-review-responder/TESTING.md

@@ -1,350 +0,0 @@
-# Testing the PR Review Responder Skill
-
-This document provides testing instructions and expected behavior.
-
-## Skill Activation Tests
-
-### Should Activate (Expected Triggers)
-
-Test these queries - skill SHOULD activate:
-
-1. **Direct requests**:
-   - "Respond to PR review comments"
-   - "Reply to code review feedback"
-   - "Post responses to reviewer comments"
-   - "Answer PR review comments before pushing"
-
-2. **Workflow mentions**:
-   - "Before I push, respond to PR comments"
-   - "I need to respond to review feedback"
-   - "Help me reply to the PR reviewer"
-
-3. **Context mentions**:
-   - "Address PR feedback and respond to comments"
-   - "Notify reviewers what I fixed"
-   - "Post review responses before pushing"
-
-### Should NOT Activate (False Positives to Avoid)
-
-These queries should NOT activate the skill:
-
-1. **Different operations**:
-   - "Create a new PR" → different skill
-   - "Review this code" → code review skill
-   - "What do the PR comments say?" → just viewing
-   - "How do I respond to reviews?" → asking how, not doing
-
-2. **Reading/viewing**:
-   - "Show me PR comments"
-   - "What feedback did I get?"
-   - "Read the review comments"
-
-3. **Other PR operations**:
-   - "Merge the PR"
-   - "Update PR description"
-   - "Add reviewer to PR"
-
-## Functional Tests
-
-### Test 1: Happy Path (with PR and comments)
-
-**Setup**:
-```bash
-# Create test PR with review comments
-gh pr create --title "Test PR" --body "Testing"
-# Have someone leave review comments
-# Make changes addressing comments
-git add .
-git commit -m "fix: address feedback"
-```
-
-**Test**:
-```
-"Respond to PR review comments"
-```
-
-**Expected behavior**:
-1. Detects PR #N
-2. Finds review comments
-3. Matches comments to changes
-4. Drafts responses
-5. Shows responses for approval
-6. Posts to GitHub after confirmation
-
-**Validation**:
-- Check GitHub PR for posted responses
-- Verify response format: `✅ **Fixed**: [description]`
-- Confirm responses are on correct comment threads
-
-### Test 2: No PR for Branch
-
-**Setup**:
-```bash
-git checkout -b new-feature
-# Don't create PR
-git commit -m "add feature"
-```
-
-**Test**:
-```
-"Respond to PR review comments"
-```
-
-**Expected behavior**:
-1. Checks for PR
-2. Finds no PR
-3. Informs user: "No PR found for this branch"
-4. Suggests creating PR first
-5. Exits gracefully
-
-**Validation**:
-- No errors thrown
-- Clear message to user
-- Suggestion to create PR
-
-### Test 3: PR with No Review Comments
-
-**Setup**:
-```bash
-gh pr create --title "Test PR" --body "Testing"
-# No one has reviewed yet
-git commit -m "update"
-```
-
-**Test**:
-```
-"Respond to PR review comments"
-```
-
-**Expected behavior**:
-1. Detects PR
-2. Fetches comments
-3. Finds no comments
-4. Informs user: "No review comments found"
-5. Exits gracefully
-
-**Validation**:
-- No errors
-- Clear message
-- No unnecessary API calls
-
-### Test 4: Comments Don't Match Changes
-
-**Setup**:
-```bash
-gh pr create --title "Test PR" --body "Testing"
-# Reviewer comments on src/views.py
-# You modify src/models.py instead
-git add src/models.py
-git commit -m "update models"
-```
-
-**Test**:
-```
-"Respond to PR review comments"
-```
-
-**Expected behavior**:
-1. Detects PR
-2. Finds review comments
-3. Gets changed files
-4. Finds no matches
-5. Shows what comments exist vs what you changed
-6. Exits with explanation
-
-**Validation**:
-- Lists comment locations
-- Lists changed files
-- Clear mismatch explanation
-
-### Test 5: Multiple Comments Addressed
-
-**Setup**:
-```bash
-# PR with 5 review comments across 3 files
-# Make changes addressing all 5
-git add .
-git commit -m "fix: address all feedback"
-```
-
-**Test**:
-```
-"Respond to PR review comments"
-```
-
-**Expected behavior**:
-1. Detects PR
-2. Finds 5 comments
-3. Matches all 5 to changes
-4. Drafts 5 responses
-5. Shows all for approval
-6. Posts all 5 after confirmation
-
-**Validation**:
-- All 5 responses posted
-- Each on correct comment thread
-- Consistent format
-
-### Test 6: Already Responded Comments Filtered
-
-**Setup**:
-```bash
-# PR with 3 comments
-# You already responded to 2 yesterday
-# Only 1 new comment unresponded
-git commit -m "fix: latest feedback"
-```
-
-**Test**:
-```
-"Respond to PR review comments"
-```
-
-**Expected behavior**:
-1. Detects PR
-2. Finds 3 comments total
-3. Filters out 2 already-replied
-4. Shows only 1 new comment
-5. Drafts 1 response
-6. Posts 1 response
-
-**Validation**:
-- Only 1 new response posted
-- Doesn't duplicate on already-replied comments
-- Tracks which were skipped
-
-## Edge Cases
-
-### Test 9: Authentication Failure
-
-**Setup**:
-- GitHub MCP server authentication is not configured or has expired
-
-**Test**:
-```
-"Respond to PR review comments"
-```
-
-**Expected behavior**:
-- Attempts to fetch PR
-- Gets auth error from MCP server
-- Shows clear error message
-- Suggests re-authenticating the GitHub MCP server
-
-### Test 10: Merged PR
-
-**Setup**:
-```bash
-# PR is already merged
-# Try to respond to old comments
-```
-
-**Test**:
-```
-"Respond to PR review comments"
-```
-
-**Expected behavior**:
-- Detects PR is merged
-- Informs user
-- Explains can't add comments to merged PR
-
-### Test 11: Permission Denied
-
-**Setup**:
-```bash
-# Readonly access to repo
-```
-
-**Test**:
-```
-"Respond to PR review comments"
-```
-
-**Expected behavior**:
-- Finds comments
-- Drafts responses
-- Fails to post (permission denied)
-- Shows error with suggestion to request access
-
-## Performance Tests
-
-### Test 12: Large PR with Many Comments
-
-**Setup**:
-- PR with 50+ review comments
-- Changes addressing 20+ comments
-
-**Expected behavior**:
-- Handles large number of comments
-- Doesn't timeout
-- Efficiently matches comments to changes
-- Shows progress during processing
-
-**Validation**:
-- Completes in reasonable time (< 30 seconds)
-- Correct matches found
-- All responses posted
-
-## Validation Checklist
-
-Before considering skill production-ready:
-
-- [ ] Frontmatter validated (name lowercase, description < 1024 chars)
-- [ ] Directory name matches frontmatter name
-- [ ] All activation triggers work
-- [ ] False positive triggers correctly avoided
-- [ ] Happy path works end-to-end
-- [ ] Edge cases handled gracefully
-- [ ] Error messages are clear and actionable
-- [ ] GitHub MCP tools respond correctly for all operations
-- [ ] Documentation is comprehensive
-- [ ] Examples cover common scenarios
-
-## Debugging
-
-If skill doesn't activate:
-
-1. **Check skill loading**:
-   ```bash
-   ls ~/.claude/skills/pr-review-responder/SKILL.md
-   ```
-
-2. **Restart Claude Code**:
-   ```
-   Exit and restart to reload skills
-   ```
-
-3. **Test with explicit trigger**:
-   ```
-   "Use the pr-review-responder skill to respond to PR comments"
-   ```
-
-4. **Check description specificity**:
-   - Does description mention "PR review", "code review", "feedback"?
-   - Does it include "respond", "reply", "post"?
-   - Are trigger words present?
-
-If MCP calls fail:
-
-1. **Check GitHub MCP server**:
-   - Verify `plugin:github:github` is listed in available MCP servers
-   - Check authentication status within the MCP server configuration
-
-2. **Check git repository**:
-   ```bash
-   git remote -v
-   ```
-
-## Success Metrics
-
-Skill is working correctly if:
-
-1. **Activation rate**: Activates on relevant queries (>90%)
-2. **False positive rate**: Doesn't activate on unrelated queries (<5%)
-3. **Matching accuracy**: Correctly matches comments to changes (>85%)
-4. **Response quality**: Drafted responses are specific and concise
-5. **Posting success**: API calls succeed (>95%)
-6. **User satisfaction**: Saves time vs manual responses
-
-Track these over time to validate skill effectiveness.

package/skills/pr-scope-resolve/SKILL.md

@@ -1,45 +0,0 @@
----
-name: pr-scope-resolve
-description: >-
-  Resolves the audit/fix target for a PR-loop skill: owner, repo, PR number,
-  head and base refs, PR URL, and head SHA, with a canonical refusal when no
-  target exists. Invoked by PR-loop orchestrators (pr-converge, bugteam, qbug,
-  findbugs, fixbugs) first; not for general git questions.
----
-
-# PR Scope Resolve
-
-**Core principle:** every PR-loop skill agrees on what it is auditing before any other work. One resolution ladder, one refusal line.
-
-## How callers invoke this
-
-- **Skill-capable contexts** (a lead session with the `Skill` tool): `Skill({skill: "pr-scope-resolve", args: "--skill <caller> [PR URL if the user gave one]"})`.
-- **Fallback** (a subagent or teammate without the `Skill` tool): the caller's spawn prompt says "Read `~/.claude/skills/pr-scope-resolve/SKILL.md` and apply the resolution ladder with the parameters below."
-
-The caller identity fills the refusal template. The resolved scope hands back: `owner`, `repo`, `number`, `head_ref`, `base_ref`, `url`, and `head_sha` (the starting `current_head`).
-
-## The resolution ladder
-
-Match the first rung that holds:
-
-1. **A PR URL was given.** Extract `owner`, `repo`, and `number` from the URL, then `pull_request_read(method="get", pullNumber=N, owner=O, repo=R)` for `head.sha`, `head.ref`, `base.ref`, and draft state.
-2. **Open PR for the current branch.** Call `pull_request_read(method="get")` with the PR number from the caller's context. When the number is unknown, recover it with the `search_pull_requests` MCP tool using the current branch name, then fetch as in rung 1.
-3. **No PR, but a remote default branch exists.** The scope is the upstream diff: `git merge-base HEAD origin/<default>` then `git diff <merge-base>...HEAD`. `head_sha` is `git rev-parse HEAD`; there is no PR number or URL, and steps that post to a PR are skipped by the caller.
-4. **Neither.** Respond exactly with the refusal template and stop:
-
-   `No PR or upstream diff. /<caller> needs a target.`
-
-## Ground rules
-
-- **The GitHub MCP is the primary transport** (`pull_request_read`, `search_pull_requests`); raw `gh api` is the fallback. MCP calls behave the same from any worktree, so scope resolution never depends on the working directory.
-- **Re-resolve `head_sha` after any push or external wait.** The scope tuple (`owner`, `repo`, `number`) is stable for a run; the head SHA is not.
-- **Full-diff scope.** The resolved scope always means the full `origin/<base>...HEAD` diff — every file the PR touches. A caller that narrows to a file list, commit range, or flagged-path subset is out of contract with every convergence gate downstream.
-
-## Gotchas
-
-- **`search_pull_requests` recovers PR numbers from branch names**, but a branch reused across repos returns several hits — filter by repo before trusting the number.
-- **A draft-state read belongs to this step.** Callers that need a draft PR (convergence loops that mark ready at the end) check `isDraft` here, on the same `get` call, rather than paying a second fetch later.
-
-## Folder map
-
-- `SKILL.md` — this file; the ladder is MCP- and git-native, so the skill ships no scripts.

package/skills/pre-compact/CLAUDE.md

@@ -1,24 +0,0 @@
-# pre-compact
-
-Composes the `/compact` focus directive for the current session and copies the full `/compact <directive>` string to the clipboard.
-
-**Trigger:** `/pre-compact` or any request to "prep for compaction".
-
-## Purpose
-
-`/compact [instructions]` accepts a directive that steers the compaction summarizer toward high-signal content. This skill builds that directive from live session state — validated against the actual git branch, PR, HEAD SHA, and worktree path — and delivers it ready to paste.
-
-## Key files
-
-| File | Purpose |
-|---|---|
-| `SKILL.md` | The complete skill — five steps (confirm intent, validate live state, write directive, copy to clipboard, hand off). No companion files. |
-
-## How the skill runs
-
-1. Asks the operator what they plan to work on next (via `AskUserQuestion`).
-2. Reads each identifier live (`git branch --show-current`, `git rev-parse --short HEAD`, `gh pr view`, `pwd`) rather than relying on conversation context.
-3. Produces a `Preserve:` block scoped to what the next task actually needs.
-4. Writes the full `/compact <directive>` string to a temp file, copies it via `pwsh Set-Clipboard`, then cleans up.
-
-`disable-model-invocation: true` is set — this skill runs without a secondary LLM call; it is pure procedural text assembly.