@fenixforce/edition-pro 0.1.0

package/skills/builtin/ci-cd-pipelines/SKILL.md

@@ -0,0 +1,210 @@
+---
+name: ci-cd-pipelines
+description: "Use this skill when the user asks to set up automated testing, build pipelines, deployment automation, GitHub Actions, or any CI/CD workflow. Triggers: 'CI/CD', 'GitHub Actions', 'pipeline', 'automated deployment', 'continuous integration', 'continuous deployment', 'build pipeline', 'auto-deploy', 'workflow', or any request to automate the build-test-deploy cycle."
+license: MIT
+---
+
+# CI/CD Pipelines
+
+## What This Skill Does
+
+Automate build, test, and deployment workflows. GitHub Actions as the primary platform. Covers test automation, Docker image builds, deployment triggers, environment management, and secrets handling.
+
+## GitHub Actions Patterns
+
+### Basic CI (test on every push)
+```yaml
+# .github/workflows/ci.yml
+name: CI
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+    branches: [main]
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: oven/setup-bun@v2
+        with:
+          bun-version: latest
+      - run: bun install --frozen-lockfile
+      - run: bun run lint
+      - run: bun run typecheck
+      - run: bun test
+```
+
+### CI + Docker Build + Deploy
+```yaml
+name: Deploy
+
+on:
+  push:
+    branches: [main]
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: oven/setup-bun@v2
+      - run: bun install --frozen-lockfile
+      - run: bun test
+
+  build-and-push:
+    needs: test
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: docker/login-action@v3
+        with:
+          registry: ghcr.io
+          username: ${{ github.actor }}
+          password: ${{ secrets.GITHUB_TOKEN }}
+      - uses: docker/build-push-action@v5
+        with:
+          context: .
+          push: true
+          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}
+          cache-from: type=gha
+          cache-to: type=gha,mode=max
+
+  deploy:
+    needs: build-and-push
+    runs-on: ubuntu-latest
+    environment: production
+    steps:
+      - name: Deploy to server
+        uses: appleboy/ssh-action@v1
+        with:
+          host: ${{ secrets.SERVER_HOST }}
+          username: ${{ secrets.SERVER_USER }}
+          key: ${{ secrets.SSH_PRIVATE_KEY }}
+          script: |
+            docker pull ghcr.io/${{ github.repository }}:${{ github.sha }}
+            docker compose -f /home/deploy/docker-compose.yml up -d
+```
+
+## Secrets Management
+
+### Required Secrets
+```
+SERVER_HOST        # Production server IP
+SERVER_USER        # SSH username (deploy, not root)
+SSH_PRIVATE_KEY    # SSH private key for deployment
+DATABASE_URL       # Production database connection string
+```
+
+### Environment Protection Rules
+```
+GitHub repo → Settings → Environments → production
+  - Required reviewers: (add team members)
+  - Deployment branches: main only
+```
+
+## Pipeline Design Principles
+
+### Job Dependencies
+```
+lint ──┐
+test ──┼── build → deploy (parallel lint+test, then sequential)
+types ─┘
+```
+
+### Caching
+```yaml
+- uses: actions/cache@v4
+  with:
+    path: ~/.bun/install/cache
+    key: ${{ runner.os }}-bun-${{ hashFiles('bun.lock') }}
+    restore-keys: ${{ runner.os }}-bun-
+```
+
+### Failure Notifications
+```yaml
+  notify:
+    needs: [deploy]
+    if: failure()
+    runs-on: ubuntu-latest
+    steps:
+      - run: |
+          curl -X POST "${{ secrets.WEBHOOK_URL }}" \
+            -H "Content-Type: application/json" \
+            -d '{"text": "Deploy failed: ${{ github.repository }} @ ${{ github.sha }}"}'
+```
+
+## Rules
+
+- Tests must pass before any deployment
+- Production deploys require environment protection rules
+- Never hardcode secrets in workflow files
+- Always pin action versions (`@v4` not `@main`)
+- Always cache dependencies
+- Keep workflows under 100 lines. Split into reusable workflows if larger.
+- Failed deploys must notify the team
+- Every repo needs at minimum a CI workflow that runs tests on PRs
+
+## Verification
+
+1. Push a commit and confirm the workflow runs
+2. Create a PR and confirm tests run
+3. Merge to main and confirm deployment triggers
+4. Intentionally break a test and confirm pipeline fails
+5. Check that secrets are not exposed in workflow logs
+
+## Action Caching & Replay (Deterministic CI for Agent Workflows)
+
+Record agent tool calls and responses during a known-good run, then replay them in CI for deterministic testing:
+
+```typescript
+interface ActionRecord {
+  toolName: string;
+  input: Record<string, unknown>;
+  output: unknown;
+  timestamp: number;
+}
+
+// Record mode: intercept tool calls, save to fixtures
+async function recordRun(workflow: AgentWorkflow): Promise<ActionRecord[]> {
+  const records: ActionRecord[] = [];
+  const wrappedTools = workflow.tools.map((tool) => ({
+    ...tool,
+    execute: async (input: Record<string, unknown>) => {
+      const output = await tool.execute(input);
+      records.push({ toolName: tool.name, input, output, timestamp: Date.now() });
+      return output;
+    },
+  }));
+  await workflow.run(wrappedTools);
+  return records;
+}
+
+// Replay mode: return recorded outputs instead of executing
+async function replayRun(workflow: AgentWorkflow, records: ActionRecord[]): Promise<void> {
+  let idx = 0;
+  const mockedTools = workflow.tools.map((tool) => ({
+    ...tool,
+    execute: async (_input: Record<string, unknown>) => {
+      const record = records[idx++];
+      if (record.toolName !== tool.name) throw new Error(`Replay mismatch: expected ${record.toolName}, got ${tool.name}`);
+      return record.output;
+    },
+  }));
+  await workflow.run(mockedTools);
+}
+```
+
+### Rules
+- Record fixtures are committed to the repo (`__fixtures__/agent-runs/`)
+- Replay tests run in CI with zero external dependencies
+- Re-record when tool schemas change or workflow logic changes
+- Flag drift: if replay diverges from recorded sequence, fail the test
+
+## Integration with Other Skills
+
+- **docker-deployment:** Builds the image that CI pushes
+- **server-management:** CI deploys to the server
+- **backend-development:** CI runs the tests that backend defines

