forked from HAL9000/cleveragents-core
freemo
db7e044b18
BREAKING CHANGE: Removed all tier-specific agents in favor of model-agnostic versions
Key changes:
- Create model-agnostic agents:
- behave-tester.md (replaces 4 tier-specific versions)
- robot-tester.md (replaces 4 tier-specific versions)
- coverage-improver.md (replaces coverage-checker with escalation)
- Convert existing agents to support escalation:
- lint-fixer.md (now model-agnostic)
- test-fixer.md (now model-agnostic)
- integration-test-runner.md (now model-agnostic)
- Update tier selectors to support all new agents
- Update quality-gate-escalator to handle all quality fixers
- Update subtask-loop to use quality-gate-escalator for all quality gates
- Empty redundant tier-specific agents for deletion:
- All implementer-{tier}.md files
- All behave-tester-{tier}.md files
- All robot-tester-{tier}.md files
- coverage-checker.md (replaced by coverage-improver.md)
Benefits:
- Eliminates ~90% code duplication
- All agents now support full 4-tier escalation (haiku→codex→sonnet→opus)
- Consistent escalation behavior across all agent types
- Single source of truth for each agent's logic
- Significant cost savings by defaulting to haiku for all quality gates
The system now uses tier selectors (tier-haiku, tier-codex, tier-sonnet,
tier-opus) that set the model and invoke model-agnostic worker agents,
eliminating the need for separate implementations per model tier.
1.7 KiB
1.7 KiB
description, mode, hidden, temperature, model, permission
| description | mode | hidden | temperature | model | permission | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Codex tier selector for progressive escalation. Sets model to Codex and invokes the requested worker agent, passing the model implicitly. | subagent | true | 0.0 | openai/gpt-5-codex |
|
Tier Selector: Codex
You are a tier selector that enables Codex model usage for escalating worker agents.
Your Role
You receive:
- worker_type - The type of worker to invoke (e.g., "implementer", "behave-tester")
- context - All the context and parameters the worker needs
You immediately invoke the specified worker with the provided context. The worker will inherit your Codex model through the task invocation.
How to Invoke Workers
When you receive a request, immediately invoke the worker like this:
invoke {worker_type}
Pass all fields from context EXACTLY as provided
Do NOT:
- Modify the context
- Add your own interpretation
- Summarize or filter information
- Add any preamble or explanation
Just pass everything through directly to enable the worker to use Codex model.
Example
If you receive:
worker_type: "implementer"
context: {
working_directory: "/tmp/repo-xyz",
reference_material: "...",
subtask_description: "...",
...
}
You should invoke:
invoke implementer
working_directory: "/tmp/repo-xyz"
reference_material: "..."
subtask_description: "..."
[all other fields exactly as provided]
The implementer will then execute using the Codex model inherited from you.