@appsforgood/next-supabase-kit 0.3.0 → 0.4.0

package/assistant-adapters/model-selection/cursor-model-selection.mdc

@@ -1,24 +0,0 @@
----
-description: Agent Kit model-selection reminder for Cursor.
-globs:
-  - "**/*"
-alwaysApply: true
----
-
-# Agent Kit Model Selection
-
-Use `MODEL_ROUTING.md` and `.agent-kit/model-routing.json` when choosing a model for the active task.
-
-## June 2026 Recommendations
-
-<!--
-Cursor model selection is controlled by the user, workspace, model picker, or team policy.
-This rule advises routing; it should not be treated as hard enforcement.
--->
-
-- Use a deep reasoning model for Lead Architect, Security Reviewer, Supabase/Postgres Engineer, migrations, RLS, auth, dependencies, release risk, and cross-layer decisions.
-- Use a strong coding model with large context for Next.js Engineer work across App Router, Server Actions, Route Handlers, forms, caching, and UI state.
-- Use a creative/vision-capable model for Frontend Design Lead work, especially screenshot critique, references, and distinctiveness benchmarking.
-- Use a fast or balanced model for low-risk docs, deployment notes, and repeated QA summaries.
-
-Record the selected Cursor model, rule evidence, date, owner, and limitations in `ASSISTANT_ADAPTERS.md`.

package/assistant-adapters/model-selection/github-copilot-model-selection.md

@@ -1,20 +0,0 @@
-# GitHub Copilot Model Selection
-
-Repository instructions can advise model choice, but model selection remains controlled by the Copilot surface, organization policy, and the user's active model picker.
-
-Use `MODEL_ROUTING.md` and `.agent-kit/model-routing.json` before starting agentic work.
-
-## June 2026 Recommendations
-
-<!--
-Select the strongest available Copilot model for architecture, security, Supabase RLS, migrations, release risk, and ambiguous planning.
-Select a faster available model for docs-only cleanup, narrow test triage, or low-risk repeated checks.
-These comments are dated setup guidance, not a guarantee that Copilot will enforce model choice from repository files.
--->
-
-## Evidence To Record
-
-- Copilot surface used: chat, edit, coding agent, PR review, or other.
-- Active model or organization policy, if visible.
-- Instruction file loaded: `.github/copilot-instructions.md` or `.github/instructions/*.instructions.md`.
-- Date, owner, and known limitations.

package/assistant-adapters/orchestrator-runtime.md

@@ -1,39 +0,0 @@
-# Orchestrator Runtime Adapter
-
-`@appsforgood/agent-kit-runtime` is the optional executable layer for the Agent Kit council. IDE rules, subagents, slash commands, and model-routing documents remain instruction adapters; they do not imply that a checkpointed graph ran.
-
-## Activation
-
-```bash
-npm install --save-dev @appsforgood/agent-kit-runtime
-agent-kit orchestrate validate
-agent-kit orchestrate plan "Describe the goal"
-```
-
-Edit `.agent-kit/orchestrator.json`, add provider credential references such as `env:OPENAI_API_KEY` or `keychain:team-openai`, configure at least one deterministic model alias, and set `enabled` to `true` only after validation passes.
-
-## Execution Contract
-
-- Roster workflows compile to explicit, bounded LangGraph nodes.
-- Runs pause at plan, network, worktree-write, host-execution, and final-commit gates when applicable.
-- Mutations occur in an isolated Git worktree. Agent Kit may create one scoped commit after approval; it never merges, pushes, or opens a pull request.
-- Docker is the default mutation command boundary. Network access is off unless configured and approved.
-- Provider and remote MCP requests reject redirects, embedded credentials, non-allowlisted hosts, and private or special-use addresses unless private access is explicitly configured.
-- Stdio MCP servers execute on the host only when both `allowHostExecution` and `sandbox.allowHostMutations` are enabled and the host gate is approved.
-- Run checkpoints live in `.agent-kit/runtime/runtime.sqlite`; redacted run records and JSONL evidence live under `.agent-kit/runtime/runs/` and are ignored by Git.
-
-## Cursor Executor
-
-Set an agent route to `cursor` only when Cursor CLI execution is intentionally required. The runtime invokes argv directly inside the isolated worktree, with no shell, a bounded timeout, minimal inherited environment, and an explicit host-mutation approval. Provider-backed model agents remain the default.
-
-## Verification
-
-Record:
-
-- `agent-kit orchestrate validate --json`
-- the offline `orchestrate plan` output
-- provider and MCP probe results, without credentials
-- run ID, approval decisions, scoped commit, and exported evidence
-- Docker image ID and any private-network or host-execution exception rationale
-
-Use `agent-kit studio serve` to inspect and decide paused runs in the local Studio UI.

