@fenixforce/edition-pro 0.1.0

package/skills/builtin/game-development/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: game-development
+description: "Use this skill when building games, game loops, physics, rendering, or game state machines. Triggers: 'game', 'game loop', 'physics', 'collision', 'sprite', 'game engine', 'canvas game', 'WebGL', or any request to build interactive games."
+license: MIT
+---
+
+# Game Development
+
+## What This Skill Does
+
+Build browser-based games. Game loops, state machines, physics, collision detection, rendering, input handling, and audio.
+
+## Game Loop
+
+```typescript
+let lastTime = 0;
+
+function gameLoop(currentTime: number) {
+  const deltaTime = (currentTime - lastTime) / 1000;
+  lastTime = currentTime;
+
+  update(deltaTime);   // Physics, AI, game logic
+  render();            // Draw everything
+
+  requestAnimationFrame(gameLoop);
+}
+
+requestAnimationFrame(gameLoop);
+```
+
+## Game State Machine
+
+```typescript
+type GameState = "menu" | "playing" | "paused" | "gameover";
+
+const stateHandlers: Record<GameState, { update: Function; render: Function }> = {
+  menu: { update: updateMenu, render: renderMenu },
+  playing: { update: updateGame, render: renderGame },
+  paused: { update: updatePause, render: renderPause },
+  gameover: { update: updateGameOver, render: renderGameOver },
+};
+```
+
+## Tools
+
+| Type | Library |
+|------|---------|
+| 2D Canvas | Native Canvas API |
+| 2D Framework | Phaser, PixiJS |
+| 3D | Three.js, Babylon.js |
+| Physics | Matter.js (2D), Cannon.js (3D) |
+| Audio | Tone.js, Howler.js |
+
+## Rules
+
+- Fixed timestep for physics (decouple from frame rate)
+- Separate update logic from render logic
+- Use object pooling for frequently created/destroyed objects (bullets, particles)
+- Input handling should be event-driven, not polled every frame
+- Fetch Context7 docs for whichever game library you're using

package/skills/builtin/git-workflow/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: git-workflow
+description: "Use this skill when the user asks about git branching strategy, commit conventions, merge vs rebase, conflict resolution, or git workflow best practices. Triggers: 'git', 'branch', 'commit', 'merge', 'rebase', 'conflict', 'PR', 'pull request', 'git flow', 'trunk-based', or any git workflow question."
+license: MIT
+---
+
+# Git Workflow
+
+## Branching Strategy (Trunk-Based, Simplified)
+
+```
+main (production) ← feature/xyz ← commits
+                  ← fix/abc ← commits
+```
+
+- `main`: always deployable
+- `feature/*`: short-lived (1-3 days max), branched from main
+- `fix/*`: bug fixes, branched from main
+- No develop branch. No release branches. Keep it simple.
+
+## Commit Conventions
+
+```
+type(scope): description
+
+feat(auth): add JWT refresh token endpoint
+fix(api): handle null response from payment provider
+docs(readme): add deployment instructions
+refactor(users): extract validation into shared module
+test(orders): add edge case tests for discount calculation
+chore(deps): update dependencies
+```
+
+Types: feat, fix, docs, refactor, test, chore, perf, ci
+
+## Rules
+
+- Commits are atomic: one logical change per commit
+- Commit messages describe WHAT changed and WHY (not HOW)
+- Rebase feature branches on main before PR (clean history)
+- Squash merge to main (one commit per feature in main history)
+- Never force-push to main
+- Delete branches after merge
+- PR description explains: what, why, how to test, screenshots if UI

