home: add claude-code program with home-manager module
Configures claude-code using the home-manager programs.claude-code module: - Settings: model, gopls plugin, auto-update disabled, permissions - Agents: docs-verifier, security-reviewer - Skills: pr summary generator Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
119
home/programs/claude-code/skills/pr/SKILL.md
Normal file
119
home/programs/claude-code/skills/pr/SKILL.md
Normal file
@@ -0,0 +1,119 @@
|
||||
---
|
||||
name: pr
|
||||
description: Generate a PR summary from the current feature branch and copy it to the clipboard.
|
||||
argument-hint: [optional: additional context or focus areas]
|
||||
user-invocable-only: true
|
||||
---
|
||||
|
||||
# PR Summary Generator
|
||||
|
||||
Generate a concise PR summary comparing the current branch to the main branch (master), and copy it to the clipboard.
|
||||
|
||||
## Input
|
||||
|
||||
Optional user context: $ARGUMENTS
|
||||
|
||||
## Process
|
||||
|
||||
1. **Get branch info**: Use git to determine:
|
||||
- Current branch name
|
||||
- Main branch (master)
|
||||
- Verify we're not on master (warn if we are)
|
||||
|
||||
2. **Gather commit information**: Use the git-explorer MCP tools:
|
||||
- `commits_between` to get all commits from master to HEAD
|
||||
- `get_commit_info` for each commit to see the full message and changes
|
||||
|
||||
3. **Evaluate commit hygiene** (CRITICAL - do this before generating summary):
|
||||
|
||||
Review all commits and check for issues that suggest squashing:
|
||||
- **Fixup commits**: Messages like "fix", "fixup", "oops", "typo", "forgot", "WIP"
|
||||
- **Iterative fixes**: Multiple commits touching the same file for the same logical change
|
||||
- **Broken intermediate states**: Commits that introduce then immediately fix issues
|
||||
- **Noise commits**: Very small changes that don't warrant their own commit
|
||||
- **Related changes split unnecessarily**: Commits that logically belong together
|
||||
|
||||
**If squashing is recommended**: STOP here. Do NOT generate PR summary or copy to clipboard.
|
||||
Instead, respond with a short report:
|
||||
- List which commits should be squashed together
|
||||
- Explain briefly why (e.g., "fixup commit", "same logical change", "WIP")
|
||||
- Suggest the resulting commit message(s)
|
||||
|
||||
**If commits look clean**: Continue to step 4.
|
||||
|
||||
4. **Analyze the changes**:
|
||||
- Group commits by topic/area if there are multiple
|
||||
- Note the key files changed
|
||||
- Understand the overall purpose of the branch
|
||||
|
||||
5. **Generate the summary**: Create a markdown summary with:
|
||||
- A "Summary" section with 2-4 bullet points describing what changed and why
|
||||
- A "Changes" section listing key files/areas modified
|
||||
|
||||
6. **Copy to clipboard**: Pipe the summary to `wl-copy`
|
||||
|
||||
## Squash Recommendation Format
|
||||
|
||||
When recommending squashing, respond like this:
|
||||
|
||||
```
|
||||
Before creating a PR, I recommend squashing some commits:
|
||||
|
||||
**Squash together:**
|
||||
- `abc123` "Add new feature"
|
||||
- `def456` "Fix typo in new feature"
|
||||
- `ghi789` "Forgot to add import"
|
||||
|
||||
→ Suggested message: "Add new feature for X"
|
||||
|
||||
**Reason:** These are iterative fixes to the same change.
|
||||
|
||||
Run `git rebase -i master` to clean up, then invoke `/pr` again.
|
||||
```
|
||||
|
||||
## Output Format
|
||||
|
||||
```markdown
|
||||
## Summary
|
||||
|
||||
- First key change or feature
|
||||
- Second key change
|
||||
- Additional context if needed
|
||||
|
||||
## Changes
|
||||
|
||||
- `path/to/file.nix` - Brief description of change
|
||||
- `path/to/other.nix` - Brief description
|
||||
```
|
||||
|
||||
## Style Guidelines
|
||||
|
||||
- **Concise**: Each bullet point should be one sentence
|
||||
- **Focus on "why"**: Explain the purpose, not just what files changed
|
||||
- **Group related changes**: Don't list every commit, summarize by area
|
||||
- **Technical accuracy**: Use correct terminology for the codebase
|
||||
- **No fluff**: Skip obvious statements like "this PR adds..."
|
||||
|
||||
## Example
|
||||
|
||||
For a branch with commits adding a new monitoring exporter:
|
||||
|
||||
```markdown
|
||||
## Summary
|
||||
|
||||
- Add systemd-exporter to all hosts for tracking service health metrics
|
||||
- Configure Prometheus scrape targets for the new exporter
|
||||
- Add Grafana dashboard for visualizing systemd unit status
|
||||
|
||||
## Changes
|
||||
|
||||
- `system/systemd-exporter.nix` - New module enabling systemd-exporter on all hosts
|
||||
- `services/monitoring/prometheus.nix` - Add scrape config for systemd-exporter job
|
||||
- `services/monitoring/grafana/dashboards/` - New systemd dashboard
|
||||
```
|
||||
|
||||
## After Generating
|
||||
|
||||
1. Confirm the summary was copied to clipboard
|
||||
2. Display the summary to the user so they can review it
|
||||
3. Mention they can paste it directly into a PR description
|
||||
Reference in New Issue
Block a user