{"owner":"pierrecomputer","repo":"pierre","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# PierreJS Monorepo\n\n## Agent Environment\n\nSet `AGENT=1` at the start of every terminal session so Bun's test runner emits\nAI-friendly output:\n\n```bash\nexport AGENT=1\n```\n\nMost local moon tasks (formatters, benchmarks, worktree management) are\nconfigured with `runInCI: 'always'` so they keep working in CI-marked shells\nlike agent harnesses. Tasks connected to the build graph (dev servers, prod\nserves, e2e variants, publish guards) stay CI-skipped — run those with\n`moonx <target> --ignore-ci-checks`, e.g.\n`moonx docs:dev-diffs --ignore-ci-checks`. For non-moon commands that CI-gate\nthemselves, unset the var: `CI= pnpm publish --dry-run`.\n\n## Toolchain\n\n- Tool versions (bun, pnpm, node, moon, gh) are pinned in `.prototools` and\n  managed by [proto](https://moonrepo.dev/docs/proto); run `proto use` if a tool\n  is missing or a pin changed. Never install toolchain versions globally; bump\n  pins only in `.prototools`.\n- [moon](https://moonrepo.dev/docs) is the task runner; `package.json` scripts\n  are npm lifecycle hooks only.\n\n## Core Rules\n\n- Use `pnpm` for install/add/remove/dedupe/package-manager and publishing work.\n  Do not use `bun`, `npm`, `yarn`, `npx`, or similar tools for package\n  operations unless there is a specific reason.\n- Dependencies use the `catalog` in `pnpm-workspace.yaml`. Never add dependency\n  versions directly to package-level `package.json` files unless a published\n  package intentionally needs its own range.\n- Run tasks through moon: `moon run <project>:<task>` (or the `moonx` shorthand)\n  works from anywhere in the repo. `moonx <project>:<task> -- args` forwards\n  arguments. Discover tasks with `moon tasks <project>`.\n- Preserve trailing newlines at the end of files.\n- Setup steps for a fresh clone live in `CONTRIBUTING.md`.\n\n## Licensing\n\nEvery package in this repo is licensed under Apache 2.0. When adding a new\npackage under `packages/*` or `apps/*`:\n\n- Set `\"license\": \"apache-2.0\"` in its `package.json`.\n- Add an Apache 2.0 `LICENSE.md` at the package root — copy one from an existing\n  package (e.g. `packages/trees/LICENSE.md`).\n\nVendored third-party code keeps its original license; record that attribution in\na `NOTICE.md` next to the package rather than changing its LICENSE.\n\n`moon run root:check-licenses` enforces both requirements and runs in CI on\nevery PR.\n\n## Skills\n\nDomain-specific context and conventions live in `.agents/skills/`. Before\nstarting any task:\n\n1. List `.agents/skills/*/SKILL.md`\n2. Read only each skill's frontmatter description to identify relevant skills\n3. Read only the full `SKILL.md` files relevant to your task\n\nDo not load skills that are not relevant to the task.\n\n## Agent Artifacts\n\nWrite agent-only planning and scratch artifacts under `.agents/ignore/` by\ndefault:\n\n- Plans: `.agents/ignore/plans/YYYY-MM-DD-<topic>.md`\n- Specs: `.agents/ignore/specs/YYYY-MM-DD-<topic>.md`\n\n`.agents/ignore/` is gitignored. Do not put source files, tests, or committed\ndocumentation there.\n\n## Verification Baseline\n\nAfter code changes, verification is not complete until you have run these from\nanywhere in the repo:\n\n```bash\nmoon run root:format root:lint\n```\n\nAlso run the affected typecheck and focused tests for the changed area, e.g.\n`moonx <project>:typecheck` and `moonx <project>:test` (or\n`moonx :typecheck --affected`). For docs-only or AGENTS/skill-only changes,\nformatting and linting are sufficient unless the edit touches executable code or\npackage config.\n\n## Code Readability\n\n- When adding non-trivial helpers, prefer a short comment directly above the\n  function explaining what the helper does and why it exists.\n- Write comments for readers new to the codepath. Avoid vague shorthand like\n  \"snapshot\" unless you immediately explain what data is captured or derived.\n- Prefer function-level comments over many inline comments. Use inline comments\n  only when a specific step is still non-obvious.\n- Keep comments concrete and behavior-focused.\n"},"files":{"AGENTS.md":"# PierreJS Monorepo\n\n## Agent Environment\n\nSet `AGENT=1` at the start of every terminal session so Bun's test runner emits\nAI-friendly output:\n\n```bash\nexport AGENT=1\n```\n\nMost local moon tasks (formatters, benchmarks, worktree management) are\nconfigured with `runInCI: 'always'` so they keep working in CI-marked shells\nlike agent harnesses. Tasks connected to the build graph (dev servers, prod\nserves, e2e variants, publish guards) stay CI-skipped — run those with\n`moonx <target> --ignore-ci-checks`, e.g.\n`moonx docs:dev-diffs --ignore-ci-checks`. For non-moon commands that CI-gate\nthemselves, unset the var: `CI= pnpm publish --dry-run`.\n\n## Toolchain\n\n- Tool versions (bun, pnpm, node, moon, gh) are pinned in `.prototools` and\n  managed by [proto](https://moonrepo.dev/docs/proto); run `proto use` if a tool\n  is missing or a pin changed. Never install toolchain versions globally; bump\n  pins only in `.prototools`.\n- [moon](https://moonrepo.dev/docs) is the task runner; `package.json` scripts\n  are npm lifecycle hooks only.\n\n## Core Rules\n\n- Use `pnpm` for install/add/remove/dedupe/package-manager and publishing work.\n  Do not use `bun`, `npm`, `yarn`, `npx`, or similar tools for package\n  operations unless there is a specific reason.\n- Dependencies use the `catalog` in `pnpm-workspace.yaml`. Never add dependency\n  versions directly to package-level `package.json` files unless a published\n  package intentionally needs its own range.\n- Run tasks through moon: `moon run <project>:<task>` (or the `moonx` shorthand)\n  works from anywhere in the repo. `moonx <project>:<task> -- args` forwards\n  arguments. Discover tasks with `moon tasks <project>`.\n- Preserve trailing newlines at the end of files.\n- Setup steps for a fresh clone live in `CONTRIBUTING.md`.\n\n## Licensing\n\nEvery package in this repo is licensed under Apache 2.0. When adding a new\npackage under `packages/*` or `apps/*`:\n\n- Set `\"license\": \"apache-2.0\"` in its `package.json`.\n- Add an Apache 2.0 `LICENSE.md` at the package root — copy one from an existing\n  package (e.g. `packages/trees/LICENSE.md`).\n\nVendored third-party code keeps its original license; record that attribution in\na `NOTICE.md` next to the package rather than changing its LICENSE.\n\n`moon run root:check-licenses` enforces both requirements and runs in CI on\nevery PR.\n\n## Skills\n\nDomain-specific context and conventions live in `.agents/skills/`. Before\nstarting any task:\n\n1. List `.agents/skills/*/SKILL.md`\n2. Read only each skill's frontmatter description to identify relevant skills\n3. Read only the full `SKILL.md` files relevant to your task\n\nDo not load skills that are not relevant to the task.\n\n## Agent Artifacts\n\nWrite agent-only planning and scratch artifacts under `.agents/ignore/` by\ndefault:\n\n- Plans: `.agents/ignore/plans/YYYY-MM-DD-<topic>.md`\n- Specs: `.agents/ignore/specs/YYYY-MM-DD-<topic>.md`\n\n`.agents/ignore/` is gitignored. Do not put source files, tests, or committed\ndocumentation there.\n\n## Verification Baseline\n\nAfter code changes, verification is not complete until you have run these from\nanywhere in the repo:\n\n```bash\nmoon run root:format root:lint\n```\n\nAlso run the affected typecheck and focused tests for the changed area, e.g.\n`moonx <project>:typecheck` and `moonx <project>:test` (or\n`moonx :typecheck --affected`). For docs-only or AGENTS/skill-only changes,\nformatting and linting are sufficient unless the edit touches executable code or\npackage config.\n\n## Code Readability\n\n- When adding non-trivial helpers, prefer a short comment directly above the\n  function explaining what the helper does and why it exists.\n- Write comments for readers new to the codepath. Avoid vague shorthand like\n  \"snapshot\" unless you immediately explain what data is captured or derived.\n- Prefer function-level comments over many inline comments. Use inline comments\n  only when a specific step is still non-obvious.\n- Keep comments concrete and behavior-focused.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# PierreJS Monorepo\n\n## Agent Environment\n\nSet `AGENT=1` at the start of every terminal session so Bun's test runner emits\nAI-friendly output:\n\n```bash\nexport AGENT=1\n```\n\nMost local moon tasks (formatters, benchmarks, worktree management) are\nconfigured with `runInCI: 'always'` so they keep working in CI-marked shells\nlike agent harnesses. Tasks connected to the build graph (dev servers, prod\nserves, e2e variants, publish guards) stay CI-skipped — run those with\n`moonx <target> --ignore-ci-checks`, e.g.\n`moonx docs:dev-diffs --ignore-ci-checks`. For non-moon commands that CI-gate\nthemselves, unset the var: `CI= pnpm publish --dry-run`.\n\n## Toolchain\n\n- Tool versions (bun, pnpm, node, moon, gh) are pinned in `.prototools` and\n  managed by [proto](https://moonrepo.dev/docs/proto); run `proto use` if a tool\n  is missing or a pin changed. Never install toolchain versions globally; bump\n  pins only in `.prototools`.\n- [moon](https://moonrepo.dev/docs) is the task runner; `package.json` scripts\n  are npm lifecycle hooks only.\n\n## Core Rules\n\n- Use `pnpm` for install/add/remove/dedupe/package-manager and publishing work.\n  Do not use `bun`, `npm`, `yarn`, `npx`, or similar tools for package\n  operations unless there is a specific reason.\n- Dependencies use the `catalog` in `pnpm-workspace.yaml`. Never add dependency\n  versions directly to package-level `package.json` files unless a published\n  package intentionally needs its own range.\n- Run tasks through moon: `moon run <project>:<task>` (or the `moonx` shorthand)\n  works from anywhere in the repo. `moonx <project>:<task> -- args` forwards\n  arguments. Discover tasks with `moon tasks <project>`.\n- Preserve trailing newlines at the end of files.\n- Setup steps for a fresh clone live in `CONTRIBUTING.md`.\n\n## Licensing\n\nEvery package in this repo is licensed under Apache 2.0. When adding a new\npackage under `packages/*` or `apps/*`:\n\n- Set `\"license\": \"apache-2.0\"` in its `package.json`.\n- Add an Apache 2.0 `LICENSE.md` at the package root — copy one from an existing\n  package (e.g. `packages/trees/LICENSE.md`).\n\nVendored third-party code keeps its original license; record that attribution in\na `NOTICE.md` next to the package rather than changing its LICENSE.\n\n`moon run root:check-licenses` enforces both requirements and runs in CI on\nevery PR.\n\n## Skills\n\nDomain-specific context and conventions live in `.agents/skills/`. Before\nstarting any task:\n\n1. List `.agents/skills/*/SKILL.md`\n2. Read only each skill's frontmatter description to identify relevant skills\n3. Read only the full `SKILL.md` files relevant to your task\n\nDo not load skills that are not relevant to the task.\n\n## Agent Artifacts\n\nWrite agent-only planning and scratch artifacts under `.agents/ignore/` by\ndefault:\n\n- Plans: `.agents/ignore/plans/YYYY-MM-DD-<topic>.md`\n- Specs: `.agents/ignore/specs/YYYY-MM-DD-<topic>.md`\n\n`.agents/ignore/` is gitignored. Do not put source files, tests, or committed\ndocumentation there.\n\n## Verification Baseline\n\nAfter code changes, verification is not complete until you have run these from\nanywhere in the repo:\n\n```bash\nmoon run root:format root:lint\n```\n\nAlso run the affected typecheck and focused tests for the changed area, e.g.\n`moonx <project>:typecheck` and `moonx <project>:test` (or\n`moonx :typecheck --affected`). For docs-only or AGENTS/skill-only changes,\nformatting and linting are sufficient unless the edit touches executable code or\npackage config.\n\n## Code Readability\n\n- When adding non-trivial helpers, prefer a short comment directly above the\n  function explaining what the helper does and why it exists.\n- Write comments for readers new to the codepath. Avoid vague shorthand like\n  \"snapshot\" unless you immediately explain what data is captured or derived.\n- Prefer function-level comments over many inline comments. Use inline comments\n  only when a specific step is still non-obvious.\n- Keep comments concrete and behavior-focused.\n","category":"root","tokens":989}]}