Indexion Agent Orient
Generate an evidence-backed codebase orientation brief so your agent learns likely owners, consumers, and risky edit zones before touching unfamiliar code.
Overview
indexion-agent-orient is an agent skill most often used in Build (also Ship review) that produces a pre-edit structure brief so agents learn owners, consumers, and unsafe locations before implementing.
Install
npx skills add https://github.com/trkbt10/indexion-skills --skill indexion-agent-orientWhat is this skill?
- Runs indexion agent orient after verifying the installed CLI exposes --help for that command
- Builds an incremental orientation map across the selected codebase, not just the truncated display window
- Owner inference uses full prebuilt map: code structure, package READMEs, and wiki pages from wiki/plan reconcile flows
- Rendered brief is evidence-backed and paste-ready for AGENTS.md, CLAUDE.md, or subagent prompts
- Warns that broad multi-root wiki pages are background only—not proof every referenced package owns your task
- Pipeline step 0 requires indexion agent orient --help before generating the brief
- Owner inference must use the full prebuilt map, not only the rendered --limit display
Adoption & trust: 505 installs on skills.sh; 1 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your agent jumps straight to the path mentioned in the prompt and edits the wrong module because it never learned who owns the behavior or what downstream surfaces break.
Who is it for?
Solo builders using Indexion on monorepos or legacy trees where package boundaries and wiki-maintained ownership matter.
Skip if: Greenfield single-file repos with obvious structure, or teams without indexion installed and updated to expose agent orient.
When should I use this skill?
Before starting implementation in an unfamiliar or ambiguous part of a codebase, or when the user wants a pre-edit structure brief for coding agents.
What do I get? / Deliverables
You paste a short, evidence-backed orientation brief into AGENTS.md or the task prompt so the next implementation pass targets the right owners and avoids structurally unsafe edits.
- Short evidence-backed structure brief suitable for AGENTS.md, CLAUDE.md, or subagent prompts
- Owner and consumer hints with unsafe edit locations called out
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Build agent-tooling because the skill prepares coding agents with structural context immediately prior to implementation work. Agent-tooling fits outputs meant for AGENTS.md, CLAUDE.md, slash commands, Codex skills, or subagent prompts—not end-user product features.
Where it fits
Paste the orient brief into a Codex skill prompt before adding a feature that spans multiple internal packages.
Clarify which service owns an API change when the user request only names a folder noun.
Regenerate orientation before a large refactor PR so review comments target true owner modules.
How it compares
A pre-flight orientation ritual using Indexion’s map—not generic “read the whole repo” chat or a linter-only review skill.
Common Questions / FAQ
Who is indexion-agent-orient for?
Developers who run coding agents against larger or unfamiliar codebases and want a structured brief before any edits land in the wrong package.
When should I use indexion-agent-orient?
Use it in Build before implementing in an ambiguous area; in Ship before review-driven refactors; in Operate when iterating in production code you did not originally structure—always after confirming indexion agent orient exists in your CLI.
Is indexion-agent-orient safe to install?
It instructs agents to run local indexion commands against your repository—review the Security Audits panel on this page and treat generated briefs as sensitive internal map data.
SKILL.md
READMESKILL.md - Indexion Agent Orient
# 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 0. Verify the installed CLI has this workflow: ```bash indexion agent orient --help ``` If this command is missing, update or rebuild indexion before continuing. Having an older `indexion` binary in PATH is not enough for this skill. 1. Generate the brief: ```bash 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-update` when 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: ```bash 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 `--task` gloss. 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: ```bash indexion agent orient --no-update --task "name/content drift scoring and remediation planning" . ``` 2. 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. 3. Confirm the owner with focused tools: ```bash 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 wor