plan-kb

Write a durable plan

Keep the plan useful before, during, and after execution. It is the coordination record, not a disposable answer or a duplicate task tracker.

Find the plan's owner

1. Resolve <vault> to the directory containing its authored or managed index.md front door, then set the shell-local KB_ROOT to that path (KB_ROOT=kb from a typical repository root, or KB_ROOT=. from inside the vault). Read the vault's AGENTS.md and the nearest guide under <vault>/plans/. Pass that resolved root to every command; do not assume the starting directory is the vault.
2. When the plan owns a repository path, resolve the repository root as KB_REPO and load that path's current memory before a whole-vault search:

kb context "<repository-path>" --root "$KB_ROOT" --repo "$KB_REPO"

Use --kind file or --kind directory when an absent future path cannot be classified from the filesystem. Read the inherited guides first, then the applicable maintained knowledge, active plans, dated research, reports, and separate historical-plan group.

1. Search existing plans before creating one:

kb list --root "$KB_ROOT" --where type=plan --sort area --json
kb search "the intended outcome" --root "$KB_ROOT" --json

If kb is not installed, do not let retrieval tooling block the plan: use rg or the available file search over <vault>/plans/, titles, aliases, and relevant terms. If the directory is not an initialized hraness/kb vault, follow the repository's existing planning convention instead of initializing one without being asked. Semantic search writes only a derived local cache; when that cache location is not writable, use exact search or point XDG_CACHE_HOME at a writable cache directory.

1. Update an existing plan when it already owns the outcome. Create a new file only for independently executable work.
2. Use <vault>/plans/<descriptive-kebab-name>.md unless the local guide already groups plans by area. Do not reorganize older plans merely to impose a new tree.