package/checklists/accessibility.md

@@ -1,12 +0,0 @@
-# Accessibility Checklist
-
-- Semantic HTML used first.
-- ARIA used only when needed.
-- Keyboard navigation works.
-- Focus states are visible.
-- Color contrast meets WCAG 2.1 AA.
-- Forms have labels and error messages.
-- Custom controls expose state.
-- Content does not rely only on color or motion.
-- Critical flows have keyboard-only smoke coverage.
-- Accessibility tooling or manual checks are documented in `TESTING.md`.

package/checklists/agent-council.md

@@ -1,13 +0,0 @@
-# Agent Council Checklist
-
-- `.agent-kit/agent-roster.json` exists and matches the expected default council contract.
-- `.agent-kit/schemas/agent-roster.schema.json` exists for roster validation.
-- `.agent-kit/schemas/council-session.schema.json` exists for structured session evidence.
-- Planner starts planning, roadmap, ambiguous, and cross-layer requests.
-- Lead Architect reviews core changes before implementation.
-- Security Reviewer joins auth, data mutation, dependency, external-call, secret, and release-risk work.
-- Frontend Design Lead joins user-facing frontend work with creative direction and visual QA evidence.
-- QA Engineer verifies behavior changes before completion.
-- Documentation Maintainer updates living docs when behavior, architecture, release, or standards change.
-- Every handoff records decision, risk, next handoff, and evidence.
-- Missing required outputs are marked missing or partial rather than hidden.

package/checklists/brand-content.md

@@ -1,15 +0,0 @@
-# Brand And Content Checklist
-
-- Product category is named.
-- Primary audience and user needs are written in user language.
-- Real content inventory exists: nouns, labels, records, data fields, examples, and assets.
-- First screen is tied to a real task, object, or workflow.
-- Brand personality has 3-5 visible traits.
-- Existing logo, colors, fonts, platform conventions, and accessibility constraints are captured.
-- Category references are used for learning only; no source is copied.
-- Non-goals name visual tropes, copy patterns, palettes, or layouts to avoid.
-- Anti-references are explicit enough to prevent generic AI-site defaults.
-- Source-safety notes name brand marks, layouts, copy, or assets that must not be copied.
-- At least two creative directions were considered before implementation.
-- Chosen direction affects tokens, layout, copy, imagery, and interaction tone.
-- Missing content or assets are documented instead of hidden behind generic placeholders.

package/checklists/deployment.md

@@ -1,10 +0,0 @@
-# Deployment Checklist
-
-- Required env vars are present.
-- Server-only secrets are not exposed.
-- Migrations are applied in the right order.
-- RLS and Storage policies are verified.
-- Build passes.
-- Smoke tests pass.
-- Logs and monitoring are checked.
-- Rollback steps are documented.

package/checklists/design-critique.md

@@ -1,13 +0,0 @@
-# Design Critique Checklist
-
-- `DESIGN.md` includes a reference set and anti-references.
-- References are used for learning, not copying.
-- Source-safety notes identify brand marks, layouts, copy, or assets that must not be copied.
-- The first screen shows the product's real task, object, content, or workflow.
-- The chosen creative direction is visible in typography, layout, density, color, imagery, copy, and interaction tone.
-- Distinctiveness verdict is recorded as weak, adequate, or strong.
-- Frontend product-quality scorecard records user/task fit, content specificity, visual identity, information architecture, component states, accessibility and interaction, and source safety.
-- Generic AI-site risks are explicitly accepted, changed, or rejected.
-- Desktop and mobile screenshots or previews were reviewed.
-- Important empty, loading, error, disabled, success, and permission states were reviewed.
-- Accessibility and visual QA evidence match the risk of the UI change.

