@appsforgood/next-supabase-kit 0.3.0 → 0.4.0

package/skills/frontend-product-quality-rubric.md

@@ -1,59 +0,0 @@
-# Frontend Product Quality Rubric Skill
-
-## Use When
-
-Reviewing or accepting any meaningful user-facing screen, page, component system, app shell, dashboard, admin workflow, onboarding flow, marketing surface, ecommerce flow, portfolio, venue page, content experience, community surface, education product, or AI workflow UI.
-
-## Goal
-
-Make frontend quality review repeatable. A UI should not pass because it has modern styling, tokens, or screenshots. It must show the product's real audience, task, content, visual identity, states, accessibility, and source-safe reference learning.
-
-## Required Inputs
-
-- `DESIGN.md` with brand/content inputs, selected creative direction, reference set, anti-references, and source-safety notes.
-- `DESIGN.md` distinctiveness benchmark evidence: first-screen proof, content fingerprint, reference benchmark, asset provenance, state proof, and visual QA proof.
-- Desktop and mobile screenshots or preview links when implementation exists.
-- Real content, data examples, record names, assets, or explicitly documented placeholder constraints.
-- Component/state evidence for important loading, empty, error, disabled, success, permission, and focus states.
-- Accessibility and visual QA evidence proportional to release risk.
-
-## Scorecard
-
-Score each dimension as `0`, `1`, or `2`.
-
-| Dimension | 0 Reject | 1 Adequate | 2 Strong |
-| --- | --- | --- | --- |
-| User/task fit | First screen could belong to any product | Main task is visible but weakly prioritized | Product object, task, or workflow is immediately clear |
-| Content specificity | Generic copy, fake metrics, or placeholder content hides missing decisions | Some real labels or data, but gaps remain | Real domain language, data shape, and content hierarchy drive the UI |
-| Visual identity | Default AI-site tropes or derivative reference styling | Direction is coherent but not very distinctive | Typography, color, density, imagery, and layout express the chosen product direction |
-| Information architecture | Navigation and hierarchy are unclear | Core path is understandable | Primary and secondary workflows are easy to scan and act on |
-| Component states | Happy path only | Common states are documented | Important state variants are implemented or captured as visual evidence |
-| Accessibility and interaction | Keyboard, focus, labels, contrast, or motion risks are unresolved | WCAG 2.1 AA basics are covered | Accessibility is verified across critical states and viewport changes |
-| Source safety | References are copied or attribution/asset risk is unclear | References are summarized without copying | Lessons, anti-references, and what not to copy are explicit |
-
-Acceptance threshold:
-
-- Reject if any dimension scores `0` for user/task fit, content specificity, accessibility and interaction, or source safety.
-- Reject if total score is below `10` of `14`.
-- Treat `10-11` as adequate and `12-14` as strong.
-- Best-practice frontend evidence requires a score of at least `12`, no critical zeroes, desktop/mobile review, and visual QA evidence for the change risk.
-- A best-practice frontend verdict also requires a passing distinctiveness benchmark. A polished but interchangeable screen remains a reject even if it reaches the numeric threshold.
-
-## Reject By Default
-
-- A polished visual system with no real product nouns, data, or workflow.
-- A landing page when the request was for an app, tool, dashboard, or operational workflow.
-- Generic gradients, card-heavy filler, fake analytics, vague SaaS copy, stock-like decoration, or one-note palettes.
-- Reference use that copies a brand, exact layout, visual signature, proprietary asset, or copy.
-- Screenshots that omit mobile, important states, or the first screen's primary task.
-
-## Review Output
-
-Return:
-
-- The score for each dimension and total score.
-- Critical zeroes, if any.
-- The acceptance verdict: `reject`, `adequate`, or `strong`.
-- The smallest changes needed to reach the next verdict.
-- Missing screenshot, state, accessibility, or visual QA evidence.
-- Any source-safety or anti-reference risks that must be resolved before release.

package/skills/landing-page-copy.md

