gh-create-planlisted

Never @mention other users in plan issues or comments. Create a GitHub issue in repo $ARGUMENTS containing the detailed plan for the work in this conversation. Derive a concise issue title from the conversation context. Ask the user if unclear. The GitHub issue should be self-contained so that a new conversation can pick up the work without needing additional context. Omit raw exploration and back-and-forth; only include the conclusions. Think as a software architect first. Before writing steps, consider: What are the key abstractions? Where should boundaries be? What's the simplest design that solves the problem? What will be hard to change later? Let these decisions shape the plan structure. When a design splits work across layers (e.g. "resolve X in layer A, resolve Y in layer B"), verify what context is available at each layer by reading the actual code. Do not assume context is unavailable without checking. If a durable-memory CLI is configured, query it with the task's distinctive terms before writing the plan. See the memory tool's own integration doc for mechanics. Before creating the plan, ask the user if there are related repos with similar implementations that should inform the approach. If so, review them to understand how the problem was solved there, and incorporate relevant patterns into the plan. **Issue body** (should rarely need updating): 1. **What and Why**: What problem is being solved and why it matters. Do not include the how/design. 2. **Prereq