{"owner":"quasarframework","repo":"quasar","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"files":{"AGENTS.md":"# Quasar Repository Agent Guide\n\nApplies repo-wide; a nested `AGENTS.md` takes precedence for its directory\n(most packages have one — check).\n\nWhen editing any `AGENTS.md` (this one included), keep it to commands,\npackage-specific gotchas and pointers into code. State repo-wide\nmechanics once — here, not per package; leave design rationale to code\ncomments; drop whatever an agent can discover from the code or never\nacts on. Exception: procedures that must be followed exactly (e.g.\n/ui's Specs workflow) earn their length.\n\n## Workflow\n\n- pnpm workspace; run commands from the repo root unless a package's docs\n  say otherwise.\n- Formatting `oxfmt`, linting `oxlint` (root `lint`/`lint:check` scripts,\n  lint-staged pre-commit). Never introduce Prettier, ESLint or any other\n  formatter/linter.\n- Before changing a package, inspect its `package.json`, nearby tests and\n  READMEs.\n- Keep changes focused; don't modify, discard or commit unrelated work\n  already in the worktree.\n- Follow existing code/test patterns. Any user-observable change (options,\n  defaults, requirements, behavior, performance, setup) is incomplete until\n  related tests, types, API JSON and the covering `docs/src/pages` pages —\n  including their `docs/src/examples` components — (search there for the\n  option/feature name) are updated in the same change set.\n\n## Code style\n\n- Never compare a native method's guaranteed-strict-boolean result\n  (`RegExp.test()`, `some()`/`every()`/`includes()`, `has()`,\n  `startsWith()`/`endsWith()`, `Object.hasOwn()`, `Number.isNaN()`,\n  `existsSync()`, …) against `=== true`/`=== false`; use it directly or\n  negate with `!`.\n- DO keep explicit comparisons for non-guaranteed booleans: user-provided\n  options, possibly-`undefined` values, project functions (their\n  implementation can drift to non-boolean returns and silently break\n  truthiness-based call sites).\n\n## Generated Quasar configuration\n\n- `quasar dev`/`build` generate `.quasar/` (tsconfig + type files);\n  `quasar prepare` does the same without a dev server or build.\n- Prepare after a fresh/clean checkout, after dependency/config changes\n  affecting generated types, and whenever lint/typechecking reports\n  `.quasar/tsconfig.json` missing or unreadable.\n- Root `pnpm prepare:types` prepares all packages defining that script;\n  `pnpm --dir <app-dir> exec quasar prepare --silent` prepares one app.\n- `.quasar` is generated output; never edit or commit it.\n\n## Validation\n\n- Narrowest relevant test while developing; the package's complete relevant\n  suite before handoff.\n- Root `pnpm test:all` runs every package's full suite — hours long,\n  meant for release-grade sweeps, never routine development.\n- Tests, dev servers and builds that need the built ui package\n  self-heal: they build it only when `ui/dist` is missing or stale\n  (`ui/build/build-stamp.js`), so expect an occasional multi-minute ui\n  build mid-command. The scaffolding e2e suites install the monorepo's\n  own packages through a throwaway local registry\n  (`create-quasar/test/e2e/local-registry.js`) — published npm packages\n  are never tested; after publishing a release train, sanity-check the\n  uploads with `npm create quasar@latest` in a temp dir.\n- Run `pnpm lint` when linted source may be affected: it runs `oxfmt`\n  (rewrites in place) then `oxlint --fix`; review the diff and hand-fix\n  what `oxlint` still reports. `pnpm lint:check` is a read-only CI gate —\n  not for finding issues.\n- Run `git diff --check` before committing.\n- Never weaken assertions, ignore generated cases or change production\n  behavior just to make a failing test pass; diagnose the contract first.\n- Don't scatter fixture-content or presentation-formatting literals through\n  assertions. Prefer, in order: derive the expected value from the fixture\n  itself; assert semantic shape via regex (label + value, never column\n  padding); else declare ONE named constant documenting the owning file,\n  with a breadcrumb comment at the fixture pointing back. Test-created\n  values may be asserted directly.\n- Tests may write only to OS temp dirs or gitignored generated paths. A\n  test that must mutate a tracked repo file follows app-vite's e2e\n  backup/restore protocol (pristine copy to a gitignored sibling before\n  modifying, self-heal from it on the next run) so a killed run can never\n  leave the worktree dirty.\n- Report every validation command run and its outcome; if one can't run,\n  state the exact blocker.\n\n## Pull requests\n\n- One logical change per PR; describe root cause/motivation, user/developer\n  impact and validation results.\n- Call out public API, SSR, hydration, platform, accessibility or security\n  implications when applicable.\n- No unrelated dependency, lockfile, formatting or generated-file changes.\n- Automated review output (CodeRabbitAI etc.) is advisory: verify each\n  claim against current code, tests, generated Specs and the intended\n  contract; apply valid findings, reject or explain the rest — never change\n  code or weaken tests merely to satisfy a bot.\n"}}