dsh-knowledge

Usage

/init [path] — build the knowledge base

/init                  the model reads the whole project and writes to .dsh/ at the project root
/init @src             the model reads src/ only; documents still go to .dsh/ at the root
/init src/lib          nested paths work the same

Path parsing is deliberately loose: a leading @ (left behind by the composer's completion) is stripped, paths with spaces can be quoted, naming the project's own directory means the whole project, and a missing path lists the available top-level directories.

/init itself does exactly two things: wake the model, then inject the full instruction.

Only the one line you typed shows in the UI (e.g. /init @src). The full instruction is injected as a system-reminder instead of flooding the conversation — the same mechanism the per-turn document injection uses.

The model then explores with glob / grep / read and writes with write, appearing in the UI like any other turn.

The knowledge base always lives at the project root, whatever subdirectory /init was scoped to. One .dsh per project.

Automatic context injection

No manual reminders needed. The first step of every turn injects:

1. the body of overview.md (truncated with a pointer to the original when it is long)
2. the document listing under .dsh
3. usage rules and an update reminder — including: the model judges for itself whether this change made the documents stale

One knowledge base is injected once per session, not on every turn; after the model edits documents, they are injected again.

When to update

The injected prompt states the rules, and the model applies them itself:

Change	Update the documents?
a feature added or removed, or the entry points, execution flow, data flow or module dependencies changed	yes — the affected document
a bug fix, a style change, an implementation detail that changes no structure	no
not sure	lean toward not writing

The principle: better no update than documents that contradict the code.

Configuration

None needed.