Kiro codebase context with skills and steering

What is Kiro codebase context?

Kiro codebase context is the project information Kiro can use while planning and implementing work. That includes steering guidance, specs, source files, tool results, and any graph or documentation artifacts exposed in the workspace. The context is strongest when intended behavior, working rules, and actual code relationships are all explicit rather than mixed into one long prompt. Better context selects fewer, more relevant files instead of asking the agent to remember everything.

• Steering describes how the team expects Kiro to work.
• Specs clarify requirements, design, and task boundaries.
• Source files provide exact implementation behavior.
• Graphify adds reusable relationships across all of them.
• Keep policy, intended behavior, and structural evidence in separate sources.

How do Kiro skills and steering complement a graph?

Kiro steering carries durable project policy while a skill describes a reusable workflow. Neither is a substitute for a structural map: steering can say when to query the graph, and the graph can answer where a dependency or call path actually goes. This separation prevents a steering file from becoming a manually maintained architecture inventory that goes stale after every refactor.

• Use steering for commands, conventions, protected paths, and verification rules.
• Use the Graphify skill for graph-query procedures and artifact names.
• Use graph.json for relationships that should not be hand-maintained.
• Use specs for intended behavior rather than inferred structure.
• Reference graph artifacts instead of copying thousands of file facts into steering.
• Keep commands and verification rules close to normal Kiro development practice.

How do you install Graphify for Kiro?

Run graphify kiro install from the repository root after installing graphifyy. The installer creates the Graphify skill under .kiro/skills and adds Kiro steering guidance so the workflow is available in later sessions. Installation changes project guidance only; Kiro still needs a repository graph and a task that benefits from structural queries. Commit the generated project files when the team wants the same Graphify workflow on every machine.

• Confirm Python 3.10 or newer is available.
• Run graphify kiro install in the repository that Kiro opens.
• Review and commit the generated Kiro skill and steering changes.
• Build graphify-out before relying on graph query answers.
• Restart or reopen Kiro if the IDE does not immediately load generated project guidance.

What should Kiro use from Graphify?

Kiro should use graph.json for queryable structure and GRAPH_REPORT.md for a concise architecture briefing. graph.html is useful when a human wants to inspect relationships, while source files remain the authority for implementation details. The report is a context selector: it should tell Kiro which modules and source files deserve deeper reading.

• Query callers and dependent modules before changing shared interfaces.
• Use communities and god nodes to locate subsystem boundaries.
• Read GRAPH_REPORT.md before broad source exploration.
• Open graph.html for human architecture review and handoff.
• Use the graph to narrow source reads without treating summaries as implementation proof.

How should Kiro query a graph during a spec?

Start from the symbols and modules named in the spec, then query reverse dependencies, call paths, and affected tests before writing a task list. This keeps the spec grounded in the repository's current structure instead of assuming a proposed design already exists. The resulting plan should distinguish existing relationships from relationships the implementation intends to create.

• Map each requirement to current files and symbols.
• Identify dependencies that constrain the implementation order.
• Find tests and documentation that must change with the code.
• Recheck the graph after major task boundaries or refactors.
• Update the spec when verified source differs from the original architecture assumption.
• Record which spec requirement each affected module or documentation file supports.

How do you refresh and verify Kiro context?

Refresh the graph after structural changes and after important specs or design documents change. Verify every graph-derived implementation claim in source and require Kiro to run the repository's type checks and tests before accepting a task. Store the graph revision or timestamp with the project guidance when several branches or long-running specs use the same repository.

• Use graphify update for code-only structural refreshes.
• Run a full extraction when semantic documents changed.
• Confirm graph edges against current source.
• Reject plans that cite stale files or missing symbols.
• Rebuild after merges that change steering assumptions or module boundaries.