@appsforgood/next-supabase-kit 0.3.0 → 0.4.1

package/profiles/stack-next-postgres.md

@@ -1,24 +0,0 @@
-# Stack Profile: Next.js And Postgres
-
-Use this profile when adapting the kit to projects using Next.js with direct Postgres access through an ORM, query builder, or server-only database client.
-
-## Replace Supabase-Specific Checks
-
-- Replace Supabase RLS review with explicit application authorization, database constraints, and optional Postgres RLS.
-- Replace Supabase Auth guidance with the project's auth provider and session verification model.
-- Keep migration, schema, index, transaction, OWASP, accessibility, testing, deployment, and living-docs requirements.
-
-## Required Evidence
-
-- Server-only database access is enforced.
-- User and tenant ownership checks are centralized and tested.
-- Migrations are ordered, reversible where practical, and covered by rollback notes.
-- Constraints and indexes protect integrity and expected access patterns.
-- Integration tests cover auth, ownership, mutations, and failed authorization.
-
-## Agent Handoff
-
-- Architect owns domain model, tenancy, and service boundaries.
-- Database engineer owns migrations, constraints, indexes, transactions, and query performance.
-- Security reviewer owns IDOR, injection, auth/session checks, secrets, and dependency exposure.
-- Frontend design lead owns task-first UX, states, accessibility, and screenshot review.

package/profiles/stack-remix-supabase.md

@@ -1,24 +0,0 @@
-# Stack Profile: Remix And Supabase
-
-Use this profile when adapting the kit to Remix projects using Supabase Auth, Postgres, Storage, Realtime, or Edge Functions.
-
-## Replace Next.js-Specific Checks
-
-- Replace App Router checks with Remix loader, action, route module, error boundary, and nested route checks.
-- Keep Supabase Auth, RLS, service-role isolation, Postgres migrations, OWASP, accessibility, testing, deployment, and living-docs requirements.
-- Treat loaders and actions as the main auth, validation, and mutation boundaries.
-
-## Required Evidence
-
-- Loaders and actions validate input, verify session state, and return safe errors.
-- Supabase clients preserve request auth context.
-- RLS protects user-owned and tenant-owned tables.
-- Service-role access is isolated to trusted server modules.
-- Route-level error boundaries cover loading, empty, failure, and permission-denied states.
-
-## Agent Handoff
-
-- Architect owns route/data boundaries and auth flow.
-- Remix engineer owns loaders, actions, nested routes, and error boundaries.
-- Supabase/Postgres engineer owns RLS, migrations, storage policies, and service-role access.
-- Security reviewer owns IDOR, SSRF, injection, secrets, and dependency exposure.

package/prompts/audit-project-setup.md

@@ -1,28 +0,0 @@
-# Audit Project Setup Prompt
-
-Audit this project's agents, skills, and markdown documentation for a best-practice Next.js + Supabase setup.
-
-Evaluate:
-
-- Agent roles and handoffs
-- `.agent-kit/agent-roster.json` default council routing
-- `.agent-kit/schemas/` roster and council-session contracts
-- `COUNCIL.md` decision, risk, next-handoff, evidence, and verification records
-- `QUALITY_GATES.md` baseline, strong, best-practice, and evidence model
-- `agent-kit audit --min-readiness <level>` threshold appropriate for the project maturity
-- Planner default planning workflow and Lead Architect core-change council workflow
-- Reusable skills
-- Supabase Auth, SSR, RLS, migrations, Storage, and service-role safety
-- Next.js App Router architecture
-- OWASP Top 10 coverage
-- WCAG 2.1 AA frontend standards
-- Testing, deployment, observability, and living docs
-
-Output:
-
-1. Verdict and readiness level: `needs-setup`, `baseline-setup`, `needs-improvement`, or `best-practice-candidate`.
-2. Strengths.
-3. Gaps and risks.
-4. Phased improvement plan.
-5. Markdown files to create or update.
-6. Implementation notes if changes are needed.

package/prompts/brand-content-intake.md

