@appsforgood/next-supabase-kit 0.1.0

package/REPOSITORY_SETTINGS.md

@@ -0,0 +1,70 @@
+# Repository Settings
+
+This file records the GitHub settings that must be applied outside git for the repository to operate as a public best-practice package.
+
+## Branch Protection
+
+Protect `main` with:
+
+- Require a pull request before merging.
+- Require at least one approval.
+- Require review from CODEOWNERS for owned paths.
+- Dismiss stale approvals when new commits are pushed.
+- Require conversation resolution before merge.
+- Require branches to be up to date before merge.
+- Require linear history.
+- Do not allow force pushes.
+- Do not allow deletions.
+- Restrict bypasses to maintainers only.
+
+Required status checks:
+
+- `Verify package`
+- `Review dependency changes`
+- `Analyze JavaScript and TypeScript`
+- `Scorecard`
+
+## Release Environment
+
+Create environment `npm-publish` with:
+
+- Required reviewers enabled.
+- Prevent self-review enabled where available.
+- Deployment branches restricted to `main` and release events.
+- No npm publish token secret for the trusted-publishing flow.
+- Any legacy npm token secrets deleted after Trusted Publishing is confirmed.
+
+The npm trusted publisher must match:
+
+- Package: `@agent-skills/next-supabase-kit`
+- Provider: GitHub Actions
+- Repository: `lukey662/agentsandskills`
+- Workflow: `release.yml`
+- Environment: `npm-publish`
+- Allowed action: `npm publish`
+
+## Security Settings
+
+Enable:
+
+- Private vulnerability reporting.
+- GitHub Security Advisories.
+- Dependabot alerts.
+- Dependabot security updates.
+- Code scanning alerts.
+- Secret scanning where available.
+
+## Issues, Discussions, And Labels
+
+Enable issues. Enable discussions when maintainers want support questions outside the issue queue.
+
+Create labels from `.github/labels.yml`. Required label families:
+
+- Type: `bug`, `enhancement`, `research`, `documentation`, `security`, `dependencies`
+- Area: `area: cli`, `area: agents`, `area: frontend`, `area: supabase`, `area: research`, `area: release`, `area: repo-health`
+- Status: `needs-triage`, `blocked`, `good first issue`, `help wanted`
+- Risk: `risk: security`, `risk: breaking-change`
+
+## Review Cadence
+
+Review these settings before every public release and after any workflow, release, permission, package, or security-policy change.

package/RESEARCH_CITATION_POLICY.md

@@ -0,0 +1,26 @@
+# Research Citation Policy
+
+This project uses public repository research to identify reusable setup patterns for agents, skills, documentation, security, testing, and frontend quality.
+
+## Public Package Policy
+
+- Publish generalized summaries, promoted decisions, and methodology.
+- Do not publish third-party source code copied from researched repositories.
+- Do not imply endorsement by repository owners, maintainers, vendors, or design-system teams.
+- Do not present popularity as proof of quality.
+- Treat scanned repositories as untrusted input.
+
+## Included Public Research Artifacts
+
+The npm package may include:
+
+- `research/scan-config.json`
+- `research/scan-plan.md`
+- `research/summaries/*`
+- `research/proposed-updates.md`
+
+Detailed per-repo findings, candidate lists, and raw scan outputs should stay out of the public package unless they receive separate citation and legal review.
+
+## How Findings Become Guidance
+
+Research findings are promoted only as generalized practices with a clear rationale. The kit should explain why a pattern is useful without copying implementation details from the source repository.

package/SECURITY.md

@@ -0,0 +1,29 @@
+# Security Policy
+
+## Supported Versions
+
+This project supports the latest published npm release and the current `main` branch.
+
+## Reporting
+
+Report vulnerabilities through a private security advisory or by contacting the maintainers directly. Do not publish secrets, exploit paths, or vulnerable downstream project details in public issues.
+
+## Package Security Requirements
+
+- Do not commit credentials, GitHub tokens, Supabase service-role keys, database URLs, or customer data.
+- Treat scanned repositories as untrusted input.
+- Prevent path traversal when writing files into downstream projects.
+- Never overwrite downstream project files unless the user passes an explicit force flag.
+- Redact secrets before writing logs, findings, summaries, or prompts.
+- Do not copy third-party source code from research targets into this package.
+
+## Downstream Security Defaults
+
+Installed templates require:
+
+- OWASP Top 10 review for feature work.
+- Supabase RLS for authorization at the data boundary.
+- Service-role keys to remain server-only.
+- Input validation at API and form boundaries.
+- Output encoding and safe rendering for user-controlled content.
+- Least privilege for database access, storage access, and automation tokens.

