@sylphx/flow 2.29.3 → 3.0.0

package/assets/skills/admin/SKILL.md

@@ -1,37 +0,0 @@
----
-name: admin
-description: Admin panel - RBAC, config, admin tools. Use when building admin UI.
----
-
-# Admin Guideline
-
-## Tech Stack
-
-* **Framework**: Next.js (with Turbopack)
-* **API**: tRPC
-* **Database**: Neon (Postgres)
-* **ORM**: Drizzle
-* **Components**: Radix UI
-* **Styling**: Tailwind CSS
-
-## Non-Negotiables
-
-* Admin bootstrap via INITIAL_SUPERADMIN_EMAIL only (one-time, non-reentrant)
-* All privilege grants must be audited (who/when/why)
-* Actions affecting money/access/security require step-up verification
-* Secrets must never be exposed through admin UI
-* Only super_admin can promote to admin or access system config
-
-## Context
-
-The admin platform is where operational power lives — and where operational mistakes happen. A well-designed admin reduces human error while giving operators tools to resolve issues quickly.
-
-MFA requirements for admin roles are enforced via `account-security`.
-
-## Driving Questions
-
-* Is bootstrap using INITIAL_SUPERADMIN_EMAIL correctly?
-* Can an admin accidentally cause serious damage?
-* How would we detect admin access misuse?
-* What repetitive admin tasks should be automated?
-* Where is audit logging missing?

package/assets/skills/appsec/SKILL.md

@@ -1,35 +0,0 @@
----
-name: appsec
-description: Application security - OWASP, validation, secrets. Use when securing the app.
----
-
-# AppSec Guideline
-
-## Tech Stack
-
-* **Rate Limiting**: Upstash Redis
-* **Framework**: Next.js (with Turbopack)
-* **Platform**: Vercel
-
-## Non-Negotiables
-
-* OWASP Top 10:2025 vulnerabilities must be addressed
-* Security headers present (CSP, HSTS, X-Frame-Options, X-Content-Type-Options)
-* CSRF protection on state-changing requests
-* No plaintext secrets in logs, returns, storage, or telemetry
-* Required configuration must fail-fast at build/startup if missing
-* Secrets must not be hardcoded or committed
-
-## Context
-
-Security isn't a feature — it's a foundational property. A single vulnerability can compromise everything else. Think like an attacker: where are the weak points?
-
-MFA and session security live in `account-security`. This skill focuses on application-level attack surface.
-
-## Driving Questions
-
-* What would an attacker target first?
-* Where is rate limiting missing or insufficient?
-* How are secrets managed and what's the rotation strategy?
-* What happens when a secret is compromised?
-* Where does "security by obscurity" substitute for real controls?

package/assets/skills/auth/SKILL.md

@@ -1,34 +0,0 @@
----
-name: auth
-description: Authentication patterns - sign-in, SSO, passkeys, sessions. Use when implementing auth flows.
----
-
-# Auth Guideline
-
-## Tech Stack
-
-* **Auth**: Better Auth
-* **Framework**: Next.js (with Turbopack)
-* **Database**: Neon (Postgres)
-* **ORM**: Drizzle
-
-## Non-Negotiables
-
-* All authentication via Better Auth (no custom implementation)
-* All authorization decisions must be server-enforced (no client-trust)
-* Email verification required for high-impact capabilities
-* Session token in httpOnly cookie only
-* If SSO provider secrets are missing, hide the option (no broken UI)
-
-## Context
-
-Auth handles how users get sessions — sign-in, SSO, token issuance. Session management (visibility, revocation, step-up) lives in `account-security`.
-
-Better Auth is the SSOT for authentication. No custom auth implementations.
-
-## Driving Questions
-
-* Is all auth handled by Better Auth?
-* Are we building custom auth logic that Better Auth already provides?
-* What's the sign-in experience for first-time vs returning users?
-* What happens when a user loses access to their primary auth method?

package/assets/skills/billing/SKILL.md

