Varlock's instructions cover the mechanics around a Bun and Turbo monorepo: dependency-aware builds, native binaries, tests, version bumps, and documentation. Several rules explain the cost they prevent. Filtered builds can miss workspace output; repeated pushes trigger paid reviews; rewriting technical examples during a tone edit can damage working documentation.
Quoted passages are verbatim. Open one to see it in the source.
01 / Hard prohibitions
Explain the build dependency
The guide requires Turbo because downstream declaration bundling needs upstream build output. The prohibition is tied to a failure mode rather than a preferred spelling of the command.
Source excerpt starting at line 27.
27- Do **not** build a package with `bun run --filter <pkg> build`: bun's filter does not build the package's workspace dependencies, and some builds require their dist output to exist (e.g. varlock's d.ts bundling inlines the emitted declarations from `packages/utils`, so it fails if that package was never built)
02 / Pointing at the source of truth
Read the local source of documentation
The public documentation service is for external users. Repository work is directed to the local docs, keeping edits and the material being consulted together.
Source excerpt starting at line 14.
14- `packages/varlock-docs-mcp` — docs MCP server for external varlock users; do **not** use it to look things up while working on this repo — read the docs source directly
03 / Contribution etiquette
Treat pushes as a workflow cost
The contribution guidance connects each push to paid automated review. It asks for local iteration followed by a batch push, making the reason for the cadence visible.
Source excerpt starting at line 65.
65- **Do not push after every commit.** Pushes to open PRs trigger automated reviews that cost money. Commit locally as you go, and only push when the work is complete (or the user asks for feedback on work in progress). When in doubt, ask before pushing
04 / House vocabulary
Keep tone edits out of executable examples
Documentation guidance protects code fences and structured content while changing prose. That boundary lets an agent simplify language without silently changing commands.
Source excerpt starting at line 78.
78- Never edit code fences, `ansi`/`diff` blocks, generated fixtures, frontmatter structure, or MDX component markup for tone. Prose only.
Put it to work
Borrow this for your repo
01Explain the dependency that makes one build entry point mandatory.
02Point internal work at local documentation sources.
03Document costly automation triggers where agents see commit and push guidance.
04Define which parts of a document a prose-only edit may touch.
Varlock's file tells an agent how the codebase works. It cannot tell it which bug three customers hit this week. Modem keeps that context current and attaches it to the work.
