"You are not writing code documentation. You are building a cognitive foundation for the next AI that takes over this project."

.nexus-map/

[!IMPORTANT] You must not produce the final

.nexus-map/

until PROFILE, REASON, OBJECT, and BENCHMARK are completed.

This is not for formal completeness, but to prevent the AI from directly writing first-glance assumptions as conclusions. The final output must be based on script outputs, repository structure, counterevidence challenges, and review verification.

• Skipping OBJECT to directly generate output assets
• Generating

  concept_model.json

  before completing BENCHMARK
• Proceeding to subsequent phases after script failure in the PROFILE phase

• Explicitly confirm "✅ Phase Name Completed" after finishing each phase before moving to the next
• OBJECT must propose a minimal set of high-value questions sufficient to overturn current assumptions, usually 1-3 questions, never padding the number
• The

  code_path

  of

  implemented

  nodes must actually exist in the repository;

  planned/inferred

  nodes must not fake

  code_path

  (see Rule 2)

repo_path: Local absolute path of the target repository (required)

scripts/languages.json

module-only coverage

• --add-extension .templ=templ

  Add a new file extension mapping (repeatable)

• --add-query templ struct "(component_declaration ...)"

  Add a structural query for a language (repeatable)

--add-query <LANG> <TYPE> <QUERY_STRING>

<TYPE>

struct

imports

--language-config <JSON_FILE>

references/05-language-customization.md

.nexus-map/
├── INDEX.md                    ← AI cold-start main entry (< 2000 tokens)
├── arch/
│   ├── systems.md              ← System boundaries + code locations
│   ├── dependencies.md         ← Mermaid dependency graph + sequence diagram
│   └── test_coverage.md        ← Static test surface: test files, covered core modules, evidence gaps
├── concepts/
│   ├── concept_model.json      ← Schema V1 machine-readable graph
│   └── domains.md              ← Core domain concept explanations
├── hotspots/
│   └── git_forensics.md        ← Git hotspots + coupling pair analysis
└── raw/
    ├── ast_nodes.json          ← Tree-sitter parsed raw data
    ├── git_stats.json          ← Git hotspot and coupling data
    └── file_tree.txt           ← Filtered file tree

• generated_by

• verified_at

• provenance

concept_model.json

label

title

title

label

provenance

module-only coverage

configured-but-unavailable

--hub-analysis

--impact

--impact --git-stats

--summary

--file

systems.md

dependencies.md

--file

--who-imports

--impact

Positioning:

.nexus-map/

is the "map", and

query_graph.py

is the "magnifying glass". The map helps you locate the general direction, while the magnifying glass helps you see local details clearly.

Detailed usage scenarios and practical cases for the five query modes can be found in

references/06-query-guide.md

.

[!IMPORTANT] You must

read_file

the corresponding reference before entering each phase; do not skip it. Detailed steps, completion checklists, and boundary scenario handling for each phase are defined in the references.

[When Skill is activated]     → read_file references/01-probe-protocol.md  (Phase step blueprint)
[Before REASON]        → read_file references/03-edge-cases.md       (Boundary scenario check)
[Before OBJECT]        → read_file references/04-object-framework.md  (3-dimensional questioning template)
[Before EMIT]          → read_file references/02-output-schema.md    (Schema verification specifications)

[!IMPORTANT] Before writing to

concept_model.json

, you must first distinguish whether a node is

implemented

,

planned

, or

inferred

. Only

implemented

nodes are allowed to have

code_path

written, and you must personally verify its existence.

undefined

For `planned` or `inferred` nodes, use:

```json
{
  "implementation_status": "planned",
  "code_path": null,
  "evidence_path": "docs/architecture.md",
  "evidence_gap": "src/agents/monarch/ not found in the repository, only mentioned in design documents"
}

• Using a "barely related" file to pretend to be

  code_path

• Writing a pseudo-precise directory when

  implementation_status

  is

  planned/inferred

• Writing

  code_path: "PLANNED"

  which puts status into the path field

INDEX.md

• < 2000 tokens — Rewrite if exceeded, do not truncate
• Conclusions must be specific — Do not use vague empty words; when evidence is insufficient, explicitly write

  evidence gap

  or

  unknown

  and explain what evidence is missing

Avoid writing only: to be confirmed · may be · suspected · perhaps · pending · unclear · need further · uncertain
Avoid writing only: pending · maybe · possibly · perhaps · TBD · to be confirmed

• unknown: No direct evidence found indicating api/ is the main entry; currently only confirmed that cli.py is referenced in README

• evidence gap: No git history in the repository, so the hotspots section is skipped

[!IMPORTANT] By default, only run scripts included with this Skill and necessary read-only checks. Do not execute build scripts, test scripts, or custom commands in the target repository just because "you want to understand the repository better".

• Allowed by default:

  extract_ast.py

  ,

  git_detective.py

  , directory traversal, text search, read-only file viewing
• Prohibited by default: Executing commands like

  npm install

  ,

  pnpm dev

  ,

  python main.py

  ,

  docker compose up

  in the target repository, unless explicitly requested by the user
• When encountering

  .env

  , key files, or credential configurations: Only record their existence and purpose, do not copy specific values

[!IMPORTANT] If AST coverage is incomplete, or if part of the dependency graph/system boundary comes from manual reading rather than script output, you must explicitly mark the provenance in the final file.

• In

  dependencies.md

  , any dependency relationship not directly supported by AST must be marked

  inferred from file tree/manual inspection

• If

  domains.md

  ,

  systems.md

  ,

  INDEX.md

  involve unsupported language areas, explicitly state

  unsupported language downgrade

• If writing progress snapshots, Sprint status, or roadmaps, attach

  verified_at

  to avoid outdated information being disguised as current facts

<repo_path>/.nexus-map/raw/ast_nodes.json

<repo_path>/.nexus-map/raw/ast_nodes.json

<repo_path>/.nexus-map/raw/ast_nodes.json

<repo_path>/.nexus-map/raw/ast_nodes.json

**Dependency Installation (First Use)**:
```bash
pip install -r $SKILL_DIR/scripts/requirements.txt

• All five phases are completed, with explicit "✅ Completed" marks for each phase
• The number of questions in OBJECT is not padded; each question is accompanied by evidence clues and an executable verification plan
• The

  code_path

  of

  implemented

  nodes has been personally verified to exist;

  planned/inferred

  nodes use

  implementation_status + evidence_path + evidence_gap

• responsibility

  field: specific, verifiable; explicitly explain gaps when evidence is insufficient
• Full text of

  INDEX.md

  is < 2000 tokens, conclusions are specific and not overly certain (Rule 4)
• If unsupported language files are found, downgrades and manual inference ranges have been explicitly marked in the final Markdown headers and relevant sections

• arch/test_coverage.md

  has been generated, and it is clearly stated that this is a static test surface rather than runtime coverage