waymark
README.md
# waymark
MCP server exposing a codebase's OKF
knowledge bundle (`okf/`) to Claude Code — three schema-enforced query
tools instead of raw `Read`/`Grep` over hand-written docs.
## Tools
- `list_concepts(type?, tags?)` — frontmatter-only summaries. `tags` matches
any-of the given tags.
- `read_concept(path)` — full frontmatter + body for one concept, by the
`path` a `list_concepts` call returned.
- `find_concept_by_resource(file_path)` — reverse lookup: which concept(s)
describe a given source file.
The server is stateless — it re-reads `okf/` from `process.cwd()` on every
call, so there's nothing to invalidate when concept files change.
## Setup (per project)
```bash
npx -y @aleburrascano/waymark init
```
This registers everything a repo needs in one step:
- Adds a `waymark` entry to `.mcp.json` (creating it if missing).
- Installs a pre-commit hook at `.git/hooks/pre-commit` that blocks commits
when a `resource`-mapped file changes without its `okf/` concept being
updated. Safe to re-run — it upgrades its own hook on later `waymark`
versions but never overwrites a hook it didn't install.
- Installs two skills to `.claude/skills/`: `okf-staleness-fix` (the
writer/judge playbook Claude Code uses to resolve a blocked commit) and
`okf-bootstrap` (the propose/approve/generate/judge playbook Claude Code
uses to seed an initial `okf/` bundle).
- Adds (or refreshes) an `## OKF context` section in the repo's `CLAUDE.md`.
Run it again any time to pick up updates from a newer `waymark` version.
## Bootstrapping an existing codebase
`okf/` bundles don't have to be hand-written from scratch. After running
`waymark init`, ask Claude Code to bootstrap one:
> "Bootstrap okf for this repo"
This invokes the `okf-bootstrap` skill, which:
1. Runs `waymark bootstrap` — a deterministic scan (`git ls-files`-based,
respects `.gitignore`) that lists every candidate source file.
2. Proposes a candidate concept list grouped by domain (one concept per
named unit you'd naturally ask "what is X" about) — nothing is written
yet.
3. Waits for your approval, or feedback to re-group/rename/split candidates.
4. Generates each approved concept, verified by a judge subagent before it's
written to disk.
5. Stages the new files with `git add` and reports what was generated —
committing is left to you.
This is a one-time, human-supervised pass. Ongoing drift after that is
caught by the pre-commit hook and `okf-staleness-fix` skill, not by
re-running bootstrap.
## Local development
```bash
npm install
npm test
npm run build && npm link # then `waymark` runs the built CLI
```
`npm test` runs vitest against TypeScript source directly — no build step
required for the test suite.
TDQS
A4.2/5.0
Scored across 3 tools
Disambiguation5/5
Each tool targets a distinct operation: listing summaries, reading a specific concept by path, and reverse lookup by resource. No overlaps or ambiguity.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern (list_, read_, find_) with snake_case. The naming is uniform and predictable.
Tool Count4/5
3 tools is a minimal but reasonable scope for a read-only concept bundle server. It's slightly on the lean side but not inappropriately so.
Completeness4/5
Covers the core read workflows: list all concepts, read a specific one, and reverse lookup by resource. Lacks create/update/delete, but that may be outside the intended purpose.
Maintenance
ActivityStale
ResponsivenessNo issues