indexion-agent-orient
trkbt10/indexion-skills
Generate pre-edit structure briefs so agents understand codebase ownership before implementing changes.
What is indexion-agent-orient?
This skill builds an orientation map of a codebase to identify likely owners, consumer surfaces, and unsafe edit locations. Run it before starting implementation in unfamiliar code areas to provide agents with evidence-backed guidance on where domain behavior should live and what to avoid.
- Generate incremental orientation maps across selected codebases using code structure, package READMEs, and wiki pages
- Render short, evidence-backed briefs identifying likely implementation owners and knowledge sources
- Identify consumer surfaces (CLI, skills, docs, adapters) that call core packages
- Flag unsafe edit locations and required preflight files to read before patching
- Support zero-knowledge agent delegation by transferring repository-specific ownership assumptions
How to install indexion-agent-orient
npx skills add https://github.com/trkbt10/indexion-skills --skill indexion-agent-orient- indexion CLI installed and updated to include the agent orient workflow
- Task description (either in a task.md file or as a short command-line string)
- Access to the codebase root directory
How to use indexion-agent-orient
- 1.Verify the installed CLI has the workflow by running: indexion agent orient --help
- 2.Generate the orientation brief using either: indexion agent orient --task-file task.md --output=.indexion/cache/agent/orient.md . or indexion agent orient --task "<objective description>" .
- 3.Read the generated brief sections: Likely Implementation Owners, Knowledge Sources, Consumer Surfaces, Do Not Implement Here, Required Preflight, and Orientation Map
- 4.Confirm the owner with focused tools like: indexion doc graph --format=text <owner>, indexion grep --semantic=name:<term> ., or indexion search "<task concept>" .
- 5.Gate implementation by checking that the intended edit path is not in Do Not Implement Here and that the owner appears in Likely Implementation Owners
- 6.For subagent delegation, provide only the task and generated brief, then verify the agent can name the core owner, a knowledge source, an unsafe location, and a preflight path
Use cases
- Before implementing a feature in an unfamiliar part of a large codebase, generate an orientation brief to identify the correct owner package
- Delegate implementation tasks to subagents by providing the generated brief so they start with correct ownership assumptions
- Verify implementation targets are not in flagged unsafe locations before beginning edits
- Confirm package ownership through focused follow-up searches using terms from the generated brief
- Transfer stable guidance to Claude Code, Cursor, or multi-agent workflows via the structured orientation output
- Coding agents working in unfamiliar or ambiguous codebases
- Teams using multi-agent workflows that need consistent ownership assumptions across agents
- Developers delegating implementation tasks and needing to verify agent understanding before work begins
indexion-agent-orient FAQ
Use it before starting implementation in unfamiliar or ambiguous parts of a codebase, or when delegating implementation tasks to subagents. It is most valuable when you need to confirm ownership assumptions before editing.
The rendered --limit is only a display limit. Owner inference uses the full prebuilt map including code structure, package READMEs, and wiki pages. Do not treat documentation-only paths as domain implementation targets.
If the user task uses language that does not appear in repository identifiers and READMEs, pass a short codebase-vocabulary gloss to --task that describes the objective without naming a suspected owner. Keep the original request and constraints in your notes separately.
A subagent passes if it can immediately name the core implementation owner, one knowledge source, one unsafe edit location, and one preflight evidence path from the brief. This confirms the prebuilt map has transferred the correct ownership assumptions.
Later runs of indexion agent orient automatically refresh changed files and affected owner profiles. Use --no-update when you want to query the saved map without refreshing, such as when a zero-knowledge agent needs an immediate owner guess from the latest prebuilt map.
Full instructions (SKILL.md)
Source of truth, from trkbt10/indexion-skills.
name: indexion-agent-orient description: Generate and use a pre-edit structure brief so coding agents learn likely owners, consumer surfaces, and unsafe edit locations before implementing.
Agent Orientation Workflow
Use this skill before starting implementation in an unfamiliar or ambiguous part of a codebase.
Why
Coding agents often anchor on the path or noun in the user prompt and start
editing before they have learned the repository's ownership structure. indexion agent orient builds an incremental orientation map across the selected
codebase, then renders a short, evidence-backed brief that can be pasted into
AGENTS.md, CLAUDE.md, a Claude slash command, a Codex skill, or a subagent prompt.
The rendered --limit is only a display limit. Owner inference must come from
the full prebuilt map, including code structure, package READMEs, and wiki pages
whose provenance is maintained by wiki pages update, wiki pages ingest, and
plan reconcile.
Owner profiles use package documentation and owner-specific wiki pages. Broad wiki pages with multiple source roots are useful background, but they should not be treated as proof that every referenced package owns the task.
Pipeline
-
Verify the installed CLI has this workflow:
indexion agent orient --helpIf this command is missing, update or rebuild indexion before continuing. Having an older
indexionbinary in PATH is not enough for this skill. -
Generate the brief:
indexion agent orient --task-file task.md --output=.indexion/cache/agent/orient.md .The first run writes
.indexion/cache/agent/orient-map.json. Later runs refresh changed files and affected owner profiles only. Use--no-updatewhen you intentionally want to query the saved map without refreshing it. This is the mode to use when a zero-knowledge agent needs an immediate owner guess from the latest prebuilt map.For short tasks:
indexion agent orient --task "add a name/content drift audit" .If the user task is in a language or wording that does not appear in the repository's identifiers and README prose, keep the original task in your notes and pass a short codebase-vocabulary gloss to
--task. The gloss should describe the objective, not the suspected owner. For example, say "detect drift between names and implementation contents" instead of naming a package you have not confirmed.Do not put supporting infrastructure constraints into the owner-inference
--taskgloss. Keep the original request, required tools, and implementation constraints in your notes or subagent prompt. The gloss is only the objective vocabulary used to query the prebuilt map, for example:indexion agent orient --no-update --task "name/content drift scoring and remediation planning" . -
Read these sections before editing:
Likely Implementation Owners: core packages that should own domain behavior. Treat the first entry as the initial owner hypothesis unless follow-up evidence contradicts it.Knowledge Sources: release notes, wiki pages, READMEs, or other documentation that matched the task. Use these as context; do not treat a documentation-only path as the place to implement domain behavior.Consumer Surfaces: CLI, skills, docs, or adapters likely to call the core.Do Not Implement Here: files to avoid as domain implementation targets.Required Preflight: files the agent should read before patching.Orientation Map: confirms the total file/owner/documentation corpus used before display truncation.
-
Confirm the owner with focused tools:
indexion doc graph --format=text <likely-owner> indexion grep --semantic=name:<term> . indexion search "<task concept>" .Use the distinguishing terms from the brief and the user task, not only the broad infrastructure words. If search results drift toward supporting systems instead of the likely owner, refine the query with the name/content, drift, divergence, or domain-specific terms that actually define the task before changing the owner.
-
Gate implementation:
- If the intended edit path appears in
Do Not Implement Here, stop and explain the conflict. - If the intended owner is absent from
Likely Implementation Owners, gather more evidence withdoc graph,grep,search, orexplore. - Keep CLI code thin unless the brief and follow-up evidence show it owns the behavior.
- If the intended edit path appears in
-
Use for zero-knowledge delegation:
Give a subagent only the task and the generated orientation brief, then quiz it before assigning implementation work. It should immediately name the core implementation owner, one knowledge source, one unsafe edit location, and one preflight evidence path. Passing that quiz is the signal that the prebuilt map has transferred the right ownership assumptions.
External Agent Mapping
- Claude Code: store stable guidance in
CLAUDE.md, project commands in.claude/commands/, and project subagents in.claude/agents/. - Codex: store stable guidance in AGENTS.md or skills, and paste the orientation brief into delegated task context.
- Multi-agent workflows: use the brief as the structured handoff payload so each isolated agent starts with the same repository-specific assumptions.
Related skills
More from trkbt10/indexion-skills and the wider catalog.
indexion-readme
Initialize, generate, and assemble project READMEs from templates, doc comments, and configuration.
indexion-sdd
Generate SDD requirements from RFCs/specs and verify implementation conformance with quantitative drift detection.
indexion-refactor
Detect and eliminate code duplication at textual, structural, and conceptual levels using indexion analysis.
indexion-documentation
Assess documentation coverage, detect code-to-doc drift, and visualize module dependencies.
indexion-segment
Split text into contextual chunks for RAG/embedding pipelines using divergence, TF-IDF, or punctuation strategies.
indexion-kgf
Debug KGF specs by inspecting tokenization, parse events, and extracted edges from source files.