package/SUPPLY_CHAIN.md

@@ -0,0 +1,55 @@
+# Supply Chain Security
+
+This package is intended for public npm distribution and downstream project bootstrapping. Release integrity is part of the product, not an optional operations detail.
+
+## Publish Identity
+
+- Public package: `@agent-skills/next-supabase-kit`.
+- Publish path: GitHub Actions release workflow through npm Trusted Publishing.
+- Authentication: OIDC trusted publisher, not a long-lived npm automation token.
+- Environment: `npm-publish`.
+- Trusted publisher must be scoped to repository `lukey662/agentsandskills`, workflow `release.yml`, and allowed action `npm publish`.
+
+When npm Trusted Publishing is used from a public GitHub repository for a public package, npm generates provenance attestations automatically. The release workflow keeps `id-token: write` for this reason and does not set `NODE_AUTH_TOKEN` for publishing.
+
+The release workflow also creates a deterministic package tarball, generates a CycloneDX SBOM from `package-lock.json`, uploads the tarball, SBOM, and pack metadata as release evidence, and attests the SBOM against the exact tarball path that is published to npm.
+
+## Release Gates
+
+Before publish:
+
+- `npm ci`
+- `npm run release:check`
+- Public release review
+
+`npm run release:check` validates JSON assets, typechecks, tests, builds, runs install smoke, runs dependency audit, validates SBOM generation, and performs package dry run. The install smoke also inspects packaged public files for forbidden private-package text.
+
+`npm run sbom:check` validates that the lockfile-derived CycloneDX SBOM can be generated, includes runtime dependencies, and has no unresolved required dependency links. Optional platform-specific dependency links may be skipped when npm records optional package edges that are not present for the current install target.
+
+After publish:
+
+- `npm view @agent-skills/next-supabase-kit@<version> version`
+- `npx --yes @agent-skills/next-supabase-kit@<version> doctor`
+- `npx --yes @agent-skills/next-supabase-kit@<version> init --stack next-supabase` in a clean temp project
+- `npx --yes @agent-skills/next-supabase-kit@<version> audit --json` with zero failures
+
+The release workflow and `npm run publish:verify` both use `scripts/post-publish-verify.mjs` for this post-publish verification path.
+
+## Repository Automation
+
+- CI verifies package behavior on push and pull request.
+- Dependency Review blocks pull requests that introduce moderate or worse known vulnerabilities.
+- Dependabot proposes npm and GitHub Actions updates.
+- CodeQL scans JavaScript/TypeScript code.
+- OpenSSF Scorecard publishes repository security posture as code-scanning evidence.
+- CODEOWNERS identifies default review ownership for source, templates, schemas, and workflows.
+- Release artifacts include an attested CycloneDX SBOM for the npm tarball.
+
+## Maintainer Rules
+
+- Do not use bypass-2FA npm publish tokens for automation.
+- Do not publish from unreviewed branches or untrusted workflow changes.
+- Treat workflow edits as release-risk changes requiring security and maintainer review.
+- Rotate and delete legacy publish secrets after Trusted Publishing is confirmed.
+- Keep package contents free of secrets, private downstream data, and copied third-party source.
+- Keep SBOM generation and attestation in the shared release path; do not publish an unattested tarball when the workflow is available.

package/SUPPORT.md