@@ -1,17 +0,0 @@
-# Brand And Content Intake Prompt
-
-Use before designing or changing a user-facing surface.
-
-Ask for or infer the smallest useful set of inputs needed to avoid generic UI.
-
-Return:
-
-1. Product category and primary audience.
-2. User needs in the user's language.
-3. Real content inventory: nouns, labels, data fields, records, assets, examples, and domain terms.
-4. Brand personality and visual constraints.
-5. Category references to learn from and patterns to avoid.
-6. First-screen task, object, or workflow that must be visible.
-7. Missing inputs that block high-quality design.
-
-Do not write vague value propositions. Use concrete domain language from the product.

package/prompts/copy-review.md

@@ -1,15 +0,0 @@
-# Copy Review Prompt
-
-Use this before accepting marketing, landing-page, onboarding, pricing, CTA, or product voice changes.
-
-Review the copy against `MESSAGING.md`, `DESIGN.md`, and the current implementation.
-
-Report:
-
-- Missing discovery answers: audience, pain, outcome, alternatives, differentiator, proof, objections, voice, and conversion goal.
-- Positioning statement and whether it is specific enough.
-- Unsupported claims, invented proof, vague SaaS language, or risky wording.
-- Headline, subhead, CTA, proof, and objection-handling alignment.
-- Onboarding, empty-state, error, permission, or upgrade copy that lacks a useful next step.
-- Voice/tone consistency and terminology conflicts.
-- Required changes before Frontend Design Lead or QA acceptance.

package/prompts/council-session-review.md

@@ -1,17 +0,0 @@
-# Council Session Review Prompt
-
-Use before completing meaningful planning, core-change, frontend-change, security-review, release, or research work.
-
-Review the current work against `.agent-kit/agent-roster.json`, `AGENT_ROSTER.md`, `COUNCIL.md`, and any `.agent-kit/council-sessions/*.json` records.
-
-Return:
-
-1. Selected workflow and why it applies.
-2. Required agents and whether each participated.
-3. Required outputs and whether each is missing, partial, complete, or not applicable.
-4. Handoff trail: agent, decision, risk, next handoff, and evidence.
-5. Verification evidence: commands, reviews, screenshots, visual diffs, or documented gaps.
-6. Blockers that prevent the session from being marked complete.
-
-Do not accept a handoff that lacks decision, risk, next owner, or evidence.
-Run `agent-kit audit` after adding or changing structured council-session JSON records.

package/prompts/creative-direction-matrix.md

@@ -1,22 +0,0 @@
-# Creative Direction Matrix Prompt
-
-Use after brand/content intake and before implementation.
-
-Create 2-3 distinct directions for the same product. Each direction must be meaningfully different in layout, density, typography, imagery, color behavior, and interaction tone.
-
-For each direction, return:
-
-- Name.
-- Best-fit audience and use case.
-- First-screen composition.
-- Token direction: color, type, spacing, radius, motion, depth.
-- Imagery or asset strategy.
-- Component/state implications.
-- Risks and what could make it look generic.
-- Reference and anti-reference fit, including what must not be copied.
-
-Then choose one direction and explain:
-
-- Why it fits the product content and user need.
-- Why rejected directions are weaker.
-- What screenshot evidence must prove after implementation.

package/prompts/design-critique-gate.md

@@ -1,28 +0,0 @@
-# Design Critique Gate Prompt
-
-Use after creative direction is chosen and before accepting implementation.
-
-Inputs:
-
-- `DESIGN.md`
-- Selected creative direction
-- Reference set and anti-references
-- Desktop and mobile screenshots or preview links
-- Primary workflow and real content/data examples
-- Accessibility and visual QA evidence
-- Frontend product-quality scorecard, if already drafted
-
-Return:
-
-- Reference-set summary: what each reference teaches and what must not be copied.
-- Anti-reference summary: patterns, palettes, layouts, copy, or interaction choices to avoid.
-- First-screen critique: whether the actual product, object, task, workflow, or content is immediately visible.
-- Distinctiveness verdict: `weak`, `adequate`, or `strong`.
-- Product-quality scorecard: user/task fit, content specificity, visual identity, information architecture, component states, accessibility and interaction, source safety, and total score.
-- AI-slop risks: generic gradients, vague SaaS copy, card soup, fake metrics, stock-like imagery, one-note palette, or placeholder content.
-- UX risks: unclear primary action, weak information hierarchy, poor density, missing states, or mobile compromise.
-- Accessibility risks: semantic structure, keyboard path, focus, contrast, motion, labels, and error feedback.
-- Required changes before acceptance.
-- Evidence still missing before release.
-
-Reject the UI if it could be swapped into another product in the same category without changing the content.

