mirror of
https://github.com/Shu-Ying/noname-shuying.git
synced 2026-10-30 19:50:04 +08:00
66 lines
4.5 KiB
Markdown
66 lines
4.5 KiB
Markdown
<comet-ambient-resume>
|
|
<!-- Managed by Comet. Edits inside this block may be replaced by comet init/update. -->
|
|
<!-- Contract: comet.resume_probe.v2 -->
|
|
|
|
## 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.
|
|
</comet-ambient-resume>
|
|
|
|
<!-- code-review-graph MCP tools -->
|
|
## 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.
|
|
<!-- /code-review-graph MCP tools -->
|