package/checklists/frontend-distinctiveness.md

@@ -1,12 +0,0 @@
-# Frontend Distinctiveness Checklist
-
-- First viewport shows the real product object, task, workflow, content, or decision.
-- Product nouns, labels, data shapes, records, actions, and edge cases are visible or documented.
-- Reference benchmark includes 3-5 references with lessons to learn.
-- Anti-references include 2-3 category tropes, palettes, layouts, copy patterns, or interaction habits to avoid.
-- Source-safety notes explain what must not be copied from references.
-- At least two creative directions were compared before implementation.
-- Asset provenance is recorded for real, generated, licensed, and placeholder visuals.
-- Loading, empty, error, disabled, success, permission, and focus states are covered where relevant.
-- Desktop and mobile evidence exists, plus visual QA for high-risk screens.
-- A design cannot pass if it would still work unchanged for another product in the same category.

package/checklists/frontend-product-quality.md

@@ -1,13 +0,0 @@
-# Frontend Product Quality Checklist
-
-- User/task fit score is at least `1`, and preferably `2`.
-- Content specificity score is at least `1`, and preferably `2`.
-- Visual identity score explains why the result fits this product rather than a generic category.
-- Information architecture score covers primary and secondary workflows.
-- Component state score covers important loading, empty, error, disabled, success, permission, and focus states.
-- Accessibility and interaction score covers keyboard path, focus, contrast, labels, reduced motion, and error feedback.
-- Source-safety score confirms references were learned from, not copied.
-- Total score is at least `10/14` before acceptance.
-- Best-practice claim requires at least `12/14`, no critical zeroes, desktop/mobile screenshot review, and visual QA evidence.
-- Best-practice claim also requires frontend distinctiveness benchmark evidence: first-screen proof, content fingerprint, reference benchmark, asset provenance, state proof, and visual QA proof.
-- `DESIGN.md` records the scorecard verdict and required changes.

package/checklists/frontend-quality.md

@@ -1,21 +0,0 @@
-# Frontend Quality Checklist
-
-- First screen shows the actual product or task.
-- `DESIGN.md` includes product category, audience, user needs, content inventory, brand constraints, and creative direction.
-- Brand/content intake was completed before visual implementation.
-- At least two creative directions were considered.
-- Reference set, anti-references, and source-safety notes are recorded.
-- Design critique verdict is adequate or strong before release.
-- Frontend product-quality scorecard is at least adequate before release.
-- Visual direction fits the domain.
-- No generic AI-site gradient/card defaults.
-- No accent-border cards, glow rails, neon strokes, gradient borders, oversized glass panels, ornamental icon walls, fake dashboard proof, decorative credibility badges, vague SaaS sayings, or layout filler sections unless documented as a brand-system exception.
-- Navigation is clear and predictable.
-- Loading, empty, error, disabled, and success states exist.
-- Mobile layout is designed, not incidental.
-- Component spacing, type, and density are consistent.
-- Forms are accessible and provide useful feedback.
-- Design tokens cover color, typography, spacing, radius, motion, depth, state color, and focus treatment.
-- A product-specific design brief has been used for SaaS, admin, marketplace, content, tool, ecommerce, portfolio/venue, education, community/social, or AI workflow surfaces.
-- Desktop and mobile screenshots have been reviewed with `prompts/screenshot-review.md`.
-- Visual QA tier is documented for high-risk UI changes.

package/checklists/marketing-copy.md

