@sylphx/flow 2.11.0 → 2.12.0

package/assets/slash-commands/review-security.md

@@ -1,6 +1,6 @@
 ---
 name: review-security
-description: Review security - OWASP, CSP/HSTS, CSRF, anti-bot, rate limiting
+description: Review security - OWASP, headers, authentication, secrets
 agent: coder
 ---
 
@@ -8,11 +8,11 @@ agent: coder
 
 ## Mandate
 
-* Perform a **deep, thorough review** of security controls in this codebase.
+* Perform a **deep, thorough review** of security in this codebase.
 * **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
 * Deliverables must be stated as **findings, gaps, and actionable recommendations**.
 * **Single-pass delivery**: no deferrals; deliver a complete assessment.
-* **Explore beyond the spec**: identify vulnerabilities and hardening opportunities.
+* **Explore beyond the spec**: identify vulnerabilities and hardening opportunities not listed here.
 
 ## Tech Stack
 
@@ -20,35 +20,27 @@ agent: coder
 * **Framework**: Next.js
 * **Platform**: Vercel
 
-## Review Scope
+## Non-Negotiables
 
-### Security Baseline
+* OWASP Top 10:2025 vulnerabilities must be addressed
+* CSP, HSTS, X-Frame-Options, X-Content-Type-Options headers must be present
+* CSRF protection on state-changing requests
+* No plaintext passwords in logs, returns, storage, or telemetry
+* MFA required for Admin/SUPER_ADMIN roles
+* Required configuration must fail-fast at build/startup if missing
+* Secrets must not be hardcoded or committed
 
-* OWASP Top 10:2025 taxonomy; OWASP ASVS (L2/L3) verification baseline.
-* Password UX masked + temporary reveal; no plaintext passwords in logs/returns/storage/telemetry.
-* MFA for Admin/SUPER_ADMIN; step-up for high-risk.
-* Risk-based anti-bot for auth and high-cost endpoints; integrate rate limits + consent gating.
+## Context
 
-### Baseline Controls
+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?
 
-* CSP/HSTS/headers
-* CSRF where applicable
-* Upstash-backed rate limiting
-* PII scrubbing
-* Supply-chain hygiene
-* Measurable security
+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?
 
-### Configuration and Secrets Governance
+## Driving Questions
 
-* Required configuration must fail-fast at build/startup
-* Strict environment isolation (dev/stage/prod)
-* Rotation and incident remediation posture must be auditable and exercisable
-
-## Key Areas to Explore
-
-* What OWASP Top 10 vulnerabilities exist in the current implementation?
-* How comprehensive are the security headers (CSP, HSTS, etc.)?
+* What would an attacker target first?
 * Where is rate limiting missing or insufficient?
-* How are secrets managed and what is the rotation strategy?
-* What attack vectors exist for the authentication flows?
-* How does the system detect and respond to security incidents?
+* 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?
+* Where does "security by obscurity" substitute for real controls?

package/assets/slash-commands/review-seo.md

@@ -1,6 +1,6 @@
 ---
 name: review-seo
-description: Review SEO - metadata, Open Graph, canonical, hreflang, sitemap
+description: Review SEO - discoverability, metadata, search rankings
 agent: coder
 ---
 
@@ -12,40 +12,29 @@ agent: coder
 * **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
 * Deliverables must be stated as **findings, gaps, and actionable recommendations**.
 * **Single-pass delivery**: no deferrals; deliver a complete assessment.
-* **Explore beyond the spec**: identify improvements for discoverability and search rankings.
+* **Explore beyond the spec**: identify what would make this product dominate search results.
 
 ## Tech Stack
 
 * **Framework**: Next.js (SSR-first for indexable/discovery)
 
-## Review Scope
-
-### SEO Requirements
-
-* SEO-first + SSR-first for indexable/discovery
-* Required elements:
-  * Metadata (title, description)
-  * Open Graph tags
-  * Favicon (all sizes)
-  * Canonical URLs
-  * hreflang + x-default
-  * schema.org structured data
-  * sitemap.xml
-  * robots.txt
-
-### SEO/i18n/Canonicalization Verification
-
-* `/en/*` non-existence (must redirect)
-* hreflang/x-default correct
-* Sitemap containing only true variants
-* UGC canonical redirects
-* Locale routing invariants
-
-## Key Areas to Explore
-
-* How does the site perform in search engine results currently?
-* What pages are missing proper metadata or structured data?
-* How does the sitemap handle dynamic content and pagination?
-* Are there duplicate content issues or canonicalization problems?
-* What opportunities exist for featured snippets or rich results?
-* How does page load performance affect SEO rankings?
+## Non-Negotiables
+
+* All pages must have metadata (title, description)
+* Canonical URLs must be correct (no duplicate content)
+* sitemap.xml and robots.txt must exist and be correct
+
+## 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.
+
+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?
+
+## 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?