package/skills/builtin/i18n-localization/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: i18n-localization
+description: "Use this skill for internationalization, translation, locale management, or RTL support. Triggers: 'i18n', 'internationalization', 'translation', 'locale', 'multilingual', 'RTL', 'localize', or requests to make an application work in multiple languages."
+license: MIT
+---
+
+# Internationalization & Localization
+
+## What This Skill Does
+
+Make applications work in multiple languages and locales. Translation file management, date/number formatting, pluralization, RTL layout, and locale detection.
+
+## Key Patterns
+
+- Extract all user-facing strings into translation files (JSON or YAML)
+- Use ICU message format for pluralization and interpolation
+- Format dates, numbers, and currencies with Intl API
+- Support RTL layouts with logical CSS properties (margin-inline-start, not margin-left)
+- Detect locale from: URL path > cookie > Accept-Language header > default
+
+## Translation File Structure
+```json
+{
+  "common": {
+    "save": "Save",
+    "cancel": "Cancel",
+    "items": "{count, plural, one {# item} other {# items}}"
+  }
+}
+```
+
+## Rules
+
+- Never concatenate translated strings (word order varies by language)
+- Never hardcode text in components
+- Test with a 30% longer pseudo-locale (German is ~30% longer than English)
+- Support at minimum: LTR and RTL, date formats, number formats, pluralization
+- Fetch Context7 docs for your i18n library (react-intl, next-intl, i18next)

package/skills/builtin/image-prompt-engineering/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: image-prompt-engineering
+description: "Use this skill when the user asks to generate AI images, write image prompts, or create visual content using DALL-E, Midjourney, Stable Diffusion, or similar tools. Triggers: 'image prompt', 'generate image', 'AI art', 'DALL-E', 'Midjourney', 'Stable Diffusion', 'visual', or requests for AI-generated imagery."
+license: MIT
+---
+
+# Image Prompt Engineering
+
+## What This Skill Does
+
+Write effective prompts for AI image generation. Structure, style keywords, composition guidance, and iteration patterns for DALL-E, Midjourney, and Stable Diffusion.
+
+## Prompt Structure
+
+```
+[Subject] + [Action/Pose] + [Setting/Background] + [Style] + [Lighting] + [Technical]
+```
+
+Example: "A software developer working at a standing desk, modern minimalist office with floor-to-ceiling windows, editorial photography style, soft natural light from the left, shallow depth of field, 85mm lens"
+
+## Style Keywords
+
+| Category | Keywords |
+|----------|----------|
+| Photography | editorial, candid, portrait, macro, aerial, street photography |
+| Art styles | watercolor, oil painting, digital art, vector illustration, line art |
+| Mood | moody, vibrant, ethereal, gritty, serene, dramatic |
+| Lighting | golden hour, studio lighting, neon, backlit, chiaroscuro, flat lighting |
+| Technical | 4K, high detail, shallow depth of field, wide angle, tilt-shift |
+
+## Rules
+
+- Be specific about composition ("centered", "rule of thirds", "looking at camera")
+- Specify what you do NOT want with negative prompts where supported
+- Iterate: start broad, then refine based on results
+- Include aspect ratio when relevant (16:9, 1:1, 9:16)
+- For consistency across multiple images, reuse the same style block

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

@@ -0,0 +1,33 @@
+# Investment Research
+## Analysis Framework
+1. **Company Analysis**: revenue, margins, growth rate, competitive position, management
+2. **Valuation**: P/E, P/S, EV/EBITDA compared to sector peers
+3. **Risk Assessment**: market risk, sector risk, company-specific risk, regulatory risk
+4. **Portfolio Fit**: correlation with existing holdings, diversification impact
+
+## Output Format
+```markdown
+## Company: [Name]
+**Sector**: [Sector] | **Market Cap**: [Cap]
+
+## Financial Highlights
+[Key metrics with YoY trends]
+
+## Competitive Position
+[Strengths, moat, threats]
+
+## Risk Factors
+[Ranked by likelihood × impact]
+
+## Valuation
+[Current vs historical vs peers]
+
+## Recommendation
+[With explicit assumptions and what would change the thesis]
+```
+
+## Rules
+- Always include risk factors alongside opportunities
+- Historical data is context, not prediction
+- State assumptions explicitly
+- Note: this is informational analysis, not financial advice.

package/skills/builtin/investor-materials/SKILL.md

