diff --git a/.agents/skills/debug-issue/skill.md b/.agents/skills/debug-issue/skill.md deleted file mode 100644 index ef1b38a..0000000 --- a/.agents/skills/debug-issue/skill.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -name: Debug Issue -description: Systematically debug issues using graph-powered code navigation ---- - -## Debug Issue - -Use the knowledge graph to systematically trace and debug issues. - -### Steps - -1. Use `semantic_search_nodes` to find code related to the issue. -2. Use `query_graph` with `callers_of` and `callees_of` to trace call chains. -3. Use `get_flow` to see full execution paths through suspected areas. -4. Run `detect_changes` to check if recent changes caused the issue. -5. Use `get_impact_radius` on suspected files to see what else is affected. - -### Tips - -- Check both callers and callees to understand the full context. -- Look at affected flows to find the entry point that triggers the bug. -- Recent changes are the most common source of new issues. - -## Token Efficiency Rules -- ALWAYS start with `get_minimal_context(task="")` before any other graph tool. -- Use `detail_level="minimal"` on all calls. Only escalate to "standard" when minimal is insufficient. -- Target: complete any review/debug/refactor task in ≤5 tool calls and ≤800 total output tokens. diff --git a/.agents/skills/explore-codebase/skill.md b/.agents/skills/explore-codebase/skill.md deleted file mode 100644 index dc7ad10..0000000 --- a/.agents/skills/explore-codebase/skill.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -name: Explore Codebase -description: Navigate and understand codebase structure using the knowledge graph ---- - -## Explore Codebase - -Use the code-review-graph MCP tools to explore and understand the codebase. - -### Steps - -1. Run `list_graph_stats` to see overall codebase metrics. -2. Run `get_architecture_overview` for high-level community structure. -3. Use `list_communities` to find major modules, then `get_community` for details. -4. Use `semantic_search_nodes` to find specific functions or classes. -5. Use `query_graph` with patterns like `callers_of`, `callees_of`, `imports_of` to trace relationships. -6. Use `list_flows` and `get_flow` to understand execution paths. - -### Tips - -- Start broad (stats, architecture) then narrow down to specific areas. -- Use `children_of` on a file to see all its functions and classes. -- Use `find_large_functions` to identify complex code. - -## Token Efficiency Rules -- ALWAYS start with `get_minimal_context(task="")` before any other graph tool. -- Use `detail_level="minimal"` on all calls. Only escalate to "standard" when minimal is insufficient. -- Target: complete any review/debug/refactor task in ≤5 tool calls and ≤800 total output tokens. diff --git a/.agents/skills/refactor-safely/skill.md b/.agents/skills/refactor-safely/skill.md deleted file mode 100644 index cf84420..0000000 --- a/.agents/skills/refactor-safely/skill.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -name: Refactor Safely -description: Plan and execute safe refactoring using dependency analysis ---- - -## Refactor Safely - -Use the knowledge graph to plan and execute refactoring with confidence. - -### Steps - -1. Use `refactor_tool` with mode="suggest" for community-driven refactoring suggestions. -2. Use `refactor_tool` with mode="dead_code" to find unreferenced code. -3. For renames, use `refactor_tool` with mode="rename" to preview all affected locations. -4. Use `apply_refactor_tool` with the refactor_id to apply renames. -5. After changes, run `detect_changes` to verify the refactoring impact. - -### Safety Checks - -- Always preview before applying (rename mode gives you an edit list). -- Check `get_impact_radius` before major refactors. -- Use `get_affected_flows` to ensure no critical paths are broken. -- Run `find_large_functions` to identify decomposition targets. - -## Token Efficiency Rules -- ALWAYS start with `get_minimal_context(task="")` before any other graph tool. -- Use `detail_level="minimal"` on all calls. Only escalate to "standard" when minimal is insufficient. -- Target: complete any review/debug/refactor task in ≤5 tool calls and ≤800 total output tokens. diff --git a/.agents/skills/review-changes/skill.md b/.agents/skills/review-changes/skill.md deleted file mode 100644 index 6bb3558..0000000 --- a/.agents/skills/review-changes/skill.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -name: Review Changes -description: Perform a structured code review using change detection and impact ---- - -## Review Changes - -Perform a thorough, risk-aware code review using the knowledge graph. - -### Steps - -1. Run `detect_changes` to get risk-scored change analysis. -2. Run `get_affected_flows` to find impacted execution paths. -3. For each high-risk function, run `query_graph` with pattern="tests_for" to check test coverage. -4. Run `get_impact_radius` to understand the blast radius. -5. For any untested changes, suggest specific test cases. - -### Output Format - -Provide findings grouped by risk level (high/medium/low) with: -- What changed and why it matters -- Test coverage status -- Suggested improvements -- Overall merge recommendation - -## Token Efficiency Rules -- ALWAYS start with `get_minimal_context(task="")` before any other graph tool. -- Use `detail_level="minimal"` on all calls. Only escalate to "standard" when minimal is insufficient. -- Target: complete any review/debug/refactor task in ≤5 tool calls and ≤800 total output tokens. diff --git a/AGENTS.md b/AGENTS.md deleted file mode 100644 index d3dc9b4..0000000 --- a/AGENTS.md +++ /dev/null @@ -1,38 +0,0 @@ - -## MCP Tools: code-review-graph - -**IMPORTANT: This project has a knowledge graph. ALWAYS use the -code-review-graph MCP tools BEFORE using Grep/Glob/Read to explore -the codebase.** The graph is faster, cheaper (fewer tokens), and gives -you structural context (callers, dependents, test coverage) that file -scanning cannot. - -### When to use graph tools FIRST - -- **Exploring code**: `semantic_search_nodes` or `query_graph` instead of Grep -- **Understanding impact**: `get_impact_radius` instead of manually tracing imports -- **Code review**: `detect_changes` + `get_review_context` instead of reading entire files -- **Finding relationships**: `query_graph` with callers_of/callees_of/imports_of/tests_for -- **Architecture questions**: `get_architecture_overview` + `list_communities` - -Fall back to Grep/Glob/Read **only** when the graph doesn't cover what you need. - -### Key Tools - -| Tool | Use when | -| ------ | ---------- | -| `detect_changes` | Reviewing code changes — gives risk-scored analysis | -| `get_review_context` | Need source snippets for review — token-efficient | -| `get_impact_radius` | Understanding blast radius of a change | -| `get_affected_flows` | Finding which execution paths are impacted | -| `query_graph` | Tracing callers, callees, imports, tests, dependencies | -| `semantic_search_nodes` | Finding functions/classes by name or keyword | -| `get_architecture_overview` | Understanding high-level codebase structure | -| `refactor_tool` | Planning renames, finding dead code | - -### Workflow - -1. The graph auto-updates on file changes (via hooks). -2. Use `detect_changes` for code review. -3. Use `get_affected_flows` to understand impact. -4. Use `query_graph` pattern="tests_for" to check coverage.