@appsforgood/next-supabase-kit 0.1.0

package/schemas/studio-session.schema.json

@@ -0,0 +1,48 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://agent-skills.dev/schemas/studio-session.schema.json",
+  "title": "Agent Kit Studio Session",
+  "type": "object",
+  "required": [
+    "schemaVersion",
+    "sessionId",
+    "title",
+    "createdAt",
+    "updatedAt",
+    "status",
+    "workflowId",
+    "request",
+    "affectedLayers",
+    "qualityTarget",
+    "requiredOutputs"
+  ],
+  "additionalProperties": false,
+  "properties": {
+    "schemaVersion": { "const": 1 },
+    "sessionId": { "type": "string", "minLength": 1 },
+    "title": { "type": "string", "minLength": 1 },
+    "createdAt": { "type": "string", "format": "date-time" },
+    "updatedAt": { "type": "string", "format": "date-time" },
+    "status": { "type": "string", "enum": ["planned", "in-progress", "blocked", "complete"] },
+    "workflowId": { "type": "string", "minLength": 1 },
+    "request": { "type": "string", "minLength": 1 },
+    "affectedLayers": { "type": "array", "items": { "type": "string" } },
+    "activeAgentId": { "type": "string" },
+    "nextAgentId": { "type": "string" },
+    "qualityTarget": { "type": "string", "enum": ["baseline-setup", "needs-improvement", "best-practice-candidate"] },
+    "requiredOutputs": {
+      "type": "array",
+      "items": {
+        "type": "object",
+        "required": ["name", "status"],
+        "additionalProperties": false,
+        "properties": {
+          "name": { "type": "string", "minLength": 1 },
+          "status": { "type": "string", "enum": ["missing", "partial", "complete", "not-applicable"] },
+          "evidence": { "type": "string" }
+        }
+      }
+    },
+    "renderedAt": { "type": "string", "format": "date-time" }
+  }
+}

package/skills/accessibility-wcag.md

@@ -0,0 +1,15 @@
+# Accessibility WCAG Skill
+
+## Use When
+
+Working on navigation, forms, modals, menus, tables, dashboards, custom controls, or interactive states.
+
+## Checklist
+
+- Semantic HTML is used where possible.
+- ARIA is used only when needed.
+- Keyboard navigation works.
+- Focus states are visible.
+- Color contrast meets WCAG 2.1 AA.
+- Forms have labels and clear error messages.
+- Motion is not required to understand the UI.

package/skills/agent-handoff-tracing.md

@@ -0,0 +1,44 @@
+# Agent Handoff Tracing Skill
+
+## Use When
+
+Planning, routing, reviewing, or completing work that involves more than one agent role, touches a core workflow, or needs auditable council evidence.
+
+## Goal
+
+Make agent collaboration inspectable. Every meaningful handoff should state who owns the next step, what was decided, what risk remains, and what evidence proves the required outputs.
+
+## Required Checks
+
+- Select the workflow from `.agent-kit/agent-roster.json`.
+- Read `.agent-kit/project-context.json` and `.agent-kit/project-context.md` when present.
+- Read active project and agent correction rules from `.agent-kit/corrections/` before making or reviewing decisions.
+- Confirm the workflow sequence and council members before implementation.
+- Record each agent handoff with decision, risk, next handoff, and evidence.
+- Confirm required outputs are missing, partial, complete, or not applicable.
+- Use `agent-kit session start`, `decision`, `handoff`, `correct`, `artifact`, `verify`, `render`, and `close` for local Agent Studio traces when available.
+- Use `COUNCIL.md` for human-readable notes and schema-backed `.agent-kit/council-sessions/` records when CLI tooling is unavailable.
+- Run `agent-kit audit` after adding structured session records.
+- Run `agent-kit session render` after changing session evidence so `index.md` and `transcript.md` are current.
+- Run `agent-kit studio export` when a self-contained local HTML session view would help the user inspect handoffs and transcript streams.
+- Do not mark a council session complete until required outputs and verification evidence are present.
+
+## Reject By Default
+
+- Specialist agents acting without Planner routing on ambiguous or cross-layer work.
+- Core changes that skip Lead Architect.
+- Security-sensitive work that skips Security Reviewer.
+- Behavior changes that skip QA evidence.
+- Handoffs with only a summary and no risk, next owner, or evidence.
+- Continuing after a user correction without recording the correction and deciding whether it should become a durable project or agent rule.
+
+## Review Output
+
+Return:
+
+- Workflow selected.
+- Agents required and agents actually involved.
+- Missing handoffs or missing required outputs.
+- Evidence that proves completion.
+- Recommended next handoff.
+- Agent Studio session path or rendered Markdown evidence when available.