@@ -0,0 +1,90 @@
+# Investor Materials
+
+Build investor-facing materials that are consistent, credible, and easy to defend.
+
+## When to Activate
+
+- creating or revising a pitch deck
+- writing an investor memo or one-pager
+- building a financial model, milestone plan, or use-of-funds table
+- answering accelerator or incubator application questions
+- aligning multiple fundraising docs around one source of truth
+
+## Golden Rule
+
+All investor materials must agree with each other.
+
+Create or confirm a single source of truth before writing:
+- traction metrics
+- pricing and revenue assumptions
+- raise size and instrument
+- use of funds
+- team bios and titles
+- milestones and timelines
+
+If conflicting numbers appear, stop and resolve them before drafting.
+
+## Core Workflow
+
+1. inventory the canonical facts
+2. identify missing assumptions
+3. choose the asset type
+4. draft the asset with explicit logic
+5. cross-check every number against the source of truth
+
+## Asset Guidance
+
+### Pitch Deck
+Recommended flow:
+1. company + wedge
+2. problem
+3. solution
+4. product / demo
+5. market
+6. business model
+7. traction
+8. team
+9. competition / differentiation
+10. ask
+11. use of funds / milestones
+12. appendix
+
+If the user wants a web-native deck, pair this skill with `frontend-slides`.
+
+### One-Pager / Memo
+- state what the company does in one clean sentence
+- show why now
+- include traction and proof points early
+- make the ask precise
+- keep claims easy to verify
+
+### Financial Model
+Include:
+- explicit assumptions
+- bear / base / bull cases when useful
+- clean layer-by-layer revenue logic
+- milestone-linked spending
+- sensitivity analysis where the decision hinges on assumptions
+
+### Accelerator Applications
+- answer the exact question asked
+- prioritize traction, insight, and team advantage
+- avoid puffery
+- keep internal metrics consistent with the deck and model
+
+## Red Flags to Avoid
+
+- unverifiable claims
+- fuzzy market sizing without assumptions
+- inconsistent team roles or titles
+- revenue math that does not sum cleanly
+- inflated certainty where assumptions are fragile
+
+## Quality Gate
+
+Before delivering:
+- every number matches the current source of truth
+- use of funds and revenue layers sum correctly
+- assumptions are visible, not buried
+- the story is clear without hype language
+- the final asset is defensible in a partner meeting

package/skills/builtin/javascript-surface-analyzer/SKILL.md

@@ -0,0 +1,66 @@
+# JavaScript Surface Analyzer
+
+## Purpose
+Extract attacker-relevant intelligence from front-end code and convert it into testable hypotheses.
+
+## Inputs
+- `target_url`
+- `seed_pages` (optional)
+- `auth_context` (optional)
+
+## Workflow
+### Phase 1: Asset Enumeration
+1. Collect static and dynamic script URLs.
+2. Expand via source maps and chunk manifests where available.
+3. Track script origin, load condition, and execution context.
+
+### Phase 2: Artifact Extraction
+1. Endpoints, route builders, and API clients.
+2. Header/token construction logic.
+3. Feature flags, debug modes, hidden route toggles.
+4. Secret candidates and key material references.
+
+### Phase 3: Sink Analysis
+1. DOM write sinks: `innerHTML`, `outerHTML`, template insertion.
+2. Code execution sinks: `eval`, `Function`, `setTimeout` string usage.
+3. URL/navigation sinks: dynamic redirects, iframe/src assignments.
+4. Storage sinks: local/session storage of sensitive artifacts.
+
+### Phase 4: Controllability Assessment
+1. Determine if attacker can influence source data.
+2. Trace sanitization or encoding at boundaries.
+3. Estimate exploit preconditions per sink.
+
+### Phase 5: Follow-up Planning
+1. Create endpoint verification cases.
+2. Create DOM-XSS and open redirect probes.
+3. Create token misuse and privilege abuse checks.
+
+## Minimum Extraction Targets
+| Category | Required Extraction |
+|---|---|
+| API surface | method + path hints + caller context |
+| Secrets | key/token candidates with confidence tag |
+| Sinks | sink type + source controllability |
+| Hidden features | flag name + activation condition |
+
+## Output Contract
+```json
+{
+  "script_inventory": [],
+  "endpoint_candidates": [],
+  "secret_candidates": [],
+  "sink_map": [],
+  "hidden_features": [],
+  "follow_up_tests": []
+}
+```
+
+## Constraints
+- Treat secret candidates as sensitive.
+- Mark uncertainty for heavily obfuscated code.
+
+## Quality Checklist
+- [ ] Dynamic script loading is covered.
+- [ ] Sink report includes controllability.
+- [ ] Follow-up tests are concrete and scoped.

