@sylphx/flow 2.28.10 → 2.29.1

package/CHANGELOG.md

@@ -1,5 +1,28 @@
 # @sylphx/flow
 
+## 2.29.1 (2026-01-08)
+
+Use Skill tool instead of hardcoded paths in /continue2
+
+### 📚 Documentation
+
+- use Skill tool instead of hardcoded paths in /continue2 ([0c2289d](https://github.com/SylphxAI/flow/commit/0c2289d0e821677b7d7c0f088b41b58ead341635))
+
+## 2.29.0 (2026-01-07)
+
+Add /continue2 slash command; clarify skill boundaries; remove hardcoded Radix list
+
+### ✨ Features
+
+- add /continue2 slash command for iterative guideline review ([3974493](https://github.com/SylphxAI/flow/commit/3974493257b74b8e603634d827af911314162562))
+
+### 📚 Documentation
+
+- remove hardcoded Radix primitives list from uiux ([a27b148](https://github.com/SylphxAI/flow/commit/a27b1480cb7286e3935c92ed4cd6c597093e06b9))
+- clarify skill boundaries and remove duplicates ([962114e](https://github.com/SylphxAI/flow/commit/962114e5ae8394abe483863d1390e1ea64ec2205))
+- refactor all skills to be requirement-focused ([06d222b](https://github.com/SylphxAI/flow/commit/06d222beed6ec16906778a3b5d77852b60fc84a4))
+- add comprehensive web standards (HTML5 head, manifest, required files) ([0cb6d7f](https://github.com/SylphxAI/flow/commit/0cb6d7fe88d7d27c0b0039849d4d77d505177b5d))
+
 ## 2.28.10 (2026-01-05)
 
 Make Radix UI mandatory - if Radix has it, you MUST use it

package/assets/skills/account-security/SKILL.md

@@ -8,46 +8,23 @@ description: Account security - MFA, sessions, recovery. Use when protecting use
 ## Tech Stack
 
 * **Auth**: Better Auth
-* **Framework**: Next.js
+* **Framework**: Next.js (with Turbopack)
 * **Database**: Neon (Postgres)
 
-## Re-authentication Flow
-
-All sensitive operations require explicit re-authentication:
-
-```
-    Sensitive action triggered
-                ↓
-        Check verified session
-                ↓
-    Does the user have a password?
-        ├─ Yes → Verify password
-        └─ No  → Send email OTP (6 digits, 10-minute expiry)
-                ↓
-        Verification succeeds
-                ↓
-        Mark session as verified
-                ↓
-    Allow scoped, time-bound sensitive actions
-    (2FA setup, email change, account deletion, etc.)
-```
-
-The verified state must:
-- Have explicit scope
-- Have explicit expiration
-- Never be implicitly reused
-- Never be shared across sessions or contexts
-
 ## Non-Negotiables
 
+* MFA required for admin/super_admin roles
+* Sensitive actions require step-up re-authentication (password or email OTP)
+* Verified session state must be scoped, time-bound, never implicitly reused
 * Session/device visibility and revocation must exist
 * All security-sensitive actions must be server-enforced and auditable
 * Account recovery must require step-up verification
-* MFA via Better Auth (no custom implementation)
 
 ## Context
 
-Account security is about giving users control over their own safety. Users should be able to see what's accessing their account, remove suspicious sessions, and understand when something unusual happens.
+Account security handles how users manage sessions — visibility, revocation, step-up verification, MFA. Sign-in and SSO live in `auth`.
+
+This is the SSOT for MFA policy. Admin and other privileged roles reference this.
 
 ## Driving Questions
 

package/assets/skills/admin/SKILL.md

@@ -7,65 +7,27 @@ description: Admin panel - RBAC, config, admin tools. Use when building admin UI
 
 ## Tech Stack
 
-* **Framework**: Next.js
+* **Framework**: Next.js (with Turbopack)
 * **API**: tRPC
 * **Database**: Neon (Postgres)
 * **ORM**: Drizzle
 * **Components**: Radix UI
-* **Styling**: UnoCSS
-
-## Bootstrap: Super Admin
-
-Simplest possible approach:
-
-```
-INITIAL_SUPERADMIN_EMAIL=your@email.com
-```
-
-Flow:
-1. Set env variable
-2. Register with that email
-3. Automatically elevated to super_admin
-4. Done
-
-Why singular:
-- Only one initial super_admin needed
-- They promote others via admin UI
-- Simple = fewer bugs
-
-The bootstrap must:
-- Execute exactly once
-- Be non-reentrant
-- Not be bypassable
-- Not become permanent logic dependency
+* **Styling**: Tailwind CSS
 
 ## Non-Negotiables
 
-* Admin bootstrap via INITIAL_SUPERADMIN_EMAIL only
+* 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
-* MFA required for admin roles
-
-## Role Hierarchy
-
-```
-super_admin
-    ↓ (can promote to)
-  admin
-    ↓ (can manage)
-  users
-```
-
-Only super_admin can:
-- Promote users to admin
-- Access system configuration
-- View audit logs
+* 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?

package/assets/skills/appsec/SKILL.md

@@ -8,30 +8,28 @@ description: Application security - OWASP, validation, secrets. Use when securin
 ## Tech Stack
 
 * **Rate Limiting**: Upstash Redis
-* **Framework**: Next.js
+* **Framework**: Next.js (with Turbopack)
 * **Platform**: Vercel
 
 ## Non-Negotiables
 
 * OWASP Top 10:2025 vulnerabilities must be addressed
-* CSP, HSTS, X-Frame-Options, X-Content-Type-Options headers must be present
+* Security headers present (CSP, HSTS, X-Frame-Options, X-Content-Type-Options)
 * CSRF protection on state-changing requests
-* No plaintext passwords in logs, returns, storage, or telemetry
-* MFA required for Admin/SUPER_ADMIN roles
+* 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. The review should think like an attacker: where are the weak points? What would I exploit?
+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?
 
-Beyond fixing vulnerabilities, consider the security architecture holistically. Is defense-in-depth implemented? Are there single points of failure? Would you trust this system with your own data?
+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?
-* What attack vectors exist in authentication flows?
 * How are secrets managed and what's the rotation strategy?
-* What happens when a secret is compromised — is incident response exercisable?
+* What happens when a secret is compromised?
 * Where does "security by obscurity" substitute for real controls?

package/assets/skills/auth/SKILL.md

@@ -8,34 +8,21 @@ description: Authentication patterns - sign-in, SSO, passkeys, sessions. Use whe
 ## Tech Stack
 
 * **Auth**: Better Auth
-* **Framework**: Next.js
+* **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)
-* Session management via Better Auth (no custom implementation)
-
-## Auth Flow
-
-```
-User initiates sign-in
-        ↓
-Better Auth handles provider/credentials
-        ↓
-Session created server-side
-        ↓
-Session token in httpOnly cookie
-        ↓
-All requests validated server-side
-```
 
 ## Context
 
-Authentication is the front door to every user's data. It needs to be both secure and frictionless. Users abandon products with painful sign-in flows, but weak auth leads to compromised accounts.
+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.
 
@@ -45,4 +32,3 @@ Better Auth is the SSOT for authentication. No custom auth implementations.
 * 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?
-* Where is auth complexity hiding bugs or security issues?

package/assets/skills/billing/SKILL.md

@@ -12,52 +12,24 @@ description: Billing - Stripe, webhooks, subscriptions. Use when implementing pa
 * **Database**: Neon (Postgres)
 * **ORM**: Drizzle
 
-## Platform-Led Billing
-
-Platform is the source of truth. Stripe syncs FROM platform, not TO it.
-
-- Platform defines products, prices, features, entitlements
-- Stripe is synced to match platform state
-- No manual Stripe dashboard configuration
-- Platform state → Stripe sync (never reverse)
-- Stripe webhooks confirm sync success, not drive state
-
 ## 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
-* UI must only display states derivable from platform-truth
-* No Stripe dashboard design — all configuration in code
-
-## Subscription Lifecycle
-
-```
-Platform defines plan
-        ↓
-Sync to Stripe (create Product + Price)
-        ↓
-User selects plan in UI
-        ↓
-Create Stripe Checkout Session
-        ↓
-User completes payment
-        ↓
-Webhook confirms → Update platform state
-        ↓
-Entitlements derived from platform state
-```
+* Subscription state changes must be audit-logged
+* Payment failures must trigger appropriate user communication
 
 ## Context
 
-Billing is where trust meets money. A bug here isn't just annoying — it's a financial and legal issue. Users must always see accurate state, and the system must never lose or duplicate charges.
+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, not a product catalog.
+The platform owns billing logic. Stripe is a payment processor. All billing configuration must be in code, not Stripe dashboard.
 
 ## Driving Questions
 
-* Is all billing configuration in code, not Stripe dashboard?
-* Can we switch payment processors without redesigning billing?
-* What happens when webhooks arrive out of order?
+* 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/data-modeling/SKILL.md

@@ -8,42 +8,27 @@ description: Data modeling - entities, relationships, schemas. Use when designin
 ## Tech Stack
 
 * **API**: tRPC
-* **Framework**: Next.js
+* **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 for billing/entitlements (Stripe syncs FROM platform)
+* 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)
 
-## Platform-Led Data Flow
-
-```
-Platform State (SSOT)
-        ↓
-  Third-party services sync FROM platform
-        ↓
-  Webhooks confirm sync success
-        ↓
-  Never reverse the flow
-```
-
-Platform defines products, prices, entitlements. External services reflect platform state.
-
 ## Context
 
-Data architecture determines what's possible and what's painful. Good architecture makes new features easy; bad architecture makes everything hard. The question isn't "does it work today?" but "will it work when requirements change?"
+Data modeling is conceptual — entities, relationships, domain boundaries. Physical implementation (indexes, migrations, query performance) lives in `database`.
 
-Consider the boundaries between domains, the flow of data through the system, and the consistency guarantees at each step. Where are implicit assumptions that will break? Where is complexity hidden that will cause bugs?
+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 architecture break as the product scales?
+* Where will the current model break as the product scales?
 * What implicit assumptions are waiting to cause bugs?
-* How do we know when state is inconsistent, and how do we recover?
 * Where is complexity hiding that makes the system hard to reason about?
-* What architectural decisions are we avoiding that we shouldn't?
+* What domain boundaries are we violating?

package/assets/skills/database/SKILL.md

@@ -13,31 +13,15 @@ description: Database - schema, indexes, migrations. Use when working with datab
 
 ## 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
-* All queries through Drizzle (no raw SQL unless necessary)
-
-## Schema Design
-
-```typescript
-// Drizzle schema is SSOT
-export const users = pgTable('users', {
-  id: text('id').primaryKey(),
-  email: text('email').notNull().unique(),
-  role: text('role').notNull().default('user'),
-  createdAt: timestamp('created_at').defaultNow(),
-})
-
-// Relations explicit
-export const usersRelations = relations(users, ({ many }) => ({
-  sessions: many(sessions),
-}))
-```
+* Drizzle schema is SSOT for database structure
 
 ## Context
 
-The database schema is the foundation everything else is built on. A bad schema creates friction for every feature built on top of it. Schema changes are expensive and risky — get the design right.
+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.
 
@@ -47,4 +31,4 @@ Drizzle is the SSOT for database access. Type-safe, end-to-end.
 * Are migrations complete and committed?
 * What constraints are missing that would prevent invalid state?
 * Where are missing indexes causing slow queries?
-* How does the schema handle data lifecycle?
+* What queries are N+1 or unbounded?

package/assets/skills/delivery/SKILL.md

@@ -18,14 +18,14 @@ description: Delivery - CI/CD, testing, releases. Use when improving pipelines.
 * Build must fail-fast on missing required configuration
 * CI must block on: lint, typecheck, tests, build
 * `/en/*` must redirect (no duplicate content)
-* Security headers (CSP, HSTS) must be verified by tests
+* Security headers must be verified by tests
 * Consent gating must be verified by tests
 
 ## Context
 
-Delivery gates are the last line of defense before code reaches users. Every manual verification step is a gate that will eventually fail. Every untested assumption is a bug waiting to ship.
+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?" Think about the deploy that breaks production at 2am — what would have prevented it?
+The question isn't "what tests do we have?" but "what could go wrong that we wouldn't catch?"
 
 ## Driving Questions
 
@@ -33,5 +33,4 @@ The question isn't "what tests do we have?" but "what could go wrong that we wou
 * 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?
-* If a deploy breaks production, how fast can we detect and rollback?
 * What's the worst thing that shipped recently that tests should have caught?

package/assets/skills/deployments/SKILL.md

@@ -13,21 +13,21 @@ description: Deployments - rollback, feature flags, ops tooling. Use when shippi
 
 ## 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
 
-Operability is about running the system in production — not just building it. Systems fail. Jobs get stuck. State drifts. The question is: when something goes wrong, can an operator fix it without deploying code?
+Deployments handles post-deployment operations — rollback, feature flags, runbooks, incident response. Pre-production CI/CD lives in `delivery`.
 
-Consider the operator experience during an incident. What tools do they have? What runbooks exist? Can they safely retry failed jobs? Can they detect and fix drift?
+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 drift can occur between systems, and how would we detect it?
 * 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

@@ -8,7 +8,7 @@ description: Growth - onboarding, activation, retention. Use for growth features
 ## Tech Stack
 
 * **Analytics**: PostHog
-* **Framework**: Next.js
+* **Framework**: Next.js (with Turbopack)
 
 ## Non-Negotiables
 

package/assets/skills/i18n/SKILL.md

@@ -8,34 +8,17 @@ description: Internationalization - localization, translations. Use when adding
 ## Tech Stack
 
 * **i18n**: next-intl
-* **Framework**: Next.js
+* **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
-
-## Bundle Strategy
-
-```
-messages/
-├── en/
-│   ├── common.json      # Shared strings
-│   ├── auth.json        # Auth flow
-│   ├── dashboard.json   # Dashboard
-│   └── settings.json    # Settings
-└── zh/
-    ├── common.json
-    ├── auth.json
-    ├── dashboard.json
-    └── settings.json
-```
-
-Each route loads only its required namespaces.
-Client bundles must not include server-only translations.
+* Client bundles must not include server-only translations
 
 ## Context
 

package/assets/skills/ledger/SKILL.md

@@ -7,7 +7,6 @@ description: Financial ledger - transactions, audit trails. Use when tracking mo
 
 ## Tech Stack
 
-* **Payments**: Stripe
 * **Database**: Neon (Postgres)
 * **ORM**: Drizzle
 
@@ -16,27 +15,13 @@ description: Financial ledger - transactions, audit trails. Use when tracking mo
 * Balances must be immutable ledger (append-only), not mutable fields
 * No floating-point for money (use deterministic precision)
 * All financial mutations must be idempotent
-* Platform ledger is source of truth (Stripe syncs FROM platform)
-
-## Platform-Led Financial State
-
-```
-Platform Ledger (SSOT)
-        ↓
-  Stripe syncs from platform
-        ↓
-  Webhooks confirm sync success
-        ↓
-  Reconciliation verifies alignment
-```
-
-Platform defines credits, balances, transactions. Stripe reflects platform state, not the reverse.
+* Every balance must be provable by replaying the ledger
 
 ## Context
 
-Financial systems are unforgiving. A bug that creates or destroys money — even briefly — is a serious incident. Users trust us with their money; that trust is easily lost and hard to regain.
+Ledger handles financial integrity — transaction history, balance correctness, audit trail. Payment processing lives in `billing`, pricing strategy lives in `pricing`.
 
-If balance/credits/wallet exists, it must be bulletproof. If it doesn't exist yet, consider whether the current design would support adding it correctly. Retrofitting financial integrity is painful.
+A bug that creates or destroys money is a serious incident. This must be bulletproof.
 
 ## Driving Questions
 
@@ -45,4 +30,3 @@ If balance/credits/wallet exists, it must be bulletproof. If it doesn't exist ye
 * What happens during concurrent transactions?
 * How would we detect if balances drifted from reality?
 * Can we prove every balance by replaying the ledger?
-* What financial edge cases (refunds, disputes, chargebacks) aren't handled?

package/assets/skills/observability/SKILL.md

@@ -15,14 +15,13 @@ description: Observability - logging, metrics, tracing. Use when adding monitori
 
 * Correlation IDs must exist end-to-end (request → job → webhook)
 * Alerts must exist for critical failures
-* No PII in logs or error tracking
 * 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?
 
-Good observability makes debugging easy. Bad observability means guessing, adding logs, redeploying, hoping.
+PII protection in logs is enforced via `privacy`. This skill focuses on making debugging effective.
 
 ## Driving Questions
 

package/assets/skills/performance/SKILL.md

@@ -7,7 +7,7 @@ description: Performance - Core Web Vitals, bundle size. Use when optimizing spe
 
 ## Tech Stack
 
-* **Framework**: Next.js (SSR/ISR/Static)
+* **Framework**: Next.js (with Turbopack)
 * **Platform**: Vercel
 * **Tooling**: Bun
 
@@ -15,6 +15,7 @@ description: Performance - Core Web Vitals, bundle size. Use when optimizing spe
 
 * 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
 

package/assets/skills/pricing/SKILL.md

@@ -11,50 +11,22 @@ description: Pricing strategy - tiers, feature gating. Use when designing pricin
 * **Database**: Neon (Postgres)
 * **ORM**: Drizzle
 
-## Platform-Led Pricing
-
-Platform is the source of truth for all pricing.
-
-- Products, prices, tiers, features defined in platform code
-- Stripe Products/Prices created via sync, not manually
-- No Stripe dashboard configuration
-- Pricing changes → code change → sync to Stripe
-- Historical prices remain in Stripe (immutable)
-
 ## Non-Negotiables
 
-* All pricing configuration must be in code
-* No manual Stripe dashboard changes
-* Pricing drift must be detectable and auto-correctable
+* 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 Model
-
-```typescript
-// Platform defines pricing (code is SSOT)
-const plans = {
-  free: { price: 0, features: ['basic'] },
-  pro: { price: 29, features: ['basic', 'advanced', 'priority'] },
-  enterprise: { price: 299, features: ['basic', 'advanced', 'priority', 'sla'] }
-}
-
-// Sync to Stripe on deploy/startup
-await syncPricingToStripe(plans)
-```
+* Pricing drift must be detectable and auto-correctable
+* No manual Stripe dashboard configuration
 
 ## Context
 
-Pricing is strategy, not just configuration. The right pricing captures value, reduces friction, and aligns incentives.
-
-Platform owns pricing. Stripe is the payment processor. This separation allows:
-- A/B testing pricing without Stripe changes
-- Switching processors without repricing
-- Complex entitlement logic beyond Stripe's model
+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?
-* Can we change pricing without touching Stripe dashboard?
 * 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/pwa/SKILL.md

@@ -7,7 +7,7 @@ description: PWA - native app parity, offline-first, engagement. Use when buildi
 
 ## Tech Stack
 
-* **Framework**: Next.js
+* **Framework**: Next.js (with Turbopack)
 * **Service Worker**: Serwist (Next.js integration)
 * **Platform**: Vercel
 
@@ -17,47 +17,8 @@ description: PWA - native app parity, offline-first, engagement. Use when buildi
 * 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)
-
-## Native App Parity
-
-| Capability | API |
-|------------|-----|
-| True offline | Cache API + localStorage/IndexedDB |
-| Background sync | Background Sync API |
-| App icon badge | Badging API |
-| Local notifications | Notifications API |
-| Push notifications | Web Push API |
-| App shortcuts | manifest.json `shortcuts` |
-| File handling | File Handling API |
-| Protocol handling | registerProtocolHandler |
-| Pull-to-refresh | Touch events + CSS |
-| View transitions | View Transitions API |
-| Bottom sheets | CSS + touch gestures |
-| Skeleton loading | CSS + React Suspense |
-| Swipe gestures | Touch/Pointer events |
-| Haptic feedback | Vibration API |
-| Sound effects | Web Audio API |
-| Media controls | Media Session API |
-| Wake lock | Screen Wake Lock API |
-| Orientation lock | Screen Orientation API |
-| Fullscreen | Fullscreen API |
-| Picture-in-Picture | PiP API |
-| Share | Web Share API |
-| Receive share | Share Target API |
-| Clipboard | Clipboard API |
-| Camera/Mic | MediaDevices API |
-| Geolocation | Geolocation API |
-| Motion sensors | DeviceMotion/Orientation |
-| Bluetooth | Web Bluetooth API |
-| NFC | Web NFC API |
-| Barcode scan | Barcode Detection API |
-| Speech | Web Speech API |
-| Payments | Payment Request API |
-| Credentials | Credential Management API |
-| Idle detection | Idle Detection API |
-| Network status | Network Information API |
-| Reduced motion | `prefers-reduced-motion` |
-| Window controls | Window Controls Overlay |
+* Complete manifest.webmanifest with all required fields
+* All required icons present (favicon, apple-touch-icon, PWA icons, maskable)
 
 ## Context
 

package/assets/skills/referral/SKILL.md

@@ -9,24 +9,22 @@ description: Referral systems - referral programs, viral loops. Use for referral
 
 * **Analytics**: PostHog
 * **Database**: Neon (Postgres)
+* **ORM**: Drizzle
 
 ## Non-Negotiables
 
-* Referral rewards must have clawback capability for fraud
-* Attribution must be auditable (who referred whom, when, reward status)
-* Velocity controls must exist to prevent abuse
+* 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
 
-Referral programs can drive explosive growth — or become fraud magnets. The best referral programs make sharing natural and rewarding. The worst become liability when abusers exploit them.
-
-Consider both sides: what makes users want to share? And what prevents bad actors from gaming the system? A referral program that's easy to abuse is worse than no referral program.
+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
 
-* Why would a user share this product with someone they know?
-* How easy is it for a bad actor to generate fake referrals?
-* What fraud patterns exist that we haven't addressed?
-* What is the actual ROI of the referral program?
-* Where do users drop off in the referral/share flow?
-* If we redesigned referrals from scratch, what would be different?
+* 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

@@ -7,25 +7,34 @@ description: SEO - meta tags, structured data. Use when optimizing for search.
 
 ## Tech Stack
 
-* **Framework**: Next.js (SSR-first for indexable/discovery)
+* **Framework**: Next.js (with Turbopack, SSR-first)
 
 ## Non-Negotiables
 
-* All pages must have metadata (title, description)
+* Every page must have complete metadata (title, description, canonical, OG, Twitter Cards)
 * Canonical URLs must be correct (no duplicate content)
-* sitemap.xml and robots.txt must exist and be correct
+* 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)
 
-## Context
+## 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
 
-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.
+## Context
 
-Consider: what queries should this product rank for? What content would genuinely serve those searchers? Is the technical foundation (metadata, structure, performance) supporting or hindering discoverability?
+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
 
-* What queries should this product rank #1 for?
-* What content gaps exist that competitors are filling?
-* Where are we losing rankings due to technical issues?
-* What structured data opportunities are we missing?
-* How does Core Web Vitals performance affect our search rankings?
-* What would make Google consider this site authoritative in our domain?
+* 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

@@ -8,40 +8,26 @@ description: File storage - uploads, CDN, blobs. Use when handling files.
 ## Tech Stack
 
 * **Storage**: Vercel Blob
+* **Framework**: Next.js (with Turbopack)
 * **Platform**: Vercel
-* **Framework**: Next.js
 
 ## Non-Negotiables
 
-* Uploads must be intent-based and server-verified
-* No direct client uploads to permanent storage
-* Server must validate blob ownership before attaching to resources
-* Abandoned uploads must be cleanable
-
-## Upload Flow
-
-```
-Client requests upload URL
-        ↓
-Server creates signed upload token
-        ↓
-Client uploads to Vercel Blob
-        ↓
-Server validates and attaches to resource
-        ↓
-Orphaned blobs cleaned periodically
-```
+* 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 uploads are a common attack vector. Users upload things you don't expect. Files live longer than you plan. Storage costs accumulate quietly.
+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
 
-* Is all storage through Vercel Blob?
-* Are uploads validated server-side?
-* What happens to orphaned files?
-* What file types do we accept, and should we?
-* How much are we spending on storage?
+* 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

@@ -7,26 +7,25 @@ description: Support - help center, tickets, docs. Use when building support.
 
 ## Tech Stack
 
+* **Framework**: Next.js (with Turbopack)
 * **Email**: Resend
-* **Framework**: Next.js
 
 ## Non-Negotiables
 
-* Unsubscribe must work reliably
-* Support contact must be discoverable
-* Newsletter/marketing must respect consent preferences
+* 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 user trust is won or lost. When something goes wrong, how easy is it to get help? When help arrives, does it actually solve the problem? Great support turns frustrated users into loyal advocates.
+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.
 
-Consider the entire help-seeking journey: finding help, explaining the problem, getting resolution. Where is there friction? Where do users give up? What would make users feel genuinely cared for?
+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
 
-* When users need help, can they find it easily?
-* What problems do users have that they can't solve themselves?
-* How long does it take to resolve a typical support request?
-* What would reduce support volume without reducing user satisfaction?
-* Where do users get stuck and give up on getting help?
-* What would make the support experience genuinely delightful?
+* 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

@@ -8,53 +8,33 @@ description: UI/UX - design system, accessibility. Use when building interfaces.
 ## Tech Stack
 
 * **Framework**: Next.js (with Turbopack)
-* **Components**: Radix UI
+* **Components**: Radix UI (mandatory)
 * **Styling**: Tailwind CSS
 * **Icons**: @iconify-icon/react
 
-## Radix UI Everywhere (Mandatory)
-
-Radix UI is mandatory. If Radix has a primitive for it, you MUST use it.
-No exceptions. No custom implementations. No alternative libraries.
-
-Before building any interactive component, check Radix first.
-If Radix provides it, use Radix. Period.
-
-Radix primitives are the SSOT for:
-- Dialogs, modals, sheets, drawers
-- Dropdowns, menus, context menus
-- Popovers, tooltips, hover cards
-- Tabs, accordions, collapsibles
-- Select, combobox, radio, checkbox, switch, toggle
-- Sliders, progress, scroll areas
-- Navigation menus, breadcrumbs
-- Toasts, alerts, alert dialogs
-- Avatar, aspect ratio, separator
-- Forms, labels, toolbar
-- Toggle groups, toggle buttons
+## 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.
-When similar UI problems arise, solve once with Radix, reuse everywhere.
 
 ## Non-Negotiables
 
-* WCAG AA accessibility compliance
-* Radix UI for all interactive components
-* Tailwind CSS for styling
-* @iconify-icon/react for all icons
-* Responsive design for all viewports
+* 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 determines how users perceive and interact with the product. A great UI isn't just "correct" — it's delightful, intuitive, and makes complex tasks feel simple.
-
-Radix provides accessible, unstyled primitives. Tailwind provides utility-first styling. @iconify-icon/react provides unified icon access. Together they enable consistent, accessible UI without reinventing components.
+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
 
-* Is every interactive component using Radix?
-* Are we building custom components Radix already provides?
-* Is the design consistent across the product?
 * Where do users get confused or frustrated?
-* What would make this experience genuinely delightful?
-* How does the UI behave on mobile vs desktop?
+* 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/continue.md

@@ -52,74 +52,28 @@ The system must remain:
 - Testable
 - Observable
 
-## UI: Radix UI Everywhere (Mandatory)
-
-Radix UI is mandatory. If Radix has a primitive for it, you MUST use it.
-No exceptions. No custom implementations. No alternative libraries.
-
-Before building any interactive component, check Radix first.
-If Radix provides it, use Radix. Period.
-
-Radix primitives are the SSOT for:
-- Dialogs, modals, sheets, drawers
-- Dropdowns, menus, context menus
-- Popovers, tooltips, hover cards
-- Tabs, accordions, collapsibles
-- Select, combobox, radio, checkbox, switch, toggle
-- Sliders, progress, scroll areas
-- Navigation menus, breadcrumbs
-- Toasts, alerts, alert dialogs
-- Avatar, aspect ratio, separator
-- Forms, labels, toolbar
-- Toggle groups, toggle buttons
+## 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.
-When similar UI problems arise, solve once with Radix, reuse everywhere.
 
-## Bootstrap: Super Admin
+## Bootstrap
 
-Simplest possible approach:
+Admin bootstrap via INITIAL_SUPERADMIN_EMAIL only. One-time, non-reentrant, non-bypassable.
 
-```
-INITIAL_SUPERADMIN_EMAIL=your@email.com
-```
+## Platform-Led Integrations
 
-Flow:
-1. Set env variable
-2. Register with that email
-3. Automatically elevated to super_admin
-4. Done
+Platform is source of truth. Third-party services sync FROM platform, never reverse.
+All configuration in code. No manual third-party dashboard configuration.
+Platform can switch providers without architectural change.
 
-Why singular:
-- Only one initial super_admin needed
-- They promote others via admin UI
-- Simple = fewer bugs
+## Re-authentication
 
-The bootstrap must:
-- Execute exactly once
-- Be non-reentrant
-- Not be bypassable
-- Not become permanent logic dependency
-
-## Third-Party Integrations: Platform-Led
-
-The platform is the source of truth. Third-party services sync FROM the platform, not TO it.
-
-**Stripe:**
-- Platform defines products, prices, features
-- Stripe is synced to match platform state
-- No manual Stripe dashboard configuration
-- Platform state → Stripe sync (never reverse)
-
-**All integrations:**
-- Design in platform first
-- Third-party services are implementation details
-- No dependency on third-party UI/configuration
-- Platform can switch providers without architectural change
+Sensitive actions require step-up re-authentication (password or email OTP).
+Verified session state must be scoped, time-bound, never implicitly reused.
 
 ## Technologies
 
-All must be used correctly, consistently, and idiomatically:
 tRPC, Next.js (with Turbopack), Radix UI, next-intl, Drizzle,
 Better Auth, Stripe, Upstash, Neon, Vercel,
 Resend (email), Vercel Blob (storage),
@@ -128,33 +82,6 @@ Tailwind CSS (styling), @iconify-icon/react (icons),
 Bun, Biome, Bun test,
 Responsive Web Design.
 
-## Re-authentication Flow
-
-All sensitive operations require explicit re-authentication:
-
-```
-    Sensitive action triggered
-                ↓
-        Check verified session
-                ↓
-    Does the user have a password?
-        ├─ Yes → Verify password
-        └─ No  → Send email OTP (6 digits, 10-minute expiry)
-                ↓
-        Verification succeeds
-                ↓
-        Mark session as verified
-                ↓
-    Allow scoped, time-bound sensitive actions
-    (2FA setup, email change, account deletion, etc.)
-```
-
-The verified state must:
-- Have explicit scope
-- Have explicit expiration
-- Never be implicitly reused
-- Never be shared across sessions or contexts
-
 ---
 
 Any ambiguity, inconsistency, incompleteness, or undefined behavior

package/assets/slash-commands/continue2.md

@@ -0,0 +1,88 @@
+---
+name: continue2
+description: Iterative guideline review - review each, delegate critique, repeat until perfect
+---
+
+# Continue2: Iterative Guideline Review
+
+Review all skill guidelines until perfection.
+
+## Process
+
+### Phase 1: Sequential Review
+
+Review each skill guideline one by one:
+
+1. Use the Skill tool to load the skill (e.g., `skill: "auth"`)
+2. Evaluate against criteria (below)
+3. Fix any issues found
+4. Move to next skill
+
+Skills to review (25 total):
+- auth, account-security, admin, appsec
+- billing, pricing, ledger
+- database, data-modeling
+- delivery, deployments, observability
+- privacy, seo, performance, pwa
+- uiux, i18n, growth
+- storage, support, referral
+- abuse-prevention, competitive-analysis, code-quality
+
+### Phase 2: Delegate to Reviewer
+
+After completing Phase 1, delegate a full review to a worker agent:
+
+```
+Task: Review all 25 skill guidelines for issues.
+
+Use the Skill tool to load each skill (e.g., skill: "auth", skill: "billing", etc.)
+
+Check for:
+- Overlapping responsibilities between skills
+- Missing cross-references where skills relate
+- Inconsistent formatting or structure
+- Missing SSOT designations where needed
+- Tutorial-style content (HOW) instead of requirements (WHAT)
+- Vague or unverifiable non-negotiables
+
+Return: List of specific issues found, or "No issues found."
+```
+
+### Phase 3: Fix and Repeat
+
+If reviewer found issues:
+1. Fix all reported issues
+2. Return to Phase 2
+
+If reviewer found no issues:
+- Done. Commit and release.
+
+## Evaluation Criteria
+
+Each skill must have:
+
+**Structure**:
+- YAML frontmatter (name, description)
+- Tech Stack section (if applicable)
+- Non-Negotiables section
+- Context section (with cross-references to related skills)
+- Driving Questions section
+
+**Content Quality**:
+- Requirements state WHAT, not HOW
+- Non-negotiables are verifiable (can be checked)
+- Context clarifies boundaries with related skills
+- No code examples or templates
+- No tutorial-style explanations
+
+**Consistency**:
+- Tech stack entries follow pattern: `* **Component**: Technology`
+- Next.js always includes `(with Turbopack)`
+- Cross-references use backtick format: `lives in \`skill-name\``
+- SSOT is designated where concepts overlap
+
+## Exit Condition
+
+The loop terminates when:
+- A reviewer agent returns "No issues found"
+- Or explicitly: no overlaps, no missing cross-refs, no formatting issues, no HOW content

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@sylphx/flow",
-	"version": "2.28.10",
+	"version": "2.29.1",
 	"description": "One CLI to rule them all. Unified orchestration layer for AI coding assistants. Auto-detection, auto-installation, auto-upgrade.",
 	"type": "module",
 	"bin": {