package/prompts/docs-update.md

@@ -1,16 +0,0 @@
-# Docs Update Prompt
-
-Update living docs after this change.
-
-Check:
-
-- `SPEC.md` for functional and technical behavior
-- `DECISIONS.md` for important tradeoffs
-- `DOCS.md` for setup, workflows, and integrations
-- `COUNCIL.md` for meaningful handoffs, required outputs, evidence, and verification status
-- `QUALITY_GATES.md` for maturity target and evidence expectations
-- `DESIGN.md` for brand/content, creative direction, and visual-system implications
-- `STYLE_GUIDE.md` for code and design patterns
-- `SECURITY.md` for auth/data boundaries
-- `TESTING.md` for coverage and gaps
-- `DEPLOYMENT.md` for release implications

package/prompts/frontend-design-review.md

@@ -1,35 +0,0 @@
-# Frontend Design Review Prompt
-
-Review this UI for product-specific quality and accessibility.
-
-Reject:
-
-- Missing brand/content intake or `DESIGN.md` context
-- Missing creative-direction rationale
-- Missing frontend product-quality scorecard
-- Missing visual QA or component-state evidence
-- Generic AI-site gradients
-- Accent-border cards, glow rails, neon strokes, gradient borders, oversized glass panels, or ornamental icon walls
-- Vague SaaS copy
-- Fake metrics
-- Decorative credibility badges or unsupported proof
-- Card soup
-- Filler sections that replace the requested app or tool workflow
-- Color-only alerts, low-contrast tints, or vague status panels
-- Missing mobile states
-- Missing loading, empty, error, disabled, or success states
-
-Recommend:
-
-- Content-first inputs that must be filled before implementation is accepted
-- Which creative direction should be selected or explored next
-- Product-quality scorecard with critical zeroes and total score
-- Which visual QA tier is appropriate for the change
-- Task-first layout
-- Domain-specific hierarchy
-- Restrained 1px full-border surfaces, subtle background tint when needed, clear labels, icons, and semantic state text
-- Concrete product nouns, user actions, constraints, real proof, and honest empty or connected-data states
-- Design tokens
-- Accessible forms and controls
-- WCAG 2.1 AA behavior
-- Stronger visual direction where needed

package/prompts/frontend-distinctiveness-benchmark.md

@@ -1,32 +0,0 @@
-# Frontend Distinctiveness Benchmark Prompt
-
-Use before accepting significant frontend work.
-
-Inputs:
-
-- `DESIGN.md`
-- Current screen, screenshots, preview URL, or implementation notes
-- Product category, audience, user needs, content inventory, and primary workflow
-- Reference set, anti-references, and source-safety notes
-- Asset list and provenance notes
-- Product-quality scorecard and visual QA evidence
-
-Review:
-
-- Does the first viewport prove what this product is and what the user does here?
-- Which product nouns, data shapes, records, actions, and edge cases are visible?
-- Which reference lessons were applied without copying source design, copy, assets, or brand identity?
-- Which anti-references were avoided?
-- Do assets have clear source, generation, license, or placeholder constraints?
-- Which loading, empty, error, disabled, success, permission, and focus states still need proof?
-- Would this screen still look valid for another product in the same category after only changing the logo or headline?
-
-Return:
-
-- Verdict: `reject`, `adequate`, or `distinctive`.
-- First-screen proof: missing, adequate, or strong.
-- Content fingerprint: missing, adequate, or strong.
-- Reference benchmark: missing, adequate, or strong.
-- Asset/source-safety risks.
-- Generic-AI-site risk.
-- Required changes before acceptance.

