{}Agent Hub

Guides

How to actually use these files

Generating the bundle is the easy part. This page covers what an agent instruction file changes, how each supported tool discovers and reads its own file, what's worth customizing before you commit it, and how to write directives of your own if you'd rather build a bundle by hand.

What these files actually do

Every AI coding tool on this list — GitHub Copilot, Claude Code, Cursor, Windsurf, Cline, Continue.dev, Aider — reads some form of repository-level context before it starts working: a system prompt it silently prepends to every request in that repo. Left at its defaults, that context is generic. It doesn't know your team formats SQL with parameterized queries, that this repo's tests live next to the code instead of in a mirrored tests/ tree, or that a README.md update is expected with every public API change.

An instruction file replaces that generic default with specifics. It's not a suggestion the agent might follow — for most of these tools it's literally concatenated into the same context window as your prompt, every single time, so "never hard-code a secret" or "use Result<T, E>, not .unwrap()" stops being something you repeat in every session and becomes something the agent already knows before you ask.

Agent Hub's generated file goes one step further than a loose list of preferences: it's built around a fixed set of 10 Core Operating Directives — the things that go wrong in real AI-assisted coding sessions regardless of stack (hallucinated APIs, missing tests, swallowed exceptions, stale READMEs) — filled in with your stack's actual idioms, file globs and anti-patterns.

The 10 Core Operating Directives

Every generated Master Agent file — for every stack, for every tool — is built around the same ten directives, each filled in with your stack's specifics.

  1. 1

    Zero Hallucination & Codebase Verification

    Read real files and real dependency versions before proposing a change. Never invent an API, package or config option.

  2. 2

    Strict Type Safety & Schemas

    Full type coverage at every boundary — your stack's own idiom for it, from mypy --strict to Pydantic v2 to Result<T, E>.

  3. 3

    Bug Prevention & Defensive Logic

    Validate edge cases explicitly: empty input, null, zero, negatives, boundary values, unexpected types.

  4. 4

    Token Efficiency

    The minimal correct diff — no full-file reprints, no narrated walkthroughs, no unrequested refactors.

  5. 5

    Comprehensive Unit Testing

    Happy path, edge cases and at least one failure mode for every new or changed unit — mocked, not hitting real infra.

  6. 6

    OWASP & Security Standards

    Every external input is untrusted until validated. No hard-coded secrets. No injection, XSS or unsafe deserialization.

  7. 7

    Performance & Resource Management

    Your stack's actual hot-path concern — N+1 queries, blocked event loops, goroutine leaks, unbounded buffering.

  8. 8

    Architectural Consistency

    Match this repo's existing structure and conventions — flag inconsistency instead of silently picking a third pattern.

  9. 9

    Error Handling & Logging

    Explicit, structured, actionable error handling. No bare catch-and-ignore. No secrets in logs.

  10. 10

    Automated Documentation & README Sync

    Mandatory, not optional: every feature, API or dependency change gets README.md updated in the same pass.

Per-tool setup guide

Exactly how each supported tool discovers and reads the file(s) Agent Hub generates for it, straight from each vendor's own docs.

GitHub Copilot — GitHub

Official docs ↗

Repo-wide custom instructions Copilot Chat, code review and the coding agent all read automatically — nothing to enable in the editor.

.github/copilot-instructions.md · .github/agents/<slug>-agent.md

How it's read: Copilot Chat (VS Code, JetBrains, Visual Studio, github.com) loads .github/copilot-instructions.md automatically on every chat turn inside the repo.

  1. 1.Extract the zip at your repository root so .github/ sits next to package.json / pyproject.toml / go.mod / etc.
  2. 2.Commit both files — Copilot reads copilot-instructions.md automatically, with no setting to flip.
  3. 3.Open Copilot Chat in VS Code, JetBrains or Visual Studio and ask a repo question — the response will reflect the instructions.
  4. 4.On github.com, Copilot code review and the Copilot coding agent read the same file for PR-level suggestions and autonomous tasks.

Claude Code — Anthropic

Official docs ↗

A root CLAUDE.md Claude Code loads at the start of every session, plus an installable subagent under .claude/agents/.

CLAUDE.md · .claude/agents/<slug>-agent.md