@@ -0,0 +1,28 @@
+# Support
+
+## Where To Ask
+
+- Use GitHub issues for reproducible package, CLI, template, audit, release, or research-scanner problems.
+- Use feature requests for reusable improvements that should apply across projects.
+- Use research-promotion issues when a public repo pattern should become a template, skill, checklist, schema, audit rule, or release gate.
+- Use labels from `.github/labels.yml` to keep triage consistent.
+- Use private security advisories for vulnerabilities.
+
+## What To Include
+
+For bugs:
+
+- Package version or commit.
+- Command run.
+- Redacted output.
+- Minimal project shape or fixture.
+- Whether the issue affects install, audit, update, research, release, or packaged assets.
+
+For feature requests:
+
+- The reusable gap being solved.
+- Evidence from dogfood installs, research summaries, or public docs.
+- Which package assets should change.
+- Risks or non-goals.
+
+Do not include secrets, private downstream project data, customer data, unreleased third-party source, or exploit details in public issues.

package/UPGRADE.md

@@ -0,0 +1,77 @@
+# Upgrade Guide
+
+This file defines how maintainers and downstream projects should upgrade Agent Kit safely.
+
+## Principles
+
+- Upgrades are reviewable changes, not blind overwrites.
+- Existing project docs and local overrides are preserved by default.
+- Breaking behavior must be called out in `CHANGELOG.md`, `ROADMAP.md`, and release notes.
+- Downstream projects should prove setup validity after each upgrade with `agent-kit audit`.
+
+## Maintainer Release Checklist
+
+Before publishing a new package version:
+
+1. Update `CHANGELOG.md` with user-visible changes, migration notes, and deprecations.
+2. Update `ROADMAP.md` and `BEST_PRACTICE_EVIDENCE.md` when a research finding becomes enforced behavior.
+3. Run `npm run release:check`.
+4. Confirm the pack dry run includes only public-safe files.
+5. Publish through npm Trusted Publishing.
+6. Verify public install with `npx @agent-skills/next-supabase-kit`.
+
+## Downstream Upgrade Checklist
+
+From a downstream project:
+
+```bash
+npx @agent-skills/next-supabase-kit@latest doctor
+npx @agent-skills/next-supabase-kit@latest diff
+npx @agent-skills/next-supabase-kit@latest update
+npx @agent-skills/next-supabase-kit@latest audit --min-readiness baseline-setup
+```
+
+The package includes an older-install regression fixture that exercises this path. The fixture proves update preserves customized docs, writes conflict templates, installs new current baseline docs and `.agent-kit/` assets, then audits with zero failures.
+
+`agent-kit diff` includes an upgrade preview. Review `preview.wouldCreate`, `preview.wouldWriteConflicts`, `agentRoster`, `modelRouting`, and `libraryFolders.missing` before running update so the branch owner knows which files will be created, which local docs will be preserved through conflicts, and which `.agent-kit/` assets will be refreshed.
+
+For mature projects, raise the gate after local evidence is updated:
+
+```bash
+npx @agent-skills/next-supabase-kit@latest audit --min-readiness best-practice-candidate
+```
+
+## Review Order
+
+1. Create a branch before running `agent-kit update`.
+2. Run `agent-kit diff` and review every changed root markdown template.
+3. Check `.agent-kit/conflicts/` before accepting template updates.
+4. Preserve valid local customizations in `.agent-kit/overrides.json`.
+5. Review `AGENTS.md`, `AGENT_ROSTER.md`, `ASSISTANT_ADAPTERS.md`, `MODEL_ROUTING.md`, `COUNCIL.md`, `QUALITY_GATES.md`, `SECURITY.md`, `TESTING.md`, `DEPLOYMENT.md`, and this file.
+6. Run project tests and release checks before merging.
+7. Record any accepted deviations in `DECISIONS.md`.
+
+## Next.js And Supabase Stack Upgrades
+
+- Use official Next.js upgrade guides and codemods for framework changes.
+- Treat Supabase schema, RLS, storage, and auth changes as migration work, not ad hoc dashboard edits.
+- Verify migration history before deployment.
+- Record migration order, rollback risk, and verification evidence in `DEPLOYMENT.md`.
+- Regenerate types after database schema changes when the project relies on generated Supabase types.
+
+## Rollback
+
+Keep rollback evidence next to the upgrade:
+
+- Git branch or commit to revert.
+- Package version before and after the upgrade.
+- Template conflicts reviewed or deferred.
+- Database migrations applied, reverted, or not applicable.
+- Verification commands and results.
+- Owner and date.
+
+## Upgrade History
+
+| Date | From | To | Scope | Evidence | Owner |
+| --- | --- | --- | --- | --- | --- |
+| TBD | TBD | TBD | TBD | TBD | TBD |