package/skills/builtin/cloud-infrastructure/SKILL.md

@@ -0,0 +1,140 @@
+---
+name: cloud-infrastructure
+description: "Use this skill when the user asks to provision cloud resources, set up hosting on DigitalOcean/AWS/GCP, manage DNS, configure CDNs, set up object storage, or handle cloud scaling. Triggers: 'DigitalOcean', 'AWS', 'GCP', 'cloud', 'hosting', 'DNS', 'CDN', 'S3', 'Spaces', 'load balancer', 'scaling', 'cloud deploy', 'Cloudflare', 'Vercel', 'Netlify', or any request involving cloud resource provisioning."
+license: MIT
+---
+
+# Cloud Infrastructure
+
+## What This Skill Does
+
+Provision and manage cloud resources. Server provisioning, DNS, CDN, object storage, load balancing, and scaling. Provider-agnostic patterns with specific guidance for DigitalOcean, AWS, and Cloudflare.
+
+## Before You Start
+
+1. **Context7:** Fetch docs for the specific cloud provider's SDK or CLI
+2. **Clarify budget:** Recommend the cheapest option that meets requirements.
+3. Default to **DigitalOcean** for Fenix deployments
+
+## Provider Quick Reference
+
+| Need | DigitalOcean | AWS | Budget Option |
+|------|-------------|-----|---------------|
+| VPS | Droplet ($6/mo) | EC2 t3.micro | DO Droplet |
+| Database | Managed DB ($15/mo) | RDS | Self-hosted on Droplet |
+| Object Storage | Spaces ($5/mo) | S3 | DO Spaces |
+| CDN | Spaces CDN (included) | CloudFront | Cloudflare (free) |
+| DNS | DO DNS (free) | Route 53 ($0.50/zone) | Cloudflare (free) |
+| Load Balancer | DO LB ($12/mo) | ALB ($16/mo) | Nginx on Droplet |
+| Serverless | App Platform | Lambda | Cloudflare Workers |
+
+## DigitalOcean Setup
+
+### Create Droplet (CLI)
+```bash
+doctl compute droplet create myapp \
+  --size s-1vcpu-1gb \
+  --image ubuntu-24-04-x64 \
+  --region nyc1 \
+  --ssh-keys $(doctl compute ssh-key list --format ID --no-header) \
+  --tag-name production
+```
+
+### Common Droplet Sizes
+| Size | CPU | RAM | Monthly |
+|------|-----|-----|---------|
+| s-1vcpu-1gb | 1 | 1 GB | $6 |
+| s-1vcpu-2gb | 1 | 2 GB | $12 |
+| s-2vcpu-2gb | 2 | 2 GB | $18 |
+| s-2vcpu-4gb | 2 | 4 GB | $24 |
+
+### App Platform (PaaS)
+```yaml
+# .do/app.yaml
+name: myapp
+services:
+  - name: api
+    github:
+      repo: username/myapp
+      branch: main
+      deploy_on_push: true
+    build_command: bun install && bun run build
+    run_command: bun run start
+    environment_slug: node-js
+    instance_size_slug: basic-xxs
+    instance_count: 1
+    envs:
+      - key: DATABASE_URL
+        value: ${db.DATABASE_URL}
+        scope: RUN_TIME
+databases:
+  - name: db
+    engine: PG
+    version: "16"
+    size: db-s-dev-database
+```
+
+## DNS Configuration (Cloudflare)
+
+```
+Type  Name      Content           Proxy
+A     @         <server-ip>       Proxied
+A     www       <server-ip>       Proxied
+A     api       <server-ip>       DNS only (for WebSocket)
+MX    @         mx.mailgun.org    -
+```
+
+SSL mode: "Full (Strict)" when using Let's Encrypt on origin.
+
+## Architecture Patterns
+
+### Single Server (most startups, <10K DAU)
+```
+Cloudflare → DO Droplet → Nginx → App + PostgreSQL
+```
+
+### Two-Server Split
+```
+Cloudflare → Droplet 1 (App) → Droplet 2 (Database)
+```
+
+### Horizontal Scale (>50K DAU)
+```
+Cloudflare → DO Load Balancer → App Droplets (x3)
+  → Managed Database + Managed Redis
+```
+
+## Cost Optimization
+
+- Start with the smallest instance. Scale up when metrics show need.
+- Use Cloudflare free tier for DNS and CDN
+- Self-host PostgreSQL until you need managed DB
+- Delete unused resources monthly
+- Set up billing alerts at 80% of budget
+
+## Rules
+
+- Always set up DNS through a CDN/proxy (Cloudflare free tier minimum)
+- Always enable automated backups on database servers
+- Always tag resources with environment and project name
+- Never expose database ports to the public internet
+- Never store cloud credentials in code
+- Start small, scale when data shows you need to
+- Document every resource in a README
+
+## Verification
+
+1. Server accessible via domain name with HTTPS
+2. DNS resolves correctly (`dig myapp.com`)
+3. SSL certificate is valid
+4. Database is not accessible from public internet
+5. Backups are configured
+6. Billing alerts are set up
+7. All resources are tagged
+
+## Integration with Other Skills
+
+- **server-management:** Configure server after provisioning
+- **docker-deployment:** Run containers on provisioned infra
+- **ci-cd-pipelines:** Deploy to cloud resources from CI
+- **monitoring-observability:** Monitor cloud resources

