Cleans up the `tableEditorApiAccessToggle` PostHog flag now that the
gated UI is shipping to everyone. Follow-up to #45034 — the new
project-creation checkbox makes the management UI a prerequisite, so no
reason to keep it behind a flag.
**Removed:**
- `useDataApiGrantTogglesEnabled` hook
- Old schemas-only multi-selector branch in the Data API settings page
(the rich per-table / per-function toggles + default-privileges switch
become the only UI)
- Flag gate around the `<ApiAccessToggle>` section in the table editor
side panel
- Flag gates around `updateTableApiAccess` calls in the save pipeline
(create / duplicate / update)
- `tableEditorApiAccessToggleEnabled` telemetry property + stale JSDoc /
docs references
**Changed:**
- `createTableApiAccessHandlerParams` no longer takes an `enabled` param
— it was always `true` after removal
## To test
- Integrations → Data API settings page: exposed tables, exposed
functions, default-privileges toggle all render and save correctly
- Table editor: creating, duplicating, and editing a table all run the
expected Data API privilege updates
- Project creation flow still works end-to-end (unchanged, but the
submit telemetry no longer includes `tableEditorApiAccessToggleEnabled`)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Improvements**
* API access configuration is now always available in the table editor
and PostgreSQL settings, removing previous conditional gating.
* Simplified the "Automatically expose new tables and functions"
interface by consolidating UI branches.
* **Documentation**
* Updated telemetry guidance and examples with current feature-flag
references.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
Migrates all studio-related Cursor rules to Claude skills and adds a
top-level `.claude/CLAUDE.md` for project context. Docs rules left in
place.
**Decisions:**
- Only studio + testing rules migrated — docs rules intentionally left
in `.cursor/rules/docs/`
- Vitest skill already shared via symlink (`.claude/skills/vitest` →
`.agents/skills/vitest`) — nothing to migrate
- Grouped ~21 granular cursor rules into 5 new skills + 1 updated skill
by topic
- `studio-architecture` skill fully merged into `CLAUDE.md` and deleted
to avoid overlap
- Skills are self-contained (content inlined, not relying on sub-files)
since Claude reads SKILL.md first
- Skills cross-reference each other inline where relevant (e.g.
best-practices → testing, error-handling, queries)
- No `paths` frontmatter — would auto-inject full skill content on every
matching file. Current description-based matching is more selective and
token-efficient.
**Removed:**
- `.cursor/rules/studio/` (21 rule files covering architecture, best
practices, UI patterns, queries, styling, etc.)
- `.cursor/rules/testing/` (e2e-studio + unit-integration rules)
- `.cursor/rules/studio-useStaticEffectEvent.mdc`
- `.claude/skills/studio-architecture/` — fully merged into CLAUDE.md to
avoid duplication
- `.claude/skills/studio-testing/rules/` — orphaned sub-files after
inlining content into SKILL.md
**Added:**
- `.claude/CLAUDE.md` — concise monorepo overview with structure,
commands, and conventions. Absorbs studio-architecture content.
References `studio-*` skills for detail.
- `.claude/skills/studio-best-practices/` — boolean naming, component
structure, loading/error/success patterns, state management, hooks,
TypeScript conventions. Cross-references `vercel-composition-patterns`,
`studio-ui-patterns`, `studio-queries`, `studio-error-handling`, and
`studio-testing` inline where relevant.
- `.claude/skills/studio-ui-patterns/` — layout, forms, tables, charts,
empty states, navigation, cards, alerts, sheets. Grouped from ~10
separate cursor rules into one cohesive skill.
- `.claude/skills/studio-queries/` — React Query `queryOptions` pattern,
`keys.ts` structure, mutation hook template, imperative fetching.
- `.claude/skills/use-static-effect-event/` — the `useStaticEffectEvent`
hook: when to use, when not to, patterns, implementation.
**Changed:**
- `.claude/skills/studio-e2e-tests/` — renamed from `e2e-studio-tests`
for `studio-*` naming consistency. Merged race condition, waiting
strategy, test structure, assertion, and cleanup patterns from the
cursor e2e rule.
- `.claude/skills/studio-testing/` — inlined key content from sub-rule
files directly into SKILL.md so it's self-contained. Removed broken
`AGENTS.md` reference. Deleted orphaned `rules/` sub-files.
- `.claude/skills/vercel-composition-patterns/` — added note that Studio
uses React 18, so React 19 patterns should be skipped.
- `.gitignore` — added `!.claude/CLAUDE.md` exception so it's tracked.
## To test
- Open Claude Code in the repo, verify `.claude/CLAUDE.md` loads as
project context
- Ask Claude about Studio conventions and verify it references the right
skills
- Check that `studio-*` skills appear in the skill list
---------
Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
## Context
Noticed while working on #43913 that `copilot-instructions.md` is
currently at ~4,600 characters. Per [GitHub's docs on Copilot code
review](https://docs.github.com/en/copilot/how-tos/use-copilot-agents/request-a-code-review/use-code-review):
> Copilot code review only reads the first 4,000 characters of any
custom instruction file. Any instructions beyond this limit will not
affect the reviews generated by Copilot code review.
This means the testing section at the bottom of our current file isn't
being read during reviews.
## Proposal
Split the single file into path-specific instruction files under
`.github/instructions/`, following [GitHub's recommended pattern for
repository custom
instructions](https://docs.github.com/en/copilot/how-tos/configure-custom-instructions/add-repository-instructions):
> These are specified in one or more `NAME.instructions.md` files within
or below the `.github/instructions` directory.
> If the path you specify matches a file that Copilot is working on, and
a repository-wide custom instructions file also exists, then the
instructions from both files are used.
This gives us separate files that each stay under the 4K limit and get
combined automatically by Copilot during reviews:
| File | Size | Scope |
|------|------|-------|
| `copilot-instructions.md` | 929 chars | General repo context +
pointers |
| `instructions/studio-telemetry.instructions.md` | 3,570 chars |
Telemetry rules for `apps/studio/**` |
| `instructions/studio-testing.instructions.md` | 1,228 chars | Testing
rules for `apps/studio/**` |
Note: Copilot reads instructions from the **base branch** of a PR, not
the feature branch — so these won't take effect until merged to master.
### New telemetry guidance
The telemetry file adds guidance we've been missing — specifically
around feature-flagged rollouts:
- Flag PRs that use `usePHFlag`/`useFlag` to gate behavior but don't
capture the flag state in telemetry
- Flag rollouts that track flag state but not user response to the new
behavior
- Documents the raw flag pattern (read via `usePHFlag`, not coerced
wrapper hooks) to avoid the `undefined`→`false` data quality bug we hit
in #43913
### What didn't change
All existing telemetry and testing rules are preserved — nothing was
removed, just reorganized. The telemetry rules still reference
`.claude/skills/telemetry-standards/SKILL.md` as the authoritative
source.
## References
- [Adding repository custom instructions for GitHub
Copilot](https://docs.github.com/en/copilot/how-tos/configure-custom-instructions/add-repository-instructions)
— file structure, path-specific instructions, frontmatter format
- [Using Copilot code
review](https://docs.github.com/en/copilot/how-tos/use-copilot-agents/request-a-code-review/use-code-review)
— 4K character limit, base branch behavior
## Open questions
Would love the team's input on:
- Does the file split make sense, or would you prefer keeping everything
in one file (and trimming to fit)?
- Are there other topics that should get their own instruction file?
- Any concerns with the new feature flag telemetry guidance?
Alaister Young