package/agents/deployment-observability-engineer.md

@@ -0,0 +1,13 @@
+# Deployment/Observability Engineer Agent
+
+## Purpose
+
+Own release safety, environment configuration, migrations, logs, monitoring, and rollback.
+
+## Responsibilities
+
+- Verify env vars and server-only secrets.
+- Confirm migration and deploy order.
+- Ensure production errors are observable.
+- Define smoke checks after deployment.
+- Document rollback steps.

package/agents/docs-maintainer.md

@@ -0,0 +1,17 @@
+# Documentation Maintainer Agent
+
+## Purpose
+
+Keep living docs accurate enough for another engineer or agent to continue safely.
+
+## Responsibilities
+
+- Update `SPEC.md` after functional changes.
+- Update `DECISIONS.md` for meaningful tradeoffs.
+- Update `DOCS.md` for workflows and setup.
+- Update `COUNCIL.md` for meaningful handoff evidence.
+- Update `QUALITY_GATES.md`, `DESIGN.md`, `STYLE_GUIDE.md`, `SECURITY.md`, `TESTING.md`, `DEPLOYMENT.md`, and `UPGRADE.md` when standards change.
+
+## Rule
+
+Docs and council evidence are part of the implementation surface, not optional cleanup.

package/agents/frontend-design-lead.md

@@ -0,0 +1,22 @@
+# Frontend Design Lead Agent
+
+## Purpose
+
+Prevent generic AI-looking UI by owning content-first creative direction, design-system quality, visual QA, accessibility, and screenshot acceptance.
+
+## Responsibilities
+
+- Require brand/content intake before visual implementation starts.
+- Produce or review at least two distinct creative directions before one is selected.
+- Require reference-set evidence, anti-references, source-safety notes, and a design critique verdict for significant frontend work.
+- Require a frontend distinctiveness benchmark for significant frontend work: first-screen proof, content fingerprint, reference benchmark, asset provenance, state proof, and visual QA proof.
+- Score significant frontend work with the product-quality rubric before acceptance.
+- Review information architecture, visual hierarchy, density, responsive behavior, imagery, copy, and component states.
+- Reject default AI-site tropes: purple-blue gradients, vague SaaS copy, fake analytics, and card soup.
+- Require real workflow screens, real content or asset assumptions, and meaningful empty/error/loading states.
+- Require visual QA evidence for important responsive screens and reusable component states.
+- Use provider-neutral design briefs for Stitch, Claude, Figma, or human design review.
+
+## Quality Bar
+
+The first screen should communicate the actual product, content, object, workflow, or task. A frontend change is not accepted until `DESIGN.md`, reference-led critique, distinctiveness benchmark, creative-direction rationale, frontend product-quality scorecard, desktop/mobile screenshot evidence, and visual QA coverage are sufficient for the change risk.

package/agents/lead-architect.md

@@ -0,0 +1,25 @@
+# Lead Architect Agent
+
+## Purpose
+
+Own architecture, affected-layer mapping, tradeoffs, and final delivery direction.
+
+## Responsibilities
+
+- Confirm existing behavior before changing it.
+- Map changes across data, business logic, presentation, auth, deployment, and docs.
+- Verify the requested maturity target in `QUALITY_GATES.md` is realistic for the scope.
+- Choose the right boundary for logic: SQL/RLS, Route Handler, Server Action, Server Component, Client Component, or shared library.
+- Keep implementation scoped and preserve behavioral contracts.
+- Record architecture handoff decisions, risks, and evidence in `COUNCIL.md` for meaningful core changes.
+- Record major decisions in `DECISIONS.md`.
+
+## Review Questions
+
+- What existing capability must be preserved?
+- Is this baseline, strong, or best-practice work, and what evidence proves that level?
+- Which layers are affected?
+- What security boundary changes?
+- What test evidence proves the change works?
+- What council-session evidence should survive beyond the chat?
+- Which docs need updating?

package/agents/marketing-copy-lead.md

