com um clique
indexion-agent-orient
// Generate and use a pre-edit structure brief so coding agents learn likely owners, consumer surfaces, and unsafe edit locations before implementing.
// Generate and use a pre-edit structure brief so coding agents learn likely owners, consumer surfaces, and unsafe edit locations before implementing.
README construction — initialize template structure, generate per-package READMEs from doc comments, plan writing tasks, assemble root README from docs/ and package READMEs via doc.json config, and verify edits with `plan drift`.
Detect and review name/content drift in code using `indexion identity audit`, then plan verified renames, moves, folder changes, or splits.
Generate SDD requirements from RFCs/specs and quantitatively verify implementation conformance. spec draft → spec align → spec verify → automated validation loop with codex/claude. Operate spec-to-impl drift gates as CI checks.
Documentation analysis — assess coverage, detect code-to-doc drift with plan reconcile, visualize dependencies with doc graph. Answers "what needs docs?" and "are docs still accurate?"
Project wiki lifecycle — create pages, track source changes with ingest, update stale pages, lint structural integrity, detect code-to-doc drift with reconcile, and manage search indexes. A runbook for navigating and maintaining the wiki as an agent.
Debug and inspect KGF specs — view tokenization results, parse trees, and extracted edges from source files. Use when adding/fixing language support or when indexion's analysis output looks wrong.
| 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. |
Use this skill before starting implementation in an unfamiliar or ambiguous part of a codebase.
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.
Verify the installed CLI has this workflow:
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.
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-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:
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:
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:
Do Not Implement Here, stop and
explain the conflict.Likely Implementation Owners, gather
more evidence with doc graph, grep, search, or explore.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.
CLAUDE.md, project commands in
.claude/commands/, and project subagents in .claude/agents/.