{"owner":"1weiho","repo":"open-slide","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# open-slide — Framework Repo Guide\n\nYou are working on the **open-slide framework** — the runtime, CLI, and tooling that ship to npm.\n\n(Slide-authoring guidance lives in the `slide-authoring` / `create-slide` skills under `apps/demo/.claude/skills/`. Use those only when editing files inside `apps/demo/slides/`.)\n\n## Layout\n\npnpm + Turbo monorepo.\n\n| Path | Package | Role |\n| --- | --- | --- |\n| `packages/core` | `@open-slide/core` | Runtime (viewer, present mode, inspector), Vite plugin, `open-slide` dev/build CLI. |\n| `packages/cli` | `@open-slide/cli` | `npx @open-slide/cli init` scaffolder + project template. |\n| `apps/demo` | private | Local consumer of `@open-slide/core` via `workspace:*`. Dogfood target — run `pnpm dev` here to exercise the framework. |\n| `apps/web` | private | Marketing site (Next.js). |\n\nShared config: `biome.json`, `turbo.json`, `pnpm-workspace.yaml`, `tsconfig` per package.\n\n## Workflow\n\n```bash\npnpm dev          # turbo: runs demo against local core\npnpm build        # build all packages\npnpm typecheck    # tsc across the graph\npnpm check        # biome (format + lint + organize imports)\npnpm check:fix    # auto-fix what biome can\npnpm test         # vitest\n```\n\nFilter to one package: `pnpm core <script>` / `pnpm cli <script>`.\n\n## Hard rules\n\n- **Biome must pass before commit.** Run `pnpm check` (or `pnpm check:fix`). CI and the user's review both expect a clean tree.\n- **If `packages/core` or `packages/cli` changes, add a changeset.** Run `pnpm changeset`, pick the right package(s) and bump (`patch` for fixes/polish, `minor` for new public API, `major` for breaking). Apps (`demo`, `web`) and root tooling do **not** need one.\n- **Changeset descriptions: short and direct.** One line, present-tense, what changed from a user's perspective. Match the tone of `.changeset/*.md` already in the repo. No paragraphs, no rationale, no \"this PR…\".\n  - Good: `Replace spinner with a hairline + sliding bar for slide and presenter loading states.`\n  - Bad: `This change introduces a new loading indicator because the previous spinner felt heavy and we wanted something more subtle for presentation contexts…`\n- Don't bump versions or edit `CHANGELOG.md` by hand — `changeset version` owns that.\n- Don't add dependencies casually. The `core` runtime ships to users; every dep inflates install size.\n- `packages/core/src/app/components/ui` is shadcn-generated and biome-ignored — leave it alone unless regenerating.\n- **Default to writing no comments.** Only add one when the WHY is non-obvious — a hidden constraint, a subtle invariant, a workaround for a specific bug, behavior that would surprise a reader. Don't explain WHAT the code does (well-named identifiers handle that), don't reference tasks/PRs/callers (\"added for X\", \"used by Y\"), don't write section-divider banners (`// ── Section ──`) or module-header descriptions, and don't leave commented-out code. If removing a comment wouldn't confuse a future reader, don't write it.\n\n## Releasing (reference)\n\n`pnpm release` builds `core` + `cli` and runs `changeset publish`. Triggered by the maintainer, not by agents.\n"},"files":{"AGENTS.md":"# open-slide — Framework Repo Guide\n\nYou are working on the **open-slide framework** — the runtime, CLI, and tooling that ship to npm.\n\n(Slide-authoring guidance lives in the `slide-authoring` / `create-slide` skills under `apps/demo/.claude/skills/`. Use those only when editing files inside `apps/demo/slides/`.)\n\n## Layout\n\npnpm + Turbo monorepo.\n\n| Path | Package | Role |\n| --- | --- | --- |\n| `packages/core` | `@open-slide/core` | Runtime (viewer, present mode, inspector), Vite plugin, `open-slide` dev/build CLI. |\n| `packages/cli` | `@open-slide/cli` | `npx @open-slide/cli init` scaffolder + project template. |\n| `apps/demo` | private | Local consumer of `@open-slide/core` via `workspace:*`. Dogfood target — run `pnpm dev` here to exercise the framework. |\n| `apps/web` | private | Marketing site (Next.js). |\n\nShared config: `biome.json`, `turbo.json`, `pnpm-workspace.yaml`, `tsconfig` per package.\n\n## Workflow\n\n```bash\npnpm dev          # turbo: runs demo against local core\npnpm build        # build all packages\npnpm typecheck    # tsc across the graph\npnpm check        # biome (format + lint + organize imports)\npnpm check:fix    # auto-fix what biome can\npnpm test         # vitest\n```\n\nFilter to one package: `pnpm core <script>` / `pnpm cli <script>`.\n\n## Hard rules\n\n- **Biome must pass before commit.** Run `pnpm check` (or `pnpm check:fix`). CI and the user's review both expect a clean tree.\n- **If `packages/core` or `packages/cli` changes, add a changeset.** Run `pnpm changeset`, pick the right package(s) and bump (`patch` for fixes/polish, `minor` for new public API, `major` for breaking). Apps (`demo`, `web`) and root tooling do **not** need one.\n- **Changeset descriptions: short and direct.** One line, present-tense, what changed from a user's perspective. Match the tone of `.changeset/*.md` already in the repo. No paragraphs, no rationale, no \"this PR…\".\n  - Good: `Replace spinner with a hairline + sliding bar for slide and presenter loading states.`\n  - Bad: `This change introduces a new loading indicator because the previous spinner felt heavy and we wanted something more subtle for presentation contexts…`\n- Don't bump versions or edit `CHANGELOG.md` by hand — `changeset version` owns that.\n- Don't add dependencies casually. The `core` runtime ships to users; every dep inflates install size.\n- `packages/core/src/app/components/ui` is shadcn-generated and biome-ignored — leave it alone unless regenerating.\n- **Default to writing no comments.** Only add one when the WHY is non-obvious — a hidden constraint, a subtle invariant, a workaround for a specific bug, behavior that would surprise a reader. Don't explain WHAT the code does (well-named identifiers handle that), don't reference tasks/PRs/callers (\"added for X\", \"used by Y\"), don't write section-divider banners (`// ── Section ──`) or module-header descriptions, and don't leave commented-out code. If removing a comment wouldn't confuse a future reader, don't write it.\n\n## Releasing (reference)\n\n`pnpm release` builds `core` + `cli` and runs `changeset publish`. Triggered by the maintainer, not by agents.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# open-slide — Framework Repo Guide\n\nYou are working on the **open-slide framework** — the runtime, CLI, and tooling that ship to npm.\n\n(Slide-authoring guidance lives in the `slide-authoring` / `create-slide` skills under `apps/demo/.claude/skills/`. Use those only when editing files inside `apps/demo/slides/`.)\n\n## Layout\n\npnpm + Turbo monorepo.\n\n| Path | Package | Role |\n| --- | --- | --- |\n| `packages/core` | `@open-slide/core` | Runtime (viewer, present mode, inspector), Vite plugin, `open-slide` dev/build CLI. |\n| `packages/cli` | `@open-slide/cli` | `npx @open-slide/cli init` scaffolder + project template. |\n| `apps/demo` | private | Local consumer of `@open-slide/core` via `workspace:*`. Dogfood target — run `pnpm dev` here to exercise the framework. |\n| `apps/web` | private | Marketing site (Next.js). |\n\nShared config: `biome.json`, `turbo.json`, `pnpm-workspace.yaml`, `tsconfig` per package.\n\n## Workflow\n\n```bash\npnpm dev          # turbo: runs demo against local core\npnpm build        # build all packages\npnpm typecheck    # tsc across the graph\npnpm check        # biome (format + lint + organize imports)\npnpm check:fix    # auto-fix what biome can\npnpm test         # vitest\n```\n\nFilter to one package: `pnpm core <script>` / `pnpm cli <script>`.\n\n## Hard rules\n\n- **Biome must pass before commit.** Run `pnpm check` (or `pnpm check:fix`). CI and the user's review both expect a clean tree.\n- **If `packages/core` or `packages/cli` changes, add a changeset.** Run `pnpm changeset`, pick the right package(s) and bump (`patch` for fixes/polish, `minor` for new public API, `major` for breaking). Apps (`demo`, `web`) and root tooling do **not** need one.\n- **Changeset descriptions: short and direct.** One line, present-tense, what changed from a user's perspective. Match the tone of `.changeset/*.md` already in the repo. No paragraphs, no rationale, no \"this PR…\".\n  - Good: `Replace spinner with a hairline + sliding bar for slide and presenter loading states.`\n  - Bad: `This change introduces a new loading indicator because the previous spinner felt heavy and we wanted something more subtle for presentation contexts…`\n- Don't bump versions or edit `CHANGELOG.md` by hand — `changeset version` owns that.\n- Don't add dependencies casually. The `core` runtime ships to users; every dep inflates install size.\n- `packages/core/src/app/components/ui` is shadcn-generated and biome-ignored — leave it alone unless regenerating.\n- **Default to writing no comments.** Only add one when the WHY is non-obvious — a hidden constraint, a subtle invariant, a workaround for a specific bug, behavior that would surprise a reader. Don't explain WHAT the code does (well-named identifiers handle that), don't reference tasks/PRs/callers (\"added for X\", \"used by Y\"), don't write section-divider banners (`// ── Section ──`) or module-header descriptions, and don't leave commented-out code. If removing a comment wouldn't confuse a future reader, don't write it.\n\n## Releasing (reference)\n\n`pnpm release` builds `core` + `cli` and runs `changeset publish`. Triggered by the maintainer, not by agents.\n","category":"root","tokens":782}]}