package/skills/best-practice-maturity-review.md

@@ -0,0 +1,26 @@
+# Best-Practice Maturity Review
+
+Use this skill when deciding whether a project, feature, release, or repository setup is baseline, strong, or best-practice ready.
+
+## Required Inputs
+
+- Current request, roadmap item, or release scope.
+- `QUALITY_GATES.md`.
+- Relevant `SPEC.md`, `DECISIONS.md`, `SECURITY.md`, `DESIGN.md`, `TESTING.md`, and `DEPLOYMENT.md` sections.
+- Current council workflow from `.agent-kit/agent-roster.json`.
+
+## Review Steps
+
+1. Classify the target maturity level: baseline, strong, or best-practice.
+2. Map affected areas: council, architecture, Supabase/RLS, security, frontend, accessibility, testing, release, docs, and repo health.
+3. Name the evidence required for each affected area.
+4. Treat missing evidence as incomplete, not as a pass with caveats.
+5. Promote repeated research or dogfood findings into templates, skills, checklists, audit checks, tests, release gates, or `DECISIONS.md`.
+
+## Output
+
+- Maturity level claimed.
+- Missing evidence by area.
+- Required council handoffs.
+- Verification commands or artifacts.
+- Docs that must be updated before the work is considered done.

package/skills/content-first-design.md

@@ -0,0 +1,50 @@
+# Content-First Design Skill
+
+## Use When
+
+Building or reviewing any user-facing site, product screen, landing page, dashboard, tool, admin workflow, marketplace, content experience, ecommerce flow, portfolio, venue page, community surface, education product, or AI workflow UI.
+
+## Goal
+
+Prevent generic output by making the interface derive from the product's real audience, content, workflows, brand constraints, and category context before visual styling or component assembly starts.
+
+## Required Inputs
+
+Collect or infer these before implementation:
+
+- Primary audience and their user needs.
+- Real content inventory: nouns, labels, record types, data fields, assets, examples, and domain language.
+- Product category and expected workflow density.
+- Brand personality, existing visual constraints, and accessibility constraints.
+- Competitive or category references to learn from without copying.
+- Non-goals: patterns, phrases, palettes, layouts, or tropes to avoid.
+
+## Required Design Work
+
+- Fill or update `DESIGN.md`.
+- Produce at least two distinct creative directions before choosing one.
+- Record a reference set, anti-references, source-safety notes, and a design critique verdict before acceptance.
+- Score significant frontend work with the frontend product-quality rubric before acceptance.
+- Map first-screen hierarchy to the user's primary task, object, or workflow.
+- Define how tokens, imagery, density, and copy support the chosen direction.
+- Identify missing real content or assets before substituting placeholders.
+
+## Reject By Default
+
+- Styling before content and workflow are understood.
+- Generic SaaS headings, fake metrics, abstract gradient backgrounds, and card-heavy filler.
+- Interfaces whose first screen could apply to any product in the category.
+- Visual directions with no link to audience, content, or domain.
+- Placeholder screenshots accepted as final evidence.
+
+## Review Output
+
+Return:
+
+- Missing content, audience, or brand inputs.
+- The selected creative direction and why it fits.
+- The reference-led critique verdict and any remaining generic-design risks.
+- The product-quality scorecard verdict and any critical zeroes.
+- Which visible details make the design specific to this product.
+- Which assets, copy, or data examples are still missing.
+- Whether `DESIGN.md`, `STYLE_GUIDE.md`, and screenshot evidence are sufficient for acceptance.

package/skills/conversion-copywriting.md

