Adding Graphify support

README.md

@@ -14,6 +14,7 @@ Supported agents: **Claude Code**, **Augment**, **Codex**, **Junie**, **Roo Code
 - **Deferred critical comments**: Classifies critical or larger-scope comments (security gaps, missing features, cross-file refactors) and handles them after all normal comments are done. For each deferred item you pick the workflow: SDD, Brainstorming, plan mode, just-do-it, or skip.
 - **Reply/Resolve preference**: One prompt per project decides whether the skill may post replies and resolve threads on your behalf (`a` post & resolve / `b` post only / `c` none). Applied uniformly across normal, deferred, and no-code-change paths.
 - **Configurable verification**: Runs project-defined lint, test, and analysis commands from `CLAUDE.md` (or `AGENTS.md` as fallback).
+- **Graphify-aware**: If a `graphify` skill is available in the running agent, the skill is required to use it for understanding code, mapping cross-file relationships, and design decisions (Step 0). If Graphify is absent, the skill proceeds normally.
 - **Language-agnostic**: Works with any programming language or framework.
 
 ## Supported Platforms
@@ -27,6 +28,14 @@ Supported agents: **Claude Code**, **Augment**, **Codex**, **Junie**, **Roo Code
 
 For platforms with two paths the skill prompts on first use. The choice is persisted in project memory and skipped on subsequent runs.
 
+## Architecture
+
+A single source (`core/` + `adapters/<agent>/`) is compiled into per-agent variants
+(`skills/`, `dist/`, `plugins/`) by `scripts/build.sh`. Generated artifacts are committed
+automatically after merge by the release workflow. For the full picture — source vs.
+generated files, per-agent `plugin.json` differences, the build, and the CI/CD release
+flow — see [docs/ARCHITECTURE.md](docs/ARCHITECTURE.md).
+
 ## Installation
 
 ### Claude Code

adapters/augment/snippets/graphify-availability.md