package/prompts/frontend-product-quality-scorecard.md

@@ -1,35 +0,0 @@
-# Frontend Product Quality Scorecard Prompt
-
-Use before accepting significant frontend work.
-
-Inputs:
-
-- `DESIGN.md`
-- Selected creative direction
-- Reference set, anti-references, and source-safety notes
-- Desktop and mobile screenshots or preview links
-- Primary workflow and real content/data examples
-- Component states, accessibility evidence, and visual QA tier
-- Frontend distinctiveness benchmark verdict
-
-Score each dimension from `0` to `2`:
-
-- User/task fit
-- Content specificity
-- Visual identity
-- Information architecture
-- Component states
-- Accessibility and interaction
-- Source safety
-
-Return:
-
-- Score table with one sentence of evidence per dimension.
-- Total score out of `14`.
-- Critical zeroes.
-- Verdict: `reject`, `adequate`, or `strong`.
-- Required changes before acceptance.
-- Evidence still missing before release.
-- Whether distinctiveness benchmark evidence is strong enough for a best-practice frontend claim.
-
-Reject when any critical dimension has a zero, total score is below `10`, or the first screen could be reused for another product in the same category without changing meaningful content.

package/prompts/implement-feature.md

@@ -1,14 +0,0 @@
-# Implement Feature Prompt
-
-Implement the requested feature using this workflow:
-
-1. Confirm preserved behavior and affected layers.
-2. Select the matching workflow from `.agent-kit/agent-roster.json` and record meaningful council-session evidence in `COUNCIL.md`.
-3. Update Supabase schema/RLS first if data boundaries change.
-4. Implement Next.js behavior with explicit server/client boundaries.
-5. Apply frontend design and accessibility review.
-6. Run OWASP security review.
-7. Add tests proportional to risk.
-8. Update living docs.
-
-Return key changes, preserved capabilities, council handoffs, tests run, docs updated, and follow-up tasks.

package/prompts/lifecycle-command-index.md

