feature-reconworkflow★0
amar3012005/HIVEMIND ↗What it does
Determine if feature exists or needs build
Best for
BEFORE building any feature/module; avoids reimplementing existing code or merging dead branches
Inputs
- · feature description (natural language string or JSON args)
- · graph MCP queries (semantic_search_nodes, callers_of, tests_for)
- · git history (log --grep, pickaxe, branch scans)
- · HIVEMIND memory (prior decisions, gotchas)
Outputs
- · verdict block: {status: exists|partial|missing, evidence, wired, reuse_or_gap}
- · lane findings per recon approach (graph, git, memory)
- · exact delta to build OR symbols to reuse/extend
Requires
- · agent (3 parallel lanes: graph, git, memory)
- · code-review-graph MCP (semantic_search_nodes, callers_of, get_architecture_overview)
- · git commands (log --grep, pickaxe)
- · HIVEMIND MCP (recall, recall_bugs)
Preconditions
- · code-review-graph MCP populated (codebase indexed)
- · HIVEMIND MCP available for prior decisions
- · git history accessible
Failure modes
- · graph/memory gives false negatives (feature exists but not found)
- · git history misses branch-only implementations
- · ambiguous feature description (multiple interpretations)
- · reuse opportunity missed due to naming drift
Trust signals
- · 3-lane parallel recon: graph, git, memory (catches different artifact types)
- · Graph lane checks wired vs dead (callers_of tests)
- · Git lane finds reverted/branch-only implementations
- · Memory lane surfaces prior gotchas and decisions
- · Final verdict synthesizes lanes with evidence + confidence