@@ -0,0 +1,20 @@
+# Marketing Copy Lead Agent
+
+## Purpose
+
+Own positioning, value proposition, conversion copy, product voice, and UX copy so public-facing pages and SaaS flows do not rely on generic marketing filler.
+
+## Responsibilities
+
+- Ask discovery questions before writing final copy when audience, offer, outcome, differentiator, proof, or conversion goal is unclear.
+- Maintain `MESSAGING.md` as the positioning, value proposition, voice, and copy-evidence contract.
+- Define the primary audience, their pain, desired outcome, current alternatives, and buying or adoption trigger.
+- Turn product facts into specific headlines, CTAs, onboarding copy, empty states, pricing copy, and supporting page sections.
+- Require proof points, examples, constraints, and objection handling before making strong claims.
+- Reject vague SaaS copy, inflated AI claims, unsupported superlatives, and copy that could fit any competitor.
+- Handoff copy direction to Frontend Design Lead so layout, hierarchy, imagery, and interaction tone support the message.
+- Handoff implemented copy to QA and Docs when claims, workflows, onboarding, or public pages change.
+
+## Quality Bar
+
+Copy is not accepted until it explains who the product is for, what problem it solves, why this approach is different, what proof supports the claim, what action the user should take, and what assumptions still need validation.

package/agents/nextjs-engineer.md

@@ -0,0 +1,20 @@
+# Next.js Engineer Agent
+
+## Purpose
+
+Own App Router implementation, rendering boundaries, data loading, forms, and UI state.
+
+## Responsibilities
+
+- Prefer Server Components unless browser state or events require Client Components.
+- Keep user-specific data out of shared caches.
+- Avoid exposing secrets to the client.
+- Add loading, error, empty, and success states.
+- Keep route handlers and server actions thin and validated.
+
+## Deliverables
+
+- Working UI and route behavior.
+- Clear server/client boundaries.
+- Tests or documented test gaps.
+- Updated docs for changed workflows.

package/agents/planner.md

@@ -0,0 +1,20 @@
+# Planner Agent
+
+## Purpose
+
+Own planning, scope breakdown, sequencing, and council routing before implementation starts.
+
+## Responsibilities
+
+- Convert user intent into phased, checkable work.
+- Identify whether a request is planning-only, frontend-only, security-sensitive, or a core change.
+- Select the matching workflow from `.agent-kit/agent-roster.json` when available.
+- Classify meaningful work against `QUALITY_GATES.md` as baseline, strong, or best-practice.
+- Route core changes to Lead Architect before implementation.
+- Name required agent handoffs and acceptance evidence.
+- Start or update `COUNCIL.md` for meaningful multi-agent work.
+- Keep the roadmap updated when a task changes delivery status.
+
+## Required Handoff
+
+Planning is complete only when the next owning agent, maturity target, affected layers, preserved behavior, risks, verification steps, and council evidence path are explicit.

package/agents/qa-engineer.md

@@ -0,0 +1,19 @@
+# QA Engineer Agent
+
+## Purpose
+
+Own tests, regression coverage, smoke checks, and acceptance evidence.
+
+## Responsibilities
+
+- Add unit tests for core logic.
+- Add regression tests for preserved behavior.
+- Add Playwright smoke tests for critical paths.
+- Add visual regression or screenshot evidence for high-risk UI changes.
+- Prioritize auth, data mutations, admin flows, and edge cases.
+- Compare evidence against the target level in `QUALITY_GATES.md`.
+- Report test gaps explicitly.
+
+## Acceptance Evidence
+
+Include commands run, results, failed checks, and residual risks.

package/agents/research-analyst.md

@@ -0,0 +1,13 @@
+# Research Analyst Agent
+
+## Purpose
+
+Own open-source repo research and conversion of evidence into reusable kit improvements.
+
+## Responsibilities
+
+- Select active, relevant repositories.
+- Separate popular patterns from good patterns.
+- Identify practices to adopt, avoid, or investigate.
+- Never copy third-party code.
+- Convert repeated findings into proposed template, skill, or checklist updates.

package/agents/security-reviewer.md

@@ -0,0 +1,16 @@
+# Security Reviewer Agent
+
+## Purpose
+
+Review implementation against OWASP Top 10 and project-specific auth/data boundaries.
+
+## Responsibilities
+
+- Check broken access control, IDOR, injection, SSRF, misconfiguration, vulnerable dependencies, and unsafe secrets.
+- Verify inputs are validated and outputs are safely rendered.
+- Ensure errors are explicit without leaking internals.
+- Require RLS or equivalent data-boundary enforcement.
+
+## Output
+
+Lead with findings, severity, affected file or behavior, exploit path, and remediation.

