edge-candidate-agent

---
name: edge-candidate-agent
description: Use when turning market observations into reproducible research tickets, exporting ideas as strategy.yaml + metadata.json, or checking edge-finder-candidate/v1 compatibility before pipeline backtests.
category: Strategy R&D
version: 1.0.0
tools: []
---

# Edge Candidate Agent

## Overview

Convert daily market observations into reproducible research tickets and Phase I-compatible candidate specs. Prioritize signal quality and interface compatibility over aggressive strategy proliferation. This skill can run standalone end to end, but in the split workflow it primarily serves the final export/validation stage.

## When to Use

- Convert market observations, anomalies, or hypotheses into structured research tickets.
- Run daily auto-detection to discover new edge candidates from EOD OHLCV data and optional hints.
- Export validated tickets as `strategy.yaml` + `metadata.json` for `trade-strategy-pipeline` Phase I.
- Run preflight compatibility checks for the `edge-finder-candidate/v1` interface before pipeline execution.

## Position in the Split Workflow

1. `edge-hint-extractor`: observations/news -> `hints.yaml`
2. `edge-concept-synthesizer`: tickets/hints -> `edge_concepts.yaml`
3. `edge-strategy-designer`: concepts -> strategy drafts + exportable ticket YAML
4. `edge-candidate-agent` (this skill): export + validate for pipeline handoff

## Methodology

1. Auto-detect candidates from EOD OHLCV, optionally seeded with human ideation hints or an external LLM ideation pass.
2. Consult the interface contract (`edge-finder-candidate/v1`), the signal-family mapping, the research-ticket schema, and the ideation-loop conventions to ground the ticket.
3. Build or update a research ticket following the schema: hypothesis, evidence, entry family, risk parameters.
4. Export candidate artifacts: `strategies/<candidate_id>/strategy.yaml` (Phase I-compatible strategy spec) and `strategies/<candidate_id>/metadata.json` (provenance metadata including interface version and ticket context).
5. Validate the interface contract and, where a pipeline root is available, the Phase I schema/stage rules; report pass/fail with reasons.
6. Hand off the candidate directory to `trade-strategy-pipeline` and dry-run before full execution.

Daily-detection artifacts to expect: `daily_report.md`, `market_summary.json`, `anomalies.json`, `watchlist.csv`, exportable ticket YAMLs, and research-only ticket YAMLs.

## Export Rules

- Keep `validation.method: full_sample`.
- Keep `validation.oos_ratio` omitted or `null`.
- Only two entry families are supported for export in v1: `pivot_breakout` (with `vcp_detection`) and `gap_up_continuation` (with `gap_up_detection`).
- Mark unsupported hypothesis families as research-only in ticket notes, never as export candidates.

## Guardrails

- Reject candidates that violate schema bounds (risk, exits, empty conditions).
- Reject a candidate when its folder name and its `id` field mismatch.
- Require deterministic metadata carrying `interface_version: edge-finder-candidate/v1`.
- Always dry-run in the pipeline before full execution.