@@ -1,11 +0,0 @@
-# Marketing And Copy Checklist
-
-- `MESSAGING.md` identifies audience, pain, desired outcome, alternatives, differentiator, proof, objections, voice, and conversion goal.
-- Missing positioning inputs are asked as explicit questions before final copy is written.
-- Claims are supported by named proof or marked as assumptions.
-- Headline, subhead, CTA, proof, and objection handling match the same value proposition.
-- Copy uses real product nouns, workflows, constraints, and customer language.
-- CTAs have one primary action and clear secondary actions.
-- Onboarding, empty, error, upgrade, and permission copy provide a useful next step.
-- Risky claims around pricing, privacy, security, compliance, performance, medical, financial, or legal topics are reviewed before release.
-- Marketing Copy Lead hands off to Frontend Design Lead for public-facing layout and visual hierarchy.

package/checklists/owasp.md

@@ -1,12 +0,0 @@
-# OWASP Checklist
-
-- Broken access control: RLS, ownership, tenant boundary, admin checks.
-- Cryptographic failures: secrets, tokens, PII, transport security.
-- Injection: SQL, command, template, prompt, and header injection.
-- Insecure design: abuse cases and missing security controls.
-- Misconfiguration: env vars, CORS, headers, storage, public buckets.
-- Vulnerable components: dependency additions and audit status.
-- Auth failures: login, logout, refresh, session expiry, protected routes.
-- Integrity failures: CI, package installs, migrations, webhooks.
-- Logging failures: errors visible without leaking secrets.
-- SSRF: external URL validation and egress restrictions.

package/checklists/rls.md

@@ -1,10 +0,0 @@
-# Supabase RLS Checklist
-
-- RLS enabled on every user-owned or tenant-owned table.
-- Policies exist for each required operation.
-- Policies enforce `auth.uid()` or tenant membership.
-- Admin policies are explicit and least-privilege.
-- Storage buckets have policies.
-- Service-role use is isolated to server-only code.
-- IDOR attempts are tested.
-- Policy assumptions are documented.

package/checklists/testing.md

@@ -1,12 +0,0 @@
-# Testing Checklist
-
-- Unit tests cover core logic.
-- Regression tests preserve existing behavior.
-- Playwright smoke tests cover critical paths.
-- Visual QA evidence exists for high-risk UI changes.
-- Auth, admin, and data mutations are prioritized.
-- Empty/error/loading states are covered where practical.
-- Test gaps and residual risks are documented.
-- CI gates are documented and match the commands used by the project.
-- Playwright smoke coverage exists for the primary workflow before release.
-- Visual baseline updates require human review and rationale when visual-regression tooling exists.

package/checklists/ui-acceptance-rubric.md

@@ -1,58 +0,0 @@
-# UI Acceptance Rubric
-
-Use this rubric after the UI detector checklist, screenshot critique, accessibility pass, and browser QA loop.
-
-## Pass/Fail
-
-| Verdict | Criteria |
-| --- | --- |
-| fail | Any blocker remains, required screenshot evidence is missing, or authenticated screens were not reviewed when auth is required |
-| conditional | No blockers remain, but major findings need documented owner, rationale, or follow-up before high-risk release |
-| pass | No blockers remain, major findings are fixed or explicitly accepted, and evidence covers viewports, states, and auth needs |
-| strong | Pass criteria plus clear product specificity, accessible keyboard flow, responsive resilience, and state coverage for the workflow |
-
-## Required Evidence
-
-- Target surface: route, component, flow, or screenshot set.
-- Product context source: `DESIGN.md`, `STYLE_GUIDE.md`, design brief, or documented override.
-- Viewports: desktop and mobile dimensions.
-- Auth state: public, signed-in, role, tenant, permission, or explicit not-applicable.
-- Data state: realistic, empty, loading, error, or fixture notes.
-- Screenshots: first viewport, primary workflow, mobile, and highest-risk state.
-- Checks: detector checklist, accessibility pass, screenshot critique, and visual QA tier.
-
-## Release Blocking Rules
-
-- Block release for any blocker detector.
-- Block high-risk UI release when desktop or mobile screenshot evidence is missing.
-- Block authenticated workflow release when no signed-in or permission-state evidence exists.
-- Block acceptance when loading, empty, error, disabled, success, permission, or focus states are relevant but omitted without rationale.
-- Block best-practice claims when product specificity, accessibility, or source safety is weak.
-
-## Risk Tiers
-
-| Tier | Use When | Minimum Evidence |
-| --- | --- | --- |
-| low | Copy-only or isolated cosmetic change to a stable component | Targeted screenshot or component evidence plus detector review |
-| medium | Layout, responsive, or state changes on a user-facing surface | Desktop and mobile screenshots plus relevant state evidence |
-| high | Authenticated workflow, checkout, data mutation, admin, onboarding, or shared component system | Desktop, mobile, auth/permission, error/empty/loading, keyboard/focus, and smoke evidence |
-
-## Exception Rules
-
-Exceptions are allowed only when:
-
-- The finding is not a blocker.
-- The rationale names product or technical constraints.
-- The owner and follow-up path are documented.
-- The exception does not weaken auth, accessibility, data integrity, or source safety.
-
-## Output Format
-
-Return:
-
-1. Verdict: fail, conditional, pass, or strong.
-2. Risk tier and target surface.
-3. Evidence reviewed.
-4. Blockers, majors, minors, and accepted exceptions.
-5. Required fixes before release.
-6. Follow-up work after release.

