Amazon Q Developer already reads project rules. Give it one that stops overpaying.

Per AWS's own docs, "the Q CLI has become the Kiro CLI" — so if you're looking for a terminal agent, that's the Kiro page, not this one. What's still called "Amazon Q Developer" today is the IDE chat (VS Code, JetBrains, Visual Studio, Eclipse) and the GitHub/GitLab integrations — both of which read the .amazonq/rules mechanism this page targets. Worth knowing before you install: AWS has also announced it will discontinue the Amazon Q Developer IDE plugins specifically on April 30, 2027, and is steering users toward Kiro for that surface too. Sources: AWS's command-line docs and the end-of-support notice on the Amazon Q Developer overview page.

How this maps onto Amazon Q Developer

One confirmed mechanism: project rules under .amazonq/rules.

Per Amazon Q Developer's own docs on project rules, you build a library of project-specific guidelines — coding standards, best practices — as plain Markdown files in project-root/.amazonq/rules. Once they exist, Amazon Q "will automatically use them as context whenever a developer chats with Amazon Q within your project, and will make sure to adhere to them when generating answers." You can create a rule file directly on disk, or from inside the IDE chat panel via the Rules button → Create new rule, which writes the same Markdown file for you. Individual rules can also be toggled on or off per chat session from that same Rules menu.

The same folder convention carries over to Amazon Q Developer's GitHub and GitLab integrations: commit a Markdown file to project-root/.amazonq/rules in a third-party-connected repo, and Amazon Q Developer "will automatically use them as context within your project, and will make sure to adhere to them when generating code for feature development." Two surfaces, one path, both documented by AWS itself — that's the confirmed mechanism this page installs to.

Undercut's tier names — cheap, standard, frontier, apex — are generic on purpose. Amazon Q Developer is built on Amazon Bedrock rather than tied to a single named model, so models.md gives the rule of thumb rather than a fixed slug. Nothing about this sits between Amazon Q Developer and its model backend — it's plain Markdown Amazon Q reads into context, no proxy, no network hop, nothing to route around if you remove the file.

Install for Amazon Q Developer

Free. MIT. Nothing installs, nothing proxies your traffic.

Option 1 — write the rule file directly (recommended, confirmed path)

Amazon Q Developer's own docs say a project rule can be "a filename of your choice" — save the policy as a Markdown file anywhere under .amazonq/rules at your project root and it's picked up automatically, no restart required.

Option 2 — use the Rules button in the IDE chat panel

Prefer not to touch the filesystem? Open the Amazon Q chat panel in your IDE, click Rules → Create new rule, name it, then paste in the policy text below — this writes the identical file to the same folder.

Option 3 — commit it for GitHub or GitLab feature development

Same folder, same file, committed to a repo connected to Amazon Q Developer's GitHub or GitLab integration — per AWS's own third-party docs, it's picked up automatically when Amazon Q generates code for feature development in that repo, no separate configuration needed.

Validate it yourself

1. 1Read the published results — testing/README.md and the raw JSON in testing/results/
2. 2Reproduce for free, no API key, no spend: node src/main.js --mock
3. 3Open the Amazon Q chat panel on a repo with the rule file in place, check the Rules menu to confirm it's listed and active, then ask it to do a small mechanical task

Zero lock-in. It's a Markdown file Amazon Q Developer reads — delete it or untoggle it in the Rules menu and you're back to status quo.

Six flags assign a tier. Three triggers are the only way up.

This is a named, versioned spec — not internal logic we could quietly change. When the rubric changes (a new flag, a different cap), the version number moves and the changelog says why.

Every unit of work gets scored against six flags, then assigned the cheapest tier that can plausibly handle it. It only moves up a tier when something objective proves it needs to — a failed check, a measured disagreement, an explicit uncertainty flag. It never moves up on a guess, and it never moves back down mid-task.

 unit of work
      |
  6-flag rubric
      |
  +---+----+
  | 0 flags|--> cheap
  | 1-2    |--> standard
  | 3+/own |--> frontier
  +---+----+
      | fail x2 / disagree / uncertain
      v
  escalate +1 tier
  (residue only)
      |
  still unresolved?
      v
  single batched
  apex tie-break

Why it holds up

Flags steer. Verification and escalation decide.

Even when the rubric flags are scored imperfectly, the escalator still routes work to the right tier almost every time — because a wrong flag only ever costs one extra cheap attempt, never a wrong answer or a big bill.

Honest limits

What this doesn't do.

Not a proxy, not a gateway, doesn't enforce anything at the network layer, and doesn't auto-flag in production — Amazon Q Developer scores the flags itself (measured robust to getting them wrong, see above). Doesn't promise a dollar figure for your workload — every figure on this page is an observation from our tasks and our graders, not a guarantee about yours; verification is not proof, it's a reproducible data point you can run yourself. It also doesn't cover a CLI — AWS's own docs say the Q CLI is now the Kiro CLI, so if that's what you run, see the Kiro page instead; this one covers the IDE chat and the GitHub/GitLab integrations, and the IDE plugins specifically are on a path to end of support on April 30, 2027 per AWS's own notice. And we found no documented user-level (~/.amazonq/rules) equivalent or a skills.sh install target — treat both as absent rather than untested. Full list of general limits, with the finance/procurement note and the paid-tier disclosure, is on the main page.