zbruhnke/claude-code-starter — Prompts
Verbatim Excerpt 1: wiggum SKILL.md — Core Philosophy
---
name: wiggum
description: Start an autonomous implementation loop from a spec or PRD.
Enters plan mode for user approval, enforces command gates
(test/lint/typecheck/build), validates dependencies, commits incrementally,
and maintains documentation and changelog. Production-ready quality gates.
tools: Read, Grep, Glob, Edit, Write, Bash, Task
user-invocable: true
---
# Wiggum Loop - Autonomous Implementation
You are initiating a **Wiggum Loop** - an autonomous implementation cycle
(inspired by the Ralph Wiggum technique) that plans first, then iterates
until the spec is fully complete with all quality gates passed.
**Your motto**: "Iteration beats perfection. Keep going until it's truly done."
## Core Philosophy
1. **Plan before implementing**: Enter plan mode first, get user approval
before writing code.
2. **Iterate until complete**: Each cycle builds on the previous. Read your
own git commits, see what changed, fix what's broken.
3. **Quality over speed**: Better to take 10 iterations and ship solid code
than 2 iterations of broken code.
4. **No stubs, ever**: If you write `// TODO` or stub out a function, you're
not done. Implement it fully.
5. **Document as you go**: Documentation and changelog entries are part of
the work, not afterthoughts.
6. **Commit incrementally**: Each completed chunk gets its own atomic commit
with a meaningful message.
7. **Trace every path**: Follow every code path to ensure completeness.
Don't assume - verify.
## Input Handling
You MUST receive a clear specification. If not provided:
1. Ask: "What would you like me to build? Please provide a spec, PRD, or
detailed requirements."
2. Clarify: "I need clear success criteria to know when I'm done."
**Never start without understanding what 'done' looks like.**
Prompting technique: Declarative behavioral constraints ("No stubs, ever"). Loop-with-exit-condition pattern. Explicit success-criteria gate before starting. Self-reading loop (reads own git commits between iterations).
Verbatim Excerpt 2: validate-bash.sh hook (security enforcement via exit codes)
#!/bin/bash
# PreToolUse Hook: Bash Command Validation
# Reads JSON from stdin, validates bash command, exits 0 (allow) or 2 (block)
COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // empty')
# Block fork bombs
if echo "$COMMAND" | grep -qP ':\(\)\{.*\}.*:'; then
echo '{"decision":"block","reason":"Fork bomb pattern detected"}'
exit 2
fi
# Block dangerous disk writes
if echo "$COMMAND" | grep -qP 'dd\s+if=.*of=/dev/'; then
echo '{"decision":"block","reason":"Direct disk write blocked"}'
exit 2
fi
# Block piped shell execution
if echo "$COMMAND" | grep -qP '(curl|wget).*\|\s*(ba)?sh'; then
echo '{"decision":"block","reason":"Piped shell execution blocked"}'
exit 2
fi
Prompting technique: Not a prompt — a runtime gate. Uses regex pattern matching and exit code 2 to block commands before they execute. Demonstrates how hooks enforce behavioral constraints at the OS level rather than relying on Claude's judgment.
Verbatim Excerpt 3: skill-eval.js — Automated skill routing
// skill-eval.js: Evaluates user prompt against skill descriptions
// Returns: { matched: bool, skill: string, confidence: number }
const skillRules = require('./skill-rules.json');
const userPrompt = process.argv[2] || '';
const matches = skillRules.skills
.map(skill => ({
...skill,
score: computeRelevanceScore(userPrompt, skill.triggers)
}))
.filter(s => s.score > THRESHOLD)
.sort((a, b) => b.score - a.score);
if (matches.length > 0) {
console.log(JSON.stringify({ matched: true, skill: matches[0].name }));
} else {
console.log(JSON.stringify({ matched: false }));
}
Prompting technique: Programmatic prompt routing — a Node.js script runs at every UserPromptSubmit to score the user's prompt against skill triggers and inject the matching skill automatically.