@@ -1,29 +0,0 @@
-# Landing Page Copy Skill
-
-## Use When
-
-Creating or reviewing homepage, landing page, campaign page, product page, feature page, waitlist page, or launch page copy.
-
-## Goal
-
-Build a page narrative that quickly proves the product's specific value, not a generic hero followed by interchangeable feature cards.
-
-## Required Work
-
-- Start from `MESSAGING.md`; ask discovery questions if positioning is unclear.
-- Define the first-viewport promise: audience, problem, outcome, differentiator, and action.
-- Use the product's real nouns, workflows, integrations, constraints, and proof.
-- Build sections around user questions: what is it, who is it for, why now, why this, how it works, proof, objections, next step.
-- Keep claims proportionate to available proof.
-- Pair copy with Frontend Design Lead so information hierarchy and visual direction reinforce the message.
-
-## Reject By Default
-
-- Hero copy that says only "build faster", "work smarter", "AI-powered", or "all-in-one".
-- Feature cards that list capabilities without tying them to user outcomes.
-- Testimonials, logos, metrics, or security claims that are invented or unverified.
-- Landing pages when the user asked for a working app, tool, or operational workflow.
-
-## Review Output
-
-Return first-viewport copy, page section outline, proof placement, objection handling, CTA hierarchy, missing inputs, and design handoff notes.

package/skills/nextjs-app-router.md

@@ -1,18 +0,0 @@
-# Next.js App Router Skill
-
-## Use When
-
-Working on routes, layouts, Server Components, Client Components, Server Actions, Route Handlers, data loading, caching, or revalidation.
-
-## Checklist
-
-- Server Components are the default.
-- Client Components are used only for browser-only behavior.
-- Secrets stay server-only.
-- User-specific data is not stored in shared caches.
-- Route params, query params, forms, and API bodies are validated.
-- Loading, error, empty, and success states are present.
-
-## Security Notes
-
-Do not trust client-side checks for authorization. Client UI can hide controls, but server code and RLS must enforce permissions.

package/skills/onboarding-empty-state-copy.md

@@ -1,37 +0,0 @@
-# Onboarding And Empty-State Copy Skill
-
-## Use When
-
-Writing or reviewing onboarding, activation, setup checklists, empty states, first-run flows, upgrade prompts, permission states, success states, or in-product guidance.
-
-## Goal
-
-Help users take the next useful step without filler, pressure, or unclear product promises.
-
-## Required Inputs
-
-- User role and first successful outcome.
-- Required setup steps and dependencies.
-- Empty-state cause: no data yet, filtered out, permission denied, failed load, unavailable feature, or completed workflow.
-- Available next actions and support paths.
-- Product voice and risk level.
-
-## Required Work
-
-- Explain what happened in the user's language.
-- Offer the smallest useful next action.
-- Separate first-run education from error or permission states.
-- Avoid blaming the user for missing data, permissions, or integrations.
-- Align CTAs with the actual route, action, or support path.
-- Include accessibility-friendly labels and error recovery where relevant.
-
-## Reject By Default
-
-- Empty states that only say "nothing here yet".
-- Onboarding copy with no clear next action.
-- Upgrade prompts that block core recovery or hide why access is limited.
-- Error or permission copy that obscures the real cause.
-
-## Review Output
-
-Return state type, user goal, message, primary action, secondary action, recovery path, and any missing product or permission details.

package/skills/owasp-security-review.md

@@ -1,19 +0,0 @@
-# OWASP Security Review Skill
-
-## Use When
-
-Reviewing auth, APIs, Server Actions, external fetches, file uploads, webhooks, dependencies, or data mutations.
-
-## Checklist
-
-- Broken access control and IDOR are tested.
-- Inputs are validated and parsed with safe schemas.
-- Outputs are safely rendered or encoded.
-- SSRF risk is addressed for server-side fetches.
-- Secrets are not logged or bundled.
-- Dependencies are reviewed for known critical CVEs.
-- Errors are explicit without leaking internals.
-
-## Output Format
-
-Report severity, exploit path, affected behavior, and concrete remediation.

package/skills/planning-council.md