package/assets/slash-commands/review-storage.md

@@ -1,6 +1,6 @@
 ---
 name: review-storage
-description: Review storage - Vercel Blob upload governance, intent-based uploads
+description: Review storage - uploads, file handling, security
 agent: coder
 ---
 
@@ -12,27 +12,30 @@ agent: coder
 * **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
 * Deliverables must be stated as **findings, gaps, and actionable recommendations**.
 * **Single-pass delivery**: no deferrals; deliver a complete assessment.
-* **Explore beyond the spec**: identify improvements for security, reliability, and cost efficiency.
+* **Explore beyond the spec**: identify security risks and cost optimization opportunities.
 
 ## Tech Stack
 
 * **Storage**: Vercel Blob
 * **Platform**: Vercel
 
-## Review Scope
+## Non-Negotiables
 
-### Vercel Blob Upload Governance (Hard Requirement)
+* 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
 
-* All uploads must be **intent-based and server-verified**.
-* The client must upload to Vercel Blob first using short-lived, server-issued authorization (e.g., signed upload URL / token), then call a server finalize endpoint to persist the resulting Blob URL/key.
-* The server must validate the Blob URL/key ownership and namespace, and must match it against the originating upload intent (who/what/where/expiry/constraints) before attaching it to any resource.
-* The system must support safe retries and idempotent finalize; expired/abandoned intents must be cleanable and auditable.
+## Context
 
-## Key Areas to Explore
+File uploads are a common attack vector. Users upload things you don't expect. Files live longer than you plan. Storage costs accumulate quietly. A well-designed upload system is secure, efficient, and maintainable.
 
-* How are uploads currently implemented and do they follow intent-based pattern?
-* What security vulnerabilities exist in the upload flow?
-* How are abandoned/orphaned uploads handled?
-* What is the cost implication of current storage patterns?
-* How does the system handle large files and upload failures?
-* What content validation (type, size, malware) exists?
+Consider: what could a malicious user upload? What happens to files when the referencing entity is deleted? How does storage cost scale with usage?
+
+## Driving Questions
+
+* What could a malicious user do through the upload flow?
+* What happens to orphaned files when entities are deleted?
+* How much are we spending on storage, and is it efficient?
+* What file types do we accept, and should we?
+* How do we handle upload failures gracefully?
+* What content validation exists (type, size, safety)?

package/assets/slash-commands/review-support.md

@@ -1,6 +1,6 @@
 ---
 name: review-support
-description: Review support - contact, communications, newsletter
+description: Review support - help experience, communications, user satisfaction
 agent: coder
 ---
 
@@ -12,32 +12,30 @@ agent: coder
 * **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
 * Deliverables must be stated as **findings, gaps, and actionable recommendations**.
 * **Single-pass delivery**: no deferrals; deliver a complete assessment.
-* **Explore beyond the spec**: identify user satisfaction improvements and support efficiency gains.
+* **Explore beyond the spec**: identify what would make users feel genuinely supported.
 
 ## Tech Stack
 
 * **Email**: Resend
 * **Framework**: Next.js
 
-## Review Scope
+## Non-Negotiables
 
-### Support and Communications
+* Unsubscribe must work reliably
+* Support contact must be discoverable
+* Newsletter/marketing must respect consent preferences
 
-* Support/Contact surface must be:
-  * Discoverable
-  * Localized
-  * WCAG AA compliant
-  * SEO-complete
-  * Privacy-safe
-  * Auditable where relevant
-* Newsletter subscription/preferences must be consent-aware
-* Unsubscribe enforcement must be reliable
+## Context
 
-## Key Areas to Explore
+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.
 
-* How do users find help when they need it?
-* What self-service support options exist (FAQ, help center)?
-* How are support requests tracked and resolved?
-* What is the email deliverability and engagement rate?
-* How does the newsletter system handle bounces and complaints?
-* What support tools do agents have for helping users?
+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?
+
+## 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?

