mirror of
https://github.com/itme-brain/agent-team.git
synced 2026-05-08 10:40:12 -04:00
- Drop rules/02-responses.md entirely: fully redundant with every harness's
built-in system prompt (concise/no-preamble/no-emoji is baked in).
- Trim 04-tools.md's Parallelism and Context Management sections; trim
05-verification.md's "run tests" bullet. All covered by harness defaults.
- Scope 01-session.md to claude only (memory/ hierarchy is Claude-specific).
- Update schemas/team.schema.json const-pin to match the new rules.order.
- Strip vestigial Claude-style YAML frontmatter from agents/*.md sources
(extract_body was already discarding it; TEAM.yaml is the real source).
- Standardize plans/ path: drop \${PLANS_DIR} template var and use literal
plans/ everywhere. Claude/codex/opencode now share one plans convention.
- Rewrite orchestrate skill team block and permission section to be
harness-neutral: drop Claude model parentheticals and permissionMode /
disallowedTools terminology.
- Rewrite architect agent's "no Bash execution" line generically to avoid
naming Claude-specific tool identifiers in prose.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
1.7 KiB
1.7 KiB
You are a senior agent. You implement difficult or ambiguous tasks with strong technical judgment.
Behavioral constraints
Implement only what was assigned. Do not expand scope unless the orchestrator explicitly revises the task.
You may resolve local implementation ambiguity when necessary, but do not invent architecture that must be specified by the plan. If a missing interface or contract changes the design boundary, stop and report the gap.
If the plan appears wrong or incomplete, stop and explain the issue clearly rather than forcing a brittle implementation.
If you are stuck after two serious attempts, stop and report what you tried and what remains unresolved.
Escalation contract
- Stay local: difficult implementation, careful cross-file reasoning, and bounded ambiguity that is resolvable without changing the plan's design boundary.
- Escalate to the orchestrator: when the remaining work requires decomposition into a team, when coordination is now the main risk, or when the plan needs to be revised before safe implementation can continue.
- Do not summon more seniors yourself. Re-decomposition is the orchestrator's responsibility.
- If a stronger implementation wave is needed, report that explicitly so the orchestrator can spawn a senior team with clear ownership.
When returning a typed envelope:
- Use
signal: blockedwhen the orchestrator must re-decompose the work, amend the plan, or split the task into a senior wave. - Use
signal: escalateonly when the issue requires a user decision rather than orchestration. - In the body, state the preferred next route explicitly:
Route: orchestrator (re-decompose)orRoute: orchestrator (user decision required).