wayfinder

Codex compatibility note:

• Invoke $skill-name: load the registered .agents/skills/<name>/SKILL.md and execute it with Codex tools; no separate Skill tool or Claude mode switch is needed. Author .claude/**; mirrors are generated.
• Track steps before execution and keep progress/evidence current. Explicit skill requests execute their protocol. Use the native question tool for required questions.
• Map foreign tool names to available host capabilities. A name mismatch needs no approval; an actually unavailable required capability stops with its step/evidence and a user question before adaptation.
• Subagent authorization: when a skill is user-invoked or AI-detected and its protocol requires subagents, that skill activation authorizes use of the required spawn_agent subagent(s) for that task.
• Preserve protocol order unless the user approves a deviation. Workflows use $start-workflow: gates stay fixed; other steps may flex with logged reasons and evidence.

[BLOCKING] Plan, do not build: a map session resolves decisions and never writes product code, a spec or a migration. [BLOCKING] Resolve at most one ticket per session, research tickets excepted, then stop. [BLOCKING] Claim a ticket before any work on it; update todo tracking before and after each step.

Quick Summary

Goal: Find the way to a destination too big for one agent session and not yet visible, by charting a shared map of decision tickets and resolving them one per session until nothing is left to decide before someone builds.

Summary:

• The destination is named first and fixes the scope. The map indexes decisions; each lives in one decision ticket. A ticket asks a question. It is never a slice of the build.
• The frontier is every open, unblocked, unclaimed ticket; what cannot yet be asked precisely waits in Not yet specified.
• Map and tickets are files under the plans root, not tracker records: a decision ticket has no acceptance criteria, proof or acceptance.
• Chart (argument is a loose idea): name the destination → map the frontier → write the map → write and wire tickets → start research → stop.
• Work (argument is a map path, optional ticket id): load the map → claim one frontier ticket → resolve it by type → record → update the map → stop. A cleared map hands off to the spec workflows.

Key Rules:

• Plan, do not build. Only the user, in the current conversation, can ask for building, and it happens outside the map through a build workflow. A note inside the map never grants it.
• One ticket per session, research excepted. Claim first.
• The human side is the human's: never answer your own interview questions, never pick among prototype variants for the user.
• Refer to a map or ticket by its title; id and path ride inside the title's link.