@fenixforce/edition-pro 0.1.0

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

@@ -0,0 +1,265 @@
+---
+name: backend-development
+description: "Use this skill when the user asks to build server-side logic, APIs, backend services, authentication, database integration, middleware, or any server-side application. Triggers: 'build an API', 'create a server', 'backend', 'endpoint', 'REST API', 'GraphQL', 'authentication', 'middleware', 'server-side', 'Node.js server', 'Express', 'Hono', 'Fastify', or any request involving server logic, data processing, or API design."
+license: MIT
+---
+
+# Backend Development
+
+## What This Skill Does
+
+Build production-quality server-side applications. APIs, authentication, middleware, database integration, background jobs, error handling. Framework-agnostic patterns with specific guidance for the Bun/TypeScript ecosystem.
+
+## Before You Start
+
+1. **Fetch current docs** via Context7 for whichever framework the user wants (Hono, Express, Fastify, etc.)
+2. **Ask the user** about their runtime (Bun, Node.js, Deno), database, and auth requirements if not specified
+3. Default to **Bun + Hono + TypeScript** for new projects (Fenix's native stack)
+
+## Project Structure
+
+```
+project/
+├── src/
+│   ├── index.ts            # Entry point, server setup
+│   ├── routes/
+│   │   ├── auth.ts         # Auth routes
+│   │   ├── users.ts        # User CRUD
+│   │   └── health.ts       # Health check
+│   ├── middleware/
+│   │   ├── auth.ts         # JWT/session validation
+│   │   ├── cors.ts         # CORS config
+│   │   ├── rateLimit.ts    # Rate limiting
+│   │   └── errorHandler.ts # Global error handler
+│   ├── services/           # Business logic (no HTTP awareness)
+│   ├── db/
+│   │   ├── client.ts       # Database connection
+│   │   ├── schema.ts       # Schema definitions
+│   │   └── migrations/     # SQL migrations
+│   ├── types/              # Shared TypeScript types
+│   └── utils/              # Helpers, validators
+├── tests/
+├── .env.example
+├── package.json
+├── tsconfig.json
+└── README.md
+```
+
+## API Design
+
+### RESTful Conventions
+
+```
+GET    /api/v1/resources          # List (with pagination)
+GET    /api/v1/resources/:id      # Get one
+POST   /api/v1/resources          # Create
+PUT    /api/v1/resources/:id      # Full update
+PATCH  /api/v1/resources/:id      # Partial update
+DELETE /api/v1/resources/:id      # Delete
+```
+
+### Response Format
+
+```typescript
+// Success
+{ "data": {...}, "meta": { "page": 1, "total": 42 } }
+
+// Error
+{ "error": { "code": "VALIDATION_ERROR", "message": "Email is required", "details": [...] } }
+```
+
+### Status Codes
+- 200 OK, 201 Created, 204 No Content
+- 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 422 Unprocessable Entity, 429 Too Many Requests
+- 500 Internal Server Error
+
+## Core Patterns
+
+### Request Validation
+
+Validate all input at the boundary. Never trust client data.
+
+```typescript
+import { z } from "zod";
+
+const CreateUserSchema = z.object({
+  email: z.string().email(),
+  name: z.string().min(1).max(100),
+  role: z.enum(["user", "admin"]).default("user"),
+});
+
+// In route handler
+const body = CreateUserSchema.safeParse(await req.json());
+if (!body.success) {
+  return Response.json(
+    { error: { code: "VALIDATION_ERROR", message: body.error.issues } },
+    { status: 422 }
+  );
+}
+```
+
+### Error Handling
+
+```typescript
+class AppError extends Error {
+  constructor(
+    public statusCode: number,
+    public code: string,
+    message: string,
+    public details?: unknown
+  ) {
+    super(message);
+  }
+}
+
+// Global error handler middleware
+function errorHandler(err: Error): Response {
+  if (err instanceof AppError) {
+    return Response.json(
+      { error: { code: err.code, message: err.message, details: err.details } },
+      { status: err.statusCode }
+    );
+  }
+  console.error("Unhandled error:", err);
+  return Response.json(
+    { error: { code: "INTERNAL_ERROR", message: "Something went wrong" } },
+    { status: 500 }
+  );
+}
+```
+
+### Authentication (JWT)
+
+```typescript
+import { sign, verify } from "jsonwebtoken";
+
+function generateToken(userId: string): string {
+  return sign({ sub: userId }, process.env.JWT_SECRET!, { expiresIn: "24h" });
+}
+
+function authMiddleware(req: Request): { userId: string } {
+  const header = req.headers.get("authorization");
+  if (!header?.startsWith("Bearer ")) {
+    throw new AppError(401, "UNAUTHORIZED", "Missing bearer token");
+  }
+  try {
+    const payload = verify(header.slice(7), process.env.JWT_SECRET!);
+    return { userId: (payload as any).sub };
+  } catch {
+    throw new AppError(401, "UNAUTHORIZED", "Invalid or expired token");
+  }
+}
+```
+
+### Database Access
+
+Separate database queries from route handlers. Services contain business logic. Routes handle HTTP.
+
+```typescript
+// services/users.ts
+export async function getUserById(db: DB, id: string) {
+  const user = await db.query("SELECT * FROM users WHERE id = $1", [id]);
+  if (!user.rows[0]) throw new AppError(404, "NOT_FOUND", "User not found");
+  return user.rows[0];
+}
+
+// routes/users.ts
+app.get("/api/v1/users/:id", async (req) => {
+  const user = await getUserById(db, req.params.id);
+  return Response.json({ data: user });
+});
+```
+
+### Rate Limiting
+
+```typescript
+const rateLimits = new Map<string, { count: number; resetAt: number }>();
+
+function rateLimit(limit: number, windowMs: number) {
+  return (req: Request): void => {
+    const key = req.headers.get("x-forwarded-for") || "unknown";
+    const now = Date.now();
+    const entry = rateLimits.get(key);
+
+    if (!entry || now > entry.resetAt) {
+      rateLimits.set(key, { count: 1, resetAt: now + windowMs });
+      return;
+    }
+    if (entry.count >= limit) {
+      throw new AppError(429, "RATE_LIMITED", "Too many requests");
+    }
+    entry.count++;
+  };
+}
+```
+
+### Environment Variables
+
+```typescript
+// Always validate env vars at startup
+const requiredEnvVars = ["DATABASE_URL", "JWT_SECRET", "PORT"] as const;
+
+for (const key of requiredEnvVars) {
+  if (!process.env[key]) {
+    console.error(`Missing required env var: ${key}`);
+    process.exit(1);
+  }
+}
+```
+
+## Security Checklist
+
+- All user input validated and sanitized
+- SQL queries use parameterized statements (never string concatenation)
+- Passwords hashed with bcrypt or argon2 (never stored plaintext)
+- CORS configured with explicit allowed origins (never `*` in production)
+- Rate limiting on all public endpoints
+- Helmet-style security headers set
+- Secrets loaded from environment variables, never committed to code
+- HTTPS enforced in production
+- Request body size limits configured
+- No stack traces or internal details in production error responses
+
+## Verification
+
+Before marking complete:
+1. Start the server and confirm it listens on the expected port
+2. Test each endpoint with curl or a request tool
+3. Test error cases (invalid input, missing auth, rate limits)
+4. Confirm database queries use parameterized statements
+5. Check that `.env.example` documents all required variables
+6. Verify no secrets are hardcoded
+
+## Integration with Other Skills
+
+- **context7-docs:** ALWAYS fetch framework docs before generating route code
+- **database-design:** Use that skill for schema design and migration strategy
+- **api-development:** Use that skill for API design patterns and documentation
+- **docker-deployment:** Use that skill to containerize the server
+- **security-audit:** Run that skill before deploying to production
+
+## Shell Lifecycle (Devin AI pattern)
+
+Shell sessions: create -> use -> close. Never leave processes running. Clean up background processes, temp files, open connections when done.
+
+Two modes:
+- **Planning mode**: read files, search code, understand structure. No changes.
+- **Standard mode**: write code, run tests, commit.
+
+Announce mode switches explicitly.
+
+## LSP-First Editing
+
+Before modifying existing code:
+1. Read the full file
+2. Understand types and interfaces via go-to-definition
+3. Check what depends on your changes via find-references
+4. Make minimal targeted changes following existing patterns
+
+Never rewrite working code just because you'd write it differently.
+
+## Minimal Output (Claude Code 2.0 pattern)
+
+Show the code, not descriptions of the code. Never explain changes unless asked.
+
+Banned: "Here is the content...", "Based on the information...", "I'll now create...", "Let me explain..."

package/skills/builtin/binary-analysis-analyst/SKILL.md

@@ -0,0 +1,61 @@
+# Binary Analysis Analyst
+
+## Purpose
+Move from suspicious leads to high-confidence binary findings with explicit exploit preconditions.
+
+## Inputs
+- `binary_path`
+- `priority_targets`
+- `runtime_context`
+- `environment_constraints`
+
+## Workflow
+### Phase 1: Lead Refinement
+1. Re-rank leads by attacker reachability.
+2. Identify state and input prerequisites.
+3. Remove dead or non-reachable leads.
+
+### Phase 2: Deep Trace
+1. Trace target function call chains.
+2. Track tainted data into memory-sensitive operations.
+3. Identify missing checks and bypassable guards.
+
+### Phase 3: Primitive Confirmation
+1. Build minimal trigger inputs.
+2. Validate memory/register side effects.
+3. Confirm repeatability across runs.
+
+### Phase 4: Exploitability Modeling
+1. Determine necessary control granularity.
+2. Determine mitigation bypass requirements.
+3. Determine privilege and environmental dependencies.
+
+### Phase 5: Finding Finalization
+1. Produce concise technical narrative.
+2. State confidence and unresolved unknowns.
+3. Recommend next exploit or remediation steps.
+
+## Analyst Decision Rubric
+- `high`: primitive validated and impact path plausible.
+- `medium`: primitive likely but incomplete control proof.
+- `low`: suspicious behavior with major unknowns.
+
+## Output Contract
+```json
+{
+  "validated_findings": [],
+  "trace_summaries": [],
+  "exploitability_assessment": [],
+  "confidence": [],
+  "unknowns": []
+}
+```
+
+## Constraints
+- No impact claims without validated primitive.
+- Unknowns must be explicit and bounded.
+
+## Quality Checklist
+- [ ] Reachability is demonstrated.
+- [ ] Primitive is technically classified.
+- [ ] Preconditions are concrete.

package/skills/builtin/binary-analysis-core/SKILL.md

@@ -0,0 +1,65 @@
+# Binary Analysis Core
+
+## Purpose
+Provide a disciplined baseline workflow for vulnerability-oriented binary analysis.
+
+## Inputs
+- `binary_path`
+- `architecture`
+- `runtime_environment`
+- `recon_targets` (optional)
+
+## Analysis Workflow
+### Phase 1: Structural Analysis
+1. Build call graph and function role map.
+2. Identify parser paths and data transformations.
+3. Locate boundary checks and memory operations.
+
+### Phase 2: Primitive Hunting
+1. Stack/heap overflow opportunities.
+2. UAF/double-free and allocator misuse.
+3. Integer arithmetic leading to memory mis-sizing.
+4. Format string and command construction flaws.
+
+### Phase 3: Control and Data Influence
+1. Determine attacker control over size, offset, and content.
+2. Determine repeatability and trigger reliability.
+3. Determine crashability vs control-flow influence.
+
+### Phase 4: Dynamic Validation
+1. Instrument breakpoints around candidate primitives.
+2. Validate assumptions under realistic input.
+3. Capture traces that prove or refute exploit conditions.
+
+### Phase 5: Prioritized Findings
+1. Rank by exploitability and preconditions.
+2. Note required bypasses for mitigations.
+3. Prepare handoff for exploit development.
+
+## Primitive Classification
+| Class | Required Proof |
+|---|---|
+| overflow | controlled overwrite target and bounds failure |
+| UAF | stale reference reuse with attacker influence |
+| integer | arithmetic error drives dangerous memory behavior |
+| format string | attacker-controlled format reaches formatter |
+
+## Output Contract
+```json
+{
+  "analysis_scope": {},
+  "candidate_primitives": [],
+  "validated_primitives": [],
+  "mitigation_interactions": [],
+  "exploitability_ranking": []
+}
+```
+
+## Constraints
+- Distinguish speculation from validated behavior.
+- Keep architecture assumptions explicit.
+
+## Quality Checklist
+- [ ] Candidate primitives include proof strategy.
+- [ ] Dynamic checks support conclusions.
+- [ ] Ranking reflects real attacker constraints.

package/skills/builtin/binary-recon/SKILL.md

@@ -0,0 +1,64 @@
+# Binary Recon
+
+## Purpose
+Create a reliable initial profile that drives deeper vulnerability analysis.
+
+## Inputs
+- `binary_path`
+- `target_platform`
+- `runtime_assumptions` (optional)
+
+## Workflow
+### Phase 1: Metadata and Build Context
+1. Determine architecture, endianness, and binary format.
+2. Identify static vs dynamic linking and dependency footprint.
+3. Record compiler and build artifacts when detectable.
+
+### Phase 2: Hardening Profile
+1. Check PIE, NX, RELRO, stack canary, Fortify.
+2. Check symbol stripping and debug artifact presence.
+3. Check obvious sandboxing or seccomp hints.
+
+### Phase 3: Interface Discovery
+1. Enumerate exported/imported functions.
+2. Extract protocol and command strings.
+3. Identify input channels: argv, env, file parsers, network listeners.
+
+### Phase 4: Hotspot Prioritization
+1. Parser-heavy code and format handlers.
+2. Memory-manipulation and boundary logic.
+3. Auth and crypto decision paths.
+4. Dangerous call clusters.
+
+### Phase 5: Recon Handoff
+1. Build prioritized function list.
+2. Add rationale for each priority target.
+3. Define proof requirements for deep analysis.
+
+## Recon Artifacts
+| Artifact | Why It Matters |
+|---|---|
+| hardening matrix | exploitability baseline |
+| symbol/function map | navigation and targeting |
+| string corpus | protocol and feature hints |
+| risky function clusters | likely vulnerability density |
+
+## Output Contract
+```json
+{
+  "binary_profile": {},
+  "hardening_matrix": {},
+  "interface_map": [],
+  "priority_targets": [],
+  "deep_analysis_requirements": []
+}
+```
+
+## Constraints
+- Keep recon low-cost and repeatable.
+- Do not produce exploit claims in recon.
+
+## Quality Checklist
+- [ ] Hardening profile is complete.
+- [ ] Input channels are mapped.
+- [ ] Priority targets are justified.

package/skills/builtin/blackboard-coordination/SKILL.md

@@ -0,0 +1,56 @@
+# Blackboard Coordination
+
+## Pattern
+
+Multiple specialist agents collaborate via a shared state object (the blackboard):
+1. Problem posted to blackboard with initial state
+2. Controller examines blackboard, selects most relevant specialist
+3. Specialist reads blackboard, contributes its analysis, writes results back
+4. Controller re-examines, selects next specialist based on updated state
+5. Repeat until solution complete or no specialist can contribute further
+
+## Roles
+
+- **Controller**: stateful planner that tracks what's been done and decides who goes next
+- **Specialists**: domain experts that read state, contribute, and write back. Each has explicit domain boundaries.
+
+## Blackboard State
+
+```typescript
+interface Blackboard {
+  problem: string;
+  currentState: Record<string, unknown>;
+  contributions: Array<{
+    specialist: string;
+    timestamp: Date;
+    input: string;
+    output: string;
+  }>;
+  status: "in_progress" | "complete" | "stuck";
+}
+```
+
+## Flow
+
+```markdown
+## Round 1
+**Specialist**: [name]
+**Read**: [what it read from blackboard]
+**Contribution**: [what it added]
+**State change**: [what changed]
+
+## Round 2
+**Specialist**: [name]
+...
+
+## Final State
+**Status**: complete / stuck
+**Solution**: [synthesized output]
+```
+
+## Rules
+
+- Specialists only contribute within their domain
+- Controller must be aware of all prior contributions before selecting next specialist
+- Maximum 10 specialist rounds per problem (prevent infinite loops)
+- If no specialist can contribute, status becomes "stuck" and escalate to user

package/skills/builtin/blog-to-podcast/SKILL.md

@@ -0,0 +1,18 @@
+# Blog to Podcast
+## Pipeline
+1. **Extract**: pull article content (from URL via web scraping or from provided text)
+2. **Restructure**: rewrite for audio consumption (remove visual references, add spoken transitions, convert lists to natural language)
+3. **Generate**: produce audio via TTS
+
+## Restructuring Rules
+- Replace "as shown below" with descriptions of what would be shown
+- Convert bullet lists to flowing sentences
+- Add verbal signposts: "First...", "Moving on to...", "The key takeaway here..."
+- Remove parenthetical citations (mention sources naturally: "According to researchers at MIT...")
+- Target length: 1 minute per 150 words
+- Add intro hook and closing summary
+
+## Rules
+- Test the restructured text by reading it aloud (does it sound natural?)
+- Maintain the original author's key points and conclusions
+- Add context that visual readers would get from images/charts but listeners miss.

package/skills/builtin/blog-writing/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: blog-writing
+description: "Use this skill when the user asks to write blog posts, articles, SEO content, or editorial pieces. Triggers: 'blog post', 'article', 'write about', 'content for', 'editorial', 'thought leadership', or requests for published written content."
+license: MIT
+---
+
+# Blog Writing
+
+## What This Skill Does
+
+Write engaging, well-structured blog posts and articles. SEO awareness, clear structure, compelling hooks, scannable formatting.
+
+## Structure
+
+1. **Hook** (first 2 sentences): Start with a problem, question, surprising fact, or bold claim
+2. **Context**: Why this matters to the reader
+3. **Body**: 3-5 main sections with subheadings. Each section: claim → evidence → implication
+4. **Conclusion**: Summary + call to action
+
+## SEO Basics
+
+- Primary keyword in title, first paragraph, and 2-3 subheadings
+- Meta description: 150-160 characters, includes keyword, compels click
+- Internal and external links where relevant
+- Alt text for any images
+- URL slug: short, hyphenated, includes keyword
+
+## Rules
+
+- Write for humans first, search engines second
+- Short paragraphs (2-4 sentences)
+- Subheadings every 200-300 words for scannability
+- Active voice over passive
+- Specific examples over abstract claims
+- End with clear next step for the reader
+- Word count target: 800-1500 words unless specified otherwise.

package/skills/builtin/brainstorming/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: brainstorming
+description: "Use this skill before any creative work: designing features, building components, choosing approaches, or solving open-ended problems. Triggers: 'brainstorm', 'ideas', 'what if', 'creative', 'design', 'how should we', 'what's the best way to', or any open-ended problem requiring exploration before commitment."
+license: MIT
+---
+
+# Brainstorming
+
+## What This Skill Does
+
+Explore options before committing to an approach. Diverge (generate many ideas), explore (evaluate top candidates), converge (select and plan), execute.
+
+## The 4 Phases
+
+### 1. DIVERGE (generate 7+ ideas)
+No filtering. Quantity over quality. Wild ideas welcome. Write every idea down.
+
+### 2. EXPLORE (evaluate top 3-5)
+For each candidate: pros, cons, effort estimate, risk, alignment with constraints.
+
+### 3. CONVERGE (score and select)
+Score each candidate on: feasibility (1-5), impact (1-5), effort (1-5 inverse), risk (1-5 inverse). Pick the highest total.
+
+### 4. EXECUTE (plan the selected approach)
+Write the implementation plan using planning-with-files skill.
+
+## Output Format
+
+```markdown
+# Brainstorm: [Topic]
+
+## Ideas (Diverge)
+1. [idea]
+2. [idea]
+...7+
+
+## Evaluation (Explore)
+### Idea 3: [name]
+- Pros: ...
+- Cons: ...
+- Effort: [S/M/L]
+- Risk: [low/medium/high]
+
+### Idea 5: [name]
+...
+
+## Decision (Converge)
+Selected: Idea 3 because [rationale]
+
+## Plan (Execute)
+[hand off to planning-with-files]
+```
+
+## Rules
+
+- Never skip the diverge phase. 7 ideas minimum.
+- Never commit to the first idea. Explore at least 3.
+- Document WHY you selected the winning approach
+- Save the brainstorm file (other ideas may become relevant later)
+
+## Self-Improvement Loop (Generate -> Critique -> Revise)
+
+After generating initial ideas or a draft:
+1. **Generate**: produce the first version (Junior role)
+2. **Critique**: evaluate against rubric with specific, actionable feedback (Senior role). Score each dimension 1-5 with reasoning BEFORE the score.
+3. **Revise**: incorporate feedback into improved version
+4. **Loop**: repeat until quality threshold met (score 4+ on all dimensions) or 3 iterations max
+
+Store high-quality final outputs as examples for future brainstorming sessions.

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

@@ -0,0 +1,42 @@
+---
+name: brand-design
+description: "Use this skill when the user asks about brand guidelines, color palettes, logo usage, brand voice, or brand consistency. Triggers: 'brand', 'branding', 'brand guidelines', 'color palette', 'brand voice', 'logo usage', 'brand identity', 'style guide', or requests for brand-related design decisions."
+license: MIT
+---
+
+# Brand Design
+
+## What This Skill Does
+
+Define and enforce brand identity. Color palettes, typography, voice guidelines, logo usage rules, and consistency standards.
+
+## Brand Guidelines Template
+
+### Colors
+- Primary: Main brand color (used for CTAs, key elements)
+- Secondary: Supporting color (used for accents, secondary actions)
+- Neutral: Background, text, borders (2-3 shades)
+- Semantic: Success (green), warning (amber), error (red), info (blue)
+- Define each as: hex, RGB, HSL, with WCAG contrast ratios documented
+
+### Typography
+- Display font: headlines, hero text
+- Body font: paragraphs, UI text
+- Mono font: code, data
+- Scale: define sizes for H1-H6, body, small, caption
+
+### Voice
+- 3-5 adjectives defining the brand personality
+- "We say... / We don't say..." examples
+- Tone shifts by context (marketing: energetic, support: empathetic, docs: precise)
+
+### Logo Usage
+- Minimum size, clear space, approved color variations
+- Do's and don'ts with visual examples
+
+## Rules
+
+- Every brand decision must have a documented rationale
+- Brand guidelines are living documents, updated quarterly
+- Consistency beats creativity (a mediocre consistent brand beats a great inconsistent one)
+- Test all color combinations for accessibility (WCAG AA minimum)