package/checklists/ui-detectors.md

@@ -1,81 +0,0 @@
-# UI Detector Checklist
-
-Use this deterministic checklist for UI audit, polish, layout cleanup, responsive cleanup, screenshot critique, and browser QA. Mark each item as `blocker`, `major`, `minor`, `pass`, or `not-applicable`.
-
-## Severity
-
-| Severity | Meaning |
-| --- | --- |
-| blocker | Prevents release because a user cannot complete the workflow, the UI is inaccessible, or required evidence is missing |
-| major | Degrades comprehension, trust, responsiveness, or state handling enough that high-risk UI should not ship without a fix or accepted exception |
-| minor | Polish issue that should be fixed when nearby but does not block normal release |
-| pass | Checked and acceptable for the target surface |
-| not-applicable | The detector does not apply to this surface or state |
-
-## Layout And Hierarchy
-
-| Detector | Blocker Signal | Major Signal |
-| --- | --- | --- |
-| Crowded layout | Primary workflow cannot be identified or completed | Too many competing sections, controls, badges, or panels |
-| Weak hierarchy | Primary action or current state is hidden | Headings, labels, and actions do not establish clear priority |
-| Inconsistent spacing | Spacing causes overlap or unusable controls | Density, gaps, padding, or alignment shift without system logic |
-| Card-within-card | Nested containers obscure the workflow or trap scroll | Decorative nested panels add visual noise without information value |
-| Poor grouping | Related controls are separated or unrelated items are grouped | Scan path is unclear or section boundaries are arbitrary |
-
-## Responsive And Mobile
-
-| Detector | Blocker Signal | Major Signal |
-| --- | --- | --- |
-| Poor tap targets | Critical control is too small, overlapped, or unreachable | Repeated controls feel cramped or hard to tap |
-| Truncation or overflow | Text, inputs, tables, or controls clip essential content | Labels wrap badly, overflow horizontally, or push layout off-screen |
-| Mobile hierarchy | Mobile first screen hides the primary task or action | Desktop order collapses into a confusing mobile sequence |
-| Sticky or fixed UI | Fixed header/footer covers content or controls | Sticky UI consumes too much viewport or causes awkward scrolling |
-| Orientation and narrow widths | Page breaks at common mobile widths | Responsive behavior is untested below tablet width |
-
-## States And Feedback
-
-| Detector | Blocker Signal | Major Signal |
-| --- | --- | --- |
-| Missing loading state | User can trigger duplicate or unsafe action while waiting | Loading state exists but does not preserve layout or context |
-| Missing empty state | Empty data leaves a dead end | Empty state lacks next action or domain-specific guidance |
-| Missing error state | Failure is silent or blocks recovery | Error is vague, unactionable, or visually disconnected |
-| Missing disabled state | Disabled action looks enabled or loses explanation | Disabled state lacks affordance, label, or contrast |
-| Missing success feedback | User cannot tell whether action completed | Success message is too subtle, transient, or ambiguous |
-| Missing permission state | Protected UI leaks actions or fails without explanation | Permission limitation is not clear to the affected role |
-| Weak interaction feedback | Focus, selected, hover, pressed, or active state is absent on critical controls | State feedback is inconsistent across similar controls |
-
-## Accessibility
-
-| Detector | Blocker Signal | Major Signal |
-| --- | --- | --- |
-| Keyboard path | Critical workflow cannot be completed by keyboard | Tab order is confusing or focus moves unexpectedly |
-| Focus visibility | Focus indicator is absent on interactive controls | Focus is low contrast or inconsistent |
-| Semantic structure | Heading, landmark, form, table, or button semantics block assistive tech use | Semantics are mostly present but incomplete |
-| Labels and errors | Inputs or controls lack accessible names or error association | Labels exist but are vague, duplicate, or visually disconnected |
-| Contrast | Text or critical controls fail WCAG 2.1 AA contrast | Secondary text or state colors are borderline |
-| Motion | Motion prevents comprehension or ignores reduced-motion need | Motion distracts from workflow or feels inconsistent |
-
-## Distinctiveness And Source Safety
-
-| Detector | Blocker Signal | Major Signal |
-| --- | --- | --- |
-| Generic SaaS styling | First screen could fit another product by changing logo and headline | Visual direction relies on common cards, gradients, fake dashboards, or vague claims |
-| Accent-border card styling | Cards, callouts, alerts, panels, or status messages rely on thick, high-contrast, one-sided colored borders, glow rails, neon strokes, or gradient borders as the main state cue | Accent borders add decoration where restrained 1px full-border surfaces, subtle background tint, clear labels, icons, and semantic state text would communicate better |
-| Gradient-as-design | Gradient hero, gradient text, abstract blobs, or glow backgrounds substitute for a product-specific first screen | Gradients are present without a tokenized role, brand rationale, or product-specific content support |
-| Card soup | The screen is mostly decorative cards and the primary workflow is unclear | Repeated cards could become a table, list, timeline, form, split pane, or workflow-specific grouped section |
-| Missing content fingerprint | UI hides missing product decisions behind placeholders | Real nouns, records, actions, or edge cases are too sparse |
-| Weak visual identity | No product-specific density, typography, imagery, or interaction point of view | Direction is coherent but category-generic |
-| Unsafe reference use | Copy, assets, layout signature, or brand identity appear copied | References are cited without lessons and anti-copy notes |
-| Fake or unsupported proof | Fake metrics or claims imply unavailable capability | Proof exists but is not tied to actual product behavior |
-| Vague SaaS sayings | Copy could apply to any product and hides what the user can actually do | Phrases like "supercharge your workflow", "unlock insights", "seamless collaboration", or "AI-powered productivity" are not grounded in concrete actions, nouns, constraints, or outcomes |
-| Decorative credibility | Badges, pills, stars, awards, or "trusted by" placeholders imply proof that does not exist | Credibility elements are decorative and should be replaced with real proof, integration names, security posture, support details, or removed |
-| Filler sections | Marketing sections replace the requested app or tool workflow on the first screen | "Features", "benefits", or "how it works" sections are generic and should be replaced with the actual usable workflow or domain-specific hierarchy |
-
-## Evidence Requirements
-
-- Desktop screenshot reviewed.
-- Mobile screenshot reviewed.
-- Highest-risk state screenshot reviewed.
-- Authenticated or permission-state screenshot reviewed when applicable.
-- Browser route, viewport, data fixture, and user role named.
-- Detector exceptions documented with rationale and owner.