@@ -1,21 +0,0 @@
-# Planning And Agent Council
-
-## Use When
-
-Use for planning requests, roadmap work, ambiguous feature requests, core architecture changes, auth/data changes, release changes, and any task that needs multiple agent roles.
-
-## Required Checks
-
-- Classify the request as planning, core-change, frontend-change, security-review, release, docs, or research.
-- Read `.agent-kit/agent-roster.json` and use it as the workflow source of truth when present.
-- Use `QUALITY_GATES.md` to name whether the target is baseline, strong, or best-practice.
-- Start planning with the Planner agent.
-- Route core changes through Lead Architect before implementation.
-- Include Security Reviewer for auth, data mutation, external-call, dependency, secret, or deployment-risk changes.
-- Include QA Engineer before completion when behavior changes.
-- Include Documentation Maintainer when living docs need updates.
-- Record meaningful council sessions in `COUNCIL.md` or a structured record matching `.agent-kit/schemas/council-session.schema.json`.
-
-## Output
-
-Name the active workflow, maturity target, council members, handoff order, affected layers, preserved capabilities, required outputs, decision/risk/next-handoff evidence, verification commands, and unresolved risks.

package/skills/positioning-messaging.md

@@ -1,42 +0,0 @@
-# Positioning And Messaging Skill
-
-## Use When
-
-Defining or reviewing product positioning, audience, value proposition, landing-page strategy, homepage messaging, pricing narrative, launch copy, or public SaaS messaging.
-
-## Goal
-
-Make copy specific to the actual product, market, user pain, outcome, and proof instead of producing interchangeable SaaS language.
-
-## Required Discovery Questions
-
-Ask these before writing final copy when the answers are missing:
-
-- Who is the primary audience, and what do they already believe or understand?
-- What painful, expensive, slow, risky, or annoying problem are they trying to solve?
-- What outcome do they want, and how will they recognize progress?
-- What alternatives are they using today, including manual workarounds?
-- What is the strongest differentiator: speed, quality, workflow fit, trust, cost, automation, insight, compliance, or convenience?
-- What proof supports the claim: data, customer quote, demo, case study, benchmark, shipped feature, integration, or domain expertise?
-- What objections would stop adoption, signup, payment, or activation?
-- What action should the page or flow make easier?
-
-## Required Work
-
-- Fill or update `MESSAGING.md`.
-- Write a one-sentence positioning statement.
-- Define primary and secondary value propositions.
-- Name proof points and objections separately from claims.
-- Translate positioning into page-level hierarchy: headline, subhead, primary CTA, secondary CTA, proof, objection handling, and next step.
-- Mark unknowns explicitly instead of hiding them behind broad claims.
-
-## Reject By Default
-
-- "AI-powered", "supercharge", "revolutionize", "all-in-one", "10x", or similar claims without concrete proof.
-- Headlines that would still work after replacing the product name with a competitor.
-- Copy with no audience, pain, differentiator, proof, or conversion target.
-- Unsupported urgency, fear, savings, compliance, or performance claims.
-
-## Review Output
-
-Return missing inputs, positioning statement, value proposition, proof gaps, objections, copy hierarchy, CTA rationale, and required follow-up questions.

package/skills/postgres-migrations.md

@@ -1,14 +0,0 @@
-# Postgres Migrations Skill
-
-## Use When
-
-Adding tables, columns, constraints, indexes, functions, triggers, seed data, or policy changes.
-
-## Checklist
-
-- Migration order is documented.
-- Constraints protect data integrity.
-- Indexes support expected queries.
-- RLS changes are reviewed with auth assumptions.
-- Backfills and destructive changes have rollback guidance.
-- Local and production application order is clear.

package/skills/product-voice-tone.md

