[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6MP4F5KADVRA4ZB6E59K4R5":3,"skill-same:01M6MP4F5KADVRA4ZB6E59K4R5":79},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":26,"publishedAt":42,"linkOnly":43,"markdownContent":44,"markdownBody":45,"frontMatter":46,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":54,"ownerHtmlUrl":55,"ownerBlogUrl":56,"ownerDescription":57,"updatedAt":58,"install":59,"resources":72},"01M6MP4F5KADVRA4ZB6E59K4R5","plan",null,"Create a structured implementation plan with parallel agent research before coding.","hashgraph-online\u002Fawesome-codex-plugins","hashgraph-online","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F160371962?v=4","01M6CNB6NRJVNNGN14TR01Q6D3","HOL (Hashgraph Online)","01M6JT1HSKKG9V68KQAQGBA7XP",1559,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fyagizdo\u002Fquiver\u002Fskills\u002Fplan\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[5,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41],"research","create","how","coding","parallel","work","user","implementation","task","structure","structured","feature","make","with","implementation plan","2026-11-10 10:12:30",false,"---\nname: plan\ndescription: Create a structured implementation plan with parallel agent research before coding.\nargument-hint: \"\u003Ctask description>\"\nwhen-to-use: \"user asks to make a plan, structure work, or plan a feature -- '\u002Fplan', 'make a plan', 'plan this out', 'how should I approach X'\"\n---\n\n# Gather Context\n\n```\n!`git rev-parse --is-inside-work-tree 2>\u002Fdev\u002Fnull || echo \"NO_GIT\"`\n```\n\n```\n!`git branch --show-current 2>\u002Fdev\u002Fnull || echo \"NO_GIT\"`\n```\n\n```\n!`git log --oneline -5 2>\u002Fdev\u002Fnull || echo \"NO_COMMITS\"`\n```\n\n```\n!`git branch --sort=-committerdate 2>\u002Fdev\u002Fnull || echo \"NO_GIT\"`\n```\n\n---\n\n# Instructions\n\nYou are a planning orchestrator. Your job is to clarify the task, dispatch research agents in parallel, synthesize their findings, and draft a step-by-step implementation plan. You do NOT write code -- you research, design, and document.\n\n## Step 0 -- Git Availability\n\nIf any gather-context block above returned `NO_GIT`, this directory is not a git repository.\nPrint: `> No git repository detected -- skipping branch\u002Fcommit context.`\nProceed to Step 1. Treat all git-sourced fields (branch, log, diff, status) as empty.\n\n## Step 1 -- Scope the Task\n\nIf `$ARGUMENTS` is empty and the conversation has no obvious pending task:\n> No task to plan. Usage: `\u002Fplan \u003Cdescribe the task you want to plan>`\n**Stop here.**\n\nOtherwise:\n\n1. **Restate** the task goal in one sentence.\n2. **List boundaries** -- what is in scope, what is out.\n3. **Identify the focus area.** If the task description is broad or ambiguous (e.g., \"refactor the map page\", \"improve the dashboard\"), use `AskUserQuestion` to clarify scope. Build action buttons from the relevant categories detected during initial context gathering. Always include a free-text option as the last button.\n\n   Example -- for a broad \"refactor X page\" request:\n   > What aspect of {area} should the plan focus on?\n   Buttons: `[\"UI\u002FDesign -- layout, styling, animations\", \"Architecture -- state management, code structure\", \"Performance -- loading, caching, optimization\", \"All of the above -- full overhaul\", \"Other (I'll describe)\"]`\n\n   Example -- for an ambiguous \"add auth\" request:\n   > Which authentication approach should the plan target?\n   Buttons: `[\"OAuth2 (Google, GitHub)\", \"Email\u002Fpassword\", \"Magic links\", \"SSO\u002FSAML\", \"Other (I'll describe)\"]`\n\n   **Rules:** Use `AskUserQuestion` with codebase-derived buttons (never plain text). Include \"Other\" as last option. At most ONE question -- skip if task is clear.\n\n4. **Assess complexity:**\n\n| Complexity | Signals | Agents to Dispatch |\n|------------|---------|-------------------|\n| **Light** | 1-3 files, single layer, well-understood | code-navigator |\n| **Standard** | 3-10 files, 2+ layers, moderate unknowns | code-navigator + best-practices-researcher |\n| **Deep** | 10+ files, architectural impact, security\u002Fauth\u002Fpayments, unfamiliar domain | code-navigator + best-practices-researcher + architecture-strategist |\n\nIf the task is trivial (single file, obvious change), use `AskUserQuestion`:\n> This task is straightforward enough to implement directly.\nButtons: `[\"Skip plan -- implement directly\", \"Create a plan anyway\"]`\n\n5. **Detect review-fix context.** Check if the task references a review report:\n   - If `$ARGUMENTS` contains a path matching `.claude\u002Freports\u002Freview-*.md` or `review-*_*-*-*.md`, this is a **review-fix plan**.\n   - If a review report path is detected, read it and extract the findings.\n   - Check `.claude\u002Fplans\u002F` for existing plans with the same `review_source` frontmatter. Count them to determine the `review_iteration` number (first fix plan = 1, second = 2).\n   - If `review_iteration` would be 3 or higher, warn the user:\n     > This would be iteration {N} of the review-fix cycle. The maximum is 2 iterations. Consider addressing remaining findings manually or accepting them as-is.\n     Buttons: `[\"Create the plan anyway\", \"Stop -- I'll handle it manually\"]`\n   - Carry the review report path and iteration number forward to Step 5 for frontmatter generation.\n\nIf the user picks \"Skip plan\", **stop here** and implement. Otherwise continue.\n\n## Step 2 -- Agent Discovery\n\nDiscover available agents before dispatch:\n\n**Tier 1 -- Research agents (dynamic):** Scan `agents\u002Fresearch\u002F*.md`. For each `.md` file, read YAML frontmatter to extract `name` and `description`.\n\n**Tier 2 -- Review agents (selective):** Scan `agents\u002Freview\u002F*.md`. Only dispatch review agents when the complexity is Deep and the agent's description matches the task domain (e.g., architecture-strategist for structural changes, security-audit for auth\u002Fsecurity tasks).\n\n**Tier 3 -- Project and user agents:** Scan `.claude\u002Fagents\u002F*.md` and `~\u002F.claude\u002Fagents\u002F*.md`. Dispatch any whose `description` matches the task domain.\n\nAgent identifiers use `quiver:{name}` for plugin agents, bare `{name}` for project\u002Fuser agents.\n\n## Step 2.5 -- Navigation Detection\n\nBefore dispatching agents, detect navigation capabilities once.\n\n**CodeGraph:** Check if `.codegraph\u002F` exists at project root. Set `codegraph_available` to `true` or `false`. No user prompt.\n\n**LSP:** Run the LSP detection flow in `skills\u002Fcode-navigation\u002FSKILL.md` (cached preference, one probe, no prompt); it yields `lsp_available`.\n\nPass both `codegraph_available` and `lsp_available` to all agents dispatched in Step 3.\n\n### Navigation tier (use in all codebase searches from Step 4 onward)\n\nAfter agents return, the main orchestrator verifies file paths, checks symbol locations, and reads code. Use the highest available tier:\n\nWhen `codegraph_available: true`: call ToolSearch with query `\"select:mcp__codegraph__codegraph_search,mcp__codegraph__codegraph_context,mcp__codegraph__codegraph_callers,mcp__codegraph__codegraph_callees,mcp__codegraph__codegraph_impact,mcp__codegraph__codegraph_node\"` to load schemas. Then use `codegraph_search` for symbol lookups, `codegraph_callers`\u002F`codegraph_callees` for reference finding. Fall through to grep if codegraph returns insufficient results. For file discovery and text patterns: always use Grep\u002FGlob regardless.\n\nWhen `codegraph_available: false` and `lsp_available: true`: use LSP `goToDefinition`\u002F`findReferences` first, grep as fallback.\n\nWhen both unavailable: use Grep, Glob, and Read.\n\n## Step 3 -- Parallel Agent Dispatch\n\nSpawn all qualifying agents simultaneously using multiple Agent tool calls in a single response. Every agent prompt must be **self-contained** -- agents have zero memory of this conversation.\n\n**Review-fix plans: reduced dispatch.** If Step 1 detected review-fix context, the review report already identified the problems and affected files. Skip best-practices-researcher and architecture-strategist -- they add no value when the scope is \"fix these specific findings.\" Dispatch only the code-navigator agent to verify file paths and current patterns are still accurate.\n\n### code-navigator Agent (always dispatched)\n\n```\nAgent(\n  subagent_type=\"quiver:code-navigator\",\n  description=\"Map codebase for planning: {short task summary}\",\n  prompt=\"Task: {full task description from Step 1}\n\n  codegraph_available: {true|false from Step 2.5}\n  lsp_available: {true|false from Step 2.5}\n\n  Search this codebase for all files related to this task. For each file found, report:\n  1. File path\n  2. One-line description of its role\n  3. Whether it has associated test files\n\n  Also report:\n  - Current patterns used in this area (naming, structure, abstractions)\n  - Any existing utilities or helpers that could be reused\n  - Test framework and conventions observed\n\n  Focus on directories: {relevant dirs if known, otherwise 'scan broadly'}\",\n\n)\n```\n\n### best-practices-researcher (Standard + Deep)\n\n```\nAgent(\n  subagent_type=\"quiver:best-practices-researcher\",\n  description=\"Research best practices for: {short topic}\",\n  prompt=\"Task context: {full task description}\n\n  The project uses:\n  - Languages: {detected from project files}\n  - Frameworks: {detected}\n  - Key libraries: {detected}\n\n  Research current best practices specifically for: {the technical areas the task touches, e.g., 'authentication middleware in Express', 'database migration patterns in Rails'}\n\n  Focus on:\n  1. Recommended patterns for this type of work\n  2. Any deprecations or breaking changes in the detected stack versions\n  3. Common pitfalls to avoid\n  4. Framework-specific conventions that apply\n\n  Keep findings actionable -- each recommendation should be something that can inform a plan step.\",\n\n)\n```\n\n### architecture-strategist (Deep only)\n\n```\nAgent(\n  subagent_type=\"quiver:architecture-strategist\",\n  description=\"Analyze architecture for: {short task summary}\",\n  prompt=\"Task context: {full task description}\n\n  Project root listing:\n  {ls output of project root}\n\n  Analyze the existing architecture and assess how this planned change should integrate. Report:\n  1. Current architectural patterns (layer boundaries, dependency direction, module organization)\n  2. Where new code should live to follow existing conventions\n  3. Boundary constraints -- which layers must not be violated\n  4. Structural risks of the proposed change\n  5. Dependency implications\n\n  Do NOT review existing code quality. Focus strictly on where and how the new work fits the architecture.\",\n\n)\n```\n\n### Domain-specific agents (when discovered and relevant)\n\nIf agent discovery found project\u002Fuser agents whose description matches the task domain, dispatch them with the same self-contained prompt pattern.\n\n**No fallback polling.** After dispatching agents, wait for the harness's completion notification before moving to Step 4 -- never call `ScheduleWakeup` as a hedge against a missed notification. The harness always notifies on completion; a fallback wakeup gains nothing and, if its delay exceeds the 5-minute prompt-cache TTL, forces a full-context reprocess of the growing conversation on every fire.\n\n## Step 4 -- Synthesize Research\n\nAfter **all** agents return, merge findings into a unified research brief. Use the navigation tier from Step 2.5 for any codebase verification -- symbol lookups via codegraph when available, grep as fallback.\n\n1. **Deduplicate** -- If multiple agents report the same file or pattern, keep the most detailed version.\n2. **Organize:**\n   - **Codebase context** (from code-navigator): affected files, current patterns, test coverage\n   - **Best practices** (from best-practices-researcher): recommended approaches, deprecation alerts\n   - **Architectural guidance** (from architecture-strategist): structural constraints, where new code belongs\n3. **Flag conflicts** -- If agents disagree (e.g., best practices suggest pattern A but existing architecture uses pattern B), surface both with trade-offs. Do not silently resolve.\n\n## Step 4.5 -- Derive Global Constraints\n\nDerive the rules that bind every task in this plan before any task is written. Constraints shape tasks, so a task drafted before them is a task that has to be rewritten once they appear.\n\n**Candidate sources, in priority order:**\n\n1. **The user's own words in `$ARGUMENTS`** -- \"without adding dependencies\", \"do not touch the hook\".\n2. **`architecture-strategist` boundary findings** from Step 3 -- structural lines the change must not cross.\n3. **`best-practices-researcher` deprecation findings** from Step 3 -- \"do not use X, it is removed in v5\".\n4. **The brainstorm spec's \"Out of scope\" section**, when the plan has a `spec_source` -- read the spec and treat each out-of-scope item as a candidate.\n5. **`CLAUDE.md` and `.claude\u002Frules\u002F*.md` invariants** that apply to the files in the File Map.\n\n**Relevance filter.** A candidate becomes a constraint only if a task in this plan could plausibly violate it. \"Use HTTPS for all requests\" in a plan that touches no network code is noise, and noise in an attention lens is worse than an empty lens -- it dilutes the constraints that matter. Drop every candidate that fails this test before the approval gate; never show it to the user.\n\n**Approval gate.** Present the surviving candidates in a single `AskUserQuestion` call:\n\n- **question:** \"Which of these should bind every task in this plan?\"\n- **header:** \"Constraints\"\n- **multiSelect:** true\n- **options:** one per surviving candidate -- `label` carries the constraint text, `description` names its source (\"from architecture-strategist\", \"from CLAUDE.md\", \"from your request\"). Add a free-text option last so the user can supply a constraint the derivation missed.\n\nOnly selected candidates are written into the plan. Zero selected is valid -- the plan then carries no Global Constraints section at all, and every downstream consumer behaves exactly as it does for a plan that never had one. If the relevance filter leaves no candidates, skip the gate and proceed to Step 5 with no section.\n\n## Step 5 -- Design the Plan\n\nUsing the synthesized research, draft the plan following this document structure and detail level rules:\n\n| Level | Complexity | Sections |\n|-------|-----------|----------|\n| **Brief** | Light | Goal, Global Constraints, Steps, Acceptance Criteria |\n| **Standard** | Standard | + Context (with agent findings), Risks, File Map |\n| **Comprehensive** | Deep | + Alternatives Considered, Phased Rollout, Rollback Strategy, Architectural Constraints |\n\n**Global Constraints section (from Step 4.5):**\nWrite this section only when Step 4.5 produced at least one approved constraint. It is on the Brief row, so all three detail levels carry it.\n- The section sits after the Goal and before Context, and before Steps at Brief level, which has no Context section.\n- It opens with the fixed sentence: \"Rules that bind every task in this plan. A change that cannot be made without violating one of these is a blocker, not a judgment call.\"\n- Each constraint is one imperative sentence in a numbered list.\n- Three to seven constraints is the working range. More than seven means the list has stopped being a set of constraints and become a style guide -- keep only the ones a task in this plan could plausibly violate.\n\nWorked example:\n\n```markdown\n## Global Constraints\n\nRules that bind every task in this plan. A change that cannot be made without\nviolating one of these is a blocker, not a judgment call.\n\n1. No new runtime dependencies -- solve with the standard library or an\n   already-installed package.\n2. Every shell block in a skill file exits 0, including when its target does\n   not exist.\n3. ASCII only -- no Unicode or emoji in skill files or output templates.\n4. No AI attribution in commits, PRs, or file contents.\n```\n\nWhen Step 4.5 approved no constraints, omit the section entirely -- no heading, no placeholder line.\n\n**File structure mapping (before defining tasks):**\nMap out which files will be created, modified, or deleted. This locks in decomposition decisions before task writing begins.\n- Create: `exact\u002Fpath\u002Fto\u002Fnew-file.ext` -- one-line purpose\n- Modify: `exact\u002Fpath\u002Fto\u002Fexisting.ext` -- what changes and why\n- Test: `tests\u002Fpath\u002Fto\u002Ftest-file.ext` -- which test files are new or updated\n- Delete: `exact\u002Fpath\u002Fto\u002Fremoved.ext` -- only if applicable\n\n**Task granularity:**\n- Each step: 2-10 minutes, independently verifiable\n- Pattern: what to do, which file(s), expected outcome\n- Include exact file paths from code-navigator findings\n- Incorporate best practices into step design\n- Respect architectural boundaries from architecture-strategist\n\n**Interface declarations (per task):**\n`\u002Fwork` dispatches tasks to parallel subagents in separate worktrees that cannot read each other's output, so a signature two tasks share has to be written in the plan or it does not exist.\n- The field is a `**Provides:**` line placed directly under the task's `**Files:**` line.\n- Each entry is the signature, then ` in `, then the file path it lives in. Both halves are required -- a signature with no path cannot be found, and a path with no signature is the state the field exists to fix.\n- Multiple entries go on separate lines under one `**Provides:**` label.\n- Write the line only when another task in this plan calls, imports, subclasses, or otherwise names by exact identifier what this task creates. A task whose output no other task names carries no line, and no task ever writes a `none` placeholder.\n- Write the signature in the target language's own syntax, exactly as the implementing task will write it. For a plan that changes no code, the unit is whatever another task references by name -- a section heading, a config key, a ledger line grammar, an exit code.\n- Three or fewer entries per task is the working range. A task providing more than three symbols to other tasks is a Check 4 granularity finding, not an interface finding.\n\nWorked example:\n\n```markdown\n### Task 3 -- Add the manifest parser\n\n**Files:** Create `src\u002Fmanifest.py`, Test `tests\u002Ftest_manifest.py`\n**Provides:** `parse_manifest(path: str) -> dict` in `src\u002Fmanifest.py` -- raises `ManifestError` on malformed input\n```\n\n**Test-first task ordering (when the project has tests):**\nIf the code-navigator agent found an existing test framework, order each task's steps as `skills\u002Ftdd\u002FSKILL.md` describes: the test step comes first and names the test file, the test name, the behavior it asserts, and the failure it is expected to produce; the implementation step follows it; each of the two names the run that proves it. `\u002Fplan` orders the steps and does not resolve the test command -- `\u002Fwork` decides at its Phase 2.5 resolution whether the cycle binds and reports `skipped:` with the reason when it does not.\n\nNot every task produces testable behavior (config changes, docs, migrations). Order those tasks as they are; the implementer records `skipped: no testable behavior (\u003Cwhat the change is>)` for them. Do not add a per-task label for this -- the reason travels in the implementer's line.\n\n**No placeholders rule:** Every step must have actionable content. Never write: \"TBD\"\u002F\"TODO\"\u002F\"implement later\", \"add appropriate handling\"\u002F\"handle edge cases\", \"similar to Task N\" (repeat details), \"write tests\" without scenarios, steps without file paths or expected outcomes, references to undefined symbols.\n\n**Language rule:** Always write plan documents in English, regardless of the conversation language. Only write in another language if the user explicitly requests it.\n\n**Research integration (mandatory):**\n- If best-practices-researcher flagged a deprecation, the plan must avoid the deprecated pattern\n- If architecture-strategist identified boundary constraints, steps must respect them\n- If code-navigator found existing test patterns, new test steps must follow them\n- Attribute findings in Context section: \"(from best-practices-researcher)\", \"(from architecture-strategist)\"\n\n**Review-fix plan frontmatter (when review-fix context detected in Step 1):**\n\nInclude these fields in the plan's YAML frontmatter:\n```yaml\nreview_source: .claude\u002Freports\u002Freview-YYYY-MM-DD_HH-MM-SS.md\nreview_iteration: 1  # increments for each fix plan targeting the same review\n```\n\n**Acceptance Criteria are mandatory for review-fix plans.** Derive them directly from the review findings:\n- One criterion per in-scope finding (e.g., \"ProductBackButton root widget is Material, not Positioned\")\n- Add a verification criterion (e.g., \"flutter analyze passes clean\")\n- These criteria become the Definition of Done -- the work skill uses them to determine when the review-fix cycle is COMPLETE and to prevent infinite re-review loops\n\n## Step 6 -- Plan Guard: Inline Validation\n\nAfter drafting the plan, run these 8 checks before presenting to the user. This is an internal quality gate -- do not show it as a separate section to the user.\n\n### Check 1: Placeholder scan\n\nSearch the plan for: \"TBD\", \"TODO\", \"implement later\", \"fill in details\", \"add appropriate\", \"handle edge cases\", \"similar to Task N\", raw `{...}` template text, and steps without file paths or expected outcomes. Replace every match with concrete content. (FIX)\n\n### Check 2: Naming consistency\n\nExtract all symbol names (functions, types, variables, file names) from every task. Flag any symbol appearing in 2+ tasks with different spellings. Normalize to the first-used spelling. (FIX)\n\n### Check 3: Spec coverage (bidirectional)\n\nIf the plan has a brainstorm spec reference (frontmatter `spec_source`, or a Context section referencing `.claude\u002Fspecs\u002F*.md`) or a review source (frontmatter `review_source`), read the source and verify:\n- **Forward:** each spec requirement maps to at least one plan task. Add a task for any gap. (ADD)\n- **Reverse:** each plan task maps to a spec requirement or explicit infrastructure need. Flag tasks that do not trace back. (NOTE -- potential scope creep)\n\n### Check 4: Task granularity\n\nFlag tasks that: modify more than 3 files, have more than 5 sub-steps, lack an expected outcome, or reference no file paths. (NOTE)\n\n### Check 5: Reference validity\n\nProbe file paths mentioned in the plan:\n- **Modify\u002FDelete** targets must exist on disk. (FIX if missing)\n- **Create** targets must NOT exist on disk. (NOTE if collision)\n- Internal cross-references (\"as defined in Task N\") must resolve to an actual task. (FIX if dangling)\n\n### Check 6: File map completeness\n\nIf the plan has a \"File Map\" section: every map entry must appear in at least one task, and every task file must appear in the map. (FIX for orphans, ADD for missing entries)\n\n### Check 7: Global Constraint contradiction\n\nIf the plan has no `## Global Constraints` section, this check is a no-op -- produce no finding and move on. Otherwise read every task against the constraint list and flag any task whose stated action contradicts a constraint. Rewrite the task so it satisfies the constraint, or drop the constraint when the task it contradicts is the point of the plan. (FIX)\n\n### Check 8: Interface declaration\n\nIf no symbol in the plan is named by more than one task, this check is a no-op -- produce no finding and move on. Otherwise reuse the cross-task symbol set Check 2 already extracted; this check asks a second question of that same set rather than building its own. For every symbol one task creates and another task names, verify the creating task carries a `**Provides:**` entry for it with a full signature and the file path it lives in, and add the entry when it is missing. If two tasks each declare an entry for the same symbol, keep the one in the earlier task and delete the other -- the task that creates the symbol owns its declaration. (ADD)\n\n### Action routing\n\nAfter running all 8 checks:\n- **FIX:** auto-fix by editing the plan content inline.\n- **ADD:** draft and insert missing content (tasks, acceptance criteria, file map entries).\n- **REORDER:** move affected tasks to satisfy dependency ordering.\n- **NOTE:** accumulate silently. If any NOTE findings exist, insert a `### Plan Guard Notes` subsection in the plan's Context section before the user sees the plan.\n\nAfter applying fixes, proceed to Step 6.5. No re-run of checks. The human review gate (Step 7) is the convergence anchor.\n\n## Step 6.5 -- Plan Guard: Agent Semantic Review\n\n**Skip conditions (check in order -- if any match, proceed directly to Step 7):**\n1. Complexity is **Light** (assessed in Step 1).\n2. This is a **review-fix plan** (detected in Step 1 via review report reference).\n\nIf neither skip condition matches, dispatch the plan-reviewer agent:\n\n### Agent dispatch\n\nSpawn a single `quiver:plan-reviewer` agent with a self-contained prompt containing:\n\n```\nAgent(\n  subagent_type=\"quiver:plan-reviewer\",\n  description=\"Semantic review of implementation plan\",\n  prompt=\"Review this implementation plan for logical coherence, dependency ordering,\n  coverage completeness, and spec alignment.\n\n  ## Plan\n\n  {full plan content with Step 6 fixes already applied}\n\n  ## Source Specification\n\n  {spec content if available from the plan's Context section or spec_source frontmatter,\n   otherwise: 'No source specification provided.'}\n\n  ## Project Context\n\n  {relevant directory listings for file paths mentioned in the plan}\n\n  Report findings using the action taxonomy: FIX, ADD, REORDER, NOTE.\n  If zero findings, state that explicitly.\",\n)\n```\n\n### Post-agent flow\n\n1. Parse the agent's structured findings.\n2. **Zero findings** -- proceed to Step 7.\n3. **Findings exist** -- apply edits:\n   - **FIX\u002FADD\u002FREORDER:** edit the plan content inline.\n   - **NOTE:** append to the `### Plan Guard Notes` subsection in the plan's Context section (create it if it does not exist from Step 6).\n4. Do NOT re-dispatch the agent. One pass only. Proceed to Step 7.\n\n## Step 7 -- Review Gate\n\nPresent the full plan to the user. Then call the `AskUserQuestion` tool with these parameters:\n\n- **question:** \"Plan has {N} steps ({detail_level}). How would you like to proceed?\"\n- **header:** \"Plan review\"\n- **multiSelect:** false\n- **options:**\n  1. label: \"Approve\" \u002F description: \"Looks good. Save the plan and choose next action.\"\n  2. label: \"Modify\" \u002F description: \"I want to adjust some steps before saving.\"\n  3. label: \"Reject\" \u002F description: \"Abandon this plan and take a different approach.\"\n\nIf the plan exceeds 15 steps, append to the question: \" Consider splitting into sub-plans or phasing the work.\"\n\nHandle each response:\n- **Approve** -- move to Step 8. Do NOT stop after approval.\n- **Modify** -- ask which steps to change, revise the plan, and re-present with `AskUserQuestion` again.\n- **Reject** -- abandon the plan. **Stop here.**\n\n## Step 8 -- Save and Follow-up\n\n**This step has TWO mandatory parts. Do NOT stop after saving.**\n\n**Part A -- Save the plan:**\n\n1. Create `.claude\u002Fplans\u002F` if it does not exist. Before the first write, apply the keep-local rule in `skills\u002Flocal-files\u002FSKILL.md`.\n2. Write the plan as `.claude\u002Fplans\u002FYYYY-MM-DD-\u003Cdescriptive-name>-plan.md` (use `date '+%Y-%m-%d'` for the date prefix).\n3. **Verify:** Read the file back and confirm it was written correctly.\n\n**Part B -- Present follow-up options:**\n\nImmediately after saving, call `AskUserQuestion` with these exact parameters:\n\n- **question:** \"Plan saved to `.claude\u002Fplans\u002F{filename}`. What would you like to do next?\"\n- **header:** \"Next step\"\n- **multiSelect:** false\n- **options:**\n  1. label: \"Start implementation\" \u002F description: \"Invoke the work skill and execute the plan step by step in the current context.\"\n  2. label: \"Refine plan\" \u002F description: \"Re-enter Step 5 to adjust steps, scope, or details.\"\n  3. label: \"Save and revisit later\" \u002F description: \"Stop here. The plan is saved on disk for later.\"\n\nYou MUST call the `AskUserQuestion` tool -- do not skip it, do not present follow-up options as plain text.\n\nHandle each response:\n\n- **Start implementation** -- invoke the `work` skill with the saved plan path.\n- **Refine plan** -- re-enter Step 5 to adjust.\n- **Save and revisit later** -- stop here.\n\n---\n\n## Anti-Patterns\n\nFollow all rules in `.claude\u002Frules\u002Fskill-rules.md`. Additionally:\n\n- **Don't** start writing implementation code -- this command plans only.\n- **Don't** run agents sequentially -- always dispatch independent agents in parallel (multiple Agent tool calls in one response).\n- **Don't** send vague prompts to agents -- every prompt must include the full task description, relevant file paths, and expected output format.\n- **Don't** ignore agent findings -- if an agent flags a deprecation or boundary constraint, the plan must address it.\n- **Don't** create plans for tasks the user wants done immediately -- ask first.\n","# Gather Context\n\n```\n!`git rev-parse --is-inside-work-tree 2>\u002Fdev\u002Fnull || echo \"NO_GIT\"`\n```\n\n```\n!`git branch --show-current 2>\u002Fdev\u002Fnull || echo \"NO_GIT\"`\n```\n\n```\n!`git log --oneline -5 2>\u002Fdev\u002Fnull || echo \"NO_COMMITS\"`\n```\n\n```\n!`git branch --sort=-committerdate 2>\u002Fdev\u002Fnull || echo \"NO_GIT\"`\n```\n\n---\n\n# Instructions\n\nYou are a planning orchestrator. Your job is to clarify the task, dispatch research agents in parallel, synthesize their findings, and draft a step-by-step implementation plan. You do NOT write code -- you research, design, and document.\n\n## Step 0 -- Git Availability\n\nIf any gather-context block above returned `NO_GIT`, this directory is not a git repository.\nPrint: `> No git repository detected -- skipping branch\u002Fcommit context.`\nProceed to Step 1. Treat all git-sourced fields (branch, log, diff, status) as empty.\n\n## Step 1 -- Scope the Task\n\nIf `$ARGUMENTS` is empty and the conversation has no obvious pending task:\n> No task to plan. Usage: `\u002Fplan \u003Cdescribe the task you want to plan>`\n**Stop here.**\n\nOtherwise:\n\n1. **Restate** the task goal in one sentence.\n2. **List boundaries** -- what is in scope, what is out.\n3. **Identify the focus area.** If the task description is broad or ambiguous (e.g., \"refactor the map page\", \"improve the dashboard\"), use `AskUserQuestion` to clarify scope. Build action buttons from the relevant categories detected during initial context gathering. Always include a free-text option as the last button.\n\n   Example -- for a broad \"refactor X page\" request:\n   > What aspect of {area} should the plan focus on?\n   Buttons: `[\"UI\u002FDesign -- layout, styling, animations\", \"Architecture -- state management, code structure\", \"Performance -- loading, caching, optimization\", \"All of the above -- full overhaul\", \"Other (I'll describe)\"]`\n\n   Example -- for an ambiguous \"add auth\" request:\n   > Which authentication approach should the plan target?\n   Buttons: `[\"OAuth2 (Google, GitHub)\", \"Email\u002Fpassword\", \"Magic links\", \"SSO\u002FSAML\", \"Other (I'll describe)\"]`\n\n   **Rules:** Use `AskUserQuestion` with codebase-derived buttons (never plain text). Include \"Other\" as last option. At most ONE question -- skip if task is clear.\n\n4. **Assess complexity:**\n\n| Complexity | Signals | Agents to Dispatch |\n|------------|---------|-------------------|\n| **Light** | 1-3 files, single layer, well-understood | code-navigator |\n| **Standard** | 3-10 files, 2+ layers, moderate unknowns | code-navigator + best-practices-researcher |\n| **Deep** | 10+ files, architectural impact, security\u002Fauth\u002Fpayments, unfamiliar domain | code-navigator + best-practices-researcher + architecture-strategist |\n\nIf the task is trivial (single file, obvious change), use `AskUserQuestion`:\n> This task is straightforward enough to implement directly.\nButtons: `[\"Skip plan -- implement directly\", \"Create a plan anyway\"]`\n\n5. **Detect review-fix context.** Check if the task references a review report:\n   - If `$ARGUMENTS` contains a path matching `.claude\u002Freports\u002Freview-*.md` or `review-*_*-*-*.md`, this is a **review-fix plan**.\n   - If a review report path is detected, read it and extract the findings.\n   - Check `.claude\u002Fplans\u002F` for existing plans with the same `review_source` frontmatter. Count them to determine the `review_iteration` number (first fix plan = 1, second = 2).\n   - If `review_iteration` would be 3 or higher, warn the user:\n     > This would be iteration {N} of the review-fix cycle. The maximum is 2 iterations. Consider addressing remaining findings manually or accepting them as-is.\n     Buttons: `[\"Create the plan anyway\", \"Stop -- I'll handle it manually\"]`\n   - Carry the review report path and iteration number forward to Step 5 for frontmatter generation.\n\nIf the user picks \"Skip plan\", **stop here** and implement. Otherwise continue.\n\n## Step 2 -- Agent Discovery\n\nDiscover available agents before dispatch:\n\n**Tier 1 -- Research agents (dynamic):** Scan `agents\u002Fresearch\u002F*.md`. For each `.md` file, read YAML frontmatter to extract `name` and `description`.\n\n**Tier 2 -- Review agents (selective):** Scan `agents\u002Freview\u002F*.md`. Only dispatch review agents when the complexity is Deep and the agent's description matches the task domain (e.g., architecture-strategist for structural changes, security-audit for auth\u002Fsecurity tasks).\n\n**Tier 3 -- Project and user agents:** Scan `.claude\u002Fagents\u002F*.md` and `~\u002F.claude\u002Fagents\u002F*.md`. Dispatch any whose `description` matches the task domain.\n\nAgent identifiers use `quiver:{name}` for plugin agents, bare `{name}` for project\u002Fuser agents.\n\n## Step 2.5 -- Navigation Detection\n\nBefore dispatching agents, detect navigation capabilities once.\n\n**CodeGraph:** Check if `.codegraph\u002F` exists at project root. Set `codegraph_available` to `true` or `false`. No user prompt.\n\n**LSP:** Run the LSP detection flow in `skills\u002Fcode-navigation\u002FSKILL.md` (cached preference, one probe, no prompt); it yields `lsp_available`.\n\nPass both `codegraph_available` and `lsp_available` to all agents dispatched in Step 3.\n\n### Navigation tier (use in all codebase searches from Step 4 onward)\n\nAfter agents return, the main orchestrator verifies file paths, checks symbol locations, and reads code. Use the highest available tier:\n\nWhen `codegraph_available: true`: call ToolSearch with query `\"select:mcp__codegraph__codegraph_search,mcp__codegraph__codegraph_context,mcp__codegraph__codegraph_callers,mcp__codegraph__codegraph_callees,mcp__codegraph__codegraph_impact,mcp__codegraph__codegraph_node\"` to load schemas. Then use `codegraph_search` for symbol lookups, `codegraph_callers`\u002F`codegraph_callees` for reference finding. Fall through to grep if codegraph returns insufficient results. For file discovery and text patterns: always use Grep\u002FGlob regardless.\n\nWhen `codegraph_available: false` and `lsp_available: true`: use LSP `goToDefinition`\u002F`findReferences` first, grep as fallback.\n\nWhen both unavailable: use Grep, Glob, and Read.\n\n## Step 3 -- Parallel Agent Dispatch\n\nSpawn all qualifying agents simultaneously using multiple Agent tool calls in a single response. Every agent prompt must be **self-contained** -- agents have zero memory of this conversation.\n\n**Review-fix plans: reduced dispatch.** If Step 1 detected review-fix context, the review report already identified the problems and affected files. Skip best-practices-researcher and architecture-strategist -- they add no value when the scope is \"fix these specific findings.\" Dispatch only the code-navigator agent to verify file paths and current patterns are still accurate.\n\n### code-navigator Agent (always dispatched)\n\n```\nAgent(\n  subagent_type=\"quiver:code-navigator\",\n  description=\"Map codebase for planning: {short task summary}\",\n  prompt=\"Task: {full task description from Step 1}\n\n  codegraph_available: {true|false from Step 2.5}\n  lsp_available: {true|false from Step 2.5}\n\n  Search this codebase for all files related to this task. For each file found, report:\n  1. File path\n  2. One-line description of its role\n  3. Whether it has associated test files\n\n  Also report:\n  - Current patterns used in this area (naming, structure, abstractions)\n  - Any existing utilities or helpers that could be reused\n  - Test framework and conventions observed\n\n  Focus on directories: {relevant dirs if known, otherwise 'scan broadly'}\",\n\n)\n```\n\n### best-practices-researcher (Standard + Deep)\n\n```\nAgent(\n  subagent_type=\"quiver:best-practices-researcher\",\n  description=\"Research best practices for: {short topic}\",\n  prompt=\"Task context: {full task description}\n\n  The project uses:\n  - Languages: {detected from project files}\n  - Frameworks: {detected}\n  - Key libraries: {detected}\n\n  Research current best practices specifically for: {the technical areas the task touches, e.g., 'authentication middleware in Express', 'database migration patterns in Rails'}\n\n  Focus on:\n  1. Recommended patterns for this type of work\n  2. Any deprecations or breaking changes in the detected stack versions\n  3. Common pitfalls to avoid\n  4. Framework-specific conventions that apply\n\n  Keep findings actionable -- each recommendation should be something that can inform a plan step.\",\n\n)\n```\n\n### architecture-strategist (Deep only)\n\n```\nAgent(\n  subagent_type=\"quiver:architecture-strategist\",\n  description=\"Analyze architecture for: {short task summary}\",\n  prompt=\"Task context: {full task description}\n\n  Project root listing:\n  {ls output of project root}\n\n  Analyze the existing architecture and assess how this planned change should integrate. Report:\n  1. Current architectural patterns (layer boundaries, dependency direction, module organization)\n  2. Where new code should live to follow existing conventions\n  3. Boundary constraints -- which layers must not be violated\n  4. Structural risks of the proposed change\n  5. Dependency implications\n\n  Do NOT review existing code quality. Focus strictly on where and how the new work fits the architecture.\",\n\n)\n```\n\n### Domain-specific agents (when discovered and relevant)\n\nIf agent discovery found project\u002Fuser agents whose description matches the task domain, dispatch them with the same self-contained prompt pattern.\n\n**No fallback polling.** After dispatching agents, wait for the harness's completion notification before moving to Step 4 -- never call `ScheduleWakeup` as a hedge against a missed notification. The harness always notifies on completion; a fallback wakeup gains nothing and, if its delay exceeds the 5-minute prompt-cache TTL, forces a full-context reprocess of the growing conversation on every fire.\n\n## Step 4 -- Synthesize Research\n\nAfter **all** agents return, merge findings into a unified research brief. Use the navigation tier from Step 2.5 for any codebase verification -- symbol lookups via codegraph when available, grep as fallback.\n\n1. **Deduplicate** -- If multiple agents report the same file or pattern, keep the most detailed version.\n2. **Organize:**\n   - **Codebase context** (from code-navigator): affected files, current patterns, test coverage\n   - **Best practices** (from best-practices-researcher): recommended approaches, deprecation alerts\n   - **Architectural guidance** (from architecture-strategist): structural constraints, where new code belongs\n3. **Flag conflicts** -- If agents disagree (e.g., best practices suggest pattern A but existing architecture uses pattern B), surface both with trade-offs. Do not silently resolve.\n\n## Step 4.5 -- Derive Global Constraints\n\nDerive the rules that bind every task in this plan before any task is written. Constraints shape tasks, so a task drafted before them is a task that has to be rewritten once they appear.\n\n**Candidate sources, in priority order:**\n\n1. **The user's own words in `$ARGUMENTS`** -- \"without adding dependencies\", \"do not touch the hook\".\n2. **`architecture-strategist` boundary findings** from Step 3 -- structural lines the change must not cross.\n3. **`best-practices-researcher` deprecation findings** from Step 3 -- \"do not use X, it is removed in v5\".\n4. **The brainstorm spec's \"Out of scope\" section**, when the plan has a `spec_source` -- read the spec and treat each out-of-scope item as a candidate.\n5. **`CLAUDE.md` and `.claude\u002Frules\u002F*.md` invariants** that apply to the files in the File Map.\n\n**Relevance filter.** A candidate becomes a constraint only if a task in this plan could plausibly violate it. \"Use HTTPS for all requests\" in a plan that touches no network code is noise, and noise in an attention lens is worse than an empty lens -- it dilutes the constraints that matter. Drop every candidate that fails this test before the approval gate; never show it to the user.\n\n**Approval gate.** Present the surviving candidates in a single `AskUserQuestion` call:\n\n- **question:** \"Which of these should bind every task in this plan?\"\n- **header:** \"Constraints\"\n- **multiSelect:** true\n- **options:** one per surviving candidate -- `label` carries the constraint text, `description` names its source (\"from architecture-strategist\", \"from CLAUDE.md\", \"from your request\"). Add a free-text option last so the user can supply a constraint the derivation missed.\n\nOnly selected candidates are written into the plan. Zero selected is valid -- the plan then carries no Global Constraints section at all, and every downstream consumer behaves exactly as it does for a plan that never had one. If the relevance filter leaves no candidates, skip the gate and proceed to Step 5 with no section.\n\n## Step 5 -- Design the Plan\n\nUsing the synthesized research, draft the plan following this document structure and detail level rules:\n\n| Level | Complexity | Sections |\n|-------|-----------|----------|\n| **Brief** | Light | Goal, Global Constraints, Steps, Acceptance Criteria |\n| **Standard** | Standard | + Context (with agent findings), Risks, File Map |\n| **Comprehensive** | Deep | + Alternatives Considered, Phased Rollout, Rollback Strategy, Architectural Constraints |\n\n**Global Constraints section (from Step 4.5):**\nWrite this section only when Step 4.5 produced at least one approved constraint. It is on the Brief row, so all three detail levels carry it.\n- The section sits after the Goal and before Context, and before Steps at Brief level, which has no Context section.\n- It opens with the fixed sentence: \"Rules that bind every task in this plan. A change that cannot be made without violating one of these is a blocker, not a judgment call.\"\n- Each constraint is one imperative sentence in a numbered list.\n- Three to seven constraints is the working range. More than seven means the list has stopped being a set of constraints and become a style guide -- keep only the ones a task in this plan could plausibly violate.\n\nWorked example:\n\n```markdown\n## Global Constraints\n\nRules that bind every task in this plan. A change that cannot be made without\nviolating one of these is a blocker, not a judgment call.\n\n1. No new runtime dependencies -- solve with the standard library or an\n   already-installed package.\n2. Every shell block in a skill file exits 0, including when its target does\n   not exist.\n3. ASCII only -- no Unicode or emoji in skill files or output templates.\n4. No AI attribution in commits, PRs, or file contents.\n```\n\nWhen Step 4.5 approved no constraints, omit the section entirely -- no heading, no placeholder line.\n\n**File structure mapping (before defining tasks):**\nMap out which files will be created, modified, or deleted. This locks in decomposition decisions before task writing begins.\n- Create: `exact\u002Fpath\u002Fto\u002Fnew-file.ext` -- one-line purpose\n- Modify: `exact\u002Fpath\u002Fto\u002Fexisting.ext` -- what changes and why\n- Test: `tests\u002Fpath\u002Fto\u002Ftest-file.ext` -- which test files are new or updated\n- Delete: `exact\u002Fpath\u002Fto\u002Fremoved.ext` -- only if applicable\n\n**Task granularity:**\n- Each step: 2-10 minutes, independently verifiable\n- Pattern: what to do, which file(s), expected outcome\n- Include exact file paths from code-navigator findings\n- Incorporate best practices into step design\n- Respect architectural boundaries from architecture-strategist\n\n**Interface declarations (per task):**\n`\u002Fwork` dispatches tasks to parallel subagents in separate worktrees that cannot read each other's output, so a signature two tasks share has to be written in the plan or it does not exist.\n- The field is a `**Provides:**` line placed directly under the task's `**Files:**` line.\n- Each entry is the signature, then ` in `, then the file path it lives in. Both halves are required -- a signature with no path cannot be found, and a path with no signature is the state the field exists to fix.\n- Multiple entries go on separate lines under one `**Provides:**` label.\n- Write the line only when another task in this plan calls, imports, subclasses, or otherwise names by exact identifier what this task creates. A task whose output no other task names carries no line, and no task ever writes a `none` placeholder.\n- Write the signature in the target language's own syntax, exactly as the implementing task will write it. For a plan that changes no code, the unit is whatever another task references by name -- a section heading, a config key, a ledger line grammar, an exit code.\n- Three or fewer entries per task is the working range. A task providing more than three symbols to other tasks is a Check 4 granularity finding, not an interface finding.\n\nWorked example:\n\n```markdown\n### Task 3 -- Add the manifest parser\n\n**Files:** Create `src\u002Fmanifest.py`, Test `tests\u002Ftest_manifest.py`\n**Provides:** `parse_manifest(path: str) -> dict` in `src\u002Fmanifest.py` -- raises `ManifestError` on malformed input\n```\n\n**Test-first task ordering (when the project has tests):**\nIf the code-navigator agent found an existing test framework, order each task's steps as `skills\u002Ftdd\u002FSKILL.md` describes: the test step comes first and names the test file, the test name, the behavior it asserts, and the failure it is expected to produce; the implementation step follows it; each of the two names the run that proves it. `\u002Fplan` orders the steps and does not resolve the test command -- `\u002Fwork` decides at its Phase 2.5 resolution whether the cycle binds and reports `skipped:` with the reason when it does not.\n\nNot every task produces testable behavior (config changes, docs, migrations). Order those tasks as they are; the implementer records `skipped: no testable behavior (\u003Cwhat the change is>)` for them. Do not add a per-task label for this -- the reason travels in the implementer's line.\n\n**No placeholders rule:** Every step must have actionable content. Never write: \"TBD\"\u002F\"TODO\"\u002F\"implement later\", \"add appropriate handling\"\u002F\"handle edge cases\", \"similar to Task N\" (repeat details), \"write tests\" without scenarios, steps without file paths or expected outcomes, references to undefined symbols.\n\n**Language rule:** Always write plan documents in English, regardless of the conversation language. Only write in another language if the user explicitly requests it.\n\n**Research integration (mandatory):**\n- If best-practices-researcher flagged a deprecation, the plan must avoid the deprecated pattern\n- If architecture-strategist identified boundary constraints, steps must respect them\n- If code-navigator found existing test patterns, new test steps must follow them\n- Attribute findings in Context section: \"(from best-practices-researcher)\", \"(from architecture-strategist)\"\n\n**Review-fix plan frontmatter (when review-fix context detected in Step 1):**\n\nInclude these fields in the plan's YAML frontmatter:\n```yaml\nreview_source: .claude\u002Freports\u002Freview-YYYY-MM-DD_HH-MM-SS.md\nreview_iteration: 1  # increments for each fix plan targeting the same review\n```\n\n**Acceptance Criteria are mandatory for review-fix plans.** Derive them directly from the review findings:\n- One criterion per in-scope finding (e.g., \"ProductBackButton root widget is Material, not Positioned\")\n- Add a verification criterion (e.g., \"flutter analyze passes clean\")\n- These criteria become the Definition of Done -- the work skill uses them to determine when the review-fix cycle is COMPLETE and to prevent infinite re-review loops\n\n## Step 6 -- Plan Guard: Inline Validation\n\nAfter drafting the plan, run these 8 checks before presenting to the user. This is an internal quality gate -- do not show it as a separate section to the user.\n\n### Check 1: Placeholder scan\n\nSearch the plan for: \"TBD\", \"TODO\", \"implement later\", \"fill in details\", \"add appropriate\", \"handle edge cases\", \"similar to Task N\", raw `{...}` template text, and steps without file paths or expected outcomes. Replace every match with concrete content. (FIX)\n\n### Check 2: Naming consistency\n\nExtract all symbol names (functions, types, variables, file names) from every task. Flag any symbol appearing in 2+ tasks with different spellings. Normalize to the first-used spelling. (FIX)\n\n### Check 3: Spec coverage (bidirectional)\n\nIf the plan has a brainstorm spec reference (frontmatter `spec_source`, or a Context section referencing `.claude\u002Fspecs\u002F*.md`) or a review source (frontmatter `review_source`), read the source and verify:\n- **Forward:** each spec requirement maps to at least one plan task. Add a task for any gap. (ADD)\n- **Reverse:** each plan task maps to a spec requirement or explicit infrastructure need. Flag tasks that do not trace back. (NOTE -- potential scope creep)\n\n### Check 4: Task granularity\n\nFlag tasks that: modify more than 3 files, have more than 5 sub-steps, lack an expected outcome, or reference no file paths. (NOTE)\n\n### Check 5: Reference validity\n\nProbe file paths mentioned in the plan:\n- **Modify\u002FDelete** targets must exist on disk. (FIX if missing)\n- **Create** targets must NOT exist on disk. (NOTE if collision)\n- Internal cross-references (\"as defined in Task N\") must resolve to an actual task. (FIX if dangling)\n\n### Check 6: File map completeness\n\nIf the plan has a \"File Map\" section: every map entry must appear in at least one task, and every task file must appear in the map. (FIX for orphans, ADD for missing entries)\n\n### Check 7: Global Constraint contradiction\n\nIf the plan has no `## Global Constraints` section, this check is a no-op -- produce no finding and move on. Otherwise read every task against the constraint list and flag any task whose stated action contradicts a constraint. Rewrite the task so it satisfies the constraint, or drop the constraint when the task it contradicts is the point of the plan. (FIX)\n\n### Check 8: Interface declaration\n\nIf no symbol in the plan is named by more than one task, this check is a no-op -- produce no finding and move on. Otherwise reuse the cross-task symbol set Check 2 already extracted; this check asks a second question of that same set rather than building its own. For every symbol one task creates and another task names, verify the creating task carries a `**Provides:**` entry for it with a full signature and the file path it lives in, and add the entry when it is missing. If two tasks each declare an entry for the same symbol, keep the one in the earlier task and delete the other -- the task that creates the symbol owns its declaration. (ADD)\n\n### Action routing\n\nAfter running all 8 checks:\n- **FIX:** auto-fix by editing the plan content inline.\n- **ADD:** draft and insert missing content (tasks, acceptance criteria, file map entries).\n- **REORDER:** move affected tasks to satisfy dependency ordering.\n- **NOTE:** accumulate silently. If any NOTE findings exist, insert a `### Plan Guard Notes` subsection in the plan's Context section before the user sees the plan.\n\nAfter applying fixes, proceed to Step 6.5. No re-run of checks. The human review gate (Step 7) is the convergence anchor.\n\n## Step 6.5 -- Plan Guard: Agent Semantic Review\n\n**Skip conditions (check in order -- if any match, proceed directly to Step 7):**\n1. Complexity is **Light** (assessed in Step 1).\n2. This is a **review-fix plan** (detected in Step 1 via review report reference).\n\nIf neither skip condition matches, dispatch the plan-reviewer agent:\n\n### Agent dispatch\n\nSpawn a single `quiver:plan-reviewer` agent with a self-contained prompt containing:\n\n```\nAgent(\n  subagent_type=\"quiver:plan-reviewer\",\n  description=\"Semantic review of implementation plan\",\n  prompt=\"Review this implementation plan for logical coherence, dependency ordering,\n  coverage completeness, and spec alignment.\n\n  ## Plan\n\n  {full plan content with Step 6 fixes already applied}\n\n  ## Source Specification\n\n  {spec content if available from the plan's Context section or spec_source frontmatter,\n   otherwise: 'No source specification provided.'}\n\n  ## Project Context\n\n  {relevant directory listings for file paths mentioned in the plan}\n\n  Report findings using the action taxonomy: FIX, ADD, REORDER, NOTE.\n  If zero findings, state that explicitly.\",\n)\n```\n\n### Post-agent flow\n\n1. Parse the agent's structured findings.\n2. **Zero findings** -- proceed to Step 7.\n3. **Findings exist** -- apply edits:\n   - **FIX\u002FADD\u002FREORDER:** edit the plan content inline.\n   - **NOTE:** append to the `### Plan Guard Notes` subsection in the plan's Context section (create it if it does not exist from Step 6).\n4. Do NOT re-dispatch the agent. One pass only. Proceed to Step 7.\n\n## Step 7 -- Review Gate\n\nPresent the full plan to the user. Then call the `AskUserQuestion` tool with these parameters:\n\n- **question:** \"Plan has {N} steps ({detail_level}). How would you like to proceed?\"\n- **header:** \"Plan review\"\n- **multiSelect:** false\n- **options:**\n  1. label: \"Approve\" \u002F description: \"Looks good. Save the plan and choose next action.\"\n  2. label: \"Modify\" \u002F description: \"I want to adjust some steps before saving.\"\n  3. label: \"Reject\" \u002F description: \"Abandon this plan and take a different approach.\"\n\nIf the plan exceeds 15 steps, append to the question: \" Consider splitting into sub-plans or phasing the work.\"\n\nHandle each response:\n- **Approve** -- move to Step 8. Do NOT stop after approval.\n- **Modify** -- ask which steps to change, revise the plan, and re-present with `AskUserQuestion` again.\n- **Reject** -- abandon the plan. **Stop here.**\n\n## Step 8 -- Save and Follow-up\n\n**This step has TWO mandatory parts. Do NOT stop after saving.**\n\n**Part A -- Save the plan:**\n\n1. Create `.claude\u002Fplans\u002F` if it does not exist. Before the first write, apply the keep-local rule in `skills\u002Flocal-files\u002FSKILL.md`.\n2. Write the plan as `.claude\u002Fplans\u002FYYYY-MM-DD-\u003Cdescriptive-name>-plan.md` (use `date '+%Y-%m-%d'` for the date prefix).\n3. **Verify:** Read the file back and confirm it was written correctly.\n\n**Part B -- Present follow-up options:**\n\nImmediately after saving, call `AskUserQuestion` with these exact parameters:\n\n- **question:** \"Plan saved to `.claude\u002Fplans\u002F{filename}`. What would you like to do next?\"\n- **header:** \"Next step\"\n- **multiSelect:** false\n- **options:**\n  1. label: \"Start implementation\" \u002F description: \"Invoke the work skill and execute the plan step by step in the current context.\"\n  2. label: \"Refine plan\" \u002F description: \"Re-enter Step 5 to adjust steps, scope, or details.\"\n  3. label: \"Save and revisit later\" \u002F description: \"Stop here. The plan is saved on disk for later.\"\n\nYou MUST call the `AskUserQuestion` tool -- do not skip it, do not present follow-up options as plain text.\n\nHandle each response:\n\n- **Start implementation** -- invoke the `work` skill with the saved plan path.\n- **Refine plan** -- re-enter Step 5 to adjust.\n- **Save and revisit later** -- stop here.\n\n---\n\n## Anti-Patterns\n\nFollow all rules in `.claude\u002Frules\u002Fskill-rules.md`. Additionally:\n\n- **Don't** start writing implementation code -- this command plans only.\n- **Don't** run agents sequentially -- always dispatch independent agents in parallel (multiple Agent tool calls in one response).\n- **Don't** send vague prompts to agents -- every prompt must include the full task description, relevant file paths, and expected output format.\n- **Don't** ignore agent findings -- if an agent flags a deprecation or boundary constraint, the plan must address it.\n- **Don't** create plans for tasks the user wants done immediately -- ask first.\n",{"name":5,"description":7,"when-to-use":47,"argument-hint":48},"user asks to make a plan, structure work, or plan a feature -- '\u002Fplan', 'make a plan', 'plan this out', 'how should I approach X'","\u003Ctask description>","main","2b63f856ce19c2a797929cacabd9e0fc936812fa","plugins\u002Fyagizdo\u002Fquiver\u002Fskills\u002Fplan",474,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins","https:\u002F\u002Fhol.org\u002Fplugins\u002Fbest-codex-plugins","https:\u002F\u002Fgithub.com\u002Fhashgraph-online","https:\u002F\u002Fhol.org","Open-source standards and developer tools for interoperable AI agents: discovery, identity, communication, payments, privacy and security.","2026-11-11 14:40:14",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add hashgraph-online\u002Fawesome-codex-plugins --skill plan",{"tool":65,"command":66},"bunx","bunx skills add hashgraph-online\u002Fawesome-codex-plugins --skill plan",{"tool":68,"command":69},"pnpm","pnpm dlx skills add hashgraph-online\u002Fawesome-codex-plugins --skill plan","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fyagizdo\u002Fquiver\u002Fskills\u002Fplan\u002FSKILL.md",true,[73],{"path":74,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":77,"sourceHtmlUrl":78},"TEST-PLAN.md","REFERENCE","参考文档",3336,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fyagizdo\u002Fquiver\u002Fskills\u002Fplan\u002FTEST-PLAN.md",[80,88,95,102,129,153],{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":86,"publishedAt":87},"01M746ZWACVKMZ1BJXJZHYJSSX","migrate-to-e2e","Moves an existing Playwright, Cypress, Selenium, Appium, Detox, Maestro, or TesterArmy suite to e2e one slice at a time, with the old suite running beside the new one until each ported test is proven. Keeps a MIGRATION.md progress file so any later session resumes where the last stopped. Optionally plants a defect to show both suites catch it. Use for \u002Fmigrate-to-e2e, \"migrate our tests to e2e\", \"port these Maestro flows\", \"move our TesterArmy tests\", or when a project has an e2e config and an older suite still running.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fmigrate-to-e2e\u002FSKILL.md",[],[],"2026-11-11 15:11:14",{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":87},"01M746ZPTAX1Q0FBKAB1CYND7E","e2e","Writes, runs, and debugs end-to-end tests for web and mobile apps with e2e, the agentic test runner, which mixes agent.act goals with exact locator assertions on a Playwright browser or an iOS or Android device. Also drives a project's running app live over the e2e MCP server to look at a screen, check a UI change, take a screenshot or record a video, and try a locator; and runs bug bashes, parallel e2e explore runs with each bug proven by a repro test. Use when a project depends on e2e or has an e2e.config.ts, when asked for end-to-end, browser, mobile, or agentic UI tests, to check a change in the running app, to QA or bug bash an app or branch, or when an e2e run fails.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fe2e\u002FSKILL.md",[],[],{"skillNo":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":101,"publishedAt":87},"01M746ZJN784HVHMDP9MQGCSGG","create-verification-skill","Generate a project-local verify-\u003Capp> skill on top of e2e, so any coding agent can launch the app, check it is worth driving, exercise a feature the way a user does, keep evidence, and bug bash it. Writes the skill, a feature map with one explore charter per feature, and proves it once. Use for \u002Fcreate-verification-skill, \"make a verification skill for this repo\", or when a project has no scripted way to prove UI behavior.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fcreate-verification-skill\u002FSKILL.md",[],[],{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":108,"publishedAt":42},"01M716A6ETNB9B1SQ3GXZC75VR","deja-search","deja-vu memory — search the user's past AI coding sessions with the deja CLI. Holds what they already settled and never wrote into the repo (naming rules, banned or already-tried tools, required checks before merge, preferred values, who owns what). Use before your first edit in a task, before you call a change done or ready to merge, before you recommend a tool, library, design or reviewer, before re-debugging an error that may already be solved, when they say 'didn't we fix this before', 'what did we decide about X' or 'I already have that', and before telling them something on this machine does not exist.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-search\u002FSKILL.md",[],[109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128],"search","deja search","never","error","ready","memory","re","decide","fix","design","debugging","when","you","done","reviewer","io","change","cli","merge","past",{"skillNo":130,"name":131,"nameZh":6,"description":132,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":133,"categories":134,"keywords":135,"publishedAt":42},"01M716A3J2W5SENSE9VGMXB375","deja-reflect","End-of-session reflection and memory curation with deja-vu. Review what was decided, what commands broke and what repaired them, and record durable project rules or decisions with deja remember so the next session starts with them.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-reflect\u002FSKILL.md",[],[136,137,138,124,40,139,140,141,142,143,144,145,146,147,114,148,149,150,151,152],"deja reflect","reflect","review","record","github","next","https","node","Rules","decisions","brew","remember","project rules","project","session","end","reflection",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":166,"publishedAt":42},"01M715T3RR4BAYSR57HPPTJ0PF","revid","Make, edit, export and post AI videos with Revid (revid.ai) through the Revid MCP server. Use whenever the user wants a short-form or long-form video made (from an idea, a script, a URL, an article, a PDF, a tweet, a product page, their own clips, or a song), wants to find what is going viral on TikTok, YouTube, Instagram or X before making something, wants to edit or re-export an existing Revid project, generate a standalone AI image or clip, make a series episode, or publish and schedule a finished video to connected social accounts. Covers setup (hosted MCP with OAuth, or an API key), the 36 tools, credits, polling and the rules for publishing. Routes to the more specific revid-* skills when one fits.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftmakersas\u002Frevid-skills\u002Fskills\u002Frevid\u002FSKILL.md",[159,162,163],{"categoryNo":160,"categoryName":161,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":164,"categoryName":165,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",[155,167,168,169,170,171,172,149,173,115,174,175,176,177,120,178,179,180,181,182],"URL","Video","short-form","standalone","PDF","viral","tiktok","short","social","MCP","song","image","mcp server","schedule","api","publish"]