package/checklists/upgrade.md

@@ -1,13 +0,0 @@
-# Upgrade Checklist
-
-- [ ] Branch created before upgrade work.
-- [ ] Release notes, changelog, or migration guide reviewed.
-- [ ] `agent-kit diff` reviewed before template updates.
-- [ ] `agent-kit update` run only after preserving local work.
-- [ ] `.agent-kit/conflicts/` reviewed.
-- [ ] `.agent-kit/overrides.json` updated for accepted local deviations.
-- [ ] Next.js codemods or manual upgrade steps reviewed when framework behavior changes.
-- [ ] Supabase migration history, RLS impact, generated types, and rollback risk reviewed when data/auth changes.
-- [ ] Tests, smoke checks, visual QA, or release checks run for affected areas.
-- [ ] `agent-kit audit --min-readiness baseline-setup` passes.
-- [ ] Upgrade evidence, rollback notes, owner, and date recorded in `UPGRADE.md`.

package/checklists/visual-regression.md

@@ -1,11 +0,0 @@
-# Visual Regression Checklist
-
-- Visual QA tier is documented: baseline screenshots, Playwright screenshots, Storybook visual tests, or visual-regression service.
-- Desktop and mobile screenshots exist for primary screens.
-- Reusable components have state stories or screenshot cases for default, loading, empty, error, disabled, success, permission-denied, and mobile states.
-- Dynamic or volatile regions are mocked, masked, frozen, or excluded with rationale.
-- Baseline updates require human review and a short rationale.
-- CI or review notes link to screenshot artifacts, Storybook, Chromatic, Argos, Playwright report, or equivalent evidence.
-- Visual checks cover at least one narrow/mobile viewport and one desktop viewport.
-- Visual checks do not replace accessibility, keyboard, semantic, auth, or data-boundary tests.
-- Known visual QA gaps are recorded in `TESTING.md` before release.