@@ -1,35 +0,0 @@
-# Product Voice And Tone Skill
-
-## Use When
-
-Defining or reviewing product voice, tone, brand language, UX writing rules, help text, error messages, onboarding guidance, transactional copy, or notification copy.
-
-## Goal
-
-Make the product sound deliberate, consistent, and appropriate for the audience and task risk.
-
-## Required Inputs
-
-- Audience sophistication and emotional state.
-- Product category and trust requirements.
-- Brand traits and words to avoid.
-- Regulatory, legal, accessibility, or support constraints.
-- Examples of existing copy that should be kept or avoided.
-
-## Required Work
-
-- Define 3-5 voice traits with "do" and "avoid" examples.
-- Set tone rules for success, warning, error, empty, loading, payment, security, and destructive actions.
-- Prefer plain, concrete language over cleverness when user trust or task completion matters.
-- Keep labels, CTAs, form hints, and errors consistent across the product.
-- Update `MESSAGING.md`, `STYLE_GUIDE.md`, or `DESIGN.md` when voice affects product UI.
-
-## Reject By Default
-
-- Cute or vague copy around errors, billing, security, auth, destructive actions, or compliance.
-- Inconsistent terms for the same object, workflow, or action.
-- Brand voice that hides important limitations or next steps.
-
-## Review Output
-
-Return voice traits, tone rules by state, terminology decisions, risky wording, and doc updates needed.

package/skills/reference-led-design-critique.md

@@ -1,48 +0,0 @@
-# Reference-Led Design Critique Skill
-
-## Use When
-
-Reviewing or designing a user-facing screen, component system, marketing surface, dashboard, tool, onboarding flow, marketplace, content page, ecommerce flow, portfolio, venue page, community surface, education product, or AI workflow UI where visual quality and product specificity matter.
-
-## Goal
-
-Prevent generic AI-looking UI by grounding design decisions in a small reference set, explicit anti-references, product content, accessibility, and a written critique verdict before implementation is accepted.
-
-## Required Inputs
-
-- `DESIGN.md` brand/content inputs and selected creative direction.
-- 3-5 category references to learn from without copying.
-- 2-3 anti-references that show what the product must not look like.
-- Real content, assets, data examples, and workflow constraints.
-- Screenshots or preview links for desktop and mobile when implementation exists.
-
-## Critique Workflow
-
-1. Identify what each reference teaches: density, hierarchy, navigation, content treatment, typography, imagery, motion, or interaction behavior.
-2. State what must not be copied: brand marks, layouts, proprietary components, exact copy, visual signatures, or protected assets.
-3. Compare the proposed UI against the chosen creative direction and product content.
-4. Score distinctiveness as `weak`, `adequate`, or `strong`.
-5. Apply the frontend product-quality scorecard for user/task fit, content specificity, visual identity, IA, states, accessibility, and source safety.
-6. Reject the work if the first screen could fit any generic product in the same category.
-7. Require the smallest useful visual QA evidence for the risk: screenshot review, Playwright screenshots, Storybook states, visual-regression baseline, or equivalent.
-
-## Reject By Default
-
-- References used as permission to copy a brand, layout, or source design.
-- One-reference design direction.
-- A UI that has tokens and states but no product-specific point of view.
-- Designs that hide missing content behind abstract gradients, fake dashboards, generic illustrations, or vague copy.
-- Screenshot evidence that omits mobile, empty, error, loading, or permission states when those states affect the workflow.
-
-## Review Output
-
-Return:
-
-- Reference set and anti-references used.
-- What was learned from each reference without copying.
-- Product-specific details that make the UI belong to this project.
-- Generic or AI-slop risks that remain.
-- Distinctiveness verdict: weak, adequate, or strong.
-- Frontend product-quality scorecard verdict and total score.
-- Required design changes before implementation or release.
-- Required screenshot, accessibility, and visual QA evidence.

package/skills/supabase-auth-rls.md

@@ -1,20 +0,0 @@
-# Supabase Auth And RLS Skill
-
-## Use When
-
-Working on Supabase Auth, SSR clients, middleware, sessions, tables, policies, Storage, or service-role operations.
-
-## Checklist
-
-- RLS is enabled on user-owned and tenant-owned tables.
-- Policies enforce ownership and tenant boundaries.
-- Service-role key is never exposed to client code.
-- Auth middleware handles session refresh safely.
-- Storage buckets have explicit policies.
-- IDOR attempts are considered and tested.
-- `SPEC.md` contains an RLS policy inventory.
-- Security-sensitive policy assumptions are recorded in `DECISIONS.md`.
-
-## Safe Default
-
-If a table stores user-specific data, assume it needs RLS before it is queried from application code.

package/skills/testing-qa.md

