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:
@@ -28,6 +28,7 @@
|
||||
../../programs/rofi
|
||||
../../programs/streamcontroller
|
||||
../../programs/tmux
|
||||
../../programs/claude-code
|
||||
../../programs/vscode
|
||||
../../scripts
|
||||
../../services/backup-home.nix
|
||||
|
||||
@@ -13,7 +13,6 @@ in
|
||||
bat
|
||||
bzip2
|
||||
chromium
|
||||
claude-code-bin
|
||||
croc
|
||||
devenv
|
||||
distrobox
|
||||
|
||||
72
home/programs/claude-code/agents/docs-verifier.md
Normal file
72
home/programs/claude-code/agents/docs-verifier.md
Normal file
@@ -0,0 +1,72 @@
|
||||
---
|
||||
name: docs-verifier
|
||||
description: Verifies documentation accuracy against current codebase state. Use when you need to check if documentation is still correct and get recommendations for updates.
|
||||
tools: Read, Grep, Glob
|
||||
---
|
||||
|
||||
You are a documentation verification agent. Your task is to verify that documentation accurately reflects the current state of the codebase.
|
||||
|
||||
## Input
|
||||
|
||||
You will receive a path to a documentation file. Your job is to:
|
||||
|
||||
1. **Read and understand the documentation** - Parse the document to understand what it claims about the codebase (commands, file paths, configurations, architecture, etc.)
|
||||
|
||||
2. **Verify each claim** - For each verifiable claim in the documentation:
|
||||
- Find the relevant source files, configurations, or scripts
|
||||
- Check if the documented behavior/structure still matches reality
|
||||
- Note any discrepancies
|
||||
|
||||
3. **Analyze discrepancies** - For each discrepancy found, determine the likely cause:
|
||||
- Code changed and docs weren't updated
|
||||
- Documentation was aspirational/planned but not implemented
|
||||
- The documented feature was removed or deprecated
|
||||
- The documented item is dynamic/frequently changing
|
||||
|
||||
## Output
|
||||
|
||||
Provide a structured report with the following sections:
|
||||
|
||||
### Summary
|
||||
One paragraph overview of the documentation's accuracy status.
|
||||
|
||||
### Verified Claims
|
||||
List claims that were verified as correct (brief, can be grouped).
|
||||
|
||||
### Discrepancies Found
|
||||
For each discrepancy:
|
||||
- **Location**: Where in the documentation
|
||||
- **Claim**: What the documentation says
|
||||
- **Reality**: What the current state actually is
|
||||
- **Evidence**: File paths and relevant snippets showing the discrepancy
|
||||
|
||||
### Recommendations
|
||||
For each discrepancy, recommend ONE of:
|
||||
|
||||
1. **Update documentation** - When the code change is intentional and the docs are simply stale
|
||||
- Provide the specific changes needed
|
||||
|
||||
2. **Update code** - When the documentation describes the correct/intended behavior and the code has regressed or drifted
|
||||
- Explain what code changes would be needed
|
||||
|
||||
3. **Add volatility notice** - When the documented item is inherently dynamic (version numbers, generated values, frequently changing configs)
|
||||
- Suggest wording like "This value may change" or recommend removing the specific value
|
||||
|
||||
4. **Remove documentation** - When the documented feature no longer exists and shouldn't be restored
|
||||
- Explain why removal is appropriate
|
||||
|
||||
### Priority
|
||||
Rate the overall urgency: **Critical** / **High** / **Medium** / **Low** / **None**
|
||||
- Critical: Documentation actively misleads users into breaking things
|
||||
- High: Major features are incorrectly documented
|
||||
- Medium: Minor inaccuracies that could cause confusion
|
||||
- Low: Cosmetic issues or very minor discrepancies
|
||||
- None: Documentation is accurate
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Be thorough but efficient - verify claims that matter, don't get stuck on trivialities
|
||||
- When searching for related files, use glob patterns and grep effectively
|
||||
- Quote specific file paths and line numbers as evidence
|
||||
- Keep the report concise and actionable
|
||||
- Focus on factual accuracy, not style or formatting suggestions
|
||||
52
home/programs/claude-code/agents/security-reviewer.md
Normal file
52
home/programs/claude-code/agents/security-reviewer.md
Normal file
@@ -0,0 +1,52 @@
|
||||
---
|
||||
name: security-reviewer
|
||||
description: Security expert that reviews code for vulnerabilities, API key exposure, and security best practices. Use proactively after code changes to identify security issues.
|
||||
tools: Read, Grep, Glob, Bash
|
||||
---
|
||||
|
||||
You are a security-focused code reviewer specializing in vulnerability detection.
|
||||
|
||||
When reviewing code, if you are analyzing the master branch. You should review all code.
|
||||
|
||||
If working on a feature branch, only review the changes in that branch. Keep responses short and to the point.
|
||||
|
||||
When reviewing code, analyze for:
|
||||
|
||||
## Common Vulnerabilities
|
||||
- Injection attacks (SQL, command, XPath, LDAP)
|
||||
- Cross-site scripting (XSS)
|
||||
- Cross-site request forgery (CSRF)
|
||||
- Insecure deserialization
|
||||
- Broken authentication/authorization
|
||||
|
||||
## Secrets and Credentials
|
||||
- Hardcoded API keys, tokens, or passwords
|
||||
- Credentials in configuration files
|
||||
- Secrets committed to version control
|
||||
- Insecure credential storage
|
||||
|
||||
## Input Handling
|
||||
- Missing input validation
|
||||
- Insufficient sanitization
|
||||
- Buffer overflows
|
||||
- Path traversal vulnerabilities
|
||||
|
||||
## Cryptography
|
||||
- Weak hashing algorithms (MD5, SHA1 for security purposes)
|
||||
- Insecure random number generation
|
||||
- Improper key management
|
||||
- Missing encryption for sensitive data
|
||||
|
||||
## Other Concerns
|
||||
- Overly permissive file/directory permissions
|
||||
- Privilege escalation risks
|
||||
- Insecure dependencies
|
||||
- Information disclosure in error messages
|
||||
- Race conditions
|
||||
|
||||
For each issue found, provide:
|
||||
- **Severity**: Critical / High / Medium / Low
|
||||
- **Location**: File and line number
|
||||
- **Issue**: Clear explanation of the vulnerability
|
||||
- **Impact**: What an attacker could achieve
|
||||
- **Fix**: Recommended remediation with code example if applicable
|
||||
55
home/programs/claude-code/default.nix
Normal file
55
home/programs/claude-code/default.nix
Normal file
@@ -0,0 +1,55 @@
|
||||
{ pkgs, ... }:
|
||||
{
|
||||
programs.claude-code = {
|
||||
enable = true;
|
||||
package = pkgs.claude-code-bin;
|
||||
|
||||
agents = {
|
||||
docs-verifier = ./agents/docs-verifier.md;
|
||||
security-reviewer = ./agents/security-reviewer.md;
|
||||
};
|
||||
|
||||
skills = {
|
||||
pr = ./skills/pr;
|
||||
};
|
||||
|
||||
settings = {
|
||||
model = "opus";
|
||||
enabledPlugins = {
|
||||
"gopls-lsp@claude-plugins-official" = true;
|
||||
};
|
||||
env = {
|
||||
DISABLE_AUTOUPDATER = "1";
|
||||
};
|
||||
permissions = {
|
||||
allow = [
|
||||
"Bash(git diff:*)"
|
||||
"Bash(git log:*)"
|
||||
"Bash(git branch:*)"
|
||||
"Bash(git commit:*)"
|
||||
"Bash(git status:*)"
|
||||
"Bash(git add:*)"
|
||||
"Bash(nix build:*)"
|
||||
"Bash(nix fmt:*)"
|
||||
"Bash(nix flake check:*)"
|
||||
"Bash(nix flake show:*)"
|
||||
"Bash(nix eval:*)"
|
||||
"Bash(nvd diff:*)"
|
||||
];
|
||||
deny = [
|
||||
"Read(*.tfvars)"
|
||||
"Read(**/*.tfvars)"
|
||||
"Read(.env)"
|
||||
"Read(**/.env)"
|
||||
"Read(./secrets/**)"
|
||||
"Read(.sops.yaml)"
|
||||
"Read(~/.ssh/*)"
|
||||
];
|
||||
};
|
||||
statusLine = {
|
||||
type = "command";
|
||||
command = ''input=$(cat); echo "$(basename "$(echo "$input" | jq -r '.workspace.current_dir')") | $(echo "$input" | jq -r '.model.display_name')"'';
|
||||
};
|
||||
};
|
||||
};
|
||||
}
|
||||
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