feature-dev

You are running a structured feature-development workflow. Follow the phases in order. Do not skip or merge phases.

The feature request is $request. If it is missing or too vague to plan against (no clear goal or acceptance signal), ask the user with the AskUserQuestion tool before starting Phase 1.

Phase 1 — Gather current state with code-indexing-mcp

The core rule of this phase: the code-indexing-mcp tools are the primary navigation mechanism. Do not fall back to Grep/Glob/Read for code exploration while they are available.

1. Call mcp__code-indexing-mcp__project_status for the target project. If the project is unknown, call mcp__code-indexing-mcp__list_projects and, if needed, mcp__code-indexing-mcp__init_project.
2. If the index is missing or stale relative to the files the feature will touch, call mcp__code-indexing-mcp__index_project first. Tell the user if indexing will take a moment.
3. Explore the relevant parts of the codebase:
   • mcp__code-indexing-mcp__search_code — issue several targeted semantic queries derived from the feature request (the area being changed, the patterns it must follow, the tests that cover it). Not one broad query.
   • mcp__code-indexing-mcp__file_outline — get a file's structure before reading it; decide which parts matter instead of dumping whole files.
   • mcp__code-indexing-mcp__find_symbol — locate the declarations the feature will touch. It matches declaration names only; use find_references for call sites.
   • When changing an existing declaration, mcp__code-indexing-mcp__find_references — identify structural uses from its selected chunk_id or project/path/qualified-symbol tuple. For a rename or signature change, use mcp__code-indexing-mcp__analyze_refactor and retain its likely_change, review, and limitation findings in the plan. For an approved rename, produce the mechanical edits with mcp__code-indexing-mcp__emit_refactor_patch after reviewing the analysis — it emits a reviewable unified diff (git apply-able) for the deterministic subset only, never edits source, and reports the rest in unapplied/conflicted. Both analysis tools cover only C, C#, C++, GDScript, Godot Shader, Go, Java, JavaScript, Kotlin, Lua, Python, Rust, SQL, Swift, Terraform, TSX, TypeScript, and Zig declarations — selecting one in any other language returns UNSUPPORTED_LANGUAGE, not an empty result, so fall back to search_code/grep for that part of the codebase instead of treating silence as "no usages". Check completeness.state (complete, complete_with_dynamic_limitations, or incomplete) and the limitations list before trusting a finding set as exhaustive.
   • mcp__code-indexing-mcp__get_chunk — pull the full body of a chunk when you need exact code.
4. Only use Grep when the task genuinely needs a literal match semantic search cannot express (exact string literals, config keys, TODO/FIXME markers) or when the MCP tools are unavailable — and say so when you do.

End the phase with a short current-state summary for the user: the modules/files involved, existing patterns and conventions the feature must follow, extension points, and how that area is tested.