package/agents/supabase-postgres-engineer.md

@@ -0,0 +1,19 @@
+# Supabase/Postgres Engineer Agent
+
+## Purpose
+
+Own Supabase Auth, SSR clients, schema, migrations, RLS, Storage policies, SQL functions, and indexes.
+
+## Responsibilities
+
+- Enforce authorization through RLS for user-owned and tenant-owned data.
+- Keep service-role keys server-only.
+- Validate migration order and rollback risk.
+- Use constraints and indexes to protect integrity and performance.
+- Document policy assumptions.
+
+## Required Review
+
+- Can a user access another user's data by changing an ID?
+- Are policies present for select, insert, update, and delete as needed?
+- Does every privileged operation use the least privilege possible?

package/assistant-adapters/README.md

@@ -0,0 +1,28 @@
+# Assistant Adapters
+
+These files help downstream projects activate the same agent council across common AI coding tools without forking the operating model.
+
+## Source Of Truth
+
+- `AGENTS.md` defines the default agent behavior.
+- `AGENT_ROSTER.md` explains human-readable routing.
+- `.agent-kit/agent-roster.json` is the machine-readable council contract.
+- `MODEL_ROUTING.md` and `.agent-kit/model-routing.json` define model-selection profiles.
+- `.agent-kit/project-context.json` and `.agent-kit/project-context.md` define local project context for agents.
+- `.agent-kit/corrections/project-rules.json` and `.agent-kit/corrections/agent-rules.json` define durable human corrections.
+- `COUNCIL.md`, `.agent-kit/council-sessions/`, and `.agent-kit/schemas/*session*.json` define handoff evidence.
+
+Adapters should point back to those files. Do not maintain separate policy, security, frontend, correction, context, or release rules inside a vendor-specific file unless the rule is truly vendor-specific.
+
+## Included Templates
+
+- `codex-agents.md`: guidance for tools that consume `AGENTS.md`.
+- `github-copilot-instructions.md`: starter repository-wide Copilot instructions.
+- `github-next-supabase.instructions.md`: path-aware Copilot/VS Code instructions for Next.js and Supabase files.
+- `cursor-agent-kit.mdc`: Cursor project-rule template.
+- `claude-code-subagents.md`: Claude Code project subagent template guidance.
+- `model-selection/`: dated setup examples for Codex, Claude Code, Cursor, and GitHub Copilot model routing.
+
+## Activation Rule
+
+Record active tool surfaces in `ASSISTANT_ADAPTERS.md`. A project is not best-practice ready simply because adapter templates exist; the team must document which tools are active, how model selection is handled, whether enforcement is enforced/partial/advisory/manual, and what evidence proves the canonical council instructions loaded.

package/assistant-adapters/claude-code-subagents.md

@@ -0,0 +1,37 @@
+# Claude Code Subagent Adapter
+
+Claude Code projects can activate Agent Kit by creating project subagents that point back to the canonical council files.
+
+Use `MODEL_ROUTING.md` and `.agent-kit/model-routing.json` when adding model comments or frontmatter to those subagents.
+
+## Suggested Project Layout
+
+```text
+.claude/
+  agents/
+    planner.md
+    lead-architect.md
+    frontend-design-lead.md
+    security-reviewer.md
+    qa-engineer.md
+```
+
+## Subagent Frontmatter Pattern
+
+```md
+---
+name: planner
+description: Use for planning, phasing, scope breakdown, workflow routing, and council setup in this repository.
+---
+
+Read `AGENTS.md`, `AGENT_ROSTER.md`, `.agent-kit/agent-roster.json`, `.agent-kit/project-context.json`, `.agent-kit/project-context.md`, `.agent-kit/corrections/project-rules.json`, `.agent-kit/corrections/agent-rules.json`, `COUNCIL.md`, `.agent-kit/council-sessions/`, and `QUALITY_GATES.md` before making routing decisions.
+
+Start with the Planner workflow. For core changes, hand off to Lead Architect. For frontend changes, require Frontend Design Lead evidence. For auth, RLS, secrets, dependency, external-call, or release-risk changes, require Security Reviewer. Record meaningful decisions, risks, handoffs, human corrections, artifacts, evidence, and verification through Agent Studio session files when available.
+```
+
+## Guardrails
+
+- Keep detailed role behavior in `AGENTS.md` and `AGENT_ROSTER.md`; subagent files should be focused entry points.
+- Document active subagents and verification evidence in `ASSISTANT_ADAPTERS.md`.
+- Record model-selection evidence and limitations in `ASSISTANT_ADAPTERS.md`.
+- Avoid giving a subagent broader tool access than its role needs.

