`tracker_design`

Teaching tool that guides tracker creation. Call it before tracker_create whenever the user asks to create a tracker.

What it returns

{
  "design_version": "1",
  "system_prompt": "...",   // 7-step design guide
  "archetypes": [...],       // 6 archetype definitions
  "existing_trackers": [...],// current trackers in catalog (cap 30)
  "next_step": "..."
}

The 7 steps

Pick an archetype — match intent to one of 6 archetypes.
Write the augmentation prompt — imperative, names sources, states conflict resolution.
Design params — live state only, flat, stable keys.
Decide schema discipline — loose early, lock when mature.
Compose render_template — MiniJinja projecting params to markdown.
Sketch body skeleton — prose sections + History block.
Check for collisions — existing_trackers prevents duplicate concerns.

Archetypes

Name	When to use
`deployment_state`	Feature flag / env rollout state per environment
`failure_table`	Numbered F-N list from a test/eval suite
`metric_baseline`	Living benchmark log with baseline + session deltas
`audit_issues`	Numbered audit output with severity + status
`task_list`	Phase-based task list with done/open/blocked status
`reflective`	Design brainstorm or decision log — prose-driven

Each archetype ships with params_shape_example, params_schema_example, render_template_example, body_skeleton, and prompt_template.

Usage

tracker_design()                    // load guide + landscape
→ pick archetype, compose spec
tracker_create(repo, rel_path, title, prompt, params, ...)

Pass intent to tracker_design for future tailoring (reserved, currently echoed back in the response).

Known limitations

existing_trackers is capped at 30 entries (scope=repo).
intent field is reserved; no tailoring is applied yet.

Keyboard shortcuts