## Comet Ambient Resume In this repository, before starting work that may need code changes or investigation, pass the current user request to the read-only probe when a Comet workflow may already be active: `comet resume-probe . --stdin --json`. - If the user explicitly invokes any Comet Skill through the host (for example, `@comet`, `/comet`, `@comet-native`, or `/comet-hotfix`), that explicit invocation takes precedence over this resume protocol; do not run the resume probe, and enter the invoked Skill directly. - If the user explicitly invokes a non-Comet skill or slash command through the host, the task intent is already explicit in that invocation: do not run the resume probe, and execute the invoked skill directly. - If you are already inside a Comet flow (including while waiting for the user to answer a question you asked in that flow), do not run the resume probe; treat replies such as option picks as continuation of the current change and proceed directly with the chosen option. - Trust only the returned `workflow`, `skill`, and `entrySource`; project configuration or the no-config compatibility fallback alone selects them. Do not scan or switch to the other workflow. - If the probe returns `auto_resume`, briefly state the selected active change and enter the permanent entry in `nextCommand`. Do not treat a state command as the resume entry or advance it blindly. - If the probe returns `ask_user`, ask one short question and wait. - If the current request did not explicitly invoke a Comet Skill and the probe returns `out_of_scope` or `none`, do not enter the Comet workflow. - An `out_of_scope` or `none` result only means do not enter the Comet workflow for this new request; it never pauses or exits a Comet flow that is already in progress. - If configuration or state is invalid and `nextCommand` is absent, stop and report the reason; do not guess another workflow. - Never attach unrelated work merely because an active change exists. The Native entry inspects uncommitted work; the probe does not attribute it automatically. ## MCP Tools: code-review-graph **This project has a knowledge graph. Start with the code-review-graph MCP tools to narrow scope, then read the source.** The graph is cheaper than scanning files and gives you structural context (callers, dependents, test coverage) that file search cannot. ### When to use graph tools FIRST - **Exploring code**: `semantic_search_nodes_tool` or `query_graph_tool` instead of Grep - **Understanding impact**: `get_impact_radius_tool` instead of manually tracing imports - **Code review**: `detect_changes_tool` + `get_review_context_tool` instead of reading entire files - **Finding relationships**: `query_graph_tool` with callers_of/callees_of/imports_of/tests_for - **Architecture questions**: `get_architecture_overview_tool` + `list_communities_tool` ### Verify in the source - Narrow scope with the graph, then read the source. Do not change code from graph output alone. - For any non-trivial change, read the implementation and the relevant tests before concluding. - Verify the exact source when touching behavior, database logic, migrations, retries, fallbacks, recovery, or compatibility code. - When the graph and the source disagree, the source wins. The graph may be stale or may not model that relationship. - An empty graph result can mean "not indexed" or "not statically visible", not "does not exist". ### Key Tools | Tool | Use when | | ------ | ---------- | | `detect_changes_tool` | Reviewing code changes — gives risk-scored analysis | | `get_review_context_tool` | Need source snippets for review — token-efficient | | `get_impact_radius_tool` | Understanding blast radius of a change | | `get_affected_flows_tool` | Finding which execution paths are impacted | | `query_graph_tool` | Tracing callers, callees, imports, tests, dependencies | | `semantic_search_nodes_tool` | Finding functions/classes by name or keyword | | `get_architecture_overview_tool` | 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_tool` for code review. 3. Use `get_affected_flows_tool` to understand impact. 4. Use `query_graph_tool` pattern="tests_for" to check coverage.