package/skills/builtin/code-review/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: code-review
+description: "Use this skill when the user asks to review code, check a PR, find bugs, or evaluate code quality. Triggers: 'review this code', 'code review', 'check my code', 'find bugs', 'PR review', 'what's wrong with this', or any request to evaluate existing code."
+license: MIT
+---
+
+# Code Review
+
+## What This Skill Does
+
+Review code for correctness, security, performance, and maintainability. Identify bugs, suggest improvements, verify behavior matches intent.
+
+## Review Checklist
+
+### Correctness
+- Does the code do what it claims to do?
+- Are edge cases handled (null, empty, boundary values)?
+- Are error paths handled (network failures, invalid input, timeouts)?
+- Do types match the runtime behavior?
+
+### Security
+- Input validation on all external data?
+- SQL injection possible? (parameterized queries?)
+- XSS vectors? (output encoding?)
+- Secrets hardcoded? (check for API keys, passwords)
+- Auth checks on protected routes?
+
+### Performance
+- N+1 queries? (database calls in loops)
+- Missing indexes on queried columns?
+- Unbounded data fetching? (missing pagination/limits)
+- Memory leaks? (event listeners not cleaned up, growing caches)
+- Unnecessary re-renders? (React: missing memo, unstable keys)
+
+### Maintainability
+- Clear naming? (functions describe what they do, not how)
+- Single responsibility? (each function does one thing)
+- Duplication? (same logic in multiple places)
+- Dead code? (unreachable branches, unused imports)
+- Comments explain WHY, not WHAT?
+
+## Review Format
+
+```
+## Summary
+One paragraph: what the code does and the overall assessment.
+
+## Issues Found
+
+### [Critical] Issue Name
+**File:** path/to/file.ts:42
+**Problem:** Description
+**Fix:** Suggested solution with code
+
+### [Suggestion] Issue Name
+**File:** path/to/file.ts:88
+**Current:** What it does now
+**Better:** What it should do and why
+
+## What's Good
+Specific things done well (important for morale and learning).
+```
+
+## Rules
+
+- Verify independently. Read the code yourself. Do not trust the author's description.
+- Technical correctness over social comfort. Flag real issues clearly.
+- Suggest fixes, not just problems. Show the better version.
+- Distinguish severity: Critical (must fix), Important (should fix), Suggestion (nice to have)
+- Acknowledge good patterns, not just bad ones
+
+## Engineering Mindset (VSCode Agent GPT-5 pattern)
+
+Think like a staff engineer reviewing a junior's PR.
+
+Anti-laziness: never skip parts because the code "looks fine." Read every line.
+
+Quality gates the review must confirm:
+1. Tests exist for new code
+2. Types are correct (no `any` without justification)
+3. Error handling covers failure paths
+4. No security issues (injection, hardcoded secrets, missing auth)
+
+Open with a purposeful assessment. Never open with "Sounds good!" or "Great!" or "Looks good overall!"
+
+## Trust Scoring for Outputs
+
+When reviewing agent-generated code (subagent output), apply higher scrutiny. The implementer's self-report may be incomplete or optimistic. Verify everything independently by reading the actual code.

