@fenixforce/edition-pro 0.1.0

package/skills/builtin/data-visualization/SKILL.md

@@ -0,0 +1,33 @@
+# Data Visualization
+## Chart Selection
+| Data Relationship | Chart Type |
+|-------------------|------------|
+| Trend over time | Line chart |
+| Comparison | Bar chart (vertical or horizontal) |
+| Part of whole | Donut chart (max 6 slices) |
+| Distribution | Histogram or box plot |
+| Correlation | Scatter plot |
+| Composition over time | Stacked area or stacked bar |
+| Geographic | Choropleth map |
+| Flow/process | Sankey diagram |
+| Hierarchy | Treemap |
+
+## Design Rules
+- Title describes the insight, not the data ("Sales grew 23% in Q3" not "Q3 Sales Data")
+- Label all axes with units
+- Start Y-axis at zero for bar charts (misleading otherwise)
+- Use colorblind-friendly palettes (avoid red-green only)
+- Remove chartjunk (unnecessary gridlines, decorations, 3D effects)
+- Highlight the key finding (bold the most important data point)
+
+## Code Generation
+Produce Plotly or Recharts code depending on context:
+- Web apps: Recharts (React) or Chart.js
+- Data analysis: Plotly (interactive) or matplotlib (static)
+- Dashboards: Plotly with dash layout
+
+## Rules
+- Every chart must have a clear purpose (what question does it answer?)
+- Interactive charts need tooltips with actual values
+- Responsive sizing for web charts
+- Export options (PNG, SVG) for reports

package/skills/builtin/database-design/SKILL.md