@@ -0,0 +1,38 @@
+# Conversion Copywriting Skill
+
+## Use When
+
+Writing or reviewing copy for landing pages, signup flows, pricing pages, checkout paths, demos, waitlists, product-led onboarding, upgrade prompts, or conversion-critical CTAs.
+
+## Goal
+
+Make each conversion surface clear, truthful, specific, and aligned to the user's stage of intent.
+
+## Required Inputs
+
+- Audience segment and awareness level.
+- Conversion goal and next action.
+- User pain, desired outcome, and urgency.
+- Product differentiator and proof.
+- Objections, risks, or trust concerns.
+- Constraints: legal, compliance, pricing, availability, region, or support limits.
+
+## Required Work
+
+- Map the page or flow to one primary action and one acceptable secondary action.
+- Match headline, subhead, proof, and CTA to the same value proposition.
+- Add trust-building copy only when the proof exists.
+- Make risk, limitations, and eligibility clear near the relevant action.
+- Use concrete product nouns, workflow language, and customer language from `MESSAGING.md`.
+- Review microcopy around forms, errors, payment, confirmation, and cancellation.
+
+## Reject By Default
+
+- Multiple competing CTAs with no hierarchy.
+- Broad benefit claims without proof or product specificity.
+- Copy that creates legal, pricing, privacy, medical, financial, or compliance risk.
+- Dark patterns, hidden conditions, forced urgency, or unclear cancellation language.
+
+## Review Output
+
+Return conversion goal, primary/secondary CTA, page hierarchy, proof used, objections handled, risky claims, missing evidence, and test ideas.

package/skills/deployment-observability.md

@@ -0,0 +1,14 @@
+# Deployment And Observability Skill
+
+## Use When
+
+Working on deployments, env vars, migrations, cron jobs, logs, production incidents, monitoring, or rollback.
+
+## Checklist
+
+- Required env vars are documented.
+- Server-only secrets are isolated.
+- Migration and app deploy order is clear.
+- Smoke checks are defined.
+- Logs expose operational failures without leaking secrets.
+- Rollback steps are documented.

package/skills/docs-maintainer.md

@@ -0,0 +1,19 @@
+# Documentation Maintainer Skill
+
+## Use When
+
+Any meaningful behavior, architecture, security, workflow, testing, deployment, or design standard changes.
+
+## Checklist
+
+- `SPEC.md` reflects current system behavior.
+- `DECISIONS.md` records important tradeoffs.
+- `DOCS.md` explains setup and workflows.
+- `COUNCIL.md` records meaningful agent handoffs, required outputs, evidence, and verification status.
+- `QUALITY_GATES.md` reflects maturity target and evidence expectations.
+- `DESIGN.md` reflects brand/content, reference-led critique, and creative-direction changes.
+- `STYLE_GUIDE.md` reflects code and design patterns.
+- `SECURITY.md` reflects current threat model and auth boundaries.
+- `TESTING.md` reflects current coverage and gaps.
+- `DEPLOYMENT.md` reflects release and rollback steps.
+- `UPGRADE.md` reflects version, migration, rollback, and package-update evidence.

package/skills/frontend-design-system.md