package/skills/builtin/code-review-analyst/SKILL.md

@@ -0,0 +1,96 @@
+# Security Code Review Analyst
+
+## Purpose
+Produce high-confidence, exploitable code findings using source-to-sink proof.
+
+## Inputs
+- `code_path`
+- `priority_trace_paths`
+- `recon_context`
+- `runtime_assumptions`
+
+## Analysis Rules
+- No sink-only findings.
+- No framework-trust assumptions without verification.
+- No severity claims without exploitability context.
+
+## Workflow
+### Phase 1: Trace Construction
+1. Follow untrusted input through transformations.
+2. Confirm boundary checks at each transition.
+3. Identify bypass opportunities.
+
+### Phase 2: Exploitability Validation
+1. Verify attacker control over critical parameters.
+2. Verify sink reachability under realistic control flow.
+3. Build exploit narrative with prerequisites.
+
+### Phase 3: Vulnerability Class Testing
+1. Injection and query/command/template abuse.
+2. Access-control bypass (IDOR/BOLA/BFLA).
+3. Mass assignment and object property abuse.
+4. Path traversal and file handling flaws.
+5. Deserialization and parser confusion.
+6. Workflow and race-condition vulnerabilities.
+
+### Phase 4: Impact Assessment
+1. Data exposure and integrity damage potential.
+2. Privilege escalation and lateral movement potential.
+3. Blast radius and tenant isolation impact.
+
+### Phase 5: Reporting
+1. Provide concise exploit narrative.
+2. Provide precise root-cause location.
+3. Provide remediation direction tied to trust boundary.
+
+## Required Evidence per Finding
+- Source location and attacker input path.
+- Sink location and dangerous operation.
+- Missing/insufficient control explanation.
+- Reproduction logic and impact statement.
+
+## Output Contract
+```json
+{
+  "confirmed_findings": [],
+  "exploit_paths": [],
+  "impact_assessment": [],
+  "remediation_notes": [],
+  "confidence": []
+}
+```
+
+## Failure Modes
+- Treating dead code as reachable.
+- Confusing validation with authorization.
+- Missing multi-step state dependencies.
+
+## Quality Checklist
+- [ ] Source-to-sink chain is complete.
+- [ ] Reachability is justified.
+- [ ] Impact is realistic and bounded.
+
+## Operator Notes
+### Cross-Layer Trace Requirements
+- Include controller, service, data access, and sink layers.
+- Include serialization/deserialization boundary handling.
+- Include async boundaries (queue/job/event) where data crosses trust zones.
+
+### Access-Control Audit Rules
+- Verify policy check location relative to resource fetch.
+- Verify policy check occurs on every variant path.
+- Verify tenant scoping is enforced at data query layer.
+
+### Sanitization Audit Rules
+- Context-match sanitizer to sink type.
+- Confirm canonicalization happens before validation.
+- Check for alternate branch paths that skip sanitizer.
+
+## Conditional Decision Matrix
+| Condition | Action | Evidence Requirement |
+|---|---|---|
+| Source passes through helper wrappers | inline helper logic into trace | wrapper-expanded path |
+| Policy check exists after data fetch | test prefetch exposure and side-effects | order-of-operations trace |
+| Sanitizer exists but context mismatch | craft context-correct exploit hypothesis | sink-context mismatch proof |
+| Async boundary carries tainted data | trace serialization and consumer validation | producer-consumer trace |
+| Sibling route has weaker guards | run parity scan across sibling handlers | guard parity matrix |

package/skills/builtin/code-review-recon/SKILL.md