package/design-adapters/claude-design.prompt.md

@@ -1,27 +0,0 @@
-# Claude Design Review Brief
-
-Review or generate UI direction for this product.
-
-Context:
-
-- DESIGN.md: `{{design_md}}`
-- Product: `{{product}}`
-- Users: `{{users}}`
-- Primary task: `{{primary_task}}`
-- Current risk: `{{design_risk}}`
-
-Output:
-
-- Design critique.
-- Brand/content gaps.
-- Creative-direction options or selected-direction critique.
-- Reference-set, anti-reference, and source-safety critique.
-- Frontend product-quality scorecard across user/task fit, content specificity, visual identity, information architecture, component states, accessibility and interaction, and source safety.
-- Improved information architecture.
-- Component inventory.
-- Mobile and desktop layout guidance.
-- Accessibility notes.
-- Copy improvements.
-- States for loading, empty, error, disabled, and success.
-
-Reject generic AI-site patterns and prefer product-specific workflow clarity.

package/design-adapters/figma.prompt.md

@@ -1,18 +0,0 @@
-# Figma Design Brief
-
-Create a Figma-ready design direction.
-
-Include:
-
-- DESIGN.md brand/content inputs and creative-direction matrix.
-- Reference set, anti-references, and source-safety notes.
-- Product-quality scorecard requirements and acceptance threshold.
-- Page structure.
-- Component list.
-- Design tokens.
-- Responsive behavior.
-- Form and control states.
-- Accessibility requirements.
-- Notes for handoff to implementation.
-
-Avoid generic AI-site visual defaults and prioritize the real product workflow.

package/design-adapters/google-stitch.prompt.md

@@ -1,36 +0,0 @@
-# Google Stitch Design Brief
-
-Use this brief to generate distinct interface directions from real product content and brand constraints.
-
-DESIGN.md context:
-`{{design_md}}`
-
-Project type:
-`{{project_type}}`
-
-Audience:
-`{{audience}}`
-
-Primary workflow:
-`{{primary_workflow}}`
-
-Design requirements:
-
-- Create three distinct directions unless `DESIGN.md` already selects one.
-- Create mobile and desktop screens.
-- Show real workflow states.
-- Use domain-specific hierarchy.
-- Tie tokens, layout, copy, imagery, density, and interaction tone to the selected content and audience.
-- Use the reference set for learning only and respect all anti-references and source-safety notes.
-- Return a product-quality scorecard covering user/task fit, content specificity, visual identity, information architecture, component states, accessibility and interaction, and source safety.
-- Include design tokens.
-- Include empty, loading, error, disabled, and success states.
-- Meet WCAG 2.1 AA.
-
-Avoid:
-
-- Generic purple-blue gradients.
-- Abstract card dashboards.
-- Fake metrics.
-- Vague SaaS copy.
-- Placeholder landing pages.

