to-prdlisted

Synthesize the current conversation context into a PRD. Do not ask discovery questions — if something is unclear, state your assumption. Do confirm technical choices (seams, contracts) with the user before writing the final document. ## Tracker Configuration Before any tracker operation, locate `issue-tracker.md` using this lookup chain: 1. `$(git rev-parse --show-toplevel)/.coding-crew/docs/issue-tracker.md` (project-level) If it does not exist, invoke the `configure-tracker` skill now to set it up, then continue. All tracker operations in this skill use the operation definitions in that file. ## Process 1. **Determine the feature slug** before anything else: - If the user provided a slug or path argument, extract it from there. - Otherwise, list existing directories under `.scratch/` and pick the one that clearly matches the topic. - If no match is found, ask: "What feature slug should I use? (This becomes the `.scratch/<slug>/` directory.)" Never guess the slug silently — confirm with the user if there's any ambiguity. 2. **Check for an existing PRD.** If `.scratch/<feature-slug>/PRD.md` already exists, read it — it may contain a `## Decisions` section pre-seeded by `crew-grill`. Preserve and expand those decisions rather than replacing them. 3. Explore the repo to understand the current state of the codebase, if you haven't already. Use the project's domain glossary vocabulary throughout, and respect any ADRs in the area you're touching. The decision