@@ -1,35 +0,0 @@
----
-name: billing
-description: Billing - Stripe, webhooks, subscriptions. Use when implementing payments.
----
-
-# Billing Guideline
-
-## Tech Stack
-
-* **Payments**: Stripe
-* **Workflows**: Upstash Workflows + QStash
-* **Database**: Neon (Postgres)
-* **ORM**: Drizzle
-
-## Non-Negotiables
-
-* Webhook signature must be verified (reject unverifiable events)
-* Stripe event ID must be used for idempotency
-* Webhooks must handle out-of-order delivery
-* Subscription state changes must be audit-logged
-* Payment failures must trigger appropriate user communication
-
-## Context
-
-Billing handles the payment processing mechanics — webhooks, subscription lifecycle, payment methods. It's the plumbing that moves money. Pricing strategy and entitlements live in `pricing`.
-
-The platform owns billing logic. Stripe is a payment processor. All billing configuration must be in code, not Stripe dashboard.
-
-## Driving Questions
-
-* Are webhooks handling all subscription lifecycle events?
-* What happens when payment fails mid-cycle?
-* How are disputes and chargebacks handled end-to-end?
-* Can failed webhooks be safely replayed?
-* Where could revenue leak (failed renewals, unhandled states)?

package/assets/skills/code-quality/SKILL.md

@@ -1,34 +0,0 @@
----
-name: code-quality
-description: Code quality - patterns, testing, maintainability. Use for code review.
----
-
-# Code Quality Guideline
-
-## Tech Stack
-
-* **Runtime**: Bun
-* **Linting/Formatting**: Biome
-* **Testing**: Bun test
-* **Language**: TypeScript (strict)
-
-## Non-Negotiables
-
-* No TODOs, hacks, or workarounds in production code
-* Strict TypeScript with end-to-end type safety (DB → API → UI)
-* No dead or unused code
-
-## Context
-
-Code quality isn't about following rules — it's about making the codebase a place where good work is easy and bad work is hard. High-quality code is readable, testable, and changeable. Low-quality code fights you on every change.
-
-Don't just look for rule violations. Look for code that technically works but is confusing, fragile, or painful to modify. Look for patterns that will cause bugs. Look for complexity that doesn't need to exist.
-
-## Driving Questions
-
-* What code would you be embarrassed to show a senior engineer?
-* Where is complexity hiding that makes the codebase hard to understand?
-* What would break if someone new tried to make changes here?
-* Where are types lying (as any, incorrect generics, missing null checks)?
-* What test coverage gaps exist for code that really matters?
-* If we could rewrite one part of this codebase, what would have the highest impact?

package/assets/skills/competitive-analysis/SKILL.md

@@ -1,29 +0,0 @@
----
-name: competitive-analysis
-description: Competitive analysis - market research, feature gaps. Use when exploring what competitors do.
----
-
-# Competitive Analysis Guideline
-
-## Tech Stack
-
-* Research across the product's full stack as needed
-
-## Non-Negotiables
-
-* None — this is pure exploration
-
-## Context
-
-Discovery is about finding what's missing, what's possible, and what would make the product significantly more competitive. It's not about fixing bugs — it's about identifying opportunities that don't yet exist.
-
-Look at competitors, market trends, user expectations, and technological possibilities. What would make users choose this product over alternatives? What capabilities would unlock new business models?
-
-## Driving Questions
-
-* What are competitors doing that we're not?
-* What do users expect based on industry standards that we lack?
-* What integrations would add significant value?
-* What pricing models are common in the market and how do we compare?
-* What technical capabilities could enable new business models?
-* What would make this product a category leader rather than a follower?

package/assets/skills/data-modeling/SKILL.md

@@ -1,34 +0,0 @@
----
-name: data-modeling
-description: Data modeling - entities, relationships, schemas. Use when designing data structures.
----
-
-# Data Modeling Guideline
-
-## Tech Stack
-
-* **API**: tRPC
-* **Framework**: Next.js (with Turbopack)
-* **Database**: Neon (Postgres)
-* **ORM**: Drizzle
-
-## Non-Negotiables
-
-* All authorization must be server-enforced (no client-trust)
-* Platform is source of truth — third-party services sync FROM platform
-* UI must never contradict server-truth
-* High-value mutations must have audit trail (who/when/why/before/after)
-
-## Context
-
-Data modeling is conceptual — entities, relationships, domain boundaries. Physical implementation (indexes, migrations, query performance) lives in `database`.
-
-Consider: what are the real-world entities? How do they relate? What invariants must hold? What will break when requirements change?
-
-## Driving Questions
-
-* If we were designing this from scratch, what would be different?
-* Where will the current model break as the product scales?
-* What implicit assumptions are waiting to cause bugs?
-* Where is complexity hiding that makes the system hard to reason about?
-* What domain boundaries are we violating?

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?