@@ -0,0 +1,68 @@
+# Frontend Design System Skill
+
+## Use When
+
+Building or reviewing any user-facing screen, page, component, app shell, dashboard, admin view, onboarding flow, or marketing surface.
+
+## Goal
+
+Create interfaces that are domain-specific, accessible, polished, and useful. Avoid the common AI-generated look.
+
+## Reject By Default
+
+- Generic purple-blue gradient heroes.
+- Vague SaaS value props.
+- Fake dashboard metrics.
+- Floating card soup.
+- Oversized rounded panels without workflow purpose.
+- Placeholder landing pages when the user asked for an app or tool.
+- One-note color palettes.
+- Styling that starts before content, audience, and workflow are understood.
+
+## Prefer
+
+- Task-first product screens.
+- Domain-specific information architecture.
+- Reusable design tokens.
+- A documented component and state inventory.
+- Clear density rules.
+- Accessible forms and controls.
+- Real loading, empty, error, disabled, and success states.
+- Mobile-first layouts.
+- Visual direction that fits the product category.
+- A chosen creative direction that is visible in tokens, layout, copy, imagery, and interaction tone.
+
+## Design Adapter Trigger
+
+Use a provider-neutral design adapter and the matching `design-briefs/*` file when:
+
+- The screen risks looking generic.
+- The product category needs stronger visual direction.
+- The workflow is unclear.
+- A high-stakes UI needs external review.
+
+Use `prompts/screenshot-review.md` after implementation when desktop and mobile screenshots exist.
+
+Use `skills/content-first-design.md`, `prompts/brand-content-intake.md`, and `prompts/creative-direction-matrix.md` before implementation when the product, audience, content, brand, or visual direction is under-specified.
+
+Use `skills/reference-led-design-critique.md` and `prompts/design-critique-gate.md` before accepting significant frontend work, especially when the screen could still look generic despite having tokens, states, and screenshots.
+
+Use `skills/frontend-product-quality-rubric.md` and `prompts/frontend-product-quality-scorecard.md` before accepting significant frontend work. The scorecard must reject work when the product task, content specificity, accessibility, or source safety is weak, even if the UI looks polished.
+
+Use `skills/frontend-distinctiveness-benchmark.md` and `prompts/frontend-distinctiveness-benchmark.md` before accepting significant frontend work that could still be interchangeable with another product in the same category. The benchmark must prove first-screen specificity, content fingerprint, safe reference learning, asset provenance, state proof, and visual QA evidence.
+
+## Review Output
+
+Return:
+
+- What looks generic or under-specified.
+- Which brand, content, audience, or creative-direction inputs are missing.
+- Which reference-set, anti-reference, source-safety, or distinctiveness evidence is missing.
+- Which design tokens are missing.
+- Which component states are missing.
+- Which accessibility risks remain.
+- Which provider-neutral design brief should be used next, if any.
+- Which screenshot evidence is still needed before the UI can be accepted.
+- Which visual-regression or component-state evidence is needed before release.
+- Which product-quality scorecard dimensions failed and what must improve before acceptance.
+- Which distinctiveness benchmark evidence is missing before the UI can be accepted as product-specific.

package/skills/frontend-distinctiveness-benchmark.md

@@ -0,0 +1,40 @@
+# Frontend Distinctiveness Benchmark Skill
+
+## Use When
+
+Planning, building, or accepting any meaningful user-facing screen where the product could drift into generic AI-site output despite having clean components, tokens, or screenshots.
+
+## Goal
+
+Prove that the interface belongs to this product, this audience, and this workflow. The design should be grounded in real content and safe reference learning before visual polish is accepted.
+
+## Required Evidence
+
+- First-screen proof: the first viewport shows the real product object, task, workflow, content, or decision.
+- Content fingerprint: product nouns, labels, data shapes, records, actions, and edge cases are visible in the UI or documented in `DESIGN.md`.
+- Reference benchmark: 3-5 relevant references name lessons to learn and 2-3 anti-references name tropes to avoid.
+- Source-safety notes: no copied brand marks, protected layouts, proprietary assets, exact copy, or visual signatures.
+- Creative divergence: at least two plausible directions were compared before one was chosen.
+- State proof: important loading, empty, error, disabled, success, permission, and focus states are designed or captured.
+- Asset provenance: real, generated, licensed, or placeholder assets are identified with usage constraints.
+- Visual QA proof: desktop, mobile, and high-risk state evidence exists for the change risk.
+
+## Reject By Default
+
+- The first screen could be reused for another product in the same category by changing only the logo or headline.
+- The interface uses fake metrics, generic dashboard cards, vague SaaS copy, abstract gradient decoration, or stock-like imagery to hide missing product decisions.
+- References are copied instead of translated into generalized lessons.
+- Product-specific content is postponed until after styling.
+- A scorecard passes while first-screen proof, content fingerprint, source safety, or visual QA evidence is missing.
+
+## Review Output
+
+Return:
+
+- First-screen proof verdict: missing, adequate, or strong.
+- Content fingerprint verdict: missing, adequate, or strong.
+- Reference benchmark verdict: missing, adequate, or strong.
+- Source-safety and asset-provenance risks.
+- Generic-AI-site risk after review.
+- Required changes before implementation or acceptance.
+- Evidence still needed for best-practice frontend status.

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

@@ -0,0 +1,59 @@
+# 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

@@ -0,0 +1,29 @@
+# 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

@@ -0,0 +1,18 @@
+# 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

@@ -0,0 +1,37 @@
+# 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

@@ -0,0 +1,19 @@
+# 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

@@ -0,0 +1,21 @@
+# 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

@@ -0,0 +1,42 @@
+# 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

@@ -0,0 +1,14 @@
+# 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

@@ -0,0 +1,35 @@
+# 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.