@@ -1,15 +0,0 @@
-# Testing And QA Skill
-
-## Use When
-
-Adding or reviewing tests, smoke checks, regression coverage, or acceptance evidence.
-
-## Checklist
-
-- Core logic has unit tests.
-- Preserved behavior has regression tests.
-- Critical user flows have Playwright smoke tests.
-- High-risk UI changes have screenshot or visual-regression evidence.
-- Auth and data mutation paths are prioritized.
-- Network failure, empty state, and error state behavior is covered.
-- Test gaps are documented when infrastructure is missing.

package/skills/ui-improvement-harness.md

@@ -1,96 +0,0 @@
-# UI Improvement Harness Skill
-
-## Use When
-
-Running operational UI improvement loops for user-facing screens, dashboards, admin flows, app shells, onboarding, marketing surfaces, component systems, or authenticated product workflows.
-
-Use this skill when a request asks for UI audit, polish, layout cleanup, responsive cleanup, accessibility pass, screenshot critique, visual distinctiveness, live browser QA, or repeatable frontend improvement workflows.
-
-## Goal
-
-Turn frontend quality guidance into repeatable commands. The harness should help agents move from screenshots and browser evidence to concrete fixes, then loop until deterministic detector findings and review findings pass for the release risk.
-
-## Required Inputs
-
-- Target surface: route, component, flow, or screenshot set.
-- Product context from `DESIGN.md`, `STYLE_GUIDE.md`, and relevant `.agent-kit/design-briefs/*`.
-- Auth and permission context for protected screens, including role, tenant, and fixture user assumptions.
-- Desktop and mobile viewports for meaningful UI changes.
-- State coverage requirements: default, loading, empty, error, disabled, success, permission, focus, and narrow viewport states where relevant.
-- Existing visual QA tier from `TESTING.md`, or a proposed tier from `.agent-kit/prompts/visual-qa-plan.md`.
-
-## Command Workflows
-
-Use `.agent-kit/prompts/ui-command-index.md` as the command index. It defines these command-like workflows:
-
-- UI audit: find blockers and major issues before implementation or release.
-- UI polish: improve hierarchy, density, spacing, state feedback, and visual finish without changing product scope.
-- Layout cleanup: remove clutter, nesting, overflow, weak grouping, and inconsistent spacing.
-- Responsive/mobile cleanup: verify mobile hierarchy, tap targets, text fit, navigation, and critical actions.
-- Accessibility pass: verify semantic structure, keyboard path, focus, labels, contrast, motion, and error feedback.
-- Visual distinctiveness pass: prove product specificity and avoid generic AI/SaaS defaults.
-- Screenshot critique: review desktop/mobile/state screenshots against product context and detector findings.
-- Live browser QA loop: inspect the running app, capture evidence, apply scoped fixes, and repeat until acceptance criteria pass.
-
-## Deterministic Detector Checklist
-
-Use `.agent-kit/checklists/ui-detectors.md` before and after polish. Treat each finding as `blocker`, `major`, `minor`, or `not-applicable`.
-
-Required detector areas:
-
-- Crowded layout and excessive competing surfaces.
-- Weak hierarchy or unclear primary action.
-- Inconsistent spacing, density, typography, radius, or alignment.
-- Poor mobile tap targets or unreachable critical actions.
-- Truncation, overflow, overlap, or text that does not fit.
-- Card-within-card patterns and decorative containers that obscure workflow.
-- Generic SaaS or AI-site styling, including abstract decoration that hides missing content.
-- Weak hover, pressed, selected, loading, success, empty, error, disabled, focus, and permission feedback.
-- Missing loading, empty, error, disabled, success, permission, and mobile states where relevant.
-- Accessibility and focus issues, including contrast, labels, landmarks, keyboard order, and motion.
-
-## Acceptance Rubric
-
-Use `.agent-kit/checklists/ui-acceptance-rubric.md`.
-
-- Blocker findings must be fixed before release.
-- Major findings must be fixed or explicitly accepted with rationale before high-risk UI changes ship.
-- High-risk UI changes require desktop and mobile screenshots plus authenticated or permission-state evidence when the workflow requires login.
-- Screenshot evidence must include the first viewport, primary workflow, and the highest-risk state affected by the change.
-- Visual checks do not replace semantic, keyboard, auth, data-boundary, or regression tests.
-
-## Live Browser QA Loop
-
-For implemented UI:
-
-1. Start or identify the app server and route.
-2. Open the target route with the required auth state or test account.
-3. Capture desktop and mobile screenshots.
-4. Run the deterministic detector checklist.
-5. Run screenshot critique and accessibility pass.
-6. Apply the smallest scoped fixes.
-7. Repeat until no blockers remain and major findings are resolved or documented.
-8. Record evidence with `agent-kit session output` when Agent Studio is in use.
-
-For authenticated screens, do not substitute a public landing page screenshot. Use a real signed-in state, a seeded local fixture, or an explicit limitation note that names the missing auth evidence.
-
-## Reject By Default
-
-- A UI pass based only on static prose with no screenshot or browser evidence when implementation exists.
-- Desktop-only review for responsive or mobile-risk changes.
-- Public-page review used as evidence for authenticated app screens.
-- Vague polish requests that do not name detector findings or acceptance criteria.
-- Fixes that add decorative cards, gradients, fake metrics, or generic copy instead of clarifying the workflow.
-- Ignoring major detector findings without rationale.
-
-## Review Output
-
-Return:
-
-- Target surface and auth state reviewed.
-- Commands run or command-like workflows applied.
-- Detector findings by severity.
-- Screenshots and viewports reviewed.
-- Accessibility, responsive, state, and distinctiveness verdicts.
-- Fixes made or required before acceptance.
-- Tests, browser checks, visual QA evidence, and gaps.

