From ix-memory
Generates narrative-first, importance-weighted documentation for a repo or subsystem, with a selective reference layer. Use --full for deeper module/class/method coverage.
How this skill is triggered — by the user, by Claude, or both
Slash command
/ix-memory:ix-docs <target> [--full] [--style narrative|reference|hybrid] [--split] [--single-doc] [--out <path>] [--save [path]]<target> [--full] [--style narrative|reference|hybrid] [--split] [--single-doc] [--out <path>] [--save [path]]The summary Claude sees in its skill listing — used to decide when to auto-load this skill
> [ix-claude-plugin shared model](../shared.md)
Check command -v ix first. If unavailable, stop and say so.
Produce documentation that helps a new engineer understand the system quickly and gives an LLM strong architectural context without drowning it in low-value detail.
Write like real engineering documentation for a framework or subsystem:
Never write a raw report dump.
Every ix-docs run produces two layers:
Narrative layer (always first)
Reference layer (always present, but selective)
Mode behavior
ix-docs <target>: narrative-heavy by default, with a minimal selective reference appendixix-docs <target> --full: deeper coverage for important components, still importance-weightedStyle behavior
--style narrative (default): prose-first narrative sections; reference layer stays compact--style reference: tighter, docs-site style structure; narrative stays brief but is not removed--style hybrid: full narrative plus fuller selective reference; best match for --full| Fragment | Variable | Default |
|---|---|---|
| first non-flag token | TARGET | required |
--full | FULL=true | false |
| `--style narrative | reference | hybrid` |
--split | SPLIT=true | false |
--single-doc | SINGLE=true | false |
--out <path> | OUT_PATH | auto-detect |
--save [path] | alias for --out when --out is absent; if both are given, --out wins | — |
Parsing
Scan $ARGUMENTS left to right:
-- is TARGET--style and --out consume the next token as their value (also accept --style=value form)TARGET is missing, stop and ask the user to supply a target before continuingOutput rules
--single-doc forces one Markdown file--split produces a directory with index.md plus per-system or per-subsystem docsFULL=true on a repo with more than 10 subsystems, auto-enable SPLIT=true--single-doc overrides auto-splittingOutput path auto-detection
docs/ exists at workspace root → docs/<target-name>.md or docs/<target-name>/doc/ exists → doc/<target-name>.md or doc/<target-name>/<target-name>.md or <target-name>/ at workspace rootIf FULL=true, tell the user the planned mode, output path, and whether splitting was auto-enabled before generating the docs.
Graph first
ix subsystems, ix overview, ix rank, ix explainix read only after graph data leaves an important behavior unclearImportance-weighted expansion
Selective low-level detail
No raw dumps
No redundancy
Code reads are rare
ix read calls totalix read calls totalUse the following ranking factors to decide what gets expanded:
ix rank, caller count, dependent countix impactix explain--fullDefault mode
Full mode
When a repo is very large, prefer:
Do not run every command mechanically. Reuse earlier results and stop when additional depth would not materially improve the documentation.
Stop early: If TARGET is an unambiguous symbol or small component and scope is clear from ix stats alone, skip the remaining Phase 1 commands and proceed to Phase 2.
Always start with:
ix stats --format llm
ix subsystems --format llm
ix subsystems --list --format llm
ix briefing --format json 2>&1
Pro check: If ix briefing returns JSON with a revision field, Pro is available. Extract activeGoals, recentDecisions, and recentChanges for use in [Pro] steps. If it errors, skip all Pro-labeled steps — the skill works fully without them.
If TARGET is not obviously the whole repo:
ix locate "$TARGET" --format llm
Resolve whether the target is:
If ambiguous, resolve it before proceeding.
Trigger: FULL=true AND the target is a repo or top-level system with more than 5 subsystems.
Phase 1 reuse: Before running Phase 1 commands, check whether subsystem and rank data is already present in context from a prior /ix-understand run in this session. If ix subsystems results and rank results are already available, skip those Phase 1 commands and use the cached data directly — do not re-run them.
Step 1 — Per-system agents: From the Phase 1 rank results, select the top systems by importance (cap at 5). For each, spawn one ix-system-explorer agent in the background:
Task template: "Build a complete architectural mental model of
$SYSTEMwithin$TARGET. Focus on: (1) internal module structure and responsibilities, (2) the most important and most-coupled components, (3) main execution flows within this subsystem, (4) outbound dependencies and shared interfaces with other subsystems. Return structured findings with: a one-paragraph subsystem summary, top 5 important modules with roles, key internal flows, and coupling risks."
Step 2 — Cross-cutting agent: Immediately after spawning the per-system agents, spawn one additional ix-system-explorer agent for cross-system concerns:
Task: "In the
$TARGETcodebase, identify only what crosses subsystem boundaries: (1) shared types, base classes, and utilities used across multiple subsystems, (2) cross-system execution flows and handoff points, (3) infrastructure or platform services that multiple systems depend on, (4) god-modules or highly-central components visible from the dependency graph. Do NOT explore individual subsystems in depth — focus exclusively on cross-cutting structure. Return structured findings."
Do not wait for any agent before starting Phase 2. Continue running Phase 2 commands while all agents work.
Step 3 — Synthesis (when agent results arrive):
Merge all agent findings with your Phase 2/3 graph results:
index.md in split mode.Skip this dispatch entirely if:
FULL=falseStop when: you have identified the top 3-5 important components and the subsystem structure is clear. Do not run additional rank queries once the most central components are known.
Use the graph to identify systems, subsystem boundaries, and the most important modules.
Common commands:
ix overview "$TARGET" --format llm
ix rank --by dependents --kind class --top 10 --exclude-path test --format llm
ix rank --by callers --kind function --top 10 --exclude-path test --format llm
If TARGET is the whole repo, skip ix overview "$TARGET" and rely on the pre-run subsystem data plus the rank results.
Additional commands by scope:
For repo or system targets:
ix subsystems "$TARGET" --format llm
ix subsystems "$TARGET" --explain
For module or file targets:
ix contains "$TARGET" --format llm
ix imports "$TARGET" --format llm
Full mode:
ix subsystems <system> and ix subsystems <system> --explainStop when: the main execution flow is understood. Skip ix trace if ix explain results are sufficient — do not run a trace just to be thorough.
This phase answers how the system works.
Use:
ix explain "$TARGET" --format llm
Also run ix explain for the most important orchestrators, services, or entry points identified in Phase 2.
Behavior budget:
Optional:
ix trace only if the main execution flow is still unclear after ix explainDescribe:
Do not narrate every edge in a trace.
Stop when: for symbol-level or small single-module targets, skip this phase entirely — relationship data at that scope adds minimal value to the documentation.
Map the important dependencies and coupling points.
Use:
ix callers "$TARGET" --limit 15 --format llm
ix callees "$TARGET" --limit 15 --format llm
ix depends "$TARGET" --depth 2 --format llm
Repo-level guard: If TARGET is the whole repo, skip ix callers "$TARGET", ix callees "$TARGET", and ix depends "$TARGET" entirely — these commands are not meaningful at repo scope and will produce noise. Instead, run them for the top 3-5 boundary components, orchestrators, or subsystem entry points identified in Phase 2, and summarize the cross-subsystem edges they reveal.
For repo or large system targets, focus on:
When counts are large:
Repo-level gate: If TARGET is the whole repo, do not run ix impact "$TARGET" — impact analysis is not meaningful at repo scope. Skip directly to running ix impact for the top 3-5 high-centrality entities identified in Phase 2.
Otherwise run:
ix impact "$TARGET" --format llm
Full mode:
ix impact for the top 2-5 high-centrality entitiesUse this phase to populate:
Stop when: for symbol-level or single-module targets, skip this phase — health issues at that scope are rarely actionable at the documentation level.
Use:
ix smells --format llm
Note: ix smells does not support --path scoping — results are always repo-wide. If the target is a subsystem or module, filter results by path prefix after retrieval.
[Pro] If Pro is available and recentDecisions is non-empty, include relevant architectural decisions in the risk and complexity section:
ix decisions --format json
Prioritize:
Group health issues by subsystem, not as a flat dump.
Stop when: you reach the read budget. Never exceed it regardless of how many unclear behaviors remain — omit or note gaps instead.
Only read code when graph data is insufficient for an important behavior.
Allowed use cases:
ix explainUse:
ix read <symbol> --format llm
Do not summarize implementation line-by-line. Extract only the behavior needed to clarify the docs.
--style narrative--style reference--style hybrid--full, onboarding docs, and handoff docsThe document should feel like real documentation, not an investigation transcript.
Use this structure.
# [Target] — Documentation
> Generated: [date]
> Scope: [repo | system | subsystem | module | symbol]
> Mode: [standard | full]
> Style: [narrative | reference | hybrid]
> Evidence quality: [strong | partial | weak]
> Coverage: [what was expanded vs summarized]
## Part 1 — Narrative
### 1. Overview
- what the system is
- what it does
- why it exists
- **[Pro]** active project goals this system serves (from `ix briefing` activeGoals), if available
### 2. Architecture
- systems -> subsystems -> modules
- boundaries and responsibilities
- high-level structure
### 3. How It Works
- main execution flows
- request or data lifecycle
- orchestration paths
### 4. Key Components
- the most important modules, classes, or services
- why they matter
### 5. Dependencies & Relationships
- major dependencies
- cross-system interactions
- important coupling points
### 6. Risk & Complexity
- high-risk areas
- fragile components
- change sensitivity
### 7. How to Work With This Repo
- where to start
- how to navigate
- common workflows
- what to modify carefully
### 8. Where to Go Deeper
- next files, modules, or symbols to inspect
- suggested exploration paths
## Part 2 — Selective Reference
### Module Summary
For each major module:
- purpose
- responsibilities
- dependencies
- key contained components
### Class / Service Summary
For each important class or service:
- role (orchestrator, boundary, helper, store, adapter, etc.)
- what it manages
- where it is used
### Method Summary
Only in `--full`, and only for key classes or services:
- method name
- 1-2 line role summary
- role in the system, not implementation detail
Use split output when:
--split is passed, orFULL=true and the repo is large enough that one doc would become unwieldyRecommended structure:
<OUT_DIR>/
index.md
<system-1>.md
<system-2>.md
...
<lower-ranked-system>-stub.md
index.mdShould contain:
Each system doc should contain:
For lower-ranked systems, create short stubs instead of full docs:
ix-docs <system> --full if deeper coverage is neededThe output is successful if:
The output has failed if:
After writing the file or files, confirm:
Documentation written.
Mode: [standard | full]
Style: [narrative | reference | hybrid]
Output: [path or directory]
Scope: [repo/system/subsystem/module/symbol]
Coverage: [systems/subsystems/components expanded]
Summary: [2-3 sentences on the system and the most important architectural fact]
[If split:]
Files written: [index + key system docs + stubs]
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Applies a firm's KYC/AML rules grid to parsed onboarding records: assigns risk rating, checks required documents, outputs rule outcomes with citations, and routes for escalation.
Generates daily or weekly digests of activity from connected sources (chat, email, docs, tasks, CRM), highlighting action items, decisions, mentions, and project updates.
npx claudepluginhub ix-infrastructure/ix-claude-plugin --plugin ix-memory