@sylphx/flow 0.2.12 → 1.0.0

package/assets/agents/reviewer.md

@@ -1,30 +0,0 @@
----
-name: Reviewer
-description: Code review and critique agent
-mode: both
-temperature: 0.3
----
-
-# REVIEWER
-
-## Core Rules
-
-1. **Never Modify**: Read and analyze existing code. Never implement changes.
-
-2. **Objective Critique**: Identify issues without bias. Present facts and reasoning.
-
-3. **Actionable Feedback**: Suggest specific improvements, not vague observations.
-
----
-
-## Review Modes
-
-**Code Review** (readability/maintainability) → Check: naming, structure, complexity, duplication. Exit: Clear improvement suggestions.
-
-**Security Review** (vulnerabilities) → Check: input validation, auth, data exposure, injection risks. Exit: Security recommendations with severity.
-
-**Performance Review** (efficiency) → Check: algorithms, queries, caching, bottlenecks. Exit: Performance improvements with impact estimate.
-
-**Architecture Review** (design) → Check: coupling, cohesion, scalability, maintainability. Exit: Design recommendations.
-
-Flow between modes based on review focus and findings.

package/assets/agents/writer.md

@@ -1,30 +0,0 @@
----
-name: Writer
-description: Documentation and explanation agent
-mode: primary
-temperature: 0.3
----
-
-# WRITER
-
-## Core Rules
-
-1. **Never Implement**: Write about code and systems. Never write executable code.
-
-2. **Audience First**: Tailor content to reader's knowledge level and needs.
-
-3. **Clarity Over Completeness**: Make complex ideas accessible. Simple beats comprehensive.
-
----
-
-## Writing Modes
-
-**Documentation** (reference) → Structure: purpose, usage, examples, edge cases. Exit: Complete, searchable docs.
-
-**Tutorial** (learning) → Structure: context, step-by-step, explain why, exercises. Exit: Learner can apply knowledge.
-
-**Explanation** (understanding) → Structure: problem, solution, reasoning, trade-offs. Exit: Reader understands decision rationale.
-
-**README** (onboarding) → Structure: what, why, quickstart, next steps. Exit: New user can get started.
-
-Flow between modes based on content purpose and audience needs.

package/assets/knowledge/data/sql.md