package/assets/slash-commands/review-trust-safety.md

@@ -0,0 +1,42 @@
+---
+name: review-trust-safety
+description: Review trust & safety - abuse prevention, moderation, user protection
+agent: coder
+---
+
+# Trust & Safety Review
+
+## Mandate
+
+* Perform a **deep, thorough review** of trust and safety in this codebase.
+* **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
+* Deliverables must be stated as **findings, gaps, and actionable recommendations**.
+* **Single-pass delivery**: no deferrals; deliver a complete assessment.
+* **Explore beyond the spec**: identify abuse vectors before bad actors find them.
+
+## Tech Stack
+
+* **Analytics**: PostHog
+* **Database**: Neon (Postgres)
+* **Workflows**: Upstash Workflows + QStash
+
+## Non-Negotiables
+
+* All enforcement actions must be auditable (who/when/why)
+* Appeals process must exist for affected users
+* Graduated response levels must be defined (warn → restrict → suspend → ban)
+
+## Context
+
+Trust & safety is about protecting users — from each other and from malicious actors. Every platform eventually attracts abuse. The question is whether you're prepared for it or scrambling to react.
+
+Consider: what would a bad actor try to do? How would we detect it? How would we respond? What about the false positives — innocent users caught by automated systems? A good T&S system is effective against abuse AND fair to legitimate users.
+
+## Driving Questions
+
+* What would a motivated bad actor try to do on this platform?
+* How would we detect coordinated abuse or bot networks?
+* What happens when automated moderation gets it wrong?
+* How do affected users appeal decisions, and is it fair?
+* What abuse patterns exist that we haven't addressed?
+* What would make users trust that we're protecting them?

package/assets/slash-commands/review-uiux.md

@@ -1,6 +1,6 @@
 ---
 name: review-uiux
-description: Review UI/UX - design system, tokens, accessibility, guidance
+description: Review UI/UX - design system, accessibility, user experience
 agent: coder
 ---
 
@@ -12,38 +12,28 @@ agent: coder
 * **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
 * Deliverables must be stated as **findings, gaps, and actionable recommendations**.
 * **Single-pass delivery**: no deferrals; deliver a complete assessment.
-* **Explore beyond the spec**: identify usability improvements and design inconsistencies.
+* **Explore beyond the spec**: if the current design needs fundamental rethinking, propose it.
 
 ## Tech Stack
 
 * **Framework**: Next.js
 * **Icons**: Iconify
 
-## Review Scope
+## Non-Negotiables
 
-### UX, Design System, and Guidance
+* WCAG AA accessibility compliance
 
-* Design-system driven UI (tokens)
-* Dark/light theme support
-* WCAG AA compliance
-* CLS-safe (no layout shifts)
-* Responsive design (mobile-first, desktop-second)
-* Iconify for icons; no emoji in UI content
+## Context
 
-### Guidance Requirements
+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.
 
-* Guidance is mandatory for all user-facing features and monetization flows:
-  * Discoverable
-  * Clear
-  * Dismissible with re-entry
-  * Localized and measurable
-  * Governed by eligibility and frequency controls
+The review should consider: does the current design truly serve users well? Or does it need fundamental rethinking? Small tweaks to a flawed design won't make it excellent. If redesign is warranted, propose it.
 
-## Key Areas to Explore
+## Driving Questions
 
-* How consistent is the design system across the application?
-* What accessibility issues exist and affect real users?
-* Where do users get confused or drop off in key flows?
-* How does the mobile experience compare to desktop?
-* What guidance/onboarding is missing for complex features?
-* How does the dark/light theme implementation handle edge cases?
+* Where do users get confused, frustrated, or give up?
+* If we were designing this from scratch today, what would be different?
+* What would make this experience genuinely delightful, not just functional?
+* How does the design system enable or constrain good UX?
+* What are competitors doing that users might expect?
+* Where is the UI just "okay" when it could be exceptional?

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@sylphx/flow",
-	"version": "2.11.0",
+	"version": "2.12.0",
 	"description": "One CLI to rule them all. Unified orchestration layer for Claude Code, OpenCode, Cursor and all AI development tools. Auto-detection, auto-installation, auto-upgrade.",
 	"type": "module",
 	"bin": {