feat: expand agents (10), skills (20), and hooks (11) with profile system
Agents: - Add YAML frontmatter (model, tools) to all 7 existing agents - New agents: planner (opus), build-error-resolver (sonnet), loop-operator (sonnet) Skills: - search-first: research before building (Adopt/Extend/Compose/Build) - verification-loop: full quality gate pipeline (Build→TypeCheck→Lint→Test→Security→Diff) - strategic-compact: when and how to run /compact effectively - autonomous-loops: 6 patterns for autonomous agent workflows - continuous-learning: extract session learnings into instincts Hooks: - Profile system (minimal/standard/strict) via run-with-profile.sh - config-protection: block linter/formatter config edits (standard) - suggest-compact: remind about /compact every ~50 tool calls (standard) - auto-tmux-dev: suggest tmux for dev servers (standard) - session-save/session-load: persist and restore session context (Stop/SessionStart) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
olekhondera
204
.claude/skills/autonomous-loops/SKILL.md
Normal file
204
.claude/skills/autonomous-loops/SKILL.md
Normal file
@@ -0,0 +1,204 @@
|
||||
---
|
||||
name: autonomous-loops
|
||||
description: Patterns for running autonomous agent workflows — from simple pipelines to complex multi-agent DAGs. Reference for setting up build-fix loops, continuous PRs, and de-sloppify passes.
|
||||
disable-model-invocation: true
|
||||
---
|
||||
|
||||
# Autonomous Loop Patterns
|
||||
|
||||
Reference guide for autonomous agent workflows, ranked by complexity.
|
||||
|
||||
## Pattern 1: Sequential Pipeline
|
||||
|
||||
**Complexity**: Low
|
||||
**Use when**: Simple one-shot tasks chained together
|
||||
|
||||
```bash
|
||||
# Run a sequence of claude commands
|
||||
claude -p "Implement feature X" --output-format json | \
|
||||
claude -p "Write tests for the implementation" --output-format json | \
|
||||
claude -p "Review the code for issues"
|
||||
```
|
||||
|
||||
**Pros**: Simple, predictable, easy to debug
|
||||
**Cons**: No error recovery, no parallelism
|
||||
|
||||
## Pattern 2: Build-Fix Loop
|
||||
|
||||
**Complexity**: Medium
|
||||
**Use when**: Making the build green after changes
|
||||
|
||||
```bash
|
||||
MAX_CYCLES=5
|
||||
CYCLE=0
|
||||
|
||||
while [ $CYCLE -lt $MAX_CYCLES ]; do
|
||||
CYCLE=$((CYCLE + 1))
|
||||
echo "=== Cycle $CYCLE ==="
|
||||
|
||||
# Run build/tests
|
||||
BUILD_OUTPUT=$(npm run build 2>&1)
|
||||
if [ $? -eq 0 ]; then
|
||||
echo "Build passed on cycle $CYCLE"
|
||||
break
|
||||
fi
|
||||
|
||||
# Fix errors
|
||||
claude -p "Fix these build errors. Make minimal changes only:
|
||||
$BUILD_OUTPUT"
|
||||
|
||||
if [ $CYCLE -eq $MAX_CYCLES ]; then
|
||||
echo "STALLED after $MAX_CYCLES cycles — escalating"
|
||||
exit 1
|
||||
fi
|
||||
done
|
||||
```
|
||||
|
||||
**Key rules**:
|
||||
- Set a MAX_CYCLES limit (3-5 is reasonable)
|
||||
- Detect stalls (same error repeating)
|
||||
- Use the `loop-operator` agent for monitoring
|
||||
|
||||
## Pattern 3: Test-Driven Fix Loop
|
||||
|
||||
**Complexity**: Medium
|
||||
**Use when**: Fixing failing tests one at a time
|
||||
|
||||
```bash
|
||||
# Get failing tests
|
||||
FAILURES=$(npm test 2>&1 | grep "FAIL")
|
||||
|
||||
for test_file in $FAILURES; do
|
||||
claude -p "Fix this failing test. Read the test to understand intent,
|
||||
then fix the implementation (not the test):
|
||||
File: $test_file"
|
||||
done
|
||||
|
||||
# Verify all tests pass
|
||||
npm test
|
||||
```
|
||||
|
||||
**Key rules**:
|
||||
- Fix implementation, not tests (unless test is wrong)
|
||||
- Run full suite after fixes to catch regressions
|
||||
- Stop if fix count exceeds threshold
|
||||
|
||||
## Pattern 4: Continuous PR Loop
|
||||
|
||||
**Complexity**: High
|
||||
**Use when**: Processing a backlog of tasks as PRs
|
||||
|
||||
```bash
|
||||
# Process tasks from a list
|
||||
while IFS= read -r task; do
|
||||
BRANCH="auto/$(echo "$task" | tr ' ' '-' | head -c 40)"
|
||||
git checkout -b "$BRANCH" main
|
||||
|
||||
claude -p "Implement: $task
|
||||
Requirements:
|
||||
- Create a single focused PR
|
||||
- Include tests
|
||||
- Follow RULES.md conventions"
|
||||
|
||||
# Run verification
|
||||
claude -p "/verification-loop"
|
||||
|
||||
# Create PR if verification passes
|
||||
if [ $? -eq 0 ]; then
|
||||
git push -u origin "$BRANCH"
|
||||
gh pr create --title "$task" --body "Automated implementation"
|
||||
fi
|
||||
|
||||
git checkout main
|
||||
done < tasks.txt
|
||||
```
|
||||
|
||||
**Key rules**:
|
||||
- One task = one branch = one PR
|
||||
- Run verification before creating PR
|
||||
- Set cost/time limits per task
|
||||
- Skip tasks that fail after N attempts
|
||||
|
||||
## Pattern 5: De-Sloppify Pass
|
||||
|
||||
**Complexity**: Medium
|
||||
**Use when**: Cleaning up after a fast implementation pass
|
||||
|
||||
The insight: **Two focused agents outperform one constrained agent**. First implement fast, then clean up.
|
||||
|
||||
```bash
|
||||
# Phase 1: Fast implementation (allow some sloppiness)
|
||||
claude -p "Implement feature X quickly. Focus on correctness, not polish."
|
||||
|
||||
# Phase 2: Cleanup pass
|
||||
claude -p "Review and clean up the recent changes:
|
||||
1. Remove console.log/debug statements
|
||||
2. Add missing error handling
|
||||
3. Fix type safety issues (no 'any')
|
||||
4. Ensure consistent naming
|
||||
5. Add missing JSDoc for public APIs
|
||||
|
||||
Do NOT change behavior or add features. Only clean up."
|
||||
```
|
||||
|
||||
**Key rules**:
|
||||
- Cleanup agent must not change behavior
|
||||
- Use git diff to scope the cleanup
|
||||
- Run tests after cleanup to verify no regressions
|
||||
|
||||
## Pattern 6: Multi-Agent DAG
|
||||
|
||||
**Complexity**: Very High
|
||||
**Use when**: Large features requiring coordinated parallel work
|
||||
|
||||
```
|
||||
┌─────────┐
|
||||
│ Planner │
|
||||
└────┬────┘
|
||||
│
|
||||
┌─────┼─────┐
|
||||
▼ ▼ ▼
|
||||
[API] [UI] [DB] ← Parallel agents in worktrees
|
||||
│ │ │
|
||||
└─────┼─────┘
|
||||
▼
|
||||
┌───────────┐
|
||||
│ Integrator│ ← Merges and resolves conflicts
|
||||
└─────┬─────┘
|
||||
▼
|
||||
┌───────────┐
|
||||
│ Reviewer │ ← Final quality check
|
||||
└───────────┘
|
||||
```
|
||||
|
||||
**Implementation**:
|
||||
|
||||
1. **Planner** decomposes the spec into independent tasks with dependencies
|
||||
2. Independent tasks run in **parallel worktrees** (isolated git branches)
|
||||
3. **Integrator** merges worktrees, resolves conflicts
|
||||
4. **Reviewer** does final quality check
|
||||
|
||||
**Key rules**:
|
||||
- Use git worktrees for isolation
|
||||
- Each agent gets a focused, self-contained task
|
||||
- Integrator handles merge conflicts
|
||||
- Full verification after integration
|
||||
|
||||
## Choosing a Pattern
|
||||
|
||||
| Situation | Pattern |
|
||||
|-----------|---------|
|
||||
| Single task, no iteration needed | 1 (Sequential) |
|
||||
| Build is broken, need to fix | 2 (Build-Fix) |
|
||||
| Tests are failing | 3 (Test-Driven Fix) |
|
||||
| Backlog of independent tasks | 4 (Continuous PR) |
|
||||
| Fast implementation needs polish | 5 (De-Sloppify) |
|
||||
| Large feature, multiple concerns | 6 (Multi-Agent DAG) |
|
||||
|
||||
## Safety Rules (All Patterns)
|
||||
|
||||
1. **Always set limits** — Max cycles, max time, max cost
|
||||
2. **Always verify** — Run tests/build after each change
|
||||
3. **Always detect stalls** — Same error 3x = stop
|
||||
4. **Always preserve work** — Commit before risky operations
|
||||
5. **Always escalate** — When stuck, stop and ask for human input
|
||||
Reference in New Issue
Block a user