@@ -1,216 +0,0 @@
----
-name: SQL & Relational DBs
-description: Postgres/MySQL patterns, indexing, transactions, migrations, query optimization
----
-
-# SQL & Relational Databases
-
-## When SQL vs NoSQL
-
-**SQL (Postgres, MySQL)**: Clear relationships, ACID transactions, complex queries with joins, strong consistency, stable schema
-
-**NoSQL (MongoDB)**: Flexible schema, horizontal scaling, document data, simple queries
-
-**Default: SQL (Postgres)** - More powerful, safer for most use cases
-
-## Schema Design
-
-### Foreign Keys & Relationships
-Always use foreign keys with `ON DELETE CASCADE/SET NULL`. Prevents orphaned records.
-
-```sql
-CREATE TABLE posts (
-  id SERIAL PRIMARY KEY,
-  user_id INTEGER REFERENCES users(id) ON DELETE CASCADE
-);
-```
-
-### Many-to-Many
-Use junction table with composite primary key to prevent duplicates:
-
-```sql
-CREATE TABLE likes (
-  user_id INTEGER REFERENCES users(id) ON DELETE CASCADE,
-  post_id INTEGER REFERENCES posts(id) ON DELETE CASCADE,
-  PRIMARY KEY (user_id, post_id)
-);
-```
-
-## Indexes
-
-```sql
--- Single column
-CREATE INDEX idx_posts_user_id ON posts(user_id);
-
--- Composite (order matters!)
-CREATE INDEX idx_posts_user_created ON posts(user_id, created_at DESC);
-```
-
-**When to index:**
-- ✅ Foreign keys (always), WHERE clauses, ORDER BY, JOIN conditions
-- ❌ Frequently changing columns (slows writes), small tables (< 1000 rows)
-
-## Query Optimization
-
-### N+1 Problem
-```sql
--- BAD: N+1 queries
-SELECT * FROM users;
--- Then for each user:
-SELECT * FROM posts WHERE user_id = ?;
-
--- GOOD: 1 query with JOIN
-SELECT u.*, p.id as post_id, p.title FROM users u
-LEFT JOIN posts p ON p.user_id = u.id;
-```
-
-### Use EXPLAIN
-```sql
-EXPLAIN ANALYZE SELECT * FROM posts WHERE user_id = 123;
-
--- Look for: Index Scan (good), Seq Scan (bad - full table)
-```
-
-### Pagination
-```sql
--- BAD: OFFSET slow for large offsets
-SELECT * FROM posts ORDER BY created_at LIMIT 20 OFFSET 10000;
--- Reads and discards 10000 rows!
-
--- GOOD: Cursor-based
-SELECT * FROM posts
-WHERE created_at < '2024-01-01'
-ORDER BY created_at DESC LIMIT 20;
-```
-
-## Transactions (ACID)
-
-**Use for**: Money transfers, inventory, related records that must stay consistent
-
-```sql
-BEGIN;
-UPDATE accounts SET balance = balance - 100 WHERE id = 1;
-UPDATE accounts SET balance = balance + 100 WHERE id = 2;
-COMMIT; -- Both succeed or both fail
-```
-
-**Isolation Levels:**
-- READ COMMITTED (default, good for most)
-- SERIALIZABLE (strongest, slowest - critical ops)
-
-## Common Patterns
-
-**Soft Deletes**: Add `deleted_at TIMESTAMP NULL`, filter with `WHERE deleted_at IS NULL`
-
-**Timestamps**: Add `created_at`, `updated_at` with triggers for auto-update
-
-**Enums**: Use CHECK constraint or ENUM type for fixed values (status, role)
-
-## Migrations
-
-### Add Column (Safe)
-```sql
--- Safe: nullable
-ALTER TABLE users ADD COLUMN phone VARCHAR(20);
-
--- Safe: with default
-ALTER TABLE users ADD COLUMN is_active BOOLEAN DEFAULT true;
-```
-
-### Change Column (Risky)
-```sql
--- Safer: Add new, migrate data, drop old
-ALTER TABLE users ADD COLUMN email_new VARCHAR(500);
-UPDATE users SET email_new = email;
-ALTER TABLE users DROP COLUMN email;
-ALTER TABLE users RENAME COLUMN email_new TO email;
-```
-
-### Add Index (Lock-Free)
-```sql
--- Postgres: doesn't block writes
-CREATE INDEX CONCURRENTLY idx_posts_user_id ON posts(user_id);
-```
-
-## Performance Tips
-
-### Connection Pooling
-```typescript
-const pool = new Pool({
-  max: 20,
-  idleTimeoutMillis: 30000,
-  connectionTimeoutMillis: 2000
-})
-
-// Use pool.query(), not new Client() per request
-```
-
-### Prepared Statements (Prevent Injection)
-```typescript
-// BAD: SQL injection vulnerable
-db.query(`SELECT * FROM users WHERE email = '${userInput}'`)
-
-// GOOD: Prepared
-db.query('SELECT * FROM users WHERE email = $1', [userInput])
-```
-
-### Batch Operations
-```sql
--- BAD: 1000 separate inserts
-INSERT INTO posts (title) VALUES ('Post 1');
-
--- GOOD: Batch
-INSERT INTO posts (title) VALUES ('Post 1'), ('Post 2'), ('Post 3');
-```
-
-## Full-Text Search
-
-Add `tsvector` column, create GIN index, use `@@` operator:
-
-```sql
-ALTER TABLE posts ADD COLUMN search_vector tsvector;
-CREATE INDEX idx_posts_search ON posts USING GIN(search_vector);
-SELECT * FROM posts WHERE search_vector @@ to_tsquery('react & typescript');
-```
-
-## Common Mistakes
-
-❌ **Not using foreign keys** → Orphaned records
-❌ **Not indexing foreign keys** → Slow joins
-❌ **VARCHAR without limit** → Use VARCHAR(255)
-❌ **Not handling NULL** → Use IS NULL, not = NULL
-❌ **String concatenation** → SQL injection, use prepared statements
-
-## ORMs (Prisma, Drizzle, TypeORM)
-
-**Pros**: Type safety, easier migrations, less SQL
-**Cons**: Less control, can generate inefficient SQL, overhead
-
-**Recommendation**: ORM for CRUD, raw SQL for complex queries
-
-```typescript
-// Prisma
-const user = await prisma.user.findUnique({
-  where: { id: 1 },
-  include: { posts: true }
-})
-
-// Raw when needed
-const result = await prisma.$queryRaw`SELECT ... complex query ...`
-```
-
-## Monitoring
-
-**Slow Query Log**: Enable logging for queries > 100ms, identify bottlenecks
-
-**Check Index Usage**: Find unused indexes with `pg_stat_user_indexes WHERE idx_scan = 0`
-
-**Check Query Stats**: Use `pg_stat_statements` to find slow queries
-
-## Decision Guide
-
-**Normalize vs Denormalize**: Normalize by default, denormalize for read-heavy, use materialized views for expensive aggregations
-
-**JSON column**: Flexible schema-less data (user preferences), data you won't query often. NOT for filtering/sorting.
-
-**Add index**: Column in WHERE on large table, foreign keys (always), after identifying slow queries. NOT on every column.

package/assets/knowledge/guides/saas-template.md

@@ -1,85 +0,0 @@
----
-name: SaaS Template
-description: Complete SaaS feature spec: auth, billing, multi-tenancy, compliance
----
-
-# SaaS Platform Specification
-
-Scalable, secure SaaS for modern web apps. USD wallet billing, tiered memberships, serverless SPA architecture. Prioritize security, usability, extensibility.
-
-## Core Requirements
-- **Architecture**: Responsive SPA, serverless backend (Vercel/Cloudflare)
-- **Currency**: USD only
-- **Billing**: Wallet-based (Stripe), membership discounts before deductions
-- **Memberships**: Tiers (Small/Medium/Large) with monthly auto-top-ups, discounts, entitlements. Yearly = 10x monthly. Admin-configurable.
-- **Compliance**: GDPR/CCPA compliant, verifiable acceptance criteria
-
-## Core Features
-
-### Auth & User Management
-- **Auth**: Email/password, SSO (Google/OAuth), Passkey-first 2FA (SimpleWebAuthn), reCAPTCHA v3, rate limiting (5 attempts/5min)
-- **Sessions**: Rotating JWTs, Redis denylist, log all logins (IP, UA, timestamp)
-- **Security**: 2FA setup/recovery codes, email alerts for new logins/devices
-- **Profiles**: Display name, bio, avatar (128x128px, S3)
-- **Usernames**: Unique, lowercase, reserved blocks, 30-day change cooldown + audit
-- **Devices**: Active sessions list (IP/UA/location), one-click logout
-
-- **Invites & Referrals**: Shareable codes/links/QR with limits/expiration. Track referrals, reward wallet credits (configurable).
-- **Notifications**: User-configurable email/push, in-app hub with bell, unread counts, mark-read
-- **Activity Feed**: Log actions (recharges, spends, logins, invites, referrals) with timestamps/filters
-
-### Billing & Wallet
-- **Wallet**: USD balances, Stripe top-ups (min $10), auto-deduct with tier discounts
-- **Memberships**: Tiers ($10/mo, $50/mo, $100/mo) with auto-top-up, % discounts, perks. Yearly = 10x. Admin CRUD.
-- **Invoicing**: PDF receipts, admin dashboard for search/export (CSV/PDF)
-
-### Admin Dashboard
-Role-based (admin/moderator). Charts/tables for insights.
-- **Overview**: Metrics (date, plan, region, device), visualize revenue/users/growth
-- **User Management**: Search, role assignment, bans, username approval
-- **Billing**: Manage subscriptions/refunds, invoices, bulk adjustments
-- **Wallet**: Reconcile, flag anomalies (>$1000 top-up)
-- **Marketing**: Newsletter lists/broadcasts, track open/unsubscribe
-- **Invites/Referrals**: Generate codes/programs, monitor stats/rewards
-- **Memberships**: CRUD plans (price, top-up, discounts, entitlements)
-- **Notifications**: Global broadcasts (email/push)
-- **Support**: Ticket queue with reply/status
-- **Audits**: Searchable logs (user/action/timestamp), export
-
-### Content & Support
-- **Knowledge Base**: Docs/FAQ (MDX)
-- **CMS**: Blog for announcements
-- **Status**: Real-time uptime/incidents, historical data
-- **Help**: Contact form → tickets, admin responses
-
-### Public Pages
-- **Landing**: Home, Features, Pricing (SEO-optimized)
-- **Profiles**: /u/<username> (bio, stats, Open Graph)
-- **Referrals**: /r/<code> redirects with tracking
-- **Legal**: Terms, Privacy, Cookies. Consent banner with granular controls.
-
-### Advanced Features
-- **Error Handling**: Custom 404/500, search/suggestions, auto-redirect
-- **Analytics**: Consent-gated GA, newsletter engagement (no PII)
-- **Consent**: Log agreements (user_id, type, version, timestamp, IP/UA). Version policies, granular toggles, history export/revocation.
-
-## Legal & Compliance
-GDPR, CCPA, PECR. Data minimization, user rights.
-- **Cookies**: Banner with opt-in/out, categorize (necessary, analytics, marketing), persist in DB
-- **Data Rights**: Export/delete endpoints, process within 30 days (P1)
-- **Documentation**: MDX pages (Privacy, Terms, Cookies), version updates with notifications
-- **Logging**: Immutable consent/action records, audit for compliance
-
-## Deployment
-Serverless for scalability, CI/CD for reliability.
-- **Local**: Docker Compose (web/DB/Redis). Run: `bun install && bun db:migrate && bun dev`
-- **Monitoring**: Sentry for errors, SLO alerts (99.9%), retry failed webhooks (3x, exponential)
-- **Status**: Auto-update from monitoring events
-
-## Testing
-100% coverage, enforce via CI. TDD for new features.
-- **Unit**: Vitest, mock externalities
-- **E2E**: Playwright (register → login → 2FA → top-up → consume → invoice → unsubscribe → invite → referral → ticket)
-- **Accessibility**: axe-core, Lighthouse A11y >95
-- **Performance**: Responsive, lazy loading, Iconify icons
-- **Quality**: Biome linting/formatting, pre-commit hooks

package/assets/knowledge/guides/system-prompt.md

@@ -1,344 +0,0 @@
----
-name: System Prompt Writing Guide
-description: MEP (Minimal Effective Prompt) framework for writing high-signal, efficient prompts
----
-
-# Minimal Effective Prompt (MEP) Framework
-
-> **Core Philosophy**: Find the smallest set of high-signal tokens that maximize desired outcomes.
-
-## Core Principles
-
-### The Three Golden Rules
-
-**1. Trust LLM Intelligence**
-Modern LLMs (GPT-4, Claude Sonnet 4+):
-- Strong contextual reasoning and inference
-- Pattern generalization from 1-2 examples
-- Trained on common frameworks, standards, best practices
-- Understand semantic compression
-
-**2. Eliminate Redundancy**
-Each concept appears **exactly once**.
-- Stated in A → Don't repeat in B
-- Implied by X → Don't state explicitly
-- Common sense → Don't state at all
-
-**3. Achieve Goldilocks Zone**
-Balance:
-- Too rigid: Hardcoded if-else, excessive checklists, brittle rules
-- Too vague: "Be helpful", high-level platitudes, no concrete guidance
-- **Goldilocks**: Specific guidance + flexible heuristics
-
----
-
-## The MEP Framework
-
-### The Three Questions (For Every Token)
-
-**1. Is this UNIQUE?**
-- Can it be inferred from other parts?
-- Is it in LLM's training data?
-- Is it just a rewording?
-
-**2. Is this ACTIONABLE?**
-- Does it enable concrete behavior?
-- Can LLM act on this?
-- Is it specific enough?
-
-**3. Is this HIGH-SIGNAL?**
-- Does it directly impact outcome?
-- Is it critical to success?
-- Would removing it degrade performance?
-
-**Decision Matrix:**
-```
-All 3 YES → KEEP (essential)
-Any 1 NO  → REMOVE or MERGE
-All 3 NO  → DELETE immediately
-```
-
-### Signal Density Target
-
-- **Good**: 60-70% high-signal
-- **Great**: 70-80% high-signal
-- **Exceptional**: 80-90% high-signal
-
-Calculate: (High-signal tokens / Total tokens) × 100%
-
----
-
-## Writing Process
-
-### Phase 1: Brain Dump
-Capture all requirements, rules, guidance. Don't filter. Focus on completeness.
-
-### Phase 2: Structure
-Organize into logical sections:
-1. Core Rules/Principles (always true)
-2. Identity/Role (who is LLM)
-3. Foundational Concepts (philosophy)
-4. Operational Guidance (how to work)
-5. Tools & Resources (available)
-6. Decision Support (when unclear)
-7. Standards (quality, security)
-8. Anti-Patterns (what to avoid)
-9. Output Format (what to deliver)
-
-### Phase 3: Identify Redundancy
-
-**Type A - Exact Repetition**: Same concept, same wording → Keep 1st, delete all others
-
-**Type B - Semantic Repetition**: Same concept, different wording → Keep clearest
-
-**Type C - Implied Repetition**: B is logical consequence of A → Keep only A
-
-**Type D - Section Redundancy**: Entire section restates another → Delete entire section
-
-### Phase 4: Apply The Three Questions
-
-For each section, validate against uniqueness, actionability, high-signal.
-
-**Remove common sense:**
-❌ "Never commit broken code", "Use descriptive names", "Test your code"
-
-**Keep specific guidance:**
-✅ "Run tests after EVERY change", "Refactor on 3rd duplication", "Extract when >20 lines"
-
-### Phase 5: Optimize Expression
-
-**Compact Syntax:**
-```
-❌ "First do A, then B, then C" → ✅ "A → B → C"
-❌ "Choose from: A, B, or C" → ✅ "Choose: A / B / C"
-❌ "If X then Y" → ✅ "X? → Y"
-❌ "Never X, never Y, never Z" → ✅ "Never: X / Y / Z"
-```
-
-**List Consolidation:**
-- **Bullets**: Complex items needing explanation
-- **Commas**: Simple, parallel items
-
-**Remove Filler:**
-```
-❌ "You should always make sure to test" → ✅ "Always test"
-❌ "It is important that you document" → ✅ "Document"
-❌ "Try to choose the simplest" → ✅ "Choose simplest"
-```
-
-**Merge Related Sections:**
-When sections are conceptually related, <50 tokens each, total merged <150 tokens.
-
-### Phase 6: Format & Polish
-
-**Headers**: Use hierarchy (`#` > `##` > `###`), avoid excessive nesting
-
-**Emphasis**: Bold for key terms (first mention only), emoji sparingly (section markers only)
-
-**Code Blocks**: For templates, examples, specific formats only
-
-**Tables**: For comparisons and decision matrices
-
----
-
-## Judgment Criteria
-
-### What to KEEP
-
-**Unique Information:**
-- Custom conventions (document format, commit format, priority hierarchy)
-- Novel frameworks (execution modes, decision frameworks)
-- Specific guidance ("Refactor on 3rd duplication", "Extract when >20 lines")
-
-**Actionable Directives:**
-- Specific actions ("Run tests after every change", "Validate inputs at boundaries")
-- Clear workflows ("Analyze → Check → Assume → Implement")
-- Decision rules ("Ambiguous? → existing > conventions > standards")
-
-**High-Signal Examples:**
-1-2 representative examples per concept (LLM generalizes)
-
-### What to REMOVE
-
-**Redundant Content:**
-- Exact repetition (same concept, same wording)
-- Semantic repetition (same concept, different wording)
-- Implied content (B follows from A)
-- Redundant sections (duplicates another section)
-
-**Low-Signal Content:**
-- Common sense ("Write clean code", "Comment your code")
-- Vague directives ("Be thoughtful", "Think carefully", "Consider context")
-- Over-emphasis ("🔴 CRITICAL: MUST VERIFY" → "Verify")
-
-**Verbose Expression:**
-- Filler words ("You should always...", "It is important that...")
-- Redundant explanations (LLM infers implications)
-
----
-
-## Common Pitfalls
-
-**Over-Specification**: 50+ conditional rules → Principles + heuristics instead
-
-**Repetition for Emphasis**: Stating "Never block" 4 times → State once, trust LLM
-
-**Excessive Examples**: 5+ examples of same pattern → 2 examples sufficient
-
-**Common Sense Inclusion**: Universal programming knowledge → Omit
-
-**Vague Directives**: "Be thoughtful" → Specific, actionable
-
-**Format Overload**: Too many emoji/bold/emphasis → Minimal, purposeful
-
-**Section Bloat**: 20+ tiny sections → Merge related (8-15 sections ideal)
-
----
-
-## Quality Checklist
-
-### Before Optimization
-- [ ] Brain dump complete
-- [ ] Organized into sections
-- [ ] All examples included
-- [ ] All rules documented
-
-### During Optimization
-- [ ] No concept appears >1 time
-- [ ] Every statement passes 3 questions
-- [ ] Compact syntax used
-- [ ] Related sections merged
-
-### After Optimization
-- [ ] All scenarios handleable
-- [ ] All frameworks fully specified
-- [ ] 40-60% token reduction
-- [ ] 75-85% signal density
-- [ ] 8-15 main sections
-- [ ] 1-2 examples per concept
-- [ ] Goldilocks Zone achieved (specific + flexible)
-- [ ] Clean, scannable formatting
-
----
-
-## Decision Trees
-
-### "Should I keep this content?"
-```
-Is it unique (not inferable)?
-├─ NO → DELETE
-└─ YES → Is it actionable?
-    ├─ NO → DELETE
-    └─ YES → Is it high-signal?
-        ├─ NO → DELETE
-        └─ YES → KEEP
-```
-
-### "Should I include this example?"
-```
-How many examples already?
-├─ 0 → ADD 1-2 representative
-├─ 1-2 → GOOD, stop
-└─ 3+ → TOO MANY, remove least representative
-```
-
-### "Should I merge these sections?"
-```
-Are they related?
-├─ NO → Keep separate
-└─ YES → Each <50 tokens?
-    ├─ NO → Keep separate
-    └─ YES → Total merged <150?
-        ├─ NO → Keep separate
-        └─ YES → MERGE
-```
-
----
-
-## Practical Examples
-
-### Example 1: Optimizing Rules
-
-**Before (110 tokens):**
-```markdown
-## Rule 1: Never Block On Uncertainty
-
-**IMPORTANT**: You must never stop working due to missing information...
-
-When you encounter uncertainty:
-1-8. [Long list of steps]
-
-Remember: It is better to complete...
-```
-
-**After (15 tokens, -86%):**
-```markdown
-## Rule 1: Never Block
-
-Make reasonable assumptions, document them, complete task.
-```
-
-### Example 2: Optimizing Decisions
-
-**Before (115 tokens):**
-```markdown
-When you face an ambiguous requirement:
-- You should choose the most reasonable...
-[Multiple verbose bullet points]
-```
-
-**After (30 tokens, -74%):**
-```markdown
-**Ambiguous?** → existing patterns > conventions > standards. Document assumption.
-**Missing info?** → Industry defaults, make configurable.
-**Multiple options?** → Simplest. Note alternatives.
-```
-
----
-
-## Token Budget Guidelines
-
-**System Prompt Types:**
-
-| Type | Target Tokens | Max Tokens | Focus |
-|------|--------------|------------|-------|
-| Shared Protocol | 150-250 | 300 | Lightweight, universal |
-| Agent-Specific | 800-1200 | 1500 | Comprehensive, specialized |
-| Task-Specific | 300-500 | 700 | Focused, actionable |
-
----
-
-## Final Validation
-
-**A great prompt should feel like:**
-- ✅ Well-written manual (clear, concise, complete)
-- ✅ Expert colleague conversation (professional, efficient)
-- ✅ Set of principles (guiding, not restricting)
-
-**A great prompt should NOT feel like:**
-- ❌ Legal terms (exhaustive, repetitive, cautious)
-- ❌ IKEA instructions (step-by-step, rigid, brittle)
-- ❌ Drill sergeant (emphasis, repetition, no trust)
-
-**The Ultimate Tests:**
-
-**Can you explain your prompt's purpose in one sentence?**
-- Yes → Focused ✅
-- No → Tries to do too much ❌
-
-**Can you identify high-signal vs noise?**
-- 75%+ essential → Great ✅
-- 50-75% essential → Good, can improve 🟡
-- <50% essential → Too much noise ❌
-
-**Would you want to read your prompt?**
-- Yes → Clean, professional, scannable ✅
-- No → Needs work ❌
-
----
-
-## Conclusion
-
-Great prompts = **Clarity** (each concept once) + **Trust** (LLM intelligence) + **Economy** (every token earns place) + **Effectiveness** (achieve outcomes)
-
-Shorter. Clearer. More effective. 🎯