@@ -0,0 +1,119 @@
+---
+name: database-design
+description: "Use this skill when the user asks to design a database schema, write migrations, optimize queries, set up PostgreSQL, or work with any ORM. Triggers: 'database', 'schema', 'migration', 'SQL', 'PostgreSQL', 'MySQL', 'SQLite', 'Prisma', 'Drizzle', 'query optimization', 'indexing', 'table design', 'relations', 'foreign key', or any request involving data modeling and storage."
+license: MIT
+---
+
+# Database Design
+
+## What This Skill Does
+
+Design schemas, write migrations, optimize queries, and manage database infrastructure. PostgreSQL as the primary target (Fenix's default), with patterns that apply to MySQL, SQLite, and others.
+
+## Before You Start
+
+1. **Context7:** Fetch docs for the chosen ORM (Prisma, Drizzle, Kysely) before generating schema code
+2. **Clarify:** What data needs to be stored? What queries will be most common? What scale?
+3. Default to **PostgreSQL + Drizzle ORM** for new Fenix projects
+
+## Schema Design Principles
+
+### Naming Conventions
+- Tables: plural, snake_case (`user_profiles`, `order_items`)
+- Columns: singular, snake_case (`created_at`, `email_address`)
+- Primary keys: `id` (UUID or auto-increment)
+- Foreign keys: `{referenced_table_singular}_id` (`user_id`)
+- Indexes: `idx_{table}_{columns}`
+
+### Essential Columns (every table)
+```sql
+CREATE TABLE resources (
+  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
+  updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
+);
+```
+
+### Relations
+```sql
+-- One-to-many
+CREATE TABLE posts (
+  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  user_id UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,
+  title TEXT NOT NULL,
+  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
+);
+
+-- Many-to-many
+CREATE TABLE post_tags (
+  post_id UUID NOT NULL REFERENCES posts(id) ON DELETE CASCADE,
+  tag_id UUID NOT NULL REFERENCES tags(id) ON DELETE CASCADE,
+  PRIMARY KEY (post_id, tag_id)
+);
+```
+
+### Indexing Strategy
+```sql
+CREATE INDEX idx_posts_user_id ON posts(user_id);
+CREATE INDEX idx_posts_created_at ON posts(created_at DESC);
+CREATE INDEX idx_posts_user_status ON posts(user_id, status);
+-- Partial index
+CREATE INDEX idx_posts_published ON posts(created_at DESC) WHERE status = 'published';
+-- Full-text search
+CREATE INDEX idx_posts_search ON posts USING GIN(to_tsvector('english', title || ' ' || body));
+```
+
+Index: foreign keys (always), frequent WHERE columns, ORDER BY on large tables, JOIN conditions.
+Don't index: small tables, low-cardinality columns on small tables, heavy-write/rare-read tables.
+
+## Migration Patterns
+
+```sql
+-- 0003_add_posts_status.sql
+BEGIN;
+ALTER TABLE posts
+  ADD COLUMN status TEXT NOT NULL DEFAULT 'draft'
+  CHECK (status IN ('draft', 'published', 'archived'));
+CREATE INDEX idx_posts_status ON posts(status);
+COMMIT;
+```
+
+Rules: every migration idempotent or transactional, never modify applied migrations, write UP and DOWN.
+
+## Query Optimization
+
+```sql
+EXPLAIN ANALYZE SELECT ...;
+-- Cursor pagination (fast)
+SELECT * FROM posts WHERE created_at < $cursor ORDER BY created_at DESC LIMIT 20;
+-- Approximate count (fast)
+SELECT reltuples::bigint FROM pg_class WHERE relname = 'posts';
+```
+
+## PostgreSQL Features
+
+- JSONB: `ALTER TABLE users ADD COLUMN preferences JSONB DEFAULT '{}';`
+- CHECK constraints over enums: `CHECK (status IN ('draft', 'published'))`
+- Row-Level Security for multi-tenant
+
+## Rules
+
+- Always use parameterized queries. Never concatenate user input into SQL.
+- Always add `created_at` and `updated_at` to every table
+- Always index foreign key columns
+- Always use transactions for multi-statement operations
+- Normalize to 3NF, then denormalize selectively for read performance
+
+## Verification
+
+1. Migrations run on clean database
+2. All foreign keys have indexes
+3. No SQL injection vectors
+4. Common queries under 100ms on expected volume
+5. Rollback migration works
+
+## Integration with Other Skills
+
+- **context7-docs:** Fetch ORM docs before generating schema code
+- **backend-development:** Routes depend on schema
+- **fullstack-project:** Schema design comes first

package/skills/builtin/decision-helper/SKILL.md

@@ -0,0 +1,84 @@
+# Decision Helper
+
+## Frameworks
+
+### Decision Matrix (Default)
+Weighted criteria scoring:
+1. List options
+2. Define criteria (importance, feasibility, cost, risk, alignment)
+3. Weight criteria (must sum to 100%)
+4. Score each option per criterion (1-5)
+5. Calculate weighted totals
+6. Recommend highest scorer with sensitivity analysis
+
+### ICE Scoring
+Impact (1-10) x Confidence (1-10) x Ease (1-10) = ICE Score
+Best for prioritizing a backlog of options quickly.
+
+### SWOT Analysis
+Strengths, Weaknesses, Opportunities, Threats per option.
+Best for strategic decisions with external factors.
+
+### Cost-Benefit Analysis
+Quantify costs and benefits over time horizon.
+Best when options have measurable financial impact.
+
+## Output Format
+
+```markdown
+## Decision
+[What needs to be decided]
+
+## Options
+1. [Option A]: [brief description]
+2. [Option B]: [brief description]
+3. [Option C]: [brief description]
+
+## Analysis
+[Framework applied with scoring]
+
+## Recommendation
+**[Recommended option]** because [clear rationale].
+
+## Key Trade-off
+[The main thing you give up by choosing this option]
+
+## Reversibility
+[How easy to change course if this doesn't work]
+```
+
+## Advocate/Critic Debate (Multi-Agent for High-Stakes Decisions)
+
+For decisions with significant consequences, run an adversarial debate:
+
+### Flow
+1. **Advocate Agent**: makes the strongest possible case FOR the proposed option
+2. **Critic Agent**: makes the strongest possible case AGAINST
+3. **Judge Agent**: evaluates both arguments, identifies which points are strongest, renders verdict
+
+### Rules for Debate
+- Advocate and Critic must argue sincerely (no strawman arguments)
+- Each gets 2 rounds: opening argument + rebuttal
+- Judge must cite specific points from each side in the verdict
+- Judge scores argument quality, not just conclusion
+
+### When to Use
+- Irreversible decisions (hiring, architecture migrations, vendor lock-in)
+- Decisions where confirmation bias is likely (the team already wants option A)
+- Decisions with incomplete information (forces both sides to surface unknowns)
+
+### Output
+```markdown
+## Debate: [Decision]
+### Advocate (FOR): [summary of strongest arguments]
+### Critic (AGAINST): [summary of strongest arguments]
+### Judge Verdict: [recommendation with reasoning from both sides]
+### Unresolved Questions: [what neither side could answer]
+```
+
+## Rules
+
+- Always present at least 2 options (including "do nothing" when relevant)
+- Name the key trade-off explicitly
+- Note what information would change the recommendation
+- Distinguish reversible from irreversible decisions

package/skills/builtin/deep-research/SKILL.md

@@ -0,0 +1,68 @@
+# Deep Research
+
+## When to Activate
+
+- User asks to research a topic in depth
+- Multiple sources needed to answer accurately
+- User needs citations and source evaluation
+- Comparing perspectives on a contested topic
+
+## Research Process
+
+### 1. Clarify the Research Question
+What exactly needs answering? What level of detail? Specific angles to prioritize?
+
+### 2. Identify Key Aspects
+Break into subtopics. List main questions. Note required background context.
+
+### 3. Gather Information
+Use web search, DeepWiki (for codebases), Context7 (for library docs). Consider multiple perspectives. Check publication dates. Evaluate source credibility.
+
+### 4. Synthesize Findings
+Identify patterns and themes. Note consensus and disagreement. Highlight key insights. Connect related information.
+
+### 5. Document Sources
+Numbered citations [1], [2]. Full sources listed at end. Note confidence levels.
+
+## Source Evaluation Hierarchy
+
+1. **Peer-reviewed journals**: highest credibility
+2. **Official reports/statistics**: authoritative data
+3. **Reputable news outlets**: fact-checked, timely
+4. **Expert commentary**: qualified opinions
+5. **General websites**: verify independently
+
+## Output Format
+
+```markdown
+## Executive Summary
+[2-3 sentence overview of key findings]
+
+## Key Findings
+- **[Finding 1]**: [Explanation] [1]
+- **[Finding 2]**: [Explanation] [2]
+
+## Detailed Analysis
+### [Subtopic 1]
+[Analysis with citations]
+
+## Areas of Consensus
+[What sources agree on]
+
+## Areas of Debate
+[Where sources disagree]
+
+## Sources
+[1] [Full citation with credibility note]
+
+## Gaps and Further Research
+[What's still unknown]
+```
+
+## Rules
+
+- Always cite sources with numbered references
+- Distinguish fact from opinion explicitly
+- Note confidence level for uncertain findings
+- Include Areas of Debate even when a consensus exists
+- Never present a single source's view as settled fact

package/skills/builtin/deepwiki-research/SKILL.md

@@ -0,0 +1,115 @@
+---
+name: deepwiki-research
+description: "Use this skill when the agent needs to understand an unfamiliar GitHub repository, explore a library's architecture, or answer questions about how open-source code works. Triggers: 'how does X work', 'explore this repo', 'understand this codebase', 'what's the architecture of', any GitHub URL the agent hasn't seen before, or when the agent needs to learn a new library before building with it. Provides instant codebase comprehension via DeepWiki's AI-generated documentation."
+license: MIT
+---
+
+# DeepWiki Research: Codebase Comprehension Tool
+
+## What This Skill Does
+
+DeepWiki transforms any public GitHub repository into structured, searchable documentation with architecture diagrams and AI-powered Q&A. When the agent encounters an unfamiliar codebase, library, or framework, this skill provides instant comprehension without cloning repos or reading thousands of lines manually.
+
+## When to Activate
+
+- User shares a GitHub URL and asks "how does this work?"
+- Agent needs to understand a library's internals before building with it
+- User asks about the architecture of any open-source project
+- Agent needs code examples from a specific repo
+- User asks "what patterns does X use?" about a GitHub project
+- Before writing integration code for an unfamiliar dependency
+
+## MCP Connection
+
+DeepWiki runs as a remote MCP server. No local installation required.
+
+**Server URL:** `https://mcp.deepwiki.com/mcp`
+**Auth:** None required for public repositories
+**Protocol:** Streamable HTTP (also supports SSE at `/sse`, deprecated)
+
+### Fenix MCP Registry Entry
+
+```json
+{
+  "name": "deepwiki",
+  "url": "https://mcp.deepwiki.com/mcp",
+  "auth": "none",
+  "description": "AI-generated documentation for any public GitHub repository",
+  "tools": ["read_wiki_structure", "read_wiki_contents", "ask_question"]
+}
+```
+
+## Available Tools
+
+### 1. `read_wiki_structure`
+
+Get the table of contents for a repository's documentation. Use this first to understand what topics are covered before diving into specifics.
+
+**Input:** `{ "repoName": "facebook/react" }`
+**Returns:** List of documentation sections and topics
+
+**When to use:** Always call this first when exploring a new repo. Review the structure, then fetch only the sections relevant to the current task.
+
+### 2. `read_wiki_contents`
+
+Fetch the full documentation content for a specific topic within a repository.
+
+**Input:** `{ "repoName": "facebook/react", "topic": "hooks-implementation" }`
+**Returns:** Detailed documentation with code references, file paths, and line numbers
+
+**When to use:** After identifying the relevant section from `read_wiki_structure`. Fetch specific topics, not the entire wiki. Token-efficient retrieval matters.
+
+### 3. `ask_question`
+
+Ask a natural language question about any repository and get an AI-powered answer grounded in the actual codebase.
+
+**Input:** `{ "repoName": "vercel/next.js", "question": "How does the app router handle server components?" }`
+**Returns:** Detailed answer with code references, file paths, and explanations
+
+**When to use:** When you have a specific question. More efficient than browsing structure + contents for targeted queries. The response includes exact code snippets with file paths and line numbers.
+
+## Workflow
+
+### Quick Answer (single question about a repo)
+
+```
+1. ask_question({ repoName: "org/repo", question: "user's question" })
+2. Return the answer with code references
+```
+
+### Deep Exploration (understanding a codebase for integration work)
+
+```
+1. read_wiki_structure({ repoName: "org/repo" })
+   → Review sections, identify relevant areas
+2. read_wiki_contents({ repoName: "org/repo", topic: "relevant-section" })
+   → Read architecture, patterns, key interfaces
+3. read_wiki_contents({ repoName: "org/repo", topic: "another-section" })
+   → Read implementation details for the specific area
+4. Synthesize findings into actionable guidance
+```
+
+### Pre-Build Research (before implementing an integration)
+
+```
+1. read_wiki_structure → understand the library's shape
+2. ask_question → "What's the public API surface?"
+3. ask_question → "How do I extend/integrate with this?"
+4. Begin implementation with accurate knowledge
+```
+
+## Rules
+
+- Always use DeepWiki before claiming "I don't know how X works" for any public GitHub project
+- Call `read_wiki_structure` before `read_wiki_contents` unless you already know the exact topic
+- Prefer `ask_question` for targeted queries over browsing the full wiki
+- Cache insights in memory (via `memory.save`) if the user is likely to ask follow-up questions about the same repo
+- Only works with public GitHub repositories. For private repos, inform the user they need a Devin account
+- Do not use DeepWiki when you already have sufficient knowledge of a well-known library. Use Context7 for up-to-date API docs instead
+- DeepWiki excels at architecture and "how does it work" questions. Context7 excels at "what's the current API" questions. Use the right tool for the question type
+
+## Integration with Other Skills
+
+- **context7-docs:** Use Context7 for current API docs. Use DeepWiki for architecture comprehension. They complement each other.
+- **fullstack-project:** Research libraries via DeepWiki before scaffolding a project that depends on them
+- **api-development:** Understand third-party API libraries before writing integration code

package/skills/builtin/dependency-audit/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: dependency-audit
+description: "Use this skill when checking dependencies for vulnerabilities, license compliance, or supply chain security. Triggers: 'dependency audit', 'npm audit', 'bun audit', 'vulnerable packages', 'license check', 'supply chain', or requests to verify dependency safety."
+license: MIT
+---
+
+# Dependency Audit
+
+## What This Skill Does
+
+Audit project dependencies for security vulnerabilities, license compliance, and supply chain risks.
+
+## Audit Commands
+
+```bash
+# Vulnerability scan
+bun audit          # or npm audit
+bun audit --fix    # Auto-fix where possible
+
+# License check
+npx license-checker --summary
+npx license-checker --failOn "GPL-3.0;AGPL-3.0"  # Fail on copyleft
+
+# Outdated packages
+bun outdated       # or npm outdated
+```
+
+## Checklist
+
+- [ ] Zero critical vulnerabilities
+- [ ] Zero high vulnerabilities (or documented exceptions with mitigations)
+- [ ] All licenses compatible with project license
+- [ ] No copyleft licenses in proprietary projects (GPL, AGPL)
+- [ ] Package versions pinned (exact versions, not ranges)
+- [ ] Lock file committed and up to date
+- [ ] No unnecessary dependencies (audit bundle size)
+- [ ] No packages with zero maintenance (last publish > 2 years, no activity)
+
+## Rules
+
+- Run dependency audit in CI on every PR
+- Block merge on critical/high vulnerabilities
+- Document any accepted risks with rationale
+- Review new dependencies before adding (check: maintenance, download count, license, bundle size)
+- Prefer well-maintained packages with active communities
+- Fenix principle: zero proprietary dependencies

package/skills/builtin/doc-coauthoring/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: doc-coauthoring
+description: "Use this skill for collaborative document editing workflows, version tracking, comment management, or structured document review processes. Triggers: 'collaborative editing', 'document review', 'track changes', 'comments', 'version control for documents', or requests for structured document collaboration workflows."
+license: MIT
+---
+
+# Document Co-Authoring
+
+## What This Skill Does
+
+Manage collaborative document workflows. Structured review processes, change tracking, comment resolution, and version management.
+
+## Review Workflow
+
+```
+1. DRAFT: Author writes initial version
+2. REVIEW: Reviewers add comments and suggested changes
+3. REVISE: Author addresses all comments (accept, reject with reason, discuss)
+4. APPROVE: Final review confirms all issues resolved
+5. PUBLISH: Document is finalized and distributed
+```
+
+## Comment Format
+
+```markdown
+<!-- COMMENT by [Name] on [Date]:
+[Specific feedback with suggested alternative]
+Status: OPEN | RESOLVED | WONTFIX
+-->
+```
+
+## Version Naming
+
+```
+document-v1.0-draft.md
+document-v1.0-review.md
+document-v1.0-final.md
+document-v1.1-draft.md  (minor revision)
+document-v2.0-draft.md  (major revision)
+```
+
+## Rules
+
+- Every comment must include a suggested alternative (not just "this is wrong")
+- All comments must be explicitly resolved before advancing to next stage
+- Keep a changelog at the top of the document
+- Archive previous versions, don't delete them
+- One author owns the final decision on any disputed change