package/skills/builtin/markdown-reports/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: markdown-reports
+description: "Use this skill when the user asks to write a report, README, documentation, changelog, technical writing, or any structured long-form document delivered as Markdown. Triggers: 'report', 'README', 'documentation', 'write up', 'analysis document', 'changelog', 'guide', or any request for structured written content."
+license: MIT
+---
+
+# Markdown Reports
+
+## What This Skill Does
+
+Write structured, professional documents in Markdown. Reports, READMEs, changelogs, guides, technical documentation. Clean formatting, logical structure, appropriate depth.
+
+## Document Structure
+
+### Report
+```markdown
+# Title
+
+## Executive Summary
+One paragraph covering what, why, and the key finding.
+
+## Background
+Context needed to understand the report.
+
+## Findings
+### Finding 1: [Name]
+Evidence, data, analysis.
+
+### Finding 2: [Name]
+Evidence, data, analysis.
+
+## Recommendations
+Actionable items ranked by priority.
+
+## Appendix
+Supporting data, methodology details.
+```
+
+### README
+```markdown
+# Project Name
+
+One-line description.
+
+## Setup
+Step-by-step from zero to running.
+
+## Usage
+Key commands and examples.
+
+## Configuration
+Environment variables, options.
+
+## Contributing
+How to submit changes.
+
+## License
+```
+
+## Rules
+
+- Lead with the conclusion, then support it
+- Use headings hierarchically (H1 → H2 → H3)
+- Tables for comparing items, not for single-column lists
+- Code blocks with language identifiers for syntax highlighting
+- Keep paragraphs under 5 sentences
+- Every document needs a clear purpose stated in the first section
+- Proofread for grammar and consistency before delivering.

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

@@ -0,0 +1,69 @@
+# Market Research
+
+Produce research that supports decisions, not research theater.
+
+## When to Activate
+
+- researching a market, category, company, investor, or technology trend
+- building TAM/SAM/SOM estimates
+- comparing competitors or adjacent products
+- preparing investor dossiers before outreach
+- pressure-testing a thesis before building, funding, or entering a market
+
+## Research Standards
+
+1. Every important claim needs a source.
+2. Prefer recent data and call out stale data.
+3. Include contrarian evidence and downside cases.
+4. Translate findings into a decision, not just a summary.
+5. Separate fact, inference, and recommendation clearly.
+
+## Common Research Modes
+
+### Investor / Fund Diligence
+Collect:
+- fund size, stage, and typical check size
+- relevant portfolio companies
+- public thesis and recent activity
+- reasons the fund is or is not a fit
+- any obvious red flags or mismatches
+
+### Competitive Analysis
+Collect:
+- product reality, not marketing copy
+- funding and investor history if public
+- traction metrics if public
+- distribution and pricing clues
+- strengths, weaknesses, and positioning gaps
+
+### Market Sizing
+Use:
+- top-down estimates from reports or public datasets
+- bottom-up sanity checks from realistic customer acquisition assumptions
+- explicit assumptions for every leap in logic
+
+### Technology / Vendor Research
+Collect:
+- how it works
+- trade-offs and adoption signals
+- integration complexity
+- lock-in, security, compliance, and operational risk
+
+## Output Format
+
+Default structure:
+1. executive summary
+2. key findings
+3. implications
+4. risks and caveats
+5. recommendation
+6. sources
+
+## Quality Gate
+
+Before delivering:
+- all numbers are sourced or labeled as estimates
+- old data is flagged
+- the recommendation follows from the evidence
+- risks and counterarguments are included
+- the output makes a decision easier

