mirror of
https://github.com/itme-brain/agent-team.git
synced 2026-05-08 10:40:12 -04:00
fix: resolve moderate issues across config
- architect: restore effort: max to match orchestrate team roster - orchestrate: remove researcher background annotation (blocks planning), remove overly broad auditor trigger clause, risk-tag table is authoritative - qa-checklist: add auditor hard rules (security_findings, build/test status) - settings.json: simplify .env deny to single **/.env* glob per tool - rules/01-session: clarify persistent context includes .claude/memory/ - memory: rename todo_inter_agent_schema.md → inter_agent_schema.md
This commit is contained in:
parent
b741354dd8
commit
cf5c14ba29
7 changed files with 12 additions and 13 deletions
|
|
@ -1 +1 @@
|
|||
- [Inter-agent communication schema](todo_inter_agent_schema.md) — YAML frontmatter envelopes implemented via message-schema skill
|
||||
- [Inter-agent communication schema](inter_agent_schema.md) — YAML frontmatter envelopes implemented via message-schema skill
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
name: architect
|
||||
description: Research-first planning agent. Handles triage, research coordination, architecture design, and wave decomposition. Use before any non-trivial implementation task. Produces the implementation blueprint the entire team follows.
|
||||
model: opus
|
||||
effort: high
|
||||
effort: max
|
||||
permissionMode: plan
|
||||
tools: Read, Glob, Grep, WebFetch, WebSearch, Bash, Write
|
||||
disallowedTools: Edit
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
# Session Behavior
|
||||
|
||||
- Treat each session as stateless — do not assume context from prior sessions
|
||||
- The CLAUDE.md hierarchy is the only source of persistent context
|
||||
- If something needs to carry forward across sessions, it belongs in a CLAUDE.md file, not in session memory
|
||||
- The CLAUDE.md hierarchy and `.claude/memory/` are the only sources of persistent context
|
||||
- If something needs to carry forward across sessions, persist it in the appropriate file — not in session memory
|
||||
|
||||
# Project Memory
|
||||
|
||||
|
|
|
|||
|
|
@ -19,18 +19,15 @@
|
|||
"Read(~/.ssh/**)",
|
||||
"Read(~/.aws/**)",
|
||||
"Read(~/.gnupg/**)",
|
||||
"Read(**/.env)",
|
||||
"Read(**/.env.*)",
|
||||
"Read(**/.env*)",
|
||||
"Write(~/.ssh/**)",
|
||||
"Write(~/.aws/**)",
|
||||
"Write(~/.gnupg/**)",
|
||||
"Write(**/.env)",
|
||||
"Write(**/.env.*)",
|
||||
"Write(**/.env*)",
|
||||
"Edit(~/.ssh/**)",
|
||||
"Edit(~/.aws/**)",
|
||||
"Edit(~/.gnupg/**)",
|
||||
"Edit(**/.env)",
|
||||
"Edit(**/.env.*)"
|
||||
"Edit(**/.env*)"
|
||||
],
|
||||
"ask": [
|
||||
"Bash(rm *)",
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ You (orchestrator)
|
|||
├── worker (sonnet default — haiku for trivial, opus for architectural)
|
||||
├── debugger (sonnet) — bug diagnosis and minimal fixes
|
||||
├── documenter (sonnet) — documentation only, never touches source
|
||||
├── researcher (sonnet, background) — one per topic, parallel fact-finding
|
||||
├── researcher (sonnet) — one per topic, parallel fact-finding
|
||||
├── architect (opus, effort: max) — triage, research coordination, architecture, wave decomposition
|
||||
├── reviewer (sonnet) — code quality + AC verification + claim checking
|
||||
└── auditor (sonnet, background) — security analysis + runtime validation
|
||||
|
|
@ -104,7 +104,7 @@ For each wave in the plan:
|
|||
After each wave, spawn `reviewer` and `auditor` in a single response. They run in parallel.
|
||||
|
||||
- **Always spawn `reviewer`**
|
||||
- **Spawn `auditor` when:** risk tags include `security`, `auth`, `data-mutation`, or `concurrent` — or any code that can be built and tested
|
||||
- **Spawn `auditor` when:** risk tags include `security`, `auth`, `data-mutation`, or `concurrent`
|
||||
|
||||
Both receive: worker output, plan file path, acceptance criteria list, risk tags.
|
||||
|
||||
|
|
|
|||
|
|
@ -44,7 +44,9 @@ Before returning your output, validate against every item below. If you find a v
|
|||
- Does the `type` field match your message type?
|
||||
- Does the `signal` field use a valid enum value from the message-schema skill?
|
||||
- Are all required fields for your message type present?
|
||||
- Are hard rules satisfied (e.g., `critical_count > 0` requires `signal: fail`)?
|
||||
- Are hard rules satisfied?
|
||||
- `review_verdict`: `critical_count > 0` requires `signal: fail`
|
||||
- `audit_verdict`: `security_findings.critical > 0` or `build_status: fail` or `test_status: fail` requires `signal: fail`
|
||||
|
||||
## After validation
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue