@fenixforce/edition-pro 0.1.0

package/skills/builtin/memory-safety-analyst/SKILL.md

@@ -0,0 +1,61 @@
+# Memory Safety Analyst
+
+## Purpose
+Provide precise, exploit-informed analysis of memory corruption and memory safety failures.
+
+## Inputs
+- `target_context` (binary or source)
+- `crash_data` (trace, core, sanitizer output)
+- `mitigation_profile`
+
+## Workflow
+### Phase 1: Fault Classification
+1. Identify bug class: stack overflow, heap overflow, out-of-bounds read/write, use-after-free, double free, integer-driven misallocation.
+2. Identify crash point and corruption origin.
+
+### Phase 2: Control Surface Analysis
+1. Determine control over corrupted bytes.
+2. Determine control over target object or return/control metadata.
+3. Determine trigger repeatability.
+
+### Phase 3: Mitigation Interaction
+1. Evaluate hardening controls in effect.
+2. Evaluate whether bug class can bypass controls.
+3. Separate crash-only from exploit-capable conditions.
+
+### Phase 4: Exploitability Grading
+1. `E0`: non-exploitable with current evidence.
+2. `E1`: crashable, limited attacker control.
+3. `E2`: meaningful data or pointer control.
+4. `E3`: viable control-flow or sensitive data compromise path.
+
+### Phase 5: Remediation Prioritization
+1. Recommend root-cause fix.
+2. Recommend short-term guardrails.
+3. Recommend regression tests.
+
+## Required Evidence
+- faulting instruction context
+- memory state before/after trigger
+- control granularity description
+- mitigation interaction notes
+
+## Output Contract
+```json
+{
+  "bug_classification": {},
+  "control_surface": {},
+  "mitigation_analysis": {},
+  "exploitability_grade": "",
+  "remediation_plan": []
+}
+```
+
+## Constraints
+- Use exact primitive terminology.
+- Avoid overstating exploitability from a single crash.
+
+## Quality Checklist
+- [ ] Classification is unambiguous.
+- [ ] Control analysis is evidence-backed.
+- [ ] Remediation targets root cause.

package/skills/builtin/meta-controller/SKILL.md

@@ -0,0 +1,44 @@
+# Meta-Controller
+
+## Pattern
+
+Supervisory agent that analyzes incoming tasks and dispatches to the right specialist:
+1. Receive task
+2. Classify: what domain? what complexity? what tools needed?
+3. Select specialist based on classification
+4. Dispatch with focused prompt and relevant context only
+5. Receive specialist output
+6. Validate output meets the original request
+7. Return to user or route to next specialist
+
+## Classification Dimensions
+
+- **Domain**: code, data, design, content, research, operations
+- **Complexity**: simple (single specialist), compound (sequential specialists), complex (parallel specialists + synthesis)
+- **Tools needed**: which tool routers the specialist needs access to
+
+## Dispatch Format
+
+```markdown
+## Task Classification
+**Domain**: [domain]
+**Complexity**: [simple/compound/complex]
+**Specialists needed**: [list]
+
+## Dispatch: [Specialist Name]
+**Context**: [only what this specialist needs]
+**Expected output**: [what to return]
+**Constraints**: [scope limits]
+
+## Validation
+**Original request**: [what user asked]
+**Specialist output**: [what was produced]
+**Meets request**: [yes/no, with reasoning]
+```
+
+## Rules
+
+- The meta-controller never does the work itself. It routes.
+- Each specialist gets only the context relevant to its task
+- Complex tasks get decomposed before dispatch
+- Specialist outputs are validated before returning to user

package/skills/builtin/mixture-of-agents/SKILL.md

@@ -0,0 +1,53 @@
+# Mixture of Agents
+
+## Pattern
+
+1. Route the same query to 3-4 different LLM providers simultaneously
+2. Each model produces an independent response
+3. Aggregator model synthesizes all responses, identifying consensus and disagreements
+4. Final output is the synthesis, not any single model's response
+
+## When to Use
+
+- Factual queries where accuracy matters more than speed
+- Analysis where different models may catch different nuances
+- High-stakes decisions where bias from one model could be costly
+- Research synthesis where breadth of perspective matters
+
+## Aggregation Prompt
+
+"You have received responses from multiple AI models. Synthesize these into a single, high-quality response. Note where models agree (high confidence) and where they disagree (flag for user). Prefer specific evidence over general claims."
+
+## Output Format
+
+```markdown
+## Query
+[Original question]
+
+## Individual Responses
+### Model A: [name]
+[Response summary]
+
+### Model B: [name]
+[Response summary]
+
+### Model C: [name]
+[Response summary]
+
+## Synthesis
+### Consensus (High Confidence)
+[What all/most models agree on]
+
+### Disagreements (Flag for Review)
+[Where models differ, with each position noted]
+
+### Final Answer
+[Synthesized response incorporating the best from each]
+```
+
+## Rules
+
+- Minimum 3 models for meaningful ensemble
+- Models should be from different providers (not just different sizes from same provider)
+- Aggregator should be a strong model (it's doing the hardest job)
+- Cost is 3-4x a single call. Only use when the accuracy gain justifies it

package/skills/builtin/monitoring-observability/SKILL.md

@@ -0,0 +1,169 @@
+---
+name: monitoring-observability
+description: "Use this skill when the user asks to set up logging, monitoring, health checks, alerting, error tracking, or uptime monitoring for an application. Triggers: 'monitoring', 'logging', 'health check', 'alerting', 'uptime', 'error tracking', 'observability', 'metrics', 'Sentry', 'Grafana', 'Prometheus', 'logs', or any request to know when something breaks."
+license: MIT
+---
+
+# Monitoring & Observability
+
+## What This Skill Does
+
+Set up logging, health checks, error tracking, uptime monitoring, and alerting. Know when things break before users tell you.
+
+## Health Checks
+
+Every application needs a health endpoint.
+
+### Basic Health Check
+```typescript
+app.get("/health", async (c) => {
+  const checks: Record<string, string> = {};
+
+  try {
+    await db.query("SELECT 1");
+    checks.database = "ok";
+  } catch {
+    checks.database = "error";
+  }
+
+  try {
+    await redis.ping();
+    checks.redis = "ok";
+  } catch {
+    checks.redis = "error";
+  }
+
+  const healthy = Object.values(checks).every(v => v === "ok");
+
+  return c.json({
+    status: healthy ? "healthy" : "degraded",
+    checks,
+    uptime: process.uptime(),
+    timestamp: new Date().toISOString(),
+    version: process.env.APP_VERSION || "unknown",
+  }, healthy ? 200 : 503);
+});
+```
+
+### Readiness vs Liveness
+```
+/health/live    → Can the process respond? (restart if no)
+/health/ready   → Can it serve traffic? (remove from LB if no)
+```
+
+## Structured Logging
+
+```typescript
+function log(level: string, message: string, data?: Record<string, unknown>) {
+  const entry = {
+    timestamp: new Date().toISOString(),
+    level,
+    message,
+    ...data,
+    service: "myapp",
+    environment: process.env.NODE_ENV,
+  };
+  if (level === "error") console.error(JSON.stringify(entry));
+  else console.log(JSON.stringify(entry));
+}
+```
+
+### What to Log
+- Every HTTP request: method, path, status code, duration
+- Authentication events: login success/failure
+- Database errors and slow queries (over 100ms)
+- External API calls: endpoint, status, duration
+- Business events: user signup, payment processed
+
+### What NOT to Log
+- Passwords, tokens, API keys, or secrets
+- Full request/response bodies (PII risk)
+- Health check requests (too noisy)
+
+## Request Logging Middleware
+```typescript
+function requestLogger(handler: Handler): Handler {
+  return async (req) => {
+    const start = performance.now();
+    const path = new URL(req.url).pathname;
+    try {
+      const response = await handler(req);
+      if (path !== "/health") {
+        log("info", "request", { method: req.method, path, status: response.status, durationMs: Math.round(performance.now() - start) });
+      }
+      return response;
+    } catch (err) {
+      log("error", "request_error", { method: req.method, path, error: (err as Error).message });
+      throw err;
+    }
+  };
+}
+```
+
+## Error Tracking
+
+```typescript
+process.on("uncaughtException", (err) => {
+  log("error", "Uncaught exception", { error: err.message, stack: err.stack });
+  process.exit(1);
+});
+
+process.on("unhandledRejection", (reason) => {
+  log("error", "Unhandled rejection", { reason: String(reason) });
+});
+```
+
+### Sentry Integration
+```typescript
+import * as Sentry from "@sentry/bun";
+Sentry.init({
+  dsn: process.env.SENTRY_DSN,
+  environment: process.env.NODE_ENV,
+  tracesSampleRate: 0.1,
+});
+```
+
+## Uptime Monitoring
+
+External services: UptimeRobot (free: 50 monitors), Better Uptime, Cronitor.
+
+```
+Monitor: HTTPS GET https://myapp.com/health
+Interval: 60s | Timeout: 10s | Alert after: 2 failures
+Alert via: Email, Slack webhook, SMS
+```
+
+## Alerting Rules
+
+| Condition | Severity | Action |
+|-----------|----------|--------|
+| Health check fails 2+ times | Critical | Page on-call |
+| Error rate > 5% in 5 min | High | Slack + email |
+| Response time p95 > 2s | Medium | Slack |
+| Disk usage > 85% | Medium | Slack |
+| SSL cert expires < 14 days | Low | Email |
+| Database backup failed | High | Slack + email |
+
+## Rules
+
+- Every application must have a `/health` endpoint
+- All logs must be structured JSON
+- Never log secrets, tokens, or PII
+- Alert on symptoms (error rate, latency) not causes
+- Every alert must have a clear action
+- Set up monitoring BEFORE going to production
+
+## Verification
+
+1. Health endpoint returns 200 with dependency status
+2. Request logs appear in structured JSON format
+3. Intentionally cause an error and verify it's logged
+4. Kill the database and verify health returns 503
+5. Uptime monitor detects downtime
+6. Alert notification reaches the configured channel
+
+## Integration with Other Skills
+
+- **server-management:** Add monitoring after server setup
+- **docker-deployment:** Health checks integrate with Docker HEALTHCHECK
+- **ci-cd-pipelines:** Run health check after deploy to verify success

package/skills/builtin/negotiation-simulator/SKILL.md

@@ -0,0 +1,24 @@
+# Negotiation Simulator
+## Architecture
+- **Buyer Agent**: negotiates for lowest price, has a maximum budget (hidden from seller)
+- **Seller Agent**: negotiates for highest price, has a minimum acceptable price (hidden from buyer)
+- **Orchestrator**: manages rounds, enforces rules, detects agreement or deadlock
+
+## Round Structure
+```typescript
+interface NegotiationRound {
+  roundNumber: number;
+  buyerOffer: number | null;
+  sellerAsk: number | null;
+  buyerReasoning: string;
+  sellerReasoning: string;
+  status: "ongoing" | "accepted" | "rejected" | "deadlock";
+}
+```
+
+## Rules
+- Maximum 10 rounds before deadlock
+- Each round: buyer makes offer, seller responds with counter or accept
+- Neither agent reveals their limit
+- Orchestrator reports final outcome with analysis of negotiation dynamics
+- BATNA (Best Alternative To Negotiated Agreement) considered by both sides

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

@@ -0,0 +1,56 @@
+---
+name: nestjs-development
+description: "Use this skill when building with NestJS. Triggers: 'NestJS', 'nest.js', 'decorator', 'module', 'injectable', 'guard', 'interceptor', or any NestJS request. Always fetch Context7 docs first."
+license: MIT
+---
+
+# NestJS Development
+
+## Before You Start
+
+**Context7:** Fetch current NestJS docs before generating code.
+
+## Core Architecture
+
+```
+src/
+├── app.module.ts           # Root module
+├── main.ts                 # Bootstrap
+├── users/
+│   ├── users.module.ts     # Feature module
+│   ├── users.controller.ts # HTTP layer
+│   ├── users.service.ts    # Business logic
+│   ├── dto/                # Data transfer objects
+│   └── entities/           # Database entities
+```
+
+## Pattern
+
+```typescript
+@Module({
+  imports: [TypeOrmModule.forFeature([User])],
+  controllers: [UsersController],
+  providers: [UsersService],
+  exports: [UsersService],
+})
+export class UsersModule {}
+
+@Controller("users")
+export class UsersController {
+  constructor(private readonly usersService: UsersService) {}
+
+  @Get()
+  findAll() { return this.usersService.findAll(); }
+
+  @Post()
+  create(@Body() dto: CreateUserDto) { return this.usersService.create(dto); }
+}
+```
+
+## Rules
+
+- One module per feature domain
+- Controllers handle HTTP, services handle business logic
+- Use DTOs with class-validator for input validation
+- Use Guards for auth, Interceptors for transforms, Pipes for validation
+- Fetch Context7 docs for the specific NestJS version

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

@@ -0,0 +1,55 @@
+---
+name: nextjs-development
+description: "Use this skill when building with Next.js. Triggers: 'Next.js', 'next.js', 'app router', 'server component', 'SSR', 'SSG', 'ISR', or any Next.js request. Always fetch Context7 docs first as the API changes significantly between versions."
+license: MIT
+---
+
+# Next.js Development
+
+## Before You Start
+
+**Context7:** MANDATORY. Next.js changes significantly between versions. Always fetch current docs before writing any Next.js code.
+
+## App Router Basics
+
+```
+app/
+├── layout.tsx          # Root layout (wraps all pages)
+├── page.tsx            # Home page (/)
+├── loading.tsx         # Loading UI
+├── error.tsx           # Error boundary
+├── not-found.tsx       # 404 page
+├── api/
+│   └── route.ts        # API route handler
+└── dashboard/
+    ├── layout.tsx      # Dashboard layout
+    └── page.tsx        # Dashboard page (/dashboard)
+```
+
+## Server vs Client Components
+
+Server Components (default): fetch data, access backend, no interactivity
+Client Components (`"use client"`): event handlers, hooks, browser APIs
+
+```tsx
+// Server Component (default)
+export default async function Page() {
+  const data = await fetch("https://api.example.com/data");
+  return <div>{/* render data */}</div>;
+}
+
+// Client Component
+"use client";
+export default function Counter() {
+  const [count, setCount] = useState(0);
+  return <button onClick={() => setCount(c => c + 1)}>{count}</button>;
+}
+```
+
+## Rules
+
+- Default to Server Components. Only add "use client" when needed.
+- Fetch Context7 docs for the specific Next.js version
+- Use Route Handlers (app/api/) for API endpoints
+- Use Server Actions for form handling and mutations
+- Test both dev and production builds (behavior can differ)

package/skills/builtin/parallel-dispatch/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: parallel-dispatch
+description: "Use this skill when multiple independent tasks can be worked on simultaneously. Triggers: 'parallel', 'simultaneously', 'at the same time', 'fan out', or when 2+ tasks have no dependencies on each other's output."
+license: MIT
+---
+
+# Parallel Dispatch
+
+## What This Skill Does
+
+Fan out independent work to parallel agents, then consolidate results. Use when tasks have no output dependencies between them.
+
+## When to Parallelize
+
+- Frontend + backend + tests (no shared output)
+- Multiple independent research queries
+- Linting + type checking + testing (separate concerns)
+- Generating multiple documents or assets
+
+## When to Serialize
+
+- Research -> implementation (output informs next step)
+- Schema design -> migration -> API routes (sequential dependency)
+- Any chain where step N needs step N-1's output
+
+## Pattern
+
+```
+1. Identify independent tasks
+2. Write focused prompt for each (self-contained, no shared context)
+3. Dispatch all simultaneously
+4. Collect results
+5. Consolidate: synthesize parallel results into unified output
+6. Resolve conflicts between parallel outputs
+```
+
+## Rules
+
+- Each parallel agent gets a self-contained prompt with all context it needs
+- Never share mutable state between parallel agents
+- Always have a consolidation step that synthesizes results
+- If tasks turn out to have dependencies discovered during execution, switch to sequential
+
+## Ensemble Decision (Cognitive Diversity)
+
+For high-stakes decisions, create 3+ agents with genuinely different perspectives:
+- Each gets the same problem but a different analytical lens (optimist vs pessimist, technical vs business, short-term vs long-term)
+- Each produces an independent analysis
+- An aggregator agent synthesizes all outputs, noting consensus and disagreement
+- Final recommendation weighted by the quality of each agent's reasoning
+
+Works for: architecture decisions, investment analysis, risk assessment, strategic planning.
+
+## Mixture of Agents
+
+For factual/research queries, route the same question to multiple LLM providers simultaneously. Synthesize independent results. Higher accuracy than any single model when the question has a definitive answer.
+
+## LLM Map-Reduce (Sandboxed Batch Processing)
+
+For processing large document batches where each document is untrusted:
+
+### Map Phase
+```
+Documents[] → fan out → [Agent per document] → partial results[]
+```
+- Each agent runs in a sandboxed context (no cross-document state)
+- Each agent processes one document and returns structured output
+- Untrusted documents are wrapped with content boundaries (see content-wrapper skill)
+
+### Reduce Phase
+```
+partial results[] → Aggregator Agent → final output
+```
+- Aggregator synthesizes all partial results
+- Resolves conflicts between documents
+- Produces unified summary or analysis
+
+### Rules
+- Each map agent gets only its assigned document (no cross-contamination)
+- Map agents have reduced tool access (read-only, no network)
+- Reduce agent validates consistency across partial results
+- Maximum batch size: 50 documents per map-reduce job
+- Failed map tasks are retried once, then marked as failed (not silently dropped)