noname-shuying/AGENTS.md

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.