@sylphx/flow 2.30.0 → 3.0.1

package/assets/skills/database/SKILL.md

@@ -1,34 +0,0 @@
----
-name: database
-description: Database - schema, indexes, migrations. Use when working with databases.
----
-
-# Database Guideline
-
-## Tech Stack
-
-* **Database**: Neon (Postgres)
-* **ORM**: Drizzle
-* **Migrations**: Drizzle Kit
-
-## Non-Negotiables
-
-* All database access through Drizzle (no raw SQL unless necessary)
-* Migration files must exist, be complete, and be committed
-* CI must fail if schema changes aren't represented by migrations
-* No schema drift between environments
-* Drizzle schema is SSOT for database structure
-
-## Context
-
-Database handles physical implementation — schema, indexes, migrations, query performance. Conceptual modeling (entities, relationships) lives in `data-modeling`.
-
-Drizzle is the SSOT for database access. Type-safe, end-to-end.
-
-## Driving Questions
-
-* Is all database access through Drizzle?
-* Are migrations complete and committed?
-* What constraints are missing that would prevent invalid state?
-* Where are missing indexes causing slow queries?
-* What queries are N+1 or unbounded?

package/assets/skills/delivery/SKILL.md

@@ -1,36 +0,0 @@
----
-name: delivery
-description: Delivery - CI/CD, testing, releases. Use when improving pipelines.
----
-
-# Delivery Guideline
-
-## Tech Stack
-
-* **CI**: GitHub Actions
-* **Testing**: Bun test
-* **Linting**: Biome
-* **Platform**: Vercel
-
-## Non-Negotiables
-
-* All release gates must be automated (manual verification doesn't count)
-* Build must fail-fast on missing required configuration
-* CI must block on: lint, typecheck, tests, build
-* `/en/*` must redirect (no duplicate content)
-* Security headers must be verified by tests
-* Consent gating must be verified by tests
-
-## Context
-
-Delivery handles pre-production — CI/CD pipeline, release gates, quality checks. Post-deployment operations (rollback, feature flags, runbooks) live in `deployments`.
-
-The question isn't "what tests do we have?" but "what could go wrong that we wouldn't catch?"
-
-## Driving Questions
-
-* What could ship to production that shouldn't?
-* Where does manual verification substitute for automation?
-* What flaky tests are training people to ignore failures?
-* How fast is the feedback loop, and what slows it down?
-* What's the worst thing that shipped recently that tests should have caught?

package/assets/skills/deployments/SKILL.md

@@ -1,33 +0,0 @@
----
-name: deployments
-description: Deployments - rollback, feature flags, ops tooling. Use when shipping to production.
----
-
-# Deployments Guideline
-
-## Tech Stack
-
-* **Workflows**: Upstash Workflows + QStash
-* **Cache**: Upstash Redis
-* **Platform**: Vercel
-
-## Non-Negotiables
-
-* Rollback plan must exist and be exercisable
-* Dead-letter handling must exist and be operable (visible, replayable)
-* Side-effects (email, billing, ledger) must be idempotent or safely re-entrant
-* Drift alerts must have remediation playbooks
-
-## Context
-
-Deployments handles post-deployment operations — rollback, feature flags, runbooks, incident response. Pre-production CI/CD lives in `delivery`.
-
-When something goes wrong, can an operator fix it without deploying code?
-
-## Driving Questions
-
-* What happens when a job fails permanently?
-* How would an operator know something is stuck?
-* Can failed workflows be safely replayed without duplicating side-effects?
-* What's the rollback plan if a deploy breaks something critical?
-* What runbooks exist, and what runbooks should exist but don't?

package/assets/skills/growth/SKILL.md

@@ -1,31 +0,0 @@
----
-name: growth
-description: Growth - onboarding, activation, retention. Use for growth features.
----
-
-# Growth Guideline
-
-## Tech Stack
-
-* **Analytics**: PostHog
-* **Framework**: Next.js (with Turbopack)
-
-## Non-Negotiables
-
-* Sharing/virality mechanics must be consent-aware
-* Growth instrumentation must not violate privacy constraints
-
-## Context
-
-Growth isn't about tricks — it's about removing friction from value delivery. Users who quickly experience value stay; users who don't, leave.
-
-The review should consider: what's preventing users from reaching their "aha moment" faster? What would make them want to share? What brings them back? These aren't features to add — they're fundamental product questions.
-
-## Driving Questions
-
-* Where do users drop off before experiencing value?
-* What would cut time-to-value in half?
-* Why would a user tell someone else about this product?
-* What brings users back after their first session?
-* What signals predict churn before it happens?
-* What would a 10x better onboarding look like?

package/assets/skills/i18n/SKILL.md

@@ -1,35 +0,0 @@
----
-name: i18n
-description: Internationalization - localization, translations. Use when adding languages.
----
-
-# i18n Guideline
-
-## Tech Stack
-
-* **i18n**: next-intl
-* **Framework**: Next.js (with Turbopack)
-
-## Non-Negotiables
-
-* All i18n via next-intl (no custom implementation)
-* `/en/*` must not exist (permanently redirect to non-prefixed)
-* Missing translation keys must fail build
-* No hardcoded user-facing strings outside localization
-* Translation bundles must be split by namespace (no monolithic files)
-* Server Components for translations wherever possible
-* Client bundles must not include server-only translations
-
-## Context
-
-Internationalization isn't just translation — it's making the product feel native to each market. Bad i18n signals users are second-class citizens. Good i18n is invisible.
-
-next-intl is the SSOT for i18n. No custom implementations.
-
-## Driving Questions
-
-* Is next-intl handling all translations?
-* Are bundles split by namespace?
-* What would make the product feel native to non-English users?
-* Where do translations feel awkward?
-* How large are client-side translation bundles?

package/assets/skills/ledger/SKILL.md

@@ -1,32 +0,0 @@
----
-name: ledger
-description: Financial ledger - transactions, audit trails. Use when tracking money.
----
-
-# Ledger Guideline
-
-## Tech Stack
-
-* **Database**: Neon (Postgres)
-* **ORM**: Drizzle
-
-## Non-Negotiables
-
-* Balances must be immutable ledger (append-only), not mutable fields
-* No floating-point for money (use deterministic precision)
-* All financial mutations must be idempotent
-* Every balance must be provable by replaying the ledger
-
-## Context
-
-Ledger handles financial integrity — transaction history, balance correctness, audit trail. Payment processing lives in `billing`, pricing strategy lives in `pricing`.
-
-A bug that creates or destroys money is a serious incident. This must be bulletproof.
-
-## Driving Questions
-
-* Does a balance/credits system exist, and is it implemented correctly?
-* Where could money be created or destroyed by a bug?
-* What happens during concurrent transactions?
-* How would we detect if balances drifted from reality?
-* Can we prove every balance by replaying the ledger?

package/assets/skills/observability/SKILL.md

@@ -1,32 +0,0 @@
----
-name: observability
-description: Observability - logging, metrics, tracing. Use when adding monitoring.
----
-
-# Observability Guideline
-
-## Tech Stack
-
-* **Error Tracking**: Sentry
-* **Analytics**: PostHog
-* **Platform**: Vercel
-
-## Non-Negotiables
-
-* Correlation IDs must exist end-to-end (request → job → webhook)
-* Alerts must exist for critical failures
-* Errors must be actionable, not noise
-
-## Context
-
-Observability is about answering questions when things go wrong. It's 3am, something is broken — can you figure out what happened? How fast?
-
-PII protection in logs is enforced via `privacy`. This skill focuses on making debugging effective.
-
-## Driving Questions
-
-* If something breaks now, how would we find out?
-* What blind spots exist where errors go unnoticed?
-* How long to trace a request through the system?
-* What alerts exist, and do they fire correctly?
-* Where is noise training people to ignore alerts?

package/assets/skills/performance/SKILL.md

@@ -1,33 +0,0 @@
----
-name: performance
-description: Performance - Core Web Vitals, bundle size. Use when optimizing speed.
----
-
-# Performance Guideline
-
-## Tech Stack
-
-* **Framework**: Next.js (with Turbopack)
-* **Platform**: Vercel
-* **Tooling**: Bun
-
-## Non-Negotiables
-
-* Core Web Vitals must meet thresholds (LCP < 2.5s, CLS < 0.1, INP < 200ms)
-* Performance regressions must be detectable
-* JavaScript bundle size must be monitored and optimized
-
-## Context
-
-Performance is a feature. Slow products feel broken, even when they're correct. Users don't read loading spinners — they leave. Every 100ms of latency costs engagement.
-
-Don't just measure — understand. Where does time go? What's blocking the critical path? What would make the product feel instant? Sometimes small architectural changes have bigger impact than optimization.
-
-## Driving Questions
-
-* What makes the product feel slow to users?
-* Where are the biggest bottlenecks in the critical user journeys?
-* What's in the critical rendering path that shouldn't be?
-* How large is the JavaScript bundle, and what's bloating it?
-* What database queries are slow, and why?
-* If we could make one thing 10x faster, what would have the most impact?

package/assets/skills/pricing/SKILL.md

@@ -1,32 +0,0 @@
----
-name: pricing
-description: Pricing strategy - tiers, feature gating. Use when designing pricing.
----
-
-# Pricing Guideline
-
-## Tech Stack
-
-* **Payments**: Stripe
-* **Database**: Neon (Postgres)
-* **ORM**: Drizzle
-
-## Non-Negotiables
-
-* Platform is source of truth — Stripe syncs FROM platform, never reverse
-* All pricing/product configuration must be in code
-* Feature entitlements derived from platform state, not Stripe metadata
-* Pricing drift must be detectable and auto-correctable
-* No manual Stripe dashboard configuration
-
-## Context
-
-Pricing owns strategy — what tiers exist, what features each tier gets, how upgrades work. Billing handles the payment mechanics. This separation allows switching payment processors without repricing.
-
-## Driving Questions
-
-* Is all pricing defined in code?
-* How do we test pricing changes before going live?
-* What would make upgrading feel like an obvious decision?
-* How do we communicate value at each tier?
-* Can we A/B test pricing without Stripe changes?

package/assets/skills/privacy/SKILL.md

@@ -1,36 +0,0 @@
----
-name: privacy
-description: Privacy and data protection - GDPR, CCPA, consent. Use when handling user data.
----
-
-# Privacy Guideline
-
-## Tech Stack
-
-* **Analytics**: PostHog
-* **Email**: Resend
-* **Tag Management**: GTM (marketing only)
-* **Observability**: Sentry
-
-## Non-Negotiables
-
-* Analytics and marketing must not fire before user consent
-* PII must not leak into logs, Sentry, PostHog, or third-party services
-* Account deletion must propagate to all third-party processors
-* Marketing tags (GTM, Google Ads) must not load without consent
-* Conversion tracking must be server-truth aligned, idempotent, and deduplicated
-
-## Context
-
-Privacy isn't just compliance — it's trust. Users share data expecting it to be handled responsibly. Every log line, every analytics event, every third-party integration is a potential privacy leak.
-
-The review should verify that actual behavior matches stated policy. If the privacy policy says "we don't track without consent," does the code actually enforce that? Mismatches are not just bugs — they're trust violations.
-
-## Driving Questions
-
-* Does the consent implementation actually block tracking, or just record preference?
-* Where does PII leak that we haven't noticed?
-* If a user requests data deletion, what actually gets deleted vs. retained?
-* Does the privacy policy accurately reflect what the code actually does?
-* How would we handle a GDPR data subject access request today?
-* What data are we collecting that we don't actually need?

package/assets/skills/pwa/SKILL.md

@@ -1,36 +0,0 @@
----
-name: pwa
-description: PWA - native app parity, offline-first, engagement. Use when building installable web apps.
----
-
-# PWA Guideline
-
-## Tech Stack
-
-* **Framework**: Next.js (with Turbopack)
-* **Service Worker**: Serwist (Next.js integration)
-* **Platform**: Vercel
-
-## Non-Negotiables
-
-* Service worker must not cache personalized/sensitive/authorized content
-* Cache invalidation on deploy must be correct (no stale content)
-* Offline experience must be functional, not just a fallback page
-* Installation prompt must be contextual (after value demonstrated)
-* Complete manifest.webmanifest with all required fields
-* All required icons present (favicon, apple-touch-icon, PWA icons, maskable)
-
-## Context
-
-PWA goal: users forget they're in a browser. The gap between "website" and "app" is measured in micro-interactions — haptics, gestures, offline resilience, and engagement hooks.
-
-A bad PWA is worse than no PWA. But a great PWA can match 90% of native with 10% of the effort.
-
-## Driving Questions
-
-* What breaks when the user goes offline mid-action?
-* What would make users install this instead of bookmarking?
-* Which native gestures (swipe, pull, long-press) are missing?
-* What local notifications would drive daily engagement?
-* Where does the app feel "webby" instead of native?
-* What's the first thing users see when they open the installed app?

package/assets/skills/referral/SKILL.md

@@ -1,30 +0,0 @@
----
-name: referral
-description: Referral systems - referral programs, viral loops. Use for referrals.
----
-
-# Referral Guideline
-
-## Tech Stack
-
-* **Analytics**: PostHog
-* **Database**: Neon (Postgres)
-* **ORM**: Drizzle
-
-## Non-Negotiables
-
-* Referral attribution must be accurate and auditable
-* Rewards must be fraud-resistant (no self-referral, duplicate abuse)
-* Terms must be clear and enforced consistently
-
-## Context
-
-Referrals turn happy users into growth engines. But poorly designed referral programs create fraud opportunities and erode trust. The best referral programs feel generous, not gameable.
-
-## Driving Questions
-
-* What would make users genuinely want to refer others?
-* How do we prevent referral fraud without punishing legitimate users?
-* Is referral attribution working correctly across all channels?
-* What's the referral conversion rate and what affects it?
-* Are referral rewards actually motivating behavior?

package/assets/skills/seo/SKILL.md

@@ -1,40 +0,0 @@
----
-name: seo
-description: SEO - meta tags, structured data. Use when optimizing for search.
----
-
-# SEO Guideline
-
-## Tech Stack
-
-* **Framework**: Next.js (with Turbopack, SSR-first)
-
-## Non-Negotiables
-
-* Every page must have complete metadata (title, description, canonical, OG, Twitter Cards)
-* Canonical URLs must be correct (no duplicate content)
-* Complete favicon set (ico, svg, apple-touch-icon, PWA icons)
-* Structured data (JSON-LD) for rich results where applicable
-* Security headers configured (CSP, HSTS, X-Frame-Options, X-Content-Type-Options)
-
-## Required Files
-
-* `robots.txt` — search engine crawling rules
-* `sitemap.xml` — page discovery for search engines
-* `llms.txt` — LLM/AI crawler guidance
-* `security.txt` — security vulnerability reporting (at `/.well-known/security.txt`)
-* `ads.txt` — if ads exist
-* `app-ads.txt` — if mobile ads exist
-
-## Context
-
-SEO is about being found when people are looking for what you offer. Good SEO isn't tricks — it's making content genuinely useful and technically accessible to search engines and AI crawlers.
-
-## Driving Questions
-
-* Is every page's head complete with all required meta tags?
-* Are Open Graph and Twitter Cards generating correct previews?
-* Is structured data present and validated?
-* Do all required files exist and pass validation?
-* Is the site accessible to both search engines and LLM crawlers?
-* Are security headers properly configured?

package/assets/skills/storage/SKILL.md

@@ -1,33 +0,0 @@
----
-name: storage
-description: File storage - uploads, CDN, blobs. Use when handling files.
----
-
-# Storage Guideline
-
-## Tech Stack
-
-* **Storage**: Vercel Blob
-* **Framework**: Next.js (with Turbopack)
-* **Platform**: Vercel
-
-## Non-Negotiables
-
-* All file uploads must be validated (type, size, content)
-* Signed URLs for private content access
-* No user-uploaded content served from main domain (XSS prevention)
-* File deletion must cascade with parent entity deletion
-
-## Context
-
-File storage is deceptively complex. Users expect uploads to just work, but there are many ways for it to fail — large files, slow connections, wrong formats, malicious content.
-
-Vercel Blob is the SSOT for file storage. No custom implementations.
-
-## Driving Questions
-
-* What happens when an upload fails halfway?
-* How are large files handled without blocking?
-* What file types are allowed and how is it enforced?
-* How long are files retained after entity deletion?
-* What's the storage cost and is it sustainable?

package/assets/skills/support/SKILL.md

@@ -1,31 +0,0 @@
----
-name: support
-description: Support - help center, tickets, docs. Use when building support.
----
-
-# Support Guideline
-
-## Tech Stack
-
-* **Framework**: Next.js (with Turbopack)
-* **Email**: Resend
-
-## Non-Negotiables
-
-* Self-service must be prioritized over contact forms
-* Support context must include user state (plan, usage, recent actions)
-* Response time expectations must be set and met
-
-## Context
-
-Support is where trust is won or lost. Users who need help are often frustrated — the support experience either deepens their trust or confirms their fears.
-
-Great support isn't just fast responses — it's making users not need support in the first place. Every support ticket is a signal that something in the product could be clearer.
-
-## Driving Questions
-
-* What are the most common support requests and can they be self-served?
-* What context does support need that they don't have?
-* Where does the product create confusion that leads to support tickets?
-* How would we handle a surge in support volume?
-* What would make users feel supported before they ask for help?

package/assets/skills/uiux/SKILL.md

@@ -1,40 +0,0 @@
----
-name: uiux
-description: UI/UX - design system, accessibility. Use when building interfaces.
----
-
-# UI/UX Guideline
-
-## Tech Stack
-
-* **Framework**: Next.js (with Turbopack)
-* **Components**: Radix UI (mandatory)
-* **Styling**: Tailwind CSS
-* **Icons**: @iconify-icon/react
-
-## Radix UI (Mandatory)
-
-If Radix has a primitive for it, you MUST use it. No exceptions. No custom implementations.
-Any custom implementation of something Radix already provides is a bug.
-
-## Non-Negotiables
-
-* WCAG 2.1 AA compliance (keyboard navigation, screen readers, contrast)
-* Touch targets minimum 44x44px on mobile
-* Responsive design (mobile-first)
-* Loading states for all async operations
-* Error states must be actionable
-* No layout shift on content load
-
-## Context
-
-UI/UX is about removing friction between users and value. Bad UX doesn't just feel bad — it costs conversion, retention, and trust.
-
-## Driving Questions
-
-* Where do users get confused or frustrated?
-* What would a first-time user struggle with?
-* Where are loading states missing or unhelpful?
-* What accessibility issues exist?
-* Where does the UI feel inconsistent?
-* What would make the product feel more polished?

package/assets/slash-commands/cleanup.md

@@ -1,59 +0,0 @@
----
-name: cleanup
-description: Clean technical debt, refactor, optimize, and simplify codebase
----
-
-# Cleanup & Refactor
-
-Scan codebase for technical debt and code smells. Clean, refactor, optimize.
-
-## Scope
-
-**Code Smells:**
-- Functions >20 lines → extract
-- Duplication (3+ occurrences) → DRY
-- Complexity (>3 nesting levels) → flatten
-- Unused code/imports/variables → remove
-- Commented code → delete
-- Magic numbers → named constants
-- Poor naming → clarify
-
-**Technical Debt:**
-- TODOs/FIXMEs → implement or delete
-- Deprecated APIs → upgrade
-- Outdated patterns → modernize
-- Performance bottlenecks → optimize
-- Memory leaks → fix
-- Lint warnings → resolve
-
-**Optimization:**
-- Algorithm complexity → reduce
-- N+1 queries → batch
-- Unnecessary re-renders → memoize
-- Large bundles → code split
-- Unused dependencies → remove
-
-## Execution
-
-1. **Scan** entire codebase systematically
-2. **Prioritize** by impact (critical → major → minor)
-3. **Clean** incrementally with atomic commits
-4. **Test** after every change
-5. **Report** what was cleaned and impact
-
-## Commit Strategy
-
-One commit per logical cleanup:
-- `refactor(auth): extract validateToken function`
-- `perf(db): batch user queries to fix N+1`
-- `chore: remove unused imports and commented code`
-
-## Exit Criteria
-
-- [ ] No code smells remain
-- [ ] All tests pass
-- [ ] Lint clean
-- [ ] Performance improved (measure before/after)
-- [ ] Technical debt reduced measurably
-
-Report: Lines removed, complexity reduced, performance gains.