package/design-adapters/human-designer-brief.prompt.md

@@ -1,36 +0,0 @@
-# Human Designer Brief
-
-## Product
-
-`{{product}}`
-
-## Audience
-
-`{{audience}}`
-
-## Primary Workflow
-
-`{{primary_workflow}}`
-
-## Design Context
-
-`{{design_md}}`
-
-## What We Need
-
-- Domain-specific visual direction.
-- Brand/content gaps and creative-direction recommendation.
-- Reference-set critique, anti-references, and source-safety concerns.
-- Product-quality scorecard with acceptance verdict.
-- Mobile and desktop screens.
-- Design tokens.
-- Component states.
-- Accessibility review.
-- Notes for implementation.
-
-## Avoid
-
-- Generic AI-generated SaaS visuals.
-- Placeholder copy.
-- Fake data.
-- Unclear primary action.

package/design-briefs/admin-dashboard.md

@@ -1,21 +0,0 @@
-# Admin Dashboard Design Brief
-
-Use this brief for internal tools, ops consoles, moderation queues, analytics, and support workflows.
-
-## Product Signals
-
-- First screen should prioritize active work, exceptions, stale items, and operational health.
-- Avoid oversized hero copy, decorative gradients, and promotional layout patterns.
-- Show filters, saved views, bulk actions, and audit trails where relevant.
-
-## Required States
-
-- Loading, empty, filtered-empty, error, partial-data, disabled, success, and permission-denied states.
-- Dense desktop workflow and usable mobile read/review mode.
-- Confirmation and undo patterns for destructive actions.
-
-## Design Direction
-
-- Favor calm information density, sticky table affordances, visible status language, and predictable controls.
-- Use color sparingly for severity, freshness, ownership, and action state.
-- Every chart or metric needs a label, source, timestamp, and empty/error fallback.

package/design-briefs/ai-workflow-product.md

@@ -1,25 +0,0 @@
-# AI Workflow Product Design Brief
-
-Use when designing AI assistants, automation tools, generation workflows, review queues, prompt tools, eval dashboards, agent consoles, or human-in-the-loop products.
-
-## First Screen
-
-Show the real work loop: input, context, model/agent state, output, review, approval, correction, or history. Do not hide the product behind a generic "AI-powered" hero.
-
-## Required Inputs
-
-- User role: operator, reviewer, creator, analyst, developer, admin, or end customer.
-- AI workflow: input sources, context, tools, model calls, outputs, approvals, retries, and audit trail.
-- Trust needs: citations, uncertainty, permissions, rate limits, cost, privacy, and rollback.
-- Human control points: edit, approve, reject, compare, regenerate, escalate, or export.
-
-## Avoid
-
-- Chat box as the only interface when the workflow needs structure.
-- Fake model confidence or fake analytics.
-- Magical language that hides limitations, costs, or review responsibility.
-- Outputs without provenance, status, or recovery path.
-
-## Required States
-
-Queued, streaming, partial output, failed tool call, hallucination report, needs review, approved, rejected, regenerated, rate limited, permission denied, audit trail, mobile review.

package/design-briefs/community-social.md

@@ -1,26 +0,0 @@
-# Community Or Social Design Brief
-
-Use when designing communities, forums, social feeds, member directories, messaging, comments, creator tools, clubs, or collaborative spaces.
-
-## First Screen
-
-Show the community's real activity, topics, people, norms, or contribution path. Avoid generic feed layouts that could belong to any network.
-
-## Required Inputs
-
-- Member types and participation goals.
-- Content types: posts, comments, events, projects, resources, profiles, messages, reactions.
-- Moderation and safety model.
-- Trust, reputation, privacy, consent, and notification rules.
-- Community tone: expert, casual, local, professional, creator-led, support-focused.
-
-## Avoid
-
-- Fake engagement metrics.
-- Infinite feeds without prioritization or safety states.
-- Profile cards with no real identity or contribution signals.
-- Missing empty states for new or quiet communities.
-
-## Required States
-
-New community empty state, muted/blocked/report states, moderation pending, deleted content, private content, notification overload, mobile composer, slow/offline posting.