@@ -1,180 +0,0 @@
-# Lifecycle Command Index
-
-Use this index for delivery lifecycle slash commands. These are command-like prompts for any assistant surface and the source of truth for native Antigravity runtime commands.
-
-For UI-only workflows, see `.agent-kit/prompts/ui-command-index.md`.
-
-Canonical sources:
-
-- `AGENTS.md`
-- `AGENT_ROSTER.md`
-- `.agent-kit/agent-roster.json`
-- `MODEL_ROUTING.md`
-- `.agent-kit/model-routing.json`
-- `SPEC.md`
-- `QUALITY_GATES.md`
-- `TESTING.md`
-- `SECURITY.md`
-- `COUNCIL.md`
-- `.agent-kit/council-sessions/`
-
-## `/setup`
-
-Onboard project context through Agent Office and project-context files.
-
-Required steps:
-
-1. Run or resume `agent-kit setup --open` when the CLI is available.
-2. Load `.agent-kit/project-context.json`, `.agent-kit/project-context.md`, and active correction rules.
-3. Confirm stack, auth model, deployment target, and maturity target from `QUALITY_GATES.md`.
-4. Record gaps as follow-up context questions or correction rules.
-
-Required outputs: context summary, unanswered questions, maturity target, next recommended command.
-
-## `/spec`
-
-Define what to build in `SPEC.md` before implementation.
-
-Required steps:
-
-1. Route through Planner and Documentation Maintainer.
-2. Read project context, corrections, and existing `SPEC.md`.
-3. Capture goal, user/workflow, acceptance criteria, preserved behavior, non-goals, and docs impact.
-4. Name affected layers: data, business logic, presentation, auth, deployment, tests.
-5. Record decision and handoff with `agent-kit session ...` when a session is active.
-
-Required outputs: spec delta or draft, acceptance criteria, preserved capabilities, non-goals, verification plan, next handoff.
-
-## `/plan`
-
-Create an implementation-ready plan through Planner and Lead Architect routing.
-
-Required steps:
-
-1. Start with Planner.
-2. Name the active workflow and maturity target from `QUALITY_GATES.md`.
-3. Map affected layers and preserved behavior.
-4. Route core changes through Lead Architect before implementation.
-5. Record decision, risk, next handoff, and required outputs with `agent-kit session ...` when available.
-
-Required outputs: goal, affected layers, preserved capabilities, implementation sequence, risks, tests, docs, handoffs, acceptance criteria.
-
-## `/handoff`
-
-Route work explicitly between council agents with recorded evidence.
-
-Required steps:
-
-1. Read `.agent-kit/agent-roster.json` and select the active workflow.
-2. State decision, risk, and required next agent from the roster sequence.
-3. Mark required outputs as missing, partial, complete, or not applicable.
-4. Record the handoff with `agent-kit session handoff` when the CLI is available.
-
-Required outputs: from-agent, to-agent, decision, risk, required outputs status, evidence path.
-
-## `/frontend`
-
-Run the frontend-change workflow with content-first design gates.
-
-Required steps:
-
-1. Complete brand/content intake and creative-direction rationale.
-2. Load the matching design brief and `DESIGN.md` / `MESSAGING.md` when public-facing.
-3. Require reference-set evidence, distinctiveness benchmark, and product-quality scorecard for significant UI work.
-4. Route implementation through Next.js Engineer after design acceptance.
-5. Use UI commands from `.agent-kit/prompts/ui-command-index.md` when polishing or auditing.
-
-Required outputs: creative direction, reference evidence, scorecard, UI rationale, visual QA plan, handoffs.
-
-## `/audit`
-
-Run the Agent Kit maturity audit and convert findings into follow-up work.
-
-Required steps:
-
-1. Run `agent-kit audit --json` when the CLI is available.
-2. Classify failures before warnings.
-3. Map each finding to the responsible council role.
-4. Record remediation tasks with `agent-kit session output` when a session is active.
-
-Required outputs: readiness level, failures, warnings, owner/council role, remediation order, verification command.
-
-## `/test`
-
-Add or run tests and produce acceptance evidence.
-
-Required steps:
-
-1. Route through QA Engineer.
-2. Read `TESTING.md` and the maturity target from `QUALITY_GATES.md`.
-3. Name unit, regression, smoke, and visual QA gaps for the change scope.
-4. Run project test commands and capture results.
-5. Record verification with `agent-kit session verify` when a session is active.
-
-Required outputs: test plan, commands run, pass/fail summary, coverage gaps, skipped-test rationale.
-
-## `/review`
-
-Run pre-merge code health review before `/ship`.
-
-Required steps:
-
-1. Route through QA Engineer for behavior, regression, and test evidence.
-2. Include Security Reviewer when auth, RLS, data mutation, dependency, secret, or external-call boundaries changed.
-3. Return findings by severity with concrete remediation.
-4. Distinguish this from release GO/NO-GO, which belongs to `/ship`.
-
-Required outputs: reviewed scope, findings by severity, required fixes, security notes when applicable, merge recommendation.
-
-## `/security`
-
-Run OWASP, auth, RLS, dependency, secret, and external-call review.
-
-Required steps:
-
-1. Route through Security Reviewer.
-2. Check OWASP Top 10, IDOR, SSRF, injection, broken auth, unsafe output rendering, secret leakage, and vulnerable dependencies.
-3. Verify service-role access stays server-only.
-4. Record findings with severity, exploit path, affected behavior, and remediation.
-
-Required outputs: reviewed boundaries, findings, severity, exploit path, mitigation, negative authorization tests or skipped rationale.
-
-## `/copy`
-
-Run marketing and conversion copy discovery and review.
-
-Required steps:
-
-1. Route through Marketing Copy Lead.
-2. Read or update `MESSAGING.md` for audience, pain, outcome, proof, objections, voice, and CTA.
-3. Reject vague SaaS copy, unsupported claims, and interchangeable headlines.
-4. Hand off public-facing copy to Frontend Design Lead for layout hierarchy review.
-
-Required outputs: discovery answers, value proposition, proof status, voice/tone, copy inventory, CTA hierarchy, design handoff notes.
-
-## `/ship`
-
-Make a GO/NO-GO release call from council, security, QA, docs, deployment, and rollback evidence.
-
-Required steps:
-
-1. Confirm implementation scope and preserved behavior.
-2. Require code review, Security Reviewer signoff, QA/test evidence, accessibility evidence when UI changed, docs evidence, deployment review, and rollback plan.
-3. Run the project release gate, normally `npm run release:check` for this package or the project-specific equivalent.
-4. Record verification with `agent-kit session verify`.
-5. Return GO only when required outputs are complete or explicitly not applicable.
-
-Required outputs: code review, security review, QA/test review, accessibility/doc/deployment checks, rollback plan, release command, GO/NO-GO verdict.
-
-## `/upgrade`
-
-Upgrade Agent Kit, framework, or dependency versions safely.
-
-Required steps:
-
-1. Read `UPGRADE.md` before accepting versioned behavior changes.
-2. Run `agent-kit diff` before accepting template changes.
-3. Preserve valid local overrides in `.agent-kit/overrides.json`.
-4. Record package versions, migration order, rollback notes, verification commands, owner, and date.
-
-Required outputs: upgrade scope, diff summary, conflict risk, migration order, rollback plan, verification commands.