package/assistant-adapters/codex-agents.md

@@ -0,0 +1,35 @@
+# Codex / AGENTS.md Adapter
+
+Use `AGENTS.md` as the primary project instruction surface.
+
+## Required References
+
+- `AGENTS.md`
+- `AGENT_ROSTER.md`
+- `.agent-kit/agent-roster.json`
+- `MODEL_ROUTING.md`
+- `.agent-kit/model-routing.json`
+- `.agent-kit/project-context.json`
+- `.agent-kit/project-context.md`
+- `.agent-kit/corrections/project-rules.json`
+- `.agent-kit/corrections/agent-rules.json`
+- `COUNCIL.md`
+- `.agent-kit/council-sessions/`
+- `QUALITY_GATES.md`
+
+## Operating Rule
+
+When a task is planning-oriented, ambiguous, risky, frontend-facing, security-sensitive, or release-related, start from the roster workflow instead of treating the request as a single generic implementation pass.
+
+Use `MODEL_ROUTING.md` to choose the model profile or reasoning effort for the active role. Exact model names belong in dated config comments, not in the role definitions.
+
+Before meaningful work, load project context and active correction rules. For meaningful handoffs, record visible decisions and evidence with `agent-kit session ...` commands, then run `agent-kit session render`.
+
+## Verification
+
+Record in `ASSISTANT_ADAPTERS.md`:
+
+- The tool/version or environment where `AGENTS.md` was observed.
+- The command, session, or screenshot that proves the instructions loaded.
+- The model-selection setting or profile used for the active role.
+- Any known limitations or manual invocation steps.

package/assistant-adapters/cursor-agent-kit.mdc

@@ -0,0 +1,30 @@
+---
+description: Use Agent Kit council routing, quality gates, and Next.js/Supabase rules.
+globs:
+  - "**/*"
+alwaysApply: true
+---
+
+# Agent Kit Cursor Rule
+
+Use `AGENTS.md`, `AGENT_ROSTER.md`, `.agent-kit/agent-roster.json`, `MODEL_ROUTING.md`, `.agent-kit/model-routing.json`, `.agent-kit/project-context.json`, `.agent-kit/project-context.md`, `.agent-kit/corrections/project-rules.json`, `.agent-kit/corrections/agent-rules.json`, `COUNCIL.md`, `.agent-kit/council-sessions/`, and `QUALITY_GATES.md` as the source of truth.
+
+## Routing
+
+- Planning starts with Planner.
+- Core changes require Lead Architect.
+- Frontend changes require Frontend Design Lead, brand/content intake, creative-direction rationale, visual QA evidence, state coverage, accessibility checks, and desktop/mobile verification.
+- Auth, RLS, data mutation, dependency, external-call, secret, and release-risk changes require Security Reviewer.
+- Behavior changes require QA evidence.
+- Significant changes require living markdown updates.
+- Meaningful work should read project context and active corrections first.
+- Human corrections should be recorded before continuing and promoted to durable project or agent correction rules when they should affect future work.
+- Meaningful multi-agent work should use `agent-kit session ...` commands and render Markdown evidence when available.
+
+## Validation
+
+Run `agent-kit audit --min-readiness baseline-setup` for setup validity. Use `agent-kit audit --min-readiness best-practice-candidate` only when project-specific evidence has replaced starter placeholders.
+
+## Model Selection
+
+Use Cursor's active model picker or team model policy with the profile in `MODEL_ROUTING.md`. Treat this rule as advisory unless the active Cursor environment provides enforceable model controls.