Prompting an agent

These tables are the same intent → command mapping each CLI’s SKILL.md carries on its own, merged across all three so you can see the whole surface at once. UNIT, TASK and SECTION are placeholders — the agent fills them from what you actually said (a unit’s name or code, a task abbreviation), never from a guessed format. See The command model for why no code format is assumed.

​

Reading

​

Writing — always plan first

Every write below follows the same two-step pattern: run it once with --dry-run to show the plan, confirm with the person, then run it again with --yes. An agent should never skip straight to --yes on a first attempt, even when the request sounds unambiguous.

​

Rules an agent should follow

• Ask before a mutation runs for real. A --dry-run plan is safe to show without asking; running the same command with --yes changes something on the platform and should follow an explicit yes from the person, not an inferred one.
• Dry-run first, every time. Even when the request is unambiguous, show the plan before applying it — it’s the only chance to catch a wrong UNIT/TASK before it’s sent.
• Never print or echo a token or session cookie. MOODLE_TOKEN/MOODLE_SESSION, EDSTEM_TOKEN, ONTRACK_TOKEN/ONTRACK_AUTH_TOKEN, and any file under a CLI’s config or cache directory hold live credentials. Don’t include their values in a message back to the person, a log, or a committed file.
• Prefer --fields to cut a response down to what’s actually needed, instead of parsing a full table or object and discarding most of it — edstem threads list UNIT --fields id,title,unread is cheaper to read than the full row for every thread.
• Page instead of pulling everything. --limit (moodle’s todo, for example) and --max/-n (edstem’s list commands) cap how much comes back in one call; ask for another page rather than requesting an unbounded list up front.