package/skills/upgrade-maintenance.md

@@ -1,32 +0,0 @@
-# Upgrade Maintenance Skill
-
-## Use When
-
-Upgrading Agent Kit, Next.js, Supabase, UI libraries, testing tools, release workflows, assistant adapters, or any shared package that can change project behavior.
-
-## Goal
-
-Make upgrades repeatable, reviewable, reversible, and evidence-backed.
-
-## Required Checks
-
-- Read `UPGRADE.md`, `CHANGELOG.md`, `ROADMAP.md`, and `DECISIONS.md` before changing versioned behavior.
-- Run `agent-kit diff` before accepting template changes.
-- Use `agent-kit update` only on a branch where conflicts can be reviewed.
-- Preserve valid local overrides in `.agent-kit/overrides.json`.
-- For Next.js upgrades, check official upgrade guidance and codemods.
-- For Supabase upgrades, verify migration history, RLS impact, service-role exposure, generated types, and rollback risk.
-- Run `agent-kit audit --min-readiness baseline-setup` after the upgrade.
-- Use `agent-kit audit --min-readiness best-practice-candidate` only after project-specific evidence is complete.
-- Record package versions, migration order, rollback notes, verification commands, owner, and date.
-
-## Output
-
-Return:
-
-- Upgrade scope.
-- Files and templates changed.
-- Conflicts accepted, deferred, or rejected.
-- Migration and rollback risk.
-- Verification commands and results.
-- Remaining warnings before best-practice readiness.

package/skills/visual-regression-qa.md

