From cc-quant-team
Set up a multi-agent quantitative research and trading team with file-based planning. Use when: (1) user asks to start a new complex quant project with a team, (2) user says "set up quant team", "create quant team", "build a research team", "start quant project", (3) user invokes /quant-team-creator with a project name, (4) user wants to organize a multi-phase quant project with parallel agent workers and persistent progress tracking. Creates TeamCreate, planning files (.plans/project/), per-agent work directories, pre-filled quant invariants and review dimensions, and spawns configured teammates. TRIGGER on: "quant team", "research team", "trading team", "start quant project", "set up quant team", "build a quant team", "organize quant project", "hft team", "lft team", "strategy team". IMPORTANT: You (team-lead) MUST read all reference files directly — do NOT delegate to subagents. NOTE: After initial setup, you can add new teammates at any time — just spawn a new Agent with the team_name and follow the same onboarding pattern. The team is not locked after creation.
How this skill is triggered — by the user, by Claude, or both
Slash command
/cc-quant-team:quant-team-creatorThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Set up a multi-agent quantitative research and trading team for complex projects, using
Set up a multi-agent quantitative research and trading team for complex projects, using persistent files for planning and progress tracking. This skill is a quant-adapted fork of CCteam-creator — same file-based infrastructure, team-lead control plane, and harness mechanisms, but specialized for quant research, trading strategy development, HFT/LFT feature engineering, C++/Python performance work, and risk management.
This skill uses native team-dispatch tools (TeamCreate, TaskCreate, TaskUpdate, TaskList, SendMessage) that are part of Claude Code's experimental agent teams feature. Without it, the dispatch instructions in this skill won't work.
Requirements:
claude --version)CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 set at session startEnable via ~/.claude/settings.json (recommended, persists across sessions):
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
Or shell env (per-session):
export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
claude
Either way, you must restart Claude Code — team tools load only at startup. After restart, verify by asking: "Is TeamCreate available?" — if yes, you're good.
Known limitations (experimental status): no session resumption with in-process teammates, task status can lag, shutdown can be slow.
Before starting Step 1, you (team-lead) MUST read all reference files directly into your own context:
Read references/onboarding.md
Read references/templates.md
Read references/roles.md
Read references/quant-invariants.md
Read references/quant-review-dimensions.md
Do NOT delegate this to a subagent (Explore, general-purpose, etc.). Subagents return summaries, losing critical detail — you need the full templates and onboarding prompts to generate files and spawn agents correctly.
If the team tools are NOT available (e.g., user forgot to enable the env var, or Claude Code is outdated), DO NOT proceed with Step 1. Instead, tell the user:
I need Claude Code's experimental agent teams feature enabled to set up the team. Please:
- Add
"env": {"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"}to~/.claude/settings.json- Restart Claude Code
- Re-invoke /quant-team-creator
See the plugin's README for details.
Do not try to simulate the team with standalone Agent() calls — that bypasses the file-based coordination this skill depends on.
Step 0 Update Check (auto): Background version fetch + one-line notification if newer version exists
Step 0 Detect (auto): Check if .plans/ exists → if yes, offer to resume existing project
Before any other step, perform a lightweight version check. No user consent needed, do not ask any questions.
Remote version: WebFetch https://raw.githubusercontent.com/LianguangXue/CC_quant_team/master/.claude-plugin/plugin.json with prompt: "What is the value of the version field? Respond with just the version string."
Local version: Use Bash to read local plugin.json (try these paths in order, use the first that exists):
cat ~/.claude/plugins/cache/cc-quant-team/CC_quant_team/*/.claude-plugin/plugin.json 2>/dev/null || \
cat ~/.claude/skills/quant-team-creator/.claude-plugin/plugin.json 2>/dev/null
Extract the version field from the output.
Compare:
ℹ️ A newer quant-team-creator version is available ( → ). It will auto-apply on next Claude Code startup. Continuing with in this session.
Hard rules:
Before starting setup, check if .plans/ directory exists in the current working directory.
If .plans/ exists:
.plans/ for project directories — if multiple, list them.plans/<project>/team-snapshot.md exists
b. If snapshot exists: Read the snapshot header metadata. Compare skill source file timestamps against snapshot generation time:
If .plans/ does not exist: Skip directly to Step 1.
Goal of this step: Help the user fully understand how the quant team works, while gathering their actual quant project requirements. Do not rush to create files or teams.
In a natural, conversational tone (do not copy this text verbatim — adapt to context), explain the following points:
What a quant team is:
When it's a good fit:
When it's NOT a good fit:
How it works:
.plans/<project>/), recording tasks, findings, progressresearch-validator gaterisk-manager gate before live deploymentcode-validator review for large features/modulesAfter the introduction, learn the following through conversation:
risk-manager gate and backend-dev live-infra roles are needed)Note: Do not fire all questions at once. Follow up naturally based on the user's answers. If the user's requirements are already clear, you may skip some questions.
Based on the user's needs, recommend an appropriate combination of roles. Explain each role's purpose and why you're recommending it.
Available quant roles (full roster in references/roles.md):
| Role | Name | Model | Multi-instance | When to include |
|---|---|---|---|---|
| Backend Dev | backend-dev | sonnet | no | Live trading infra, exchange API, order DB, realtime feed |
| Frontend Dev | frontend-dev | sonnet | no | Lazy — only when viz/dashboard needed |
| Algorithm Engineer | algorithm-engineer | sonnet | yes (volume) | C++/Python perf work, pybind11, memory optimization |
| HFT Researcher | hft-researcher | sonnet | yes (direction) | Tick-level / L2 feature engineering |
| LFT Researcher | lft-researcher | sonnet | yes (direction) | Daily/minute feature engineering |
| Data Engineer | data-engineer | sonnet | no | Historical pipeline, parquet schemas, data quality |
| Model Researcher | model-researcher | opus | no | DL/ML signal/alpha modeling |
| Strategy Researcher | strategy-researcher | opus | no | Portfolio construction, execution, simulator |
| Code Validator | code-validator | sonnet | no | Code review + writes corner-case tests |
| Research Validator | research-validator | opus | no | Lookahead / survivorship / leakage / overfitting checks |
| Risk Manager | risk-manager | opus | no | Fund verification, strategy risk, monitoring |
Model default:
sonnetfor most roles.opusformodel-researcher,strategy-researcher,research-validator, andrisk-manager— these require deep reasoning (signal design, multi-factor tradeoffs, subtle bias detection, tail-risk analysis). Cost-justified because a missed lookahead bias or risk miscalibration costs far more than opus tokens.
See references/roles.md for detailed role definitions.
Recommendation principles:
research-validator + optionally data-engineer — for pure feature research projectsdata-engineer + 1-2 researchers + model-researcher + strategy-researcher + research-validator + risk-manager + code-validatoralgorithm-engineer + code-validator + the role owning the slow codebackend-dev + risk-manager (mandatory for live)algorithm-engineer-1 optimizes feature pipeline, algorithm-engineer-2 optimizes orderbook reconstruction)hft-researcher-microstructure, hft-researcher-orderflow)research-validator is mandatory for any project producing features, models, or signals. This is the single most important gate for preventing subtle quant bugsrisk-manager is mandatory for any strategy going to live tradingcode-validator recommended for teams with 4+ agents or long-running projects — for small teams, team-lead can absorb code review directlyml-infra-engineer, tca-analyst). Provide: name, responsibilities, model, subagent_type.Inform the user that the following can all be adjusted as needed:
quant_golden_rules.py (Q-1 timestamp monotonicity check)Team-lead = the main conversation (you). Do not generate a team-lead agent.
If the user is improving an existing quant team system rather than starting from scratch, explicitly decide whether the change belongs in:
CC_quant_team source templates themselvesRule of thumb:
CC_quant_team firstDo not recommend immediately rebuilding an active team unless the template changes are already written back and a phase boundary has been chosen.
After thorough discussion, use AskUserQuestion to get final user confirmation on:
alpha-v3, hft-orderflow, data-pipeline)Only proceed to the creation steps after the user confirms.
See references/templates.md for file templates.
.plans/<project>/
task_plan.md -- Main plan (lean navigation map, not encyclopedia)
findings.md -- Team-level summary
progress.md -- Work log (archive old entries when bloated)
decisions.md -- Architecture decision log
docs/ -- Project knowledge base
index.md -- Navigation map with sections & line ranges
pipeline-flow.md -- Quant pipeline: data → features → models → signals → strategy → execution
data-schemas.md -- All data artifact schemas (raw, features, signals, models, orders)
strategy-contracts.md -- Signal → position → order interface (if live trading in scope)
invariants.md -- Pre-filled with 21 quant invariants (trimmed per project)
archive/ -- Archived history (old progress, old plans)
<agent-name>/ -- One directory per agent
task_plan.md -- Agent task list
findings.md -- INDEX only (keep lean, no content dumping)
progress.md -- Agent work log (archive old entries when bloated)
<prefix>-<task>/ -- Task folder (one per assigned task)
task_plan.md / findings.md / progress.md
Every role creates task folders when assigned distinct tasks. The root findings.md serves
as an index — linking to each task-specific findings file instead of dumping everything
into one giant document.
| Role | Folder Prefix | Example |
|---|---|---|
| backend-dev / frontend-dev | task- | task-ctp-client/, task-dashboard/ |
| algorithm-engineer | perf- | perf-orderbook-reconstruction/, perf-feature-rolling-ops/ |
| hft-researcher / lft-researcher | research- | research-orderflow-imbalance/, research-momentum-factor/ |
| data-engineer | pipeline- | pipeline-datayes-l2/, pipeline-daily-fundamentals/ |
| model-researcher | model- | model-lgbm-alpha-v1/, model-lstm-intraday/ |
| strategy-researcher | strategy- | strategy-momentum-v2/, strategy-hft-market-making/ |
| code-validator | review- or test- | review-orderbook-cpp/, test-feature-pipeline/ |
| research-validator | research-review- | research-review-orderflow-imbalance/ |
| risk-manager | risk- | risk-momentum-v2-preflight/, risk-live-monitoring-setup/ |
Quick one-off notes (small bug fixes, config changes) can go directly in root files without a task folder.
CLAUDE.md in the project working directory is always loaded into the main session's context by Claude Code. This is the mechanism that keeps team-lead operational knowledge persistent across context compressions.
Create (or append to) a CLAUDE.md file in the project working directory (not inside .plans/).
See references/templates.md for the CLAUDE.md template. The template must be dynamically filled:
If the project directory already has a CLAUDE.md, append the team operations section at the end (with a clear separator), do not overwrite the existing content.
Without this file, after context compression the team-lead loses all knowledge of:
The CLAUDE.md solves this by keeping a concise operations guide permanently in context.
In Step 3, also create docs/index.md — a detailed navigation map showing each doc's sections
and line ranges. This file is maintained by code-validator (or custodian if added) and actively
Read by agents when they need to find specific information.
See references/templates.md for the docs/index.md template.
CLAUDE.md is a living document, not a one-time generation. Update it when:
## Known Pitfalls)docs/invariants.md, reference from CLAUDE.md)Do NOT put task-level details here — only durable operational knowledge.
Set up the enforcement infrastructure — this is the core of making research errors mechanically catchable.
Copy both bundled scripts from this skill into the project:
mkdir -p <project>/scripts
cp <skill-path>/scripts/common_checks.py <project>/scripts/common_checks.py
cp <skill-path>/scripts/quant_golden_rules.py <project>/scripts/quant_golden_rules.py
Then configure the bottom of quant_golden_rules.py for this project:
# ---- Project configuration ----
PROJECT_ROOT = Path(__file__).parent.parent
SRC_DIRS = [...] # Python package dirs (e.g., ["Tool", "Data", "StockBook"])
DATA_PATHS = [ # For Q-1 timestamp monotonicity check
{"path": "...", "format": "parquet", "ts_col": "Ts"},
{"path": "...", "format": "pkl.gz", "ts_col": "Ts"},
]
RESEARCH_DIRS = [...] # For Q-2 unseeded randomness check
PROD_DIRS = [...] # For U-3 debug leftovers check
EXEMPT_DIRS = ["tests", "notebooks", "archive"]
Q1_SAMPLE_RATE = 1 # Files sampled per date/path (0 = all)
Q1_ENABLED = True # Disable if data dirs not mounted
Universal (common_checks.py):
print(, breakpoint(), pdb.set_trace() in prod dirs (not tests/notebooks)Quant-specific (quant_golden_rules.py):
Ts non-decreasing per instrument per date in all configured data paths (parquet + pkl.gz)numpy.random / random / torch imports without seed callio.py, types.py, random.py, collections.py, etc.Any/Optional/Callable/etc. used as annotation must be in from typing import ...pd.read_csv Without dtype: WARN on pd.read_csv(...) calls without dtype= argumentCopy the full quant invariants list from references/quant-invariants.md into the project's docs/invariants.md. During Step 1 consultation, team-lead confirmed which invariants apply — remove the ones that don't (e.g., INV-E1–E4 for pure research projects).
Create scripts/run_ci.py:
import sys
from common_checks import check_all as common_check_all
from quant_golden_rules import check_all as quant_check_all
if __name__ == "__main__":
exit_code = max(common_check_all(), quant_check_all())
sys.exit(exit_code)
Devs add project-specific checks as they write tests. The skeleton does not need to be complete at project start — it grows as the project grows. But the file must exist from day one, otherwise no one will create it later.
All check scripts MUST produce agent-readable error messages: [WHAT] + [WHERE] + [HOW TO FIX].
# GOOD: agent can directly fix this
[Q-4 TYPING-IMPORT] Tool/stats.py:42 uses Optional but `from typing import Optional` is missing
File: Tool/stats.py:42
Symbol used: Optional
FIX: Add `Optional` to the existing `from typing import ...` statement at line 8,
OR add a new line: `from typing import Optional`
Add the CI command to the project CLAUDE.md Key Protocols table so it survives context compression.
TeamCreate(team_name: "<project>").plans/ path in the description. Set dependencies (addBlockedBy) and owners (owner) via TaskUpdate. Specify input/output to minimize inter-agent information lossrun_in_background: trueSee references/onboarding.md for the onboarding prompt for each role.
.plans/<project>/team-snapshot.md containing the rendered onboarding prompts and skill file timestamps. This enables fast resume without re-reading all skill files.Show the user a table of team members and the file locations.
Then guide the user to run /compact to free up context.
After compaction, team-lead may "lose memory" — forgetting teammate names, operational protocols, and the current project context. This is normal behavior of Claude Code's compaction.
If I (team-lead) seem confused after compaction, just tell me one sentence:
"Read
.plans/<project>/team-snapshot.mdto restore team state"This makes me reload the full team roster and all onboarding prompts, returning to a working state immediately.
.plans/ files are the source of truth (persistent); native TaskCreate is the live dispatch layer. TaskCreate description = one-line summary + .plans/ pathcode-validator after completing a feature/new module; small changes do not require reviewresearch-validator review before downstream use. This is a hard gate — no exceptions. Subtle bias errors (lookahead, survivorship, leakage) are the #1 cause of quant losses, and they're invisible without an independent checkrisk-manager review before going live. Risk-manager reviews: capacity, slippage modeling, fee modeling, tail-scenario stress, correlation to existing strategies, circuit breakers, monitoring setupdocs/data-schemas.md, docs/pipeline-flow.md, and docs/strategy-contracts.md when code changes — undocumented schemas do not exist for other agentsdocs/invariants.md, then converted to automated tests. research-validator / risk-manager are second line of defense; automated tests are first[AUTOMATE] on a recurring pattern → team-lead adds a new check (Q-6, Q-7, …) to quant_golden_rules.py. If the check is universal-quant, flag [TEAM-PROTOCOL] for template sync back to CC_quant_teamCC_quant_team source files before recommending a rebuildStatus: complete in the root findings.md indexThe core idea behind planning-with-files is: file system = disk, context = memory, important things must be written to disk.
In a quant team project, this principle operates at three levels:
| Level | Owner | File Location | Focus |
|---|---|---|---|
| Project Global | team-lead | .plans/<project>/task_plan.md | Phase progress, pipeline decisions, task assignments |
| Agent Level | Each agent individually | .plans/<project>/<agent>/ | Task index, general notes, work log |
| Task Level | Each agent | .plans/<project>/<agent>/<prefix>-<name>/ | Detailed steps, findings, and progress for a specific task |
Proactively check at these moments:
Quick scan (read each agent's progress.md in parallel):
Read .plans/<project>/data-engineer/progress.md
Read .plans/<project>/hft-researcher/progress.md
Read .plans/<project>/model-researcher/progress.md
...(adjust for actual roles)
Deep dive (read findings.md when something seems off):
Read .plans/<project>/<agent-name>/findings.md
Gate status check (specific to quant):
Read .plans/<project>/research-validator/findings.md -- which outputs are blocked/approved
Read .plans/<project>/risk-manager/findings.md -- which strategies have passed risk gate
Decision alignment:
Read .plans/<project>/task_plan.md
Reading order: progress → findings → task_plan → gate status
SendMessage to a spawned teammate is delivered only when the recipient is idle (between turns). You cannot interrupt a running agent — messages queue until its current turn ends.
Consequences for dispatch:
progress.md / findings.md directlyThe team-lead is responsible for:
.plans/<project>/task_plan.md, decisions.md, and project CLAUDE.mdCC_quant_teamTeam-lead MUST keep project-level files current. Agents write to their own dirs; team-lead writes to the project root. If team-lead doesn't write, there is no project-level record — only scattered agent files with no coherent picture.
Team-lead owns 5 root-level files (agents write to their own dirs; these are project-global):
| File | Purpose | Team-lead role |
|---|---|---|
task_plan.md | Navigation map: phases, task summary, gate status | Primary author. Update §4 / §5 / §6 on every dispatch / completion / phase change |
progress.md | Chronological log of what happened across the team | Append after every significant event (dispatch, completion, verdict, decision, phase) |
findings.md | Cross-team findings consolidation, tagged by source agent | Consolidate important findings from agents at milestones (see Milestone Consolidation below) |
decisions.md | Architecture / pipeline / tool-choice decisions with rationale | New D entry for every non-trivial decision |
team-snapshot.md | Cached onboarding prompts + roster for fast resume | Regenerate when roster changes, at phase boundaries, or when skill source files update |
When to update — event-driven triggers:
| Trigger | task_plan.md | progress.md | findings.md | decisions.md | team-snapshot.md |
|---|---|---|---|---|---|
| Dispatch a task | §4: add row | append | — | — | — |
| Agent reports completion | §4: mark done | append with verdict | — | — | — |
| Validator verdict | §6: gate status | append | — | — | — |
| Architecture decision | — | append | — | new D | — |
| Phase boundary | §5: phase status | phase summary | consolidate (see below) | — | check staleness |
| Roster change | — | append | — | — | regenerate |
| New Known Pitfall | — | append | — | — | — |
| Session resume | — | status summary | — | — | check staleness |
| User requests status | — | — | — | — | — |
| Milestone reached | — | append | consolidate (see below) | if applicable | — |
At phase boundaries or whenever significant work completes (a feature family validated, a model finalized, a strategy backtested), team-lead must consolidate:
Step 1 — Consolidate findings.md: Read each agent's relevant task-folder findings.md. Extract the key results, metrics, and conclusions that matter at the project level. Write a consolidated entry to the main .plans/<project>/findings.md:
## [MILESTONE] <date> — Phase 2 Feature Research Complete
### Source: team-lead (consolidated from agent findings)
**Features Delivered:**
- Orderflow imbalance family (hft-researcher-orderflow): IC=0.04, rank-IC=0.05, coverage=95%
- Full report: hft-researcher-orderflow/research-orderflow-imbalance/findings.md
- Research-validator verdict: [OK] (2026-04-15)
- Momentum factor (lft-researcher): IC=0.03, turnover=0.8, coverage=92%
- Full report: lft-researcher/research-momentum-factor/findings.md
- Research-validator verdict: [OK] (2026-04-16)
**Key Technical Decisions:**
- Used Ts (local receive time) not ExchangeTs for all features (INV-T4 compliant)
- OrgData schema frozen as of 2026-04-10 — no further changes until Phase 4
**Blocked / Deferred:**
- Queue position features deferred to Phase 4 (needs StockBook L3 data not yet available)
**Metrics Summary:**
| Feature | IC | Rank-IC | Turnover | Coverage | Validator |
|---------|-----|---------|----------|----------|-----------|
| orderflow_imbalance | 0.04 | 0.05 | 0.6 | 0.95 | [OK] |
| momentum_60d | 0.03 | 0.04 | 0.8 | 0.92 | [OK] |
Step 2 — Update docs/ when milestone reveals important details: If the milestone produced knowledge that downstream agents need (schema details, interface specifics, performance characteristics, capacity numbers), create or update the relevant docs/ file with those details:
| What was learned | Where to put it |
|---|---|
| Feature schema details (columns, dtypes, lookback, NaN handling) | docs/data-schemas.md §Features |
| Pipeline latency / throughput numbers from data-engineer | docs/pipeline-flow.md §Latency Budgets |
| Model training results + signal output format | docs/data-schemas.md §Models + §Signals |
| Strategy backtest metrics + execution model | docs/strategy-contracts.md |
| Capacity / risk limits from risk-manager | docs/strategy-contracts.md §Risk Limits |
| Newly discovered invariant | docs/invariants.md |
This is NOT copying agent findings verbatim. Team-lead reads agent findings, extracts the durable knowledge (schemas, metrics, interfaces, constraints), and writes it to the appropriate docs/ file in a structured format that future agents can consume.
Step 3 — Update docs/index.md: If any docs/ file was created or significantly changed, update docs/index.md with the new section names and line ranges.
Why this matters: Agent task-folder findings are detailed but scattered. Without consolidation, the next phase's agents (e.g., model-researcher starting Phase 3) must read 5 different agent directories to understand what features exist. Consolidated findings.md + updated docs/ give them one place to look.
Format for team-lead progress.md entries:
## <date> — <session title or phase>
### Dispatched
- T5 → hft-researcher-orderflow: orderflow imbalance feature family
- T6 → data-engineer: validate OrgData for 2023H1
### Completed
- T3 (algorithm-engineer): orderbook reconstruction optimized 18.9× — code-validator [OK]
- T4 (lft-researcher): momentum factor — research-validator [CONCERN], needs regime test
### Gate Updates
- research-validator: orderflow-imbalance → [OK]
- risk-manager: momentum-v2 → [RISK-WARN] (capacity concerns at >$30M)
### Decisions
- D4: Use LightGBM over LSTM for alpha-v1 (see decisions.md)
### Milestone Consolidation
- Wrote [MILESTONE] Phase 2 summary to findings.md
- Updated docs/data-schemas.md §Features with orderflow + momentum schemas
- Updated docs/index.md line ranges
### Phase Status
- Phase 2 (Feature Research): 3/5 feature families complete, 2 in progress
- Next milestone: all features research-validator [OK] before Phase 3
### Next Actions
- Wait for hft-researcher-orderflow T5 completion
- Dispatch momentum regime-test to lft-researcher after T4 fix
Self-check (every ~5 interactions with agents or user):
task_plan.md §4 Task Summary current? (no stale in_progress rows for finished tasks)task_plan.md §6 Gate Status current?progress.md?findings.md up to date? (any agent completions since last consolidation?)docs/ files current with the latest schemas/interfaces/metrics?CLAUDE.md still reflect actual roster and protocols?team-snapshot.md stale? (roster changed since last generation?)If any answer is "no" — update the file NOW before doing anything else.
When an agent reports "3 failures, escalating to team-lead":
## Known Pitfalls[TEAM-PROTOCOL] and consider template updateEach phase advancement has 3 mandatory steps: READ → WRITE → ADVANCE.
Data phase complete:
docs/data-schemas.md currentResearch phase complete:
[OK]Modeling phase complete:
Strategy phase complete:
Risk review complete:
[RISK-OK] → advance to live; if [RISK-BLOCK] → back to strategyAll done:
Phase boundary health check (do this BEFORE writing phase-advance entries):
in_progress tasks in TaskList? → update task_plan.md §4docs/data-schemas.md synced with code?team-snapshot.md still current? (if roster changed during this phase, regenerate)Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Searches MemPalace before answering questions about past work, people, projects, or prior decisions. Returns verbatim stored content instead of guessing from model memory.
npx claudepluginhub lianguangxue/cc_quant_team --plugin cc-quant-team