@@ -0,0 +1 @@
+These harnesses do not expose a skills registry. Treat Graphify as available only if the project clearly ships it (e.g. a `graphify` skill/command file under the project's skills directory or an entry in the agent config). If you cannot positively confirm it, treat Graphify as unavailable and proceed without it.

adapters/claude/snippets/graphify-availability.md

@@ -0,0 +1 @@
+Check the list of available skills surfaced by the harness for a `graphify` skill (it may appear as `graphify` or a plugin-namespaced `<plugin>:graphify`). If present, Graphify is available; invoke it via the Skill tool when required below.

adapters/codex/snippets/graphify-availability.md

@@ -0,0 +1 @@
+These harnesses do not expose a skills registry. Treat Graphify as available only if the project clearly ships it (e.g. a `graphify` skill/command file under the project's skills directory or an entry in the agent config). If you cannot positively confirm it, treat Graphify as unavailable and proceed without it.

adapters/junie/snippets/graphify-availability.md

@@ -0,0 +1 @@
+These harnesses do not expose a skills registry. Treat Graphify as available only if the project clearly ships it (e.g. a `graphify` skill/command file under the project's skills directory or an entry in the agent config). If you cannot positively confirm it, treat Graphify as unavailable and proceed without it.

adapters/roo/snippets/graphify-availability.md

@@ -0,0 +1 @@
+These harnesses do not expose a skills registry. Treat Graphify as available only if the project clearly ships it (e.g. a `graphify` skill/command file under the project's skills directory or an entry in the agent config). If you cannot positively confirm it, treat Graphify as unavailable and proceed without it.

core/kernel.md

@@ -1,3 +1,19 @@
+## Step 0: Graphify Availability (mandatory if present)
+
+Before anything else, check whether the **Graphify** skill is available in the running agent for this project.
+
+<!-- ADAPTER: graphify-availability -->
+
+If Graphify **is** available, using it is **mandatory** for this run. Wherever a later step requires understanding code, mapping relationships across files, or making a design decision, you MUST first run Graphify on the relevant input (the affected file(s), the PR/MR diff, or the surrounding module) and use the resulting knowledge graph to inform your work. This applies in particular to:
+
+- **Step 4** — understanding each comment in the context of the surrounding code.
+- **Step 4b** — every deferred item: build the graph for the item's scope before choosing and executing a design route.
+- **Step 6** — self-review: graph the diff to check cross-file impact.
+
+If Graphify is **not** available, proceed normally — do not block on it.
+
+Record availability as a transient session fact — do NOT persist it; skill availability can change between sessions.
+
 ## Step 1: Platform Detection & CLI Verification
 
 ### 1.1 Check Memory
@@ -137,7 +153,7 @@ When a comment is unclear, ask **one** short clarifying question. Before asking,
 Then work through each task sequentially:
 
 1. **Read the affected file** at the referenced location
-2. **Understand the comment** in the context of the surrounding code
+2. **Understand the comment** in the context of the surrounding code (if Graphify is available per Step 0, graph the affected file(s) first and use the result to understand the surrounding code)
 3. If the comment is marked `(outdated)`, check whether the feedback is still relevant before acting
 4. **If unclear**: Ask the user what exactly is expected. <!-- ADAPTER: ask-user -->
 5. **Implement the change** according to the reviewer's feedback
@@ -156,6 +172,8 @@ Otherwise announce: "Now handling N deferred items." Process items strictly in t
 
 For each deferred item:
 
+0. If Graphify is available (Step 0), build the knowledge graph for this item's scope first and use it to inform the route choice and execution below.
+
 1. Detect which design skills are visible to the running agent:
 
    <!-- ADAPTER: skill-availability -->
@@ -209,6 +227,8 @@ Review all changes made:
 git diff
 ```
 
+If Graphify is available (Step 0), graph the diff and use the result to check cross-file impact and relationships before the checks below.
+
 Check for:
 
 ### Reusability

dist/augment/skills/resolve-comments/SKILL.md

@@ -9,6 +9,22 @@ Work through all unresolved review comments from a pull request or merge request
 
 > This skill activates implicitly when its description matches your request. You can also reference it explicitly by name.
 
+## Step 0: Graphify Availability (mandatory if present)
+
+Before anything else, check whether the **Graphify** skill is available in the running agent for this project.
+
+These harnesses do not expose a skills registry. Treat Graphify as available only if the project clearly ships it (e.g. a `graphify` skill/command file under the project's skills directory or an entry in the agent config). If you cannot positively confirm it, treat Graphify as unavailable and proceed without it.
+
+If Graphify **is** available, using it is **mandatory** for this run. Wherever a later step requires understanding code, mapping relationships across files, or making a design decision, you MUST first run Graphify on the relevant input (the affected file(s), the PR/MR diff, or the surrounding module) and use the resulting knowledge graph to inform your work. This applies in particular to:
+
+- **Step 4** — understanding each comment in the context of the surrounding code.
+- **Step 4b** — every deferred item: build the graph for the item's scope before choosing and executing a design route.
+- **Step 6** — self-review: graph the diff to check cross-file impact.
+
+If Graphify is **not** available, proceed normally — do not block on it.
+
+Record availability as a transient session fact — do NOT persist it; skill availability can change between sessions.
+
 ## Step 1: Platform Detection & CLI Verification
 
 ### 1.1 Check Memory
@@ -190,7 +206,7 @@ When a comment is unclear, ask **one** short clarifying question. Before asking,
 Then work through each task sequentially:
 
 1. **Read the affected file** at the referenced location
-2. **Understand the comment** in the context of the surrounding code
+2. **Understand the comment** in the context of the surrounding code (if Graphify is available per Step 0, graph the affected file(s) first and use the result to understand the surrounding code)
 3. If the comment is marked `(outdated)`, check whether the feedback is still relevant before acting
 4. **If unclear**: Ask the user what exactly is expected. Ask the user directly in chat with the listed options.
 5. **Implement the change** according to the reviewer's feedback
@@ -209,6 +225,8 @@ Otherwise announce: "Now handling N deferred items." Process items strictly in t
 
 For each deferred item:
 
+0. If Graphify is available (Step 0), build the knowledge graph for this item's scope first and use it to inform the route choice and execution below.
+
 1. Detect which design skills are visible to the running agent:
 
    These harnesses do not currently expose a skills registry; assume `[s]` and `[b]` are unavailable. Show them marked unavailable; allow the user to type a path to a local skill file if they want to invoke one manually. Record this as a transient session fact — do NOT persist it.
@@ -262,6 +280,8 @@ Review all changes made:
 git diff
 ```
 
+If Graphify is available (Step 0), graph the diff and use the result to check cross-file impact and relationships before the checks below.
+
 Check for:
 
 ### Reusability

dist/codex/skills/resolve-comments/SKILL.md

@@ -9,6 +9,22 @@ Work through all unresolved review comments from a pull request or merge request
 
 > Invoke this skill via `$resolve-comments` or the `/skills` command. This skill is stateless: platform detection runs on every invocation.
 
+## Step 0: Graphify Availability (mandatory if present)
+
+Before anything else, check whether the **Graphify** skill is available in the running agent for this project.
+
+These harnesses do not expose a skills registry. Treat Graphify as available only if the project clearly ships it (e.g. a `graphify` skill/command file under the project's skills directory or an entry in the agent config). If you cannot positively confirm it, treat Graphify as unavailable and proceed without it.
+
+If Graphify **is** available, using it is **mandatory** for this run. Wherever a later step requires understanding code, mapping relationships across files, or making a design decision, you MUST first run Graphify on the relevant input (the affected file(s), the PR/MR diff, or the surrounding module) and use the resulting knowledge graph to inform your work. This applies in particular to:
+
+- **Step 4** — understanding each comment in the context of the surrounding code.
+- **Step 4b** — every deferred item: build the graph for the item's scope before choosing and executing a design route.
+- **Step 6** — self-review: graph the diff to check cross-file impact.
+
+If Graphify is **not** available, proceed normally — do not block on it.
+
+Record availability as a transient session fact — do NOT persist it; skill availability can change between sessions.
+
 ## Step 1: Platform Detection & CLI Verification
 
 ### 1.1 Check Memory
@@ -175,7 +191,7 @@ When a comment is unclear, ask **one** short clarifying question. Before asking,
 Then work through each task sequentially:
 
 1. **Read the affected file** at the referenced location
-2. **Understand the comment** in the context of the surrounding code
+2. **Understand the comment** in the context of the surrounding code (if Graphify is available per Step 0, graph the affected file(s) first and use the result to understand the surrounding code)
 3. If the comment is marked `(outdated)`, check whether the feedback is still relevant before acting
 4. **If unclear**: Ask the user what exactly is expected. Ask the user directly in chat with the listed options.
 5. **Implement the change** according to the reviewer's feedback
@@ -194,6 +210,8 @@ Otherwise announce: "Now handling N deferred items." Process items strictly in t
 
 For each deferred item:
 
+0. If Graphify is available (Step 0), build the knowledge graph for this item's scope first and use it to inform the route choice and execution below.
+
 1. Detect which design skills are visible to the running agent:
 
    These harnesses do not currently expose a skills registry; assume `[s]` and `[b]` are unavailable. Show them marked unavailable; allow the user to type a path to a local skill file if they want to invoke one manually. Record this as a transient session fact — do NOT persist it.
@@ -247,6 +265,8 @@ Review all changes made:
 git diff
 ```
 
+If Graphify is available (Step 0), graph the diff and use the result to check cross-file impact and relationships before the checks below.
+
 Check for:
 
 ### Reusability

dist/junie/.junie/skills/resolve-comments/SKILL.md

@@ -9,6 +9,22 @@ Work through all unresolved review comments from a pull request or merge request
 
 > Junie activates this skill when its description matches your task.
 
+## Step 0: Graphify Availability (mandatory if present)
+
+Before anything else, check whether the **Graphify** skill is available in the running agent for this project.
+
+These harnesses do not expose a skills registry. Treat Graphify as available only if the project clearly ships it (e.g. a `graphify` skill/command file under the project's skills directory or an entry in the agent config). If you cannot positively confirm it, treat Graphify as unavailable and proceed without it.
+
+If Graphify **is** available, using it is **mandatory** for this run. Wherever a later step requires understanding code, mapping relationships across files, or making a design decision, you MUST first run Graphify on the relevant input (the affected file(s), the PR/MR diff, or the surrounding module) and use the resulting knowledge graph to inform your work. This applies in particular to:
+
+- **Step 4** — understanding each comment in the context of the surrounding code.
+- **Step 4b** — every deferred item: build the graph for the item's scope before choosing and executing a design route.
+- **Step 6** — self-review: graph the diff to check cross-file impact.
+
+If Graphify is **not** available, proceed normally — do not block on it.
+
+Record availability as a transient session fact — do NOT persist it; skill availability can change between sessions.
+
 ## Step 1: Platform Detection & CLI Verification
 
 ### 1.1 Check Memory
@@ -190,7 +206,7 @@ When a comment is unclear, ask **one** short clarifying question. Before asking,
 Then work through each task sequentially:
 
 1. **Read the affected file** at the referenced location
-2. **Understand the comment** in the context of the surrounding code
+2. **Understand the comment** in the context of the surrounding code (if Graphify is available per Step 0, graph the affected file(s) first and use the result to understand the surrounding code)
 3. If the comment is marked `(outdated)`, check whether the feedback is still relevant before acting
 4. **If unclear**: Ask the user what exactly is expected. Ask the user directly in chat with the listed options.
 5. **Implement the change** according to the reviewer's feedback
@@ -209,6 +225,8 @@ Otherwise announce: "Now handling N deferred items." Process items strictly in t
 
 For each deferred item:
 
+0. If Graphify is available (Step 0), build the knowledge graph for this item's scope first and use it to inform the route choice and execution below.
+
 1. Detect which design skills are visible to the running agent:
 
    These harnesses do not currently expose a skills registry; assume `[s]` and `[b]` are unavailable. Show them marked unavailable; allow the user to type a path to a local skill file if they want to invoke one manually. Record this as a transient session fact — do NOT persist it.
@@ -262,6 +280,8 @@ Review all changes made:
 git diff
 ```
 
+If Graphify is available (Step 0), graph the diff and use the result to check cross-file impact and relationships before the checks below.
+
 Check for:
 
 ### Reusability

dist/roo/.roo/skills/resolve-comments/SKILL.md

@@ -9,6 +9,22 @@ Work through all unresolved review comments from a pull request or merge request
 
 > Roo loads this skill on demand when your request matches the description above.
 
+## Step 0: Graphify Availability (mandatory if present)
+
+Before anything else, check whether the **Graphify** skill is available in the running agent for this project.
+
+These harnesses do not expose a skills registry. Treat Graphify as available only if the project clearly ships it (e.g. a `graphify` skill/command file under the project's skills directory or an entry in the agent config). If you cannot positively confirm it, treat Graphify as unavailable and proceed without it.
+
+If Graphify **is** available, using it is **mandatory** for this run. Wherever a later step requires understanding code, mapping relationships across files, or making a design decision, you MUST first run Graphify on the relevant input (the affected file(s), the PR/MR diff, or the surrounding module) and use the resulting knowledge graph to inform your work. This applies in particular to:
+
+- **Step 4** — understanding each comment in the context of the surrounding code.
+- **Step 4b** — every deferred item: build the graph for the item's scope before choosing and executing a design route.
+- **Step 6** — self-review: graph the diff to check cross-file impact.
+
+If Graphify is **not** available, proceed normally — do not block on it.
+
+Record availability as a transient session fact — do NOT persist it; skill availability can change between sessions.
+
 ## Step 1: Platform Detection & CLI Verification
 
 ### 1.1 Check Memory
@@ -190,7 +206,7 @@ When a comment is unclear, ask **one** short clarifying question. Before asking,
 Then work through each task sequentially:
 
 1. **Read the affected file** at the referenced location
-2. **Understand the comment** in the context of the surrounding code
+2. **Understand the comment** in the context of the surrounding code (if Graphify is available per Step 0, graph the affected file(s) first and use the result to understand the surrounding code)
 3. If the comment is marked `(outdated)`, check whether the feedback is still relevant before acting
 4. **If unclear**: Ask the user what exactly is expected. Ask the user directly in chat with the listed options.
 5. **Implement the change** according to the reviewer's feedback
@@ -209,6 +225,8 @@ Otherwise announce: "Now handling N deferred items." Process items strictly in t
 
 For each deferred item:
 
+0. If Graphify is available (Step 0), build the knowledge graph for this item's scope first and use it to inform the route choice and execution below.
+
 1. Detect which design skills are visible to the running agent:
 
    These harnesses do not currently expose a skills registry; assume `[s]` and `[b]` are unavailable. Show them marked unavailable; allow the user to type a path to a local skill file if they want to invoke one manually. Record this as a transient session fact — do NOT persist it.
@@ -262,6 +280,8 @@ Review all changes made:
 git diff
 ```
 
+If Graphify is available (Step 0), graph the diff and use the result to check cross-file impact and relationships before the checks below.
+
 Check for:
 
 ### Reusability