The graph is only as useful as the prompts that leverage it. This lesson teaches you how to write prompts that exploit community clustering and structural knowledge — turning the graph from passive context into active guidance.
After this lesson, your AI sessions start faster and resolve tasks with fewer round-trips because you're front-loading structural context the agent would otherwise spend tokens discovering.
Instead of starting a session cold, open with a primer that orients the agent using the graph report:
# At the start of a Kiro CLI session:
/graphify
# Then immediately:
"I'm working in the [Community Name] cluster. My task is [X].
Before writing any code, tell me which files in this community
I need to read and what patterns they follow."
This two-step opening eliminates the discovery phase. The agent already has the graph; your prompt tells it where in the graph to focus.
The GRAPH_REPORT.md names your communities. Use those names in prompts to scope the agent's attention:
# Bad — agent searches the entire graph
"Write a new test file for the $min operator"
# Good — agent focuses on the right cluster
"Looking at the 'Update Operator Tests' community in the graph,
write a new test file for $min following the same pattern as
the other operator test files in that community."
Community names act as landmarks. The agent uses them to pull the relevant subgraph and ignore everything else.
When you need to replicate an existing convention, ask the agent to extract the pattern from the graph first:
"From the graph, identify the common structure shared by test files
in the 'Comparison Operators' community. List:
1. The base class they inherit from
2. The imports they share
3. The test function signature pattern
4. How they define test data
Then use that pattern to create test_min_comparisons.py."
This forces the agent to articulate the pattern before writing code — catching mismatches before they happen.
Before making a change, ask the graph about impact:
"I'm going to rename `execute_command` to `run_command`.
Using the graph, show me every file that imports or calls this function
so I know the full blast radius before I start."
The graph answers this instantly from edge data — no file reading needed.
Use the graph to find what's missing:
"Looking at the 'Update Operator Tests' community, which operators
have test files and which don't? I want to know what's missing."
The graph has nodes for all files. Absence is visible.
Prompts that waste graph context:
| Anti-pattern | Why it wastes tokens | Better approach |
|---|---|---|
| "Read all the test files and tell me about them" | Defeats the purpose — forces file reading | "From the graph, summarize the test communities" |
| "Write this code" (no context) | Agent doesn't know to consult the graph | Scope to a community or reference existing nodes |
| "Is my code correct?" | Behavioral question — graph can't answer | Ask for structural alignment: "Does this follow the pattern in [community]?" |
The best graph-driven prompts are scoped (name a community or node), structural (ask about relationships, not behavior), and comparative (reference existing patterns to replicate).
As you find prompts that work well with your graph, save them. Create a simple file in your project:
# .graphify-prompts.md
## Start-of-session primer
/graphify then: "I'm working in [COMMUNITY]. My task is [TASK]."
## New test file
"From the [COMMUNITY] community, extract the shared pattern
and create a new test file for [OPERATOR]."
## Impact analysis
"Using the graph, show all callers of [FUNCTION]."
## Gap analysis
"Which nodes in [COMMUNITY] have no incoming edges from test files?"
What makes a prompt "graph-driven" rather than just a normal prompt?
Why is "Write a new test file for $min" worse than scoping to a community?
GRAPH_REPORT.md and note 2-3 community names/graphify