Thread Context — Triangulator Skill Build¶
Where We Left Off¶
Everything is built and configured. The triangulator hasn't been tested with a live query yet (sandbox blocks outbound HTTP). Brian was about to try his first triangulation.
To Resume This Work¶
Immediate next step¶
Run a triangulation! Say "triangulate: [any question]" and the full flow kicks in: 1. AskUserQuestion for query type + depth 2. Auto-recommend models from the registry 3. Confirm or customize 4. Query all 7 providers in parallel 5. Synthesize
Architecture¶
api-keys.json ← 7 provider keys (shared across all skills)
model-registry.json ← 25 tagged models (auto-refreshed weekly)
balance-checker.py ← Credit monitoring (daily scheduled check)
llm-triangulator-* ← Skill-specific config, script, instructions
UX Flow¶
Phase 1: Query type (reasoning/coding/creative/research) + depth (quick/standard/deep) Phase 2: Auto-recommend best model per provider → "use these" or "customize" Phase 3 (optional): Per-provider model override + "Remember for this session" option
Key design principles Brian emphasized¶
- System should NOT be static — models and capabilities auto-update
- Shared infrastructure across skills (key vault, registry)
- Configurable alert thresholds for credit monitoring
- Smart defaults with full override capability
Future work discussed¶
- Image/video critique skill: Together AI's generative models (FLUX, Kling, Sora 2) + vision-capable LLMs. Same shared key vault. Would add image/video tags to model registry.
Brian's working style (learned this session)¶
- Asks "what are best practices?" before committing to an approach
- Prefers configurable over static — wants things to self-maintain
- Thinks about shared infrastructure across skills
- Iterates on UX — started basic, evolved to smart recommendations
- Thorough — covers edge cases like credit monitoring and model freshness