| name | cta-research-loop |
| description | Use for CTA research inside Aura when the task is to inspect archived runs, review evaluation artifacts, generate the next structured proposal, or advance approval-gated archive state. Do not use it for generic coding or to invent unsupported execution capability. |
| allowed-tools | ["cta__artifact_find","cta__artifact_load","cta__archive_candidate","cta__archive_lineage","cta__proposal_generate","cta__approval_list","cta__approval_resolve","cta__apply_approved_transition"] |
CTA Research Loop
Use this skill for persisted CTA research state, proposal generation, and archive governance inside Aura.
Quick Routing
- Need exact prior state or payloads: read
references/tool_contract.md, then use artifact and archive tools.
- Need the next experiment or strategy iteration: load the latest
StrategySpec, ExperimentSpec, and optional EvalReport, then call cta__proposal_generate.
- Need promotion, freeze movement, or approval handling: use approval tools first, then materialize the archive transition.
- Need to archive a promising completed run as a new candidate: use
cta__archive_candidate.
- Need a fresh backtest run: read
references/current_limits.md first. If no deterministic harness exists, stop and propose or implement the missing assembler instead of fabricating execution.
- Need a concrete example of how to execute one of those tasks: read
references/research_playbook.md.
Workflow
- Anchor on persisted CTA state, not chat memory.
- Load only the specific artifacts or archive records required for the current decision.
- Emit structured outputs: proposals, approvals, and archive transitions stay machine-readable.
- Respect the current execution boundary before suggesting or claiming a new run.
- Do not recursively scan
.archive/, .aura/, or large data directories with generic file listing when restoring CTA state; use CTA tools and targeted refs first.
Response Contract
- Default to a compact structured answer with four parts:
state_summary, evidence, recommended_action, blocked_by.
- In
evidence, cite concrete artifact refs, archive ids, approval ids, or report ids actually loaded in this turn.
- In
recommended_action, distinguish between proposal, approval_decision, archive_transition, and implementation_gap.
- If the task is blocked by missing execution infrastructure, say so explicitly and name the missing deterministic component.
Rules
- Treat CTA artifacts, archive records, and approvals as the source of truth.
- Keep outputs structured; do not collapse proposals or governance state into free-form prose.
- Do not bypass approvals when archive state changes are requested.
- Do not claim there is a generic
StrategySpec -> executable strategy module path unless the repo has added one.
References
- Read
references/tool_contract.md for task-to-tool mapping and payload expectations.
- Read
references/current_limits.md when the task touches fresh execution, generic strategy compilation, or runtime boundaries.
- Read
references/research_playbook.md for concrete end-to-end task patterns.
- Read
references/response_contract.md when you need exact output shapes for state review, proposal, governance, or blocked execution tasks.