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:
14
RULES.md
14
RULES.md
@@ -68,11 +68,13 @@ conflict.
|
||||
## 4. Agent Profiles & Selection
|
||||
|
||||
- Agent profiles live in `agents/` and define role‑specific behavior (metadata + detailed instructions).
|
||||
- Each agent declares `model` (opus/sonnet) and `tools` (allowed tool set) in YAML frontmatter.
|
||||
- Before starting a task:
|
||||
1. Scan available profiles in `agents/`.
|
||||
2. Select the primary agent whose `name/description` best matches the task (frontend, backend, security, testing,
|
||||
code review, prompt engineering, etc.).
|
||||
3. Apply that profile in addition to these core rules.
|
||||
2. Select the primary agent whose `name/description` best matches the task.
|
||||
3. For complex planning/architecture → use **opus** agents (planner, architects, security-auditor).
|
||||
4. For implementation/review → use **sonnet** agents (code-reviewer, test-engineer, build-error-resolver).
|
||||
5. Apply that profile in addition to these core rules.
|
||||
- If a task spans domains, follow Section 5 for coordination.
|
||||
|
||||
---
|
||||
@@ -81,13 +83,17 @@ conflict.
|
||||
|
||||
1. Identify all relevant domains/agents.
|
||||
2. Choose a primary agent based on the main intent:
|
||||
- **Design/architecture** → architect‑type agent.
|
||||
- **Planning/breakdown** → planner agent.
|
||||
- **Design/architecture** → architect‑type agent (frontend/backend).
|
||||
- **Implementation** → domain architect (frontend/backend).
|
||||
- **Review/audit** → reviewer/security agent.
|
||||
- **Build errors** → build-error-resolver agent.
|
||||
- **Prompt/workflow** → prompt‑engineer agent.
|
||||
- **Autonomous loops** → loop-operator agent.
|
||||
3. Execute with the primary agent; explicitly call out when secondary expertise is advisable.
|
||||
4. If the request mixes distinct phases (e.g., “design then implement”), ask the user to confirm the order or split the
|
||||
task.
|
||||
5. For autonomous multi-step work, use the `/autonomous-loops` skill to select the appropriate loop pattern.
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user