package/skills/builtin/mcp-builder/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: mcp-builder
+description: "Use this skill when the user asks to create an MCP server, expose tools via MCP, or integrate external services as MCP resources. Triggers: 'MCP', 'Model Context Protocol', 'create MCP server', 'expose tool', 'MCP integration', or requests to make a service accessible to AI agents via MCP."
+license: MIT
+---
+
+# MCP Server Builder
+
+## What This Skill Does
+
+Create Model Context Protocol servers that expose tools, resources, and prompts to AI agents. TypeScript implementation with stdio or streamable-http transport.
+
+## Before You Start
+
+1. **Context7:** Fetch MCP SDK docs (`@modelcontextprotocol/sdk`)
+2. **DeepWiki:** Research the service you're integrating with
+
+## Project Structure
+
+```
+mcp-server-name/
+├── src/
+│   ├── index.ts       # Server setup, tool registration
+│   ├── tools/         # Tool implementations
+│   └── types.ts       # Input/output schemas
+├── package.json
+├── tsconfig.json
+└── README.md
+```
+
+## Minimal MCP Server
+
+```typescript
+import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
+import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
+import { z } from "zod";
+
+const server = new McpServer({ name: "my-server", version: "1.0.0" });
+
+server.tool("greet", { name: z.string() }, async ({ name }) => ({
+  content: [{ type: "text", text: `Hello, ${name}!` }],
+}));
+
+const transport = new StdioServerTransport();
+await server.connect(transport);
+```
+
+## Tool Design Rules
+
+- One clear purpose per tool (agents struggle with multi-purpose tools)
+- Descriptive names: `search_documents` not `search`
+- Input validation with Zod schemas
+- Return structured data, not raw HTML or unformatted text
+- Include error messages that help the agent recover
+- Keep tool count under 20 (agents lose track with too many)
+
+## Transport Options
+
+| Transport | Use When |
+|-----------|----------|
+| stdio | Local tools, CLI integration |
+| Streamable HTTP | Remote servers, cloud deployment |
+| SSE | Legacy (being deprecated) |
+
+## Rules
+
+- Always validate inputs with Zod
+- Always return structured content blocks
+- Always include a health/status tool for debugging
+- Test with an actual MCP client before shipping
+- Document every tool with description, parameters, and example usage
+
+## Multi-MCP Orchestration
+
+A single agent can connect to multiple MCP servers simultaneously:
+```json
+{
+  "mcp_servers": [
+    { "name": "github", "url": "https://mcp.github.com/sse" },
+    { "name": "calendar", "url": "https://gcal.mcp.claude.com/mcp" },
+    { "name": "deepwiki", "url": "https://mcp.deepwiki.com/mcp" }
+  ]
+}
+```
+
+The agent discovers tools from all servers and routes calls to the correct server based on tool name. When building MCP servers, consider how they compose with other servers the agent may have connected.

package/skills/builtin/meeting-notes/SKILL.md

@@ -0,0 +1,47 @@
+# Meeting Notes
+
+## Extraction Process
+
+1. Read through the full transcript or notes
+2. Identify key decisions made during the meeting
+3. Extract action items with owner and due date
+4. Summarize discussion topics at a high level
+5. Note open questions and parking lot items
+
+## Output Format
+
+```markdown
+## Meeting: [Title]
+**Date**: [date]
+**Attendees**: [names]
+**Duration**: [time]
+
+## Decisions
+- [Decision 1]: [context and rationale]
+- [Decision 2]: [context and rationale]
+
+## Action Items
+| Action | Owner | Due Date | Status |
+|--------|-------|----------|--------|
+| [task] | [name] | [date] | pending |
+
+## Discussion Summary
+### [Topic 1]
+[Key points discussed, different viewpoints raised]
+
+### [Topic 2]
+[Key points]
+
+## Open Questions
+- [Question needing follow-up]
+
+## Next Meeting
+[Date, agenda items carried forward]
+```
+
+## Rules
+
+- Every action item must have an owner and due date
+- Decisions should include brief rationale (not just what, but why)
+- Distinguish between decisions (final) and discussion points (ongoing)
+- Keep summaries concise — capture essence, not transcript