How it's read: Claude Code reads CLAUDE.md from the repository root (and any parent directory) automatically when it starts a session in this project.

  1. 1.Extract the zip at your repository root so CLAUDE.md and .claude/ sit next to your project's top-level files.
  2. 2.Commit CLAUDE.md — Claude Code loads it automatically for everyone working in the repo, no configuration needed.
  3. 3.Optional: run /agents inside Claude Code to see the generated subagent(s) listed, or invoke one directly by name for a focused task.
  4. 4.Run claude in the repo root and ask it to make a change — it will follow the directives without being reminded.

Cursor — Anysphere

Official docs ↗

A project rule under .cursor/rules/*.mdc, set to always-apply so it's active in every Cursor chat and Tab completion in this repo.

.cursor/rules/<slug>-agent.mdc

How it's read: Cursor reads every .mdc file under .cursor/rules/ at project load; alwaysApply: true in its frontmatter means it's attached to every request without you mentioning it.

  1. 1.Extract the zip at your repository root so .cursor/rules/ sits at the project root.
  2. 2.Commit the .mdc file(s) — Cursor picks up project rules automatically the next time the project is opened.
  3. 3.Open Cursor Settings → Rules to confirm each rule is listed and enabled if you want to double-check.
  4. 4.Start a Cursor Chat or Composer session in the repo — every always-apply rule applies without needing to be pasted in.

Windsurf — Cognition

Official docs ↗

A single flat .windsurfrules file at the repo root, read automatically by Windsurf's Cascade agent.

.windsurfrules

How it's read: Windsurf's Cascade agent reads .windsurfrules from the workspace root automatically on every request in that workspace.

  1. 1.Extract the zip at your repository root so .windsurfrules sits next to your project's top-level files.
  2. 2.Commit the file — Cascade picks it up automatically the next time the workspace is opened.
  3. 3.Windsurf reads one flat file, so a multi-stack selection is always merged into one file for this tool, the same way Combined mode works for every target.
  4. 4.Start a Cascade conversation in the repo and ask it to make a change — it will follow the directives without being reminded.

Cline — Cline (VS Code extension)

Official docs ↗

A project rule file under .clinerules/, toggled on or off per-rule from the Cline sidebar.

.clinerules/<slug>-agent.md

How it's read: Cline reads every file under .clinerules/ in the workspace and lists them as toggleable rules in its sidebar; enabled rules are included in context automatically.

  1. 1.Extract the zip at your repository root so .clinerules/ sits at the project root.
  2. 2.Commit the file(s) — open the Cline sidebar's Rules section to confirm each is listed and toggled on.
  3. 3.Start a new Cline task in the repo — enabled rules are included in context without pasting them in.

Continue.dev — Continue

Official docs ↗

A rule block under .continue/rules/, picked up by the Continue extension for VS Code and JetBrains.

.continue/rules/<slug>-agent.md

How it's read: Continue reads Markdown rule files under .continue/rules/ in the workspace and applies them to chat and autocomplete requests in that project.

  1. 1.Extract the zip at your repository root so .continue/rules/ sits at the project root.
  2. 2.Commit the file(s) — Continue picks up workspace rules automatically the next time the project loads.
  3. 3.Open the Continue panel and ask it to make a change in the repo — the rule(s) apply without being pasted in.

Aider — Aider (open source)

Official docs ↗

A plain CONVENTIONS.md plus an .aider.conf.yml snippet that tells Aider to read it on every run.

CONVENTIONS.md · .aider.conf.yml

How it's read: Aider doesn't auto-discover a conventions file by name — it reads whatever file(s) the read: option in .aider.conf.yml (or the --read flag) points at, on every run.

  1. 1.Extract the zip at your repository root so CONVENTIONS.md and .aider.conf.yml sit at the project root.
  2. 2.If you already have an .aider.conf.yml, merge in the generated read: line instead of overwriting your file.
  3. 3.Commit both files — anyone running aider in the repo now gets the conventions loaded automatically.
  4. 4.Aider reads one plain file, so a multi-stack selection is always merged into one CONVENTIONS.md, the same way Combined mode works for every target.

AGENTS.md (Universal) — Open, multi-vendor convention

Official docs ↗

One plain-Markdown AGENTS.md at the repo root — the emerging open convention already read by OpenAI Codex, Jules, Amp, RooCode and others, and a sane fallback for any tool without dedicated support here.

AGENTS.md

How it's read: Tools built on the AGENTS.md convention look for this exact filename at the repository root (or nearest parent) and load it automatically — no per-tool configuration.

  1. 1.Extract the zip at your repository root so AGENTS.md sits next to your project's top-level files.
  2. 2.Commit it — any AGENTS.md-aware tool picks it up automatically with no setup.
  3. 3.AGENTS.md is one flat file by convention, so a multi-stack selection is always merged into one file here, the same way Combined mode works for every target.

What to customize first

The generated file is a strong, opinionated default — not a rulebook to commit unread. Before you do, spend five minutes on these:

Test framework name

The testing directive says "whatever this repo already has configured" — if that's not obviously discoverable (a monorepo with several), name it explicitly: pytest, Vitest, JUnit 5, RSpec.

Primary surface globs

Check the file globs match your actual folder layout, especially in a monorepo — a Next.js app under apps/web/ needs apps/web/src/app/**, not the generic src/app/**.

House rules

Add anything specific to how your team ships: required PR template sections, a changelog file to update alongside README, a specific branch-naming or commit-message convention.

Anti-patterns

Add the two or three mistakes that actually keep showing up in your PRs — the generated list is realistic but generic; your repo's own recurring review comments are more valuable than any template.

Writing directives that actually work

Building your own from scratch, or extending a generated file? These hold up across every tool on this list:

  • Be specific, not aspirational. "Write clean code" changes nothing — an agent has no way to act on it. "Every public function gets a type hint; run mypy --strict in CI" is checkable and specific enough to actually follow.
  • State the failure mode, not just the rule. "Validate input" is vague. "Treat every request body, query param and header as untrusted until validated — this prevents injection and mass-assignment bugs" gives the agent a reason, which holds up better against edge cases the rule alone doesn't cover.
  • Prefer a small number of directives enforced consistently over a long list skimmed once. Context windows aren't infinite and attention degrades over a long prompt — ten directives that are always followed beat forty that are half-ignored.
  • Give it a working agreement, not just a list. A short, ordered "verify, then write, then review against security/performance, then match conventions, then handle errors, then update docs" sequence at the end turns a list of rules into an actual process the agent runs through.
  • Don't claim capabilities the tool doesn't have. If your repo has no CI configured yet, don't write "CI will fail if…" — say what a human reviewer should check instead. An instruction that references infrastructure that doesn't exist trains the agent (and your reviewers) to ignore the file.

One master agent vs. many small ones

Early instruction-file setups tend to split concerns into several small files — a security-auditor.md, a test-generator.md, a context-optimizer.md, one specialist file per stack. It reads well in a docs folder, but in practice most tools either load every file in the relevant directory on every request (so you're paying the context-window cost of all of them anyway) or require the agent to be explicitly told which specialist to consult, which defeats the point of an instruction file being read automatically.

Agent Hub deliberately generates one consolidated Master Agent per stack instead: token efficiency, testing, security and stack idioms all live in the same file, all enforced together, on every change — nothing to keep in sync across files, and nothing an agent can partially read.

That said, some tools genuinely benefit from a second, narrower file for a specific job — Claude Code's subagents (.claude/agents/*.md) are invoked deliberately for a focused task rather than loaded on every turn, so Agent Hub generates one alongside CLAUDE.md for exactly that case. The rule of thumb: if a tool auto-loads everything in a folder, keep it to one file; if a tool lets you invoke a specialist by name, a focused specialist file is worth having.

Questions

Do I need to pick just one AI coding tool?+

No. Generate for every tool anyone on your team actually uses — the files don't conflict, and most teams end up with two or three (say, Claude Code + Cursor, or Copilot + AGENTS.md as a fallback for everything else).

Will my team actually follow a file like this?+

The file governs the AI agent's behavior, not your teammates' — it's not a style guide people have to read, it's the context an agent reads before every change so it stops needing to be told the same thing every session.

What if two directives conflict with how my codebase actually works?+

Edit the file. It's a generated starting point, not a contract — trim or reword anything that doesn't match your team's real conventions before committing it. See "What to customize first" below.

Do these files replace code review?+

No — they raise the floor on what an AI agent produces before a human ever looks at it. Treat the agent's output the way you'd treat a capable but new teammate's first draft: reviewed, not rubber-stamped.

Ready to generate your bundle?

Pick a stack, pick your tool(s), download the zip.

Open the generator