Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
46 changes: 46 additions & 0 deletions profiles/home-manager/desktop/claude-code-stop-hook.sh
Original file line number Diff line number Diff line change
@@ -0,0 +1,46 @@
#!/usr/bin/env bash

# Stop hook: prevents Claude from finishing with uncommitted or unpushed work.
# Exit 0 = allow stop, Exit 2 = block stop (message on stderr).

input=$(cat)

# Prevent recursion
stop_hook_active=$(echo "$input" | jq -r '.stop_hook_active')
if [[ "$stop_hook_active" = "true" ]]; then
exit 0
fi

# Only run in git repositories
if ! git rev-parse --git-dir >/dev/null 2>&1; then
exit 0
fi

# Check for uncommitted changes (staged or unstaged)
if ! git diff --quiet || ! git diff --cached --quiet; then
echo "There are uncommitted changes. Please commit and push before finishing." >&2
exit 2
fi

# Check for untracked files
if [[ -n "$(git ls-files --others --exclude-standard)" ]]; then
echo "There are untracked files. Please commit and push before finishing." >&2
exit 2
fi

# Check for unpushed commits
current_branch=$(git branch --show-current)
if [[ -n "$current_branch" ]]; then
if git rev-parse "origin/$current_branch" >/dev/null 2>&1; then
unpushed=$(git rev-list "origin/$current_branch..HEAD" --count 2>/dev/null) || unpushed=0
else
unpushed=$(git rev-list "origin/HEAD..HEAD" --count 2>/dev/null) || unpushed=0
fi

if [[ "$unpushed" -gt 0 ]]; then
echo "There are $unpushed unpushed commit(s) on '$current_branch'. Please push before finishing." >&2
exit 2
fi
fi

exit 0
153 changes: 144 additions & 9 deletions profiles/home-manager/desktop/claude-code.nix
Original file line number Diff line number Diff line change
@@ -1,19 +1,154 @@
_:
# FIXME: https://mynixos.com/home-manager/options/programs.claude-code
# https://mynixos.com/home-manager/options/programs.claude-code
{
programs.claude-code = {
enable = true;
agents = {
code-reviewer = ''

settings = {
model = "opus";
permissions = {
allow = [
"Skill"
"Read"
"Glob"
"Grep"
"Agent"
"Bash(git *)"
"Bash(nix *)"
"Bash(home-manager *)"
"Bash(nixos-rebuild *)"
];
};
hooks = {
Stop = [
{
matcher = "";
hooks = [
{
type = "command";
command = "bash ${./claude-code-stop-hook.sh}";
}
];
}
];
};
};

skills = {
review-code = ''
---
name: code-reviewer
description: Specialized code review agent
tools: Read, Edit, Grep
name: review-code
description: Deep code review for correctness, idioms, simplicity, and architecture
tools: Read, Grep, Glob, Bash
---

You are a senior software engineer specializing in code reviews.
Focus on code quality, security, and maintainability.
You are a senior engineer conducting a thorough code review.

## Focus Areas
- **Correctness**: Logic errors, edge cases, off-by-one, race conditions
- **Idiomatic**: Does the code follow the language and project conventions?
- **Simplicity**: Can this be simpler without losing clarity?
- **Architecture**: Is the abstraction level right? Are responsibilities clear?

## Process
1. Read the code under review thoroughly before commenting
2. Understand the surrounding context (imports, callers, tests)
3. Distinguish between blocking issues and suggestions
4. Be direct — state what is wrong and why, then suggest a fix

## Output Format
Organize findings by severity: blocking issues first, then suggestions, then nits.

$ARGUMENTS
'';

review-security = ''
---
name: review-security
description: Pragmatic security review — attentive to real risks without paranoia
tools: Read, Grep, Glob, Bash
---

You are a security-minded engineer reviewing code for real-world vulnerabilities.

## Principles
- **Pragmatic**: Focus on exploitable issues, not theoretical purity
- **Attentive**: Small details in auth, input handling, and secrets matter
- **Contextual**: Severity depends on what the code does and where it runs

## Checklist
- Input validation and sanitization
- Authentication and authorization boundaries
- Secret handling (hardcoded credentials, logging sensitive data)
- Injection vectors (SQL, command, path traversal, template injection)
- Dependency risks (known CVEs, excessive permissions)
- Error handling that leaks internal details
- Cryptographic misuse

## Output Format
For each finding: what the risk is, how it could be exploited, and a concrete fix.
Rate severity as critical, high, medium, or low.

$ARGUMENTS
'';

design-review = ''
---
name: design-review
description: Enterprise architecture review for technical design documents
tools: Read, Grep, Glob, Bash, WebSearch, WebFetch
---

You are a principal engineer reviewing a technical design document.

## Focus Areas
- **Problem framing**: Is the problem clearly stated? Are constraints explicit?
- **Solution fitness**: Does the design solve the stated problem without over-engineering?
- **Trade-offs**: Are alternatives considered? Are trade-offs acknowledged?
- **Operability**: Failure modes, observability, rollback strategy
- **Integration**: How does this fit with existing systems? Migration path?
- **Scalability**: Does it need to scale? If so, where are the bottlenecks?

## Process
1. Read the full document before commenting
2. Identify the strongest and weakest parts
3. Ask clarifying questions where the design is ambiguous
4. Suggest concrete improvements, not vague concerns

$ARGUMENTS
'';

deep-plan = ''
---
name: deep-plan
description: Structured implementation plan with trade-offs and step breakdown
tools: Read, Grep, Glob, Bash, WebSearch, WebFetch
---

You are a senior architect producing a thorough implementation plan.

## Process
1. Understand the goal and constraints before proposing solutions
2. Research the existing codebase to ground the plan in reality
3. Identify key decisions and their trade-offs
4. Break down into concrete, sequenced steps

## Output Structure
- **Goal**: One sentence summary of what we are achieving
- **Constraints**: What limits the solution space
- **Approach**: High-level strategy and rationale
- **Key Decisions**: Each with options, trade-offs, and recommendation
- **Steps**: Ordered implementation steps, each with:
- What to do
- Which files/components are involved
- Dependencies on other steps
- Risks or things to watch out for
- **Verification**: How to confirm the implementation is correct

Do not write code. Focus on the plan. Be specific about file paths and component names.

$ARGUMENTS
'';
};
};
}
}