project-context

project-context

Before modifying any code in a project directory, read the project's PROJECT.md (if present) to learn its conventions, structure, and rules. This prevents the most common drift: the agent inventing a parallel implementation instead of editing the one that exists.

When to use

• The user references a directory or codebase ("the TUI", "the parser", "the lazartui").
• You're about to write code under $LAZAR_HOME/workspace/<project>/ or similar.
• You need to know "where does X live?" or "what language/framework does this project use?"

How to use

1. Identify the project root. Usually it's:

   • The deepest directory containing PROJECT.md (or README.md if no PROJECT.md).
   • The deepest directory containing a manifest like go.mod, Cargo.toml, package.json.

2. Read the project pin:

   cat <project-root>/PROJECT.md 2>/dev/null \
     || cat <project-root>/AGENTS.md 2>/dev/null \
     || ls <project-root>          # fall back to listing files
   

3. Follow the conventions in PROJECT.md verbatim — language, file layout, build commands, "do not" rules.

4. If PROJECT.md says "always read X first", do that next.

5. If there is NO PROJECT.md, infer from the manifest and existing files. Read the entry point (main.go, src/lib.rs, index.ts) before suggesting changes.

Hard rules

• Never create parallel implementations. If main.go exists, modify main.go. Don't write main2.go "to experiment". If you need to experiment, branch with git, not with file proliferation.
• Don't introduce new languages or frameworks unless PROJECT.md explicitly invites it. The presence of go.mod means Go is the language; don't suddenly add Python.
• Read before writing. For any non-trivial edit, read the file you're about to modify in full. Patch in place; don't rewrite.
• Stay inside the project root. Don't create new directories at the workspace level "for organization" unless asked.

Anti-patterns to recognize in yourself