Shared source map

AI steering files for real projects.

This site and the README are rendered from the same content map, so the guidance stays in sync as the repo grows. Use it to see which files matter, what each one should contain, and where to add new context without making the tree noisy.

Shared source: src/data/steering-data.js

Agent-Agnostic Files

Agent-Agnostic Files

These files should stay useful no matter which assistant is reading the repo.

AGENTS.md

AGENTS.md

The vendor-neutral operating manual for coding agents.

Use it for: repo-specific agent behavior, safe defaults and guardrails, commands that are reliable in this repo, review and merge expectations

Should contain

  • project summary
  • preferred workflow
  • exact install, test, lint, build, and deploy commands
  • branch policy
  • risky actions that need approval
  • any do-not-do-this-casually rules

PRODUCT.md

PRODUCT.md

Product context that keeps implementation choices aligned with the business.

Use it for: target users, the problem being solved, major workflows, business objectives and success criteria

Should contain

  • why the project exists
  • who it is for
  • what good looks like
  • what is in scope and out of scope
  • the outcomes that matter most

TECH.md

TECH.md

The technical source of truth for stack and implementation constraints.

Use it for: frameworks and libraries, runtime versions, build and test commands, deployment targets and integration points

Should contain

  • the canonical stack
  • supported commands
  • preferred libraries and frameworks
  • external services and APIs
  • the constraints agents must respect

STRUCTURE.md

STRUCTURE.md

A map of the repository that helps agents put changes in the right place.

Use it for: top-level directory layout, naming conventions, import patterns, module boundaries

Should contain

  • a directory map
  • ownership boundaries
  • import rules
  • placement rules for new files
  • special-case folders that matter for the agent

VISION.md

VISION.md

The durable product and taste direction that should change less often than product specs.

Use it for: long-term product vision, non-goals, design and product taste, the kind of future you are trying to create

Should contain

  • vision and constraints
  • what the project should become
  • what should never drift
  • success criteria at the level of outcomes, not implementation

DESIGN.md

DESIGN.md

A design-system source of truth for AI-generated interface work.

Use it for: design tokens, typography, spacing, color principles, component patterns, accessibility expectations

Should contain

  • the visual language
  • spacing and type rules
  • layout constraints
  • component style preferences
  • things the agent should avoid when generating UI

Agent-Specific Files

Agent-Specific Files

These files should exist when a tool needs its own memory, syntax, or scope rules.

CLAUDE.md

CLAUDE.md

The Claude Code instruction file.

Use it for: Claude-specific guidance, repo conventions that should persist across Claude sessions, build/test/verify expectations for Claude, workflow notes that are useful for Claude but not all tools

Should contain

  • project-specific instructions
  • code style and review rules
  • build and test commands
  • escalation boundaries
  • paths or workflows Claude should treat specially

GEMINI.md

GEMINI.md

The Gemini CLI / Gemini agent context file.

Use it for: Gemini-specific instructions, repo conventions that should persist across Gemini sessions, project context and response preferences, custom commands or tool usage hints

Should contain

  • project-specific context
  • coding conventions
  • build/test/verify notes
  • any files or folders Gemini should prioritize

.github/copilot-instructions.md

.github/copilot-instructions.md

The repository-wide GitHub Copilot instructions file.

Use it for: instructions that should apply to Copilot across the repo, build/test/validation guidance, repo-specific coding standards, review and safety expectations

Should contain

  • how to build and test the repo
  • conventions and patterns to follow
  • constraints that should always be respected
  • any special validation steps

.cursor/rules/*.mdc

.cursor/rules/*.mdc

Path-scoped Cursor rules for workflows that should only apply in specific places.

Use it for: file-specific or workflow-specific rules, path-scoped instructions, rule sets that should only apply in certain parts of the repo, agent behavior that needs to be narrower than a repo-wide file

Should contain

  • path or task scope
  • the conventions to follow in that scope
  • examples of good output
  • what should auto-apply vs stay manual

Writing checklist

Good steering files are short, specific, and grounded in the repo.

  1. Say what the file controls. Start with the scope and the intended reader.
  2. Prefer commands over vibes. Include exact install, test, lint, build, and deploy commands.
  3. Name the good examples. Point agents to files and modules that show the preferred pattern.
  4. Document constraints. Spell out security, data, accessibility, performance, and product boundaries.
  5. Keep the source shared. Edit the data map once, then render the site and README from it.
  6. Review after real agent work. Update the files when agents repeatedly ask the same question or make the same mistake.