Conducty Context

Conducty Context — Project Ingestion as a Sub-Graph

A single big Context My App.md is a brittle context engine. Re-reading 250 lines on every plan misses what changed and what's stale. Instead, conducty-context decomposes a project into a linked sub-graph in the Obsidian vault. Each note has one purpose, a stable filename, and explicit cross-links. Plans pull only the slices they need; refreshes record deltas instead of overwriting.

[!important] Read [[conducty-obsidian]] first All output goes to the vault. Per-instance notes follow Title Case; this skill writes a hub note plus several sub-notes per project.

When to Use

• First time loading a project: conducty-context /path/to/project
• The user says "refresh context" or "the project has changed since last load"
• Plan execution surfaces stale architecture info — a refresh fires
• A new bounded context emerges that wasn't captured before

The Project Sub-Graph

For each project, the vault holds one hub note plus a set of slice notes. All slice names are deterministic so wikilinks resolve from any plan or design.

Bounded-context deep notes (optional, written when a module is large enough to warrant one):

• Context {Project} {Module}.md — purpose, public interface, internal invariants, key files

Refresh deltas (one per refresh):

• Context Refresh {Project} YYYY-MM-DD HHmm.md — what changed since last load: new files, removed files, new bounded contexts, broken invariants, new convention violations. Older refresh notes accumulate as a temporal record.

Workflow

Step 1: Identify the Target

Resolve the directory path to absolute. Extract project name from the basename, convert to Title Case for vault filenames (my-app → My App).

Check the vault for an existing hub note:

test -f "$VAULT/Context/$PROJECT/Context $PROJECT.md" && echo "refresh" || echo "first load"

If this is a first load, create the project sub-graph directories before writing any slice:

mkdir -p "$VAULT/Context/$PROJECT/Modules" "$VAULT/Context/$PROJECT/Refreshes"

Step 2: First Load vs. Refresh

First load: generate every slice + the hub. Move on.

Refresh: read the existing hub's last_refreshed frontmatter. Compute deltas (Step 7) and either edit each slice in place (preserving frontmatter, prepending changes) or write a refresh-delta note describing the diff and updating the hub's last_refreshed.

Step 3: Read Project Identity

Read these files if present (skip if absent):

• README.md or README
• package.json, Cargo.toml, pyproject.toml, go.mod, Gemfile, pom.xml
• docker-compose.yml, Dockerfile
• AGENTS.md, CLAUDE.md — agent instructions
• .editorconfig, tsconfig.json, .eslintrc*, prettier*, ruff.toml, .golangci.yml — style/lint
• .claude/ if present — local skills/commands

Capture: language, framework, key dependencies, build/test/lint commands, declared style rules, any agent instructions.

Step 4: Map Architecture and Bounded Contexts

Use Glob (src/**, lib/**, pkg/**, app/**) two levels deep to enumerate modules. For each module:

• What is its responsibility?
• What does it import from other modules?
• What imports it?
• What's its public surface (exports)?

Render a Mermaid dependency diagram in the Architecture slice — Obsidian renders Mermaid natively:

flowchart LR
    auth --> session
    api --> auth
    api --> billing
    billing --> session
    session --> db

For modules with non-trivial internal complexity (>500 lines, multiple sub-responsibilities, or a public API surface other code depends on), generate a bounded-context deep note at Context/{Project}/Modules/Context {Project} {Module}.md and link it from Architecture.

Step 5: Capture Conventions

From style configs and observed code:

• Naming: file, type, function, variable
• File organization: where do new features go? where do tests live?
• Patterns: error handling, logging, configuration, dependency injection
• Forbidden: things the project explicitly rejects (commented in CLAUDE.md, lint rules, README)
• Lint/format commands

Step 6: Capture Invariants

Things that MUST NOT change silently:

• Public API surfaces (HTTP routes, exported functions, RPC schemas)
• Database schemas / migrations
• Configuration contracts (env vars, config files)
• File formats / wire formats
• Performance budgets if declared

For each invariant, note where it lives and what would break if it changed.

Step 7: Capture Hotspots and Recent Activity

Bash:

git log --format='%H %s' -50
git log --format='' --name-only -50 | sort | uniq -c | sort -rn | head -20
git diff --stat HEAD~10
git branch -a --sort=-committerdate | head -10

The most-touched files are the hot spots. Plans that touch hot spots inherit higher complexity ratings.

Grep for TODO|FIXME|XXX|HACK in recent commits' files.

Step 8: Capture Test + Tooling Commands

This slice is consumed directly by [[conducty-ship]] — the entries here populate the ship battery.

test: npm test
test_unit: npm run test:unit
test_integration: npm run test:integration
typecheck: tsc --noEmit
lint: npm run lint
format: npm run format -- --check
vuln_check: npm audit --audit-level=high
build: npm run build

If a command can't be run safely (long-running, external deps required), record it but don't execute. If you can run it, do — record last_test_count, last_pass_count, last_run timestamp.

Step 9: Build the Glossary

Pull domain terms from:

• README headings + first occurrence prose
• Public type names, route names, table names
• Comments that define terms

For each: term + 1-sentence definition + a backlink to the most relevant code path. The glossary makes plans precise — when a prompt says "publish a SessionTrace", everyone reading the plan knows what that means without re-deriving it.