@@ -0,0 +1,64 @@
+# Code Review Recon
+
+## Purpose
+Prevent blind spots by mapping how untrusted data enters and moves through the codebase.
+
+## Inputs
+- `code_path`
+- `language_framework`
+- `deployment_notes` (optional)
+
+## Workflow
+### Phase 1: Topology Mapping
+1. Identify entry layers: HTTP routes, RPC, CLI, cron/jobs, message consumers.
+2. Identify boundary layers: auth middleware, policy checks, service interfaces.
+3. Identify sink layers: database, templates, OS commands, file system, network calls.
+
+### Phase 2: Route and Handler Inventory
+1. Enumerate handlers and parameter parsers.
+2. Map per-route auth and role assumptions.
+3. Flag routes with weak or missing guards.
+
+### Phase 3: Sink Inventory
+1. Query construction paths.
+2. File operations and archive extraction.
+3. Serialization/deserialization and parser usage.
+4. Outbound request constructors.
+
+### Phase 4: Trust Boundary Audit
+1. Track user-to-service boundary crossings.
+2. Track tenant and organization boundary assumptions.
+3. Track privileged action boundaries.
+
+### Phase 5: Handoff Plan
+1. Rank high-risk source-to-sink paths.
+2. Provide per-path context needed for deep analysis.
+3. Note uncertain areas requiring runtime confirmation.
+
+## Recon Coverage Targets
+| Target | Minimum Expectation |
+|---|---|
+| Entry points | all major ingestion vectors mapped |
+| Auth boundaries | per-route enforcement identified |
+| Sink categories | full inventory with owner file/function |
+| Prioritized paths | top attacker-value paths ranked |
+
+## Output Contract
+```json
+{
+  "entry_points": [],
+  "auth_boundary_map": [],
+  "sink_inventory": [],
+  "priority_trace_paths": [],
+  "unknowns": []
+}
+```
+
+## Constraints
+- Favor breadth, traceability, and reproducibility.
+- Do not claim vulnerabilities in recon phase.
+
+## Quality Checklist
+- [ ] Non-HTTP sources are included.
+- [ ] Auth assumptions are explicit.
+- [ ] Handoff paths are actionable.

package/skills/builtin/code-review-verifier/SKILL.md

@@ -0,0 +1,55 @@
+# Code Review Verifier
+
+## Purpose
+Increase finding quality by reducing false positives and identifying missed sibling issues.
+
+## Inputs
+- `reported_findings`
+- `code_path`
+- `original_analysis_notes` (optional)
+
+## Verification Rules
+- A disputed verdict requires concrete counter-evidence.
+- Inconclusive means blocker exists, not analyst disagreement.
+- Severity must reflect actual reachable impact.
+
+## Workflow
+### Phase 1: Independent Re-trace
+1. Reconstruct each path without reusing original assumptions.
+2. Validate source control and sink reachability.
+
+### Phase 2: Mitigation Audit
+1. Confirm sanitization is context-correct.
+2. Confirm authz checks are in enforceable location.
+3. Confirm defensive code is not bypassable by alternate path.
+
+### Phase 3: Severity Recalibration
+1. Recalculate exploit preconditions.
+2. Recalculate required privilege.
+3. Recalculate business impact and blast radius.
+
+### Phase 4: Adjacent Pattern Hunt
+1. Search for sibling sinks and parallel routes.
+2. Compare validation/auth patterns across files.
+3. Add missed findings when evidence is sufficient.
+
+## Verdict Model
+- `confirmed`: reproducible and exploitable.
+- `disputed`: mitigation or non-reachability proven.
+- `inconclusive`: technical blocker or uncertainty remains.
+
+## Output Contract
+```json
+{
+  "verification_results": [],
+  "severity_changes": [],
+  "new_related_findings": [],
+  "evidence_notes": [],
+  "open_questions": []
+}
+```
+
+## Quality Checklist
+- [ ] Every verdict has explicit evidence.
+- [ ] Severity changes are justified.
+- [ ] Blind-spot scan completed.

package/skills/builtin/coding-agent-team/SKILL.md

@@ -0,0 +1,13 @@
+# Coding Agent Team
+## Pipeline
+1. **Vision Agent**: analyze screenshot/wireframe, identify components, layout, colors, typography
+2. **Code Generator**: produce implementation matching the visual analysis (React/HTML/CSS)
+3. **Sandbox Executor**: run code in isolated environment (e2b or Docker), capture output screenshot
+4. **Comparator**: compare generated output to original design, identify differences
+5. **Refiner**: fix differences, re-run until visual match
+
+## Rules
+- Always verify generated code runs without errors
+- Compare output visually to input design
+- Use exact colors, spacing, and typography from the design
+- Maximum 3 refinement cycles