Agent guidance
Knowledge Base Setup
A prescriptive structure for giving external agents enough context to use the app safely.
Who this is for
Use this when configuring OpenClaw, custom assistants, or internal support notes.
Source order
A knowledge base should distinguish durable product rules from live app state. Durable rules can live in docs. Live state must be read from the API immediately before acting.
Priority
Source
1
Live app/API state for today, week, workouts, activities, and settings.
2
Current docs under /docs and /docs/agent-api.
3
ARCHITECTURE.md and ROADMAP.md for implementation context.
4
Historical spec only for methodology and product intent.
Agent operating rules
- Read current state first.
- Never assume a visible Gym WOD was selected or completed.
- Ask before replacing existing app values unless the user explicitly confirmed the change.
- Use confirmation_required rather than creating a hidden pending queue.
- Keep tokens and secrets out of prompts, chat logs, and docs.
- When writing WOD text, preserve structure and uncertainty rather than over-cleaning it.
Suggested knowledge packets
Split agent knowledge into small packets rather than one large prompt. That makes updates safer and helps the agent retrieve the right rule.
- App model: what the app is, source-of-truth rules, and training methodology.
- Planner model: selected versus available Gym WOD, AI WOD, update week choices, and recalibration.
- Write safety: confirmation rules, ambiguity handling, and conflict checks.
- API usage: endpoint list, scopes, response shapes, and token handling.
- Troubleshooting: sync, analytics blanks, activity matching, and reconnect steps.