Varlock Agent Rules

Validate environment variables and manage application secrets.

Overview

Varlock covers dependency-aware builds, native binaries, tests, version bumps, and docs in a Bun and Turbo monorepo. Its rules name their costs: filtered builds miss workspace output, repeated pushes trigger paid reviews, and tone edits can break technical examples.

Documents

├── 
├──  · imports AGENTS.md
└── packages
    └── varlock-website
        └── src
            └── content
                └── docs — Local documentation source

Patterns in this file

Hard prohibitions Pointing at the source of truth Contribution etiquette House vocabulary

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.

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.

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.

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.

78- Never edit code fences, `ansi`/`diff` blocks, generated fixtures, frontmatter structure, or MDX component markup for tone. Prose only.

Ideas for your repo

Explain the dependency that makes one build entry point mandatory.
Point internal work at local documentation sources.
Document costly automation triggers where agents see commit and push guidance.
Define which parts of a document a prose-only edit may touch.