@@ -1,42 +0,0 @@
-# Visual Regression QA Skill
-
-## Use When
-
-Reviewing or changing user-facing UI, reusable components, app shells, dashboards, marketing pages, visual design tokens, responsive layouts, image-heavy pages, or any screen where appearance is part of the acceptance criteria.
-
-## Goal
-
-Turn visual quality from subjective review into repeatable evidence. Capture important UI states, compare them across changes, and require intentional approval for visual diffs.
-
-## Coverage Tiers
-
-- Baseline: desktop and mobile screenshots reviewed with `prompts/screenshot-review.md`.
-- Strong: Playwright screenshot checks for primary workflows and responsive breakpoints.
-- Mature: Storybook stories for reusable component states plus visual regression in CI through a tool such as Chromatic, Argos, Loki, or Playwright snapshots.
-
-## Required Checks
-
-- Primary screens have screenshot evidence for desktop and mobile.
-- Reusable components have meaningful state coverage: default, hover/focus where practical, loading, empty, error, disabled, success, permission-denied, and mobile.
-- Dynamic data, animations, dates, avatars, ads, third-party widgets, and generated media are stabilized, mocked, or masked before visual comparison.
-- Baseline updates are reviewed as product changes, not accepted automatically.
-- Visual diffs are linked in PRs, CI artifacts, or review notes.
-- Accessibility and interaction tests still run; visual diffs do not replace semantic checks.
-
-## Reject By Default
-
-- A single happy-path screenshot as final UI evidence.
-- Visual baselines updated without rationale.
-- Full-page visual snapshots that are flaky because dynamic content is uncontrolled.
-- Screenshot tests that ignore mobile, long text, empty data, or error states.
-- Treating a visual testing service as proof of good design without `DESIGN.md` and screenshot review.
-
-## Review Output
-
-Return:
-
-- Visual surfaces covered and missing.
-- Component states covered and missing.
-- Baseline/diff evidence and where it can be reviewed.
-- Flake risks and stabilization strategy.
-- Whether the visual QA tier is appropriate for the change risk.

package/templates/next-supabase/.agent-kit/orchestrator.json

@@ -1,48 +0,0 @@
-{
-  "schemaVersion": 1,
-  "enabled": false,
-  "defaultWorkflow": "planning",
-  "defaultAlias": "balanced",
-  "databasePath": ".agent-kit/runtime/runtime.sqlite",
-  "providers": {},
-  "modelAliases": {},
-  "agentRoutes": {},
-  "agentExecutors": {},
-  "mutationAgents": [
-    "supabase-postgres-engineer",
-    "nextjs-engineer",
-    "frontend-design-lead",
-    "marketing-copy-lead",
-    "qa-engineer",
-    "docs-maintainer",
-    "deployment-observability-engineer"
-  ],
-  "cursor": {
-    "enabled": false,
-    "command": "cursor-agent",
-    "args": ["--print", "--output-format", "stream-json", "--force"],
-    "timeoutMs": 900000
-  },
-  "mcpServers": {},
-  "sandbox": {
-    "provider": "docker",
-    "image": "node:22-bookworm-slim",
-    "network": "none",
-    "allowHostMutations": false,
-    "timeoutMs": 600000,
-    "memoryMb": 2048,
-    "cpus": 2
-  },
-  "approvals": {
-    "mode": "risk-tiered",
-    "requirePlan": true,
-    "requireFinalCommit": true
-  },
-  "limits": {
-    "maxSteps": 24,
-    "maxAgentVisits": 2,
-    "maxRetriesPerNode": 2,
-    "maxToolCallsPerAgent": 20,
-    "runTimeoutMs": 3600000
-  }
-}

package/templates/next-supabase/.agent-kit/runtime/gitignore.template

@@ -1,2 +0,0 @@
-*
-!.gitignore

package/templates/next-supabase/.github/workflows/agent-kit-audit.yml

@@ -1,34 +0,0 @@
-name: Agent Kit Audit
-
-on:
-  pull_request:
-  push:
-    branches:
-      - main
-  workflow_dispatch:
-
-permissions:
-  contents: read
-
-jobs:
-  audit:
-    name: Agent kit readiness
-    # Automatic hosted CI is opt-in so unavailable Actions billing cannot block delivery.
-    # Set the repository variable AGENT_KIT_ACTIONS_ENABLED=true to enable push/PR runs.
-    if: ${{ github.event_name == 'workflow_dispatch' || vars.AGENT_KIT_ACTIONS_ENABLED == 'true' }}
-    runs-on: ubuntu-latest
-    timeout-minutes: 10
-
-    steps:
-      - name: Checkout
-        uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6
-        with:
-          persist-credentials: false
-
-      - name: Setup Node
-        uses: actions/setup-node@48b55a011bda9f5d6aeb4c2d9c7362e8dae4041e # v6
-        with:
-          node-version: "24"
-
-      - name: Run baseline audit gate
-        run: npx --yes @appsforgood/next-supabase-kit@0.3.0 audit --json --min-readiness baseline-setup