package/prompts/migration-review.md

@@ -1,14 +0,0 @@
-# Migration Review Prompt
-
-Review this Supabase/Postgres migration.
-
-Check:
-
-- Schema correctness
-- Constraints and indexes
-- RLS enablement
-- Select, insert, update, and delete policies
-- Ownership and tenant boundaries
-- Service-role assumptions
-- Backfill or destructive-change risk
-- Rollback and deployment order

package/prompts/screenshot-review.md

@@ -1,28 +0,0 @@
-# Screenshot Review Prompt
-
-Use after a UI is implemented and screenshots are available across desktop and mobile.
-
-Review the screenshots against the product goal, `DESIGN.md`, design brief, and `STYLE_GUIDE.md`.
-
-Check:
-
-- First screen shows the real product, task, object, or workflow.
-- The selected creative direction is visible in tokens, layout, copy, imagery, density, and interaction tone.
-- Layout is usable on desktop and mobile without overlapping text or controls.
-- Visual direction fits the domain and does not rely on generic AI-site gradients, accent-border cards, glow rails, neon strokes, gradient borders, card soup, oversized glass panels, ornamental icon walls, vague SaaS copy, decorative credibility badges, filler sections, or fake metrics.
-- Cards, callouts, alerts, panels, and status messages use restrained 1px full-border surfaces, subtle background tint when needed, clear labels, icons, semantic state text, and WCAG AA contrast instead of decorative borders or color-only state.
-- Design tokens are visible in color, typography, spacing, radius, state color, and focus treatment.
-- Loading, empty, error, disabled, success, and mobile states are represented or explicitly accounted for.
-- Visual QA tier is appropriate for the risk: screenshot review, Playwright screenshots, Storybook visual tests, or visual-regression service.
-- Controls use familiar patterns: icons for repeated tools, inputs for values, toggles for booleans, tabs for views, and menus for option sets.
-- Text is specific, scannable, and not padded with feature explanations.
-- Accessibility risks are called out: contrast, focus, keyboard order, touch target size, labels, semantics, and motion.
-
-Return:
-
-1. Critical blockers.
-2. High-value polish fixes.
-3. Evidence that the screen avoids generic AI-site defaults.
-4. Evidence that the screen follows the selected creative direction.
-5. Visual QA tier and baseline-review risks.
-6. Follow-up screenshots or states still required.

package/prompts/security-review.md

@@ -1,17 +0,0 @@
-# Security Review Prompt
-
-Review this change against OWASP Top 10 and the project's Supabase/Auth/RLS boundaries.
-
-Prioritize:
-
-- Broken access control
-- IDOR
-- Injection
-- SSRF
-- Secret exposure
-- Service-role misuse
-- Missing RLS
-- Unsafe dependencies
-- Misconfiguration
-
-Lead with findings ordered by severity. Include exploit path, affected behavior, and remediation.