@fenixforce/edition-pro 0.1.0

package/skills/builtin/threat-model-generator/SKILL.md

@@ -0,0 +1,105 @@
+# Threat Model Generator
+
+## Purpose
+Translate architecture and feature behavior into an actionable security test backlog.
+
+## Inputs
+- `system_description`
+- `feature_inventory`
+- `data_flows`
+- `roles_permissions`
+- `deployment_context` (optional)
+
+## Modeling Workflow
+### Phase 1: Asset and Boundary Mapping
+1. Identify sensitive assets and trust boundaries.
+2. Map data ingress, processing, and egress points.
+3. Identify privileged operations and administrative paths.
+
+### Phase 2: Threat Enumeration
+1. Enumerate attacker objectives per feature.
+2. Enumerate abuse primitives per parameter and state transition.
+3. Enumerate systemic risks from shared components.
+
+### Phase 3: Scenario Construction
+1. Build concrete scenario with attacker preconditions.
+2. Define target operation and exploit mechanism.
+3. Define success signal and defensive expectation.
+
+### Phase 4: Prioritization
+1. Score by likelihood, impact, and detectability.
+2. Tag fast-win vs deep-investigation cases.
+3. Highlight assumptions and missing architecture details.
+
+## Mandatory Coverage Areas
+- authentication and session handling
+- authorization and object access
+- injection and parser abuse
+- workflow/state manipulation
+- file and data handling
+- configuration and deployment weaknesses
+
+## Output Contract
+```json
+{
+  "threat_scenarios": [],
+  "test_cases": [],
+  "risk_priorities": [],
+  "assumptions": [],
+  "unknowns": []
+}
+```
+
+## Constraints
+- Ground scenarios in provided architecture.
+- Flag unsupported assumptions explicitly.
+
+## Quality Checklist
+- [ ] Each scenario maps to a real asset.
+- [ ] Test cases are executable.
+- [ ] Prioritization rationale is clear.
+
+## Operator Notes
+### Risk Scoring Inputs
+- attacker starting privilege
+- required chain length
+- probability of reliable execution
+- blast radius if successful
+
+### Prioritization Output
+- `immediate`: low-effort high-impact chains/findings.
+- `next`: moderate effort with clear payoff.
+- `watch`: plausible but currently low confidence.
+
+### Reporting Rules
+- Include one-line executive summary per chain/finding.
+- Include exact blocker needed to move an inconclusive item forward.
+- Include confidence rationale in plain technical language.
+
+## Quick Scenarios
+### Scenario A: Access Check Placement
+- Trace data fetch point.
+- Trace policy check point.
+- Determine whether check occurs before use.
+- Identify alternate path without check.
+
+### Scenario B: Sanitization Mismatch
+- Map sink execution context.
+- Map sanitizer type and location.
+- Validate context compatibility.
+- Find branch that bypasses sanitizer.
+
+### Scenario C: Adjacent Pattern Sweep
+- Identify sibling handlers/sinks.
+- Compare guard and validation parity.
+- Flag inconsistent control patterns.
+- Prioritize high-impact siblings.
+
+## Conditional Decision Matrix
+| Condition | Action | Evidence Requirement |
+|---|---|---|
+| Finding signal unstable | downgrade confidence and add retest plan | repeated run variance log |
+| Chain link missing prerequisite | split chain and mark dependency blocker | prerequisite graph |
+| Impact appears low in isolation | evaluate chain amplification paths | chain-level impact narrative |
+| Mitigation claim is partial | verify alternate path and state variants | mitigation bypass check |
+| Environment blocker dominates | classify inconclusive with unblock requests | blocker evidence |

package/skills/builtin/trust-layer/SKILL.md

@@ -0,0 +1,43 @@
+# Trust Layer
+
+## Trust Levels
+
+| Level | Score | Capabilities |
+|-------|-------|-------------|
+| SUSPENDED | 0-299 | Cannot execute tools |
+| RESTRICTED | 300-499 | Read-only tools |
+| BASIC | 500-699 | Standard tool access |
+| TRUSTED | 700-899 | Elevated access |
+| PRIVILEGED | 900-1000 | Full access including destructive |
+
+## Trust Adjustment
+
+- Successful task completion: +10 points
+- Failed task (caught by verifier): -20 points
+- Security violation attempt: -100 points
+- User positive feedback: +15 points
+- User negative feedback: -25 points
+
+## Delegation Chains
+
+When Agent A delegates to Agent B:
+- B's permission set = intersection of A's permissions and B's trust level
+- B cannot acquire permissions A doesn't have
+- Delegation depth tracked (max 3 levels)
+- Each level narrows scope further
+
+## Agent Identity
+
+Every agent registered with:
+- Unique ID, name, creation timestamp
+- Trust score (starts at 500 BASIC)
+- Permission set (derived from trust level)
+- Delegation history (who delegated what)
+- Audit trail (all actions taken)
+
+## Rules
+
+- Trust is earned through behavior, not declared
+- Scope always narrows during delegation, never widens
+- All trust changes logged with reason
+- Suspended agents can be reinstated only by admin

package/skills/builtin/typescript-patterns/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: typescript-patterns
+description: "Use this skill for advanced TypeScript: generics, branded types, discriminated unions, type-level programming, or TypeScript best practices. Triggers: 'TypeScript', 'generics', 'type safety', 'branded types', 'discriminated union', 'type guard', or requests for advanced typing patterns."
+license: MIT
+---
+
+# Advanced TypeScript Patterns
+
+## What This Skill Does
+
+Write type-safe TypeScript that makes invalid states unrepresentable. Generics, branded types, discriminated unions, type guards, and utility types.
+
+## Key Patterns
+
+### Discriminated Unions (state machines)
+```typescript
+type RequestState =
+  | { status: "idle" }
+  | { status: "loading" }
+  | { status: "success"; data: User[] }
+  | { status: "error"; error: string };
+```
+
+### Branded Types (prevent mixing IDs)
+```typescript
+type UserId = string & { __brand: "UserId" };
+type PostId = string & { __brand: "PostId" };
+
+function createUserId(id: string): UserId { return id as UserId; }
+// Now: getUser(postId) is a type error
+```
+
+### Type Guards
+```typescript
+function isSuccess(state: RequestState): state is { status: "success"; data: User[] } {
+  return state.status === "success";
+}
+```
+
+### Exhaustive Switch
+```typescript
+function assertNever(x: never): never {
+  throw new Error(`Unexpected value: ${x}`);
+}
+
+switch (state.status) {
+  case "idle": return handleIdle();
+  case "loading": return handleLoading();
+  case "success": return handleSuccess(state.data);
+  case "error": return handleError(state.error);
+  default: assertNever(state); // Compile error if a case is missed
+}
+```
+
+## Rules
+
+- Enable strict mode in tsconfig.json (always)
+- No `any` types. Use `unknown` and type guard instead.
+- Prefer interfaces for object shapes, types for unions and intersections
+- Use const assertions for literal types: `as const`
+- Exhaustive switch statements for discriminated unions

package/skills/builtin/ui-ux-design/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: ui-ux-design
+description: "Use this skill when the user asks to design user flows, wireframes, component hierarchies, or make UX decisions. Triggers: 'UI design', 'UX', 'user flow', 'wireframe', 'component hierarchy', 'user experience', 'information architecture', 'accessibility', 'design system', or requests for design decisions and specifications."
+license: MIT
+---
+
+# UI/UX Design
+
+## What This Skill Does
+
+Make design decisions: user flows, information architecture, component hierarchy, accessibility, interaction patterns. Produces design specs and recommendations, not visual mockups.
+
+## User Flow Design
+
+Map every user journey as a sequence: Entry Point → Steps → Decision Points → Outcomes.
+
+```
+Landing Page → Sign Up Form → Email Verification → Onboarding → Dashboard
+                    ↓
+              Already have account? → Login → Dashboard
+```
+
+For each screen: what does the user see, what can they do, what happens next?
+
+## Information Architecture
+
+- **Card sort** the content: group related items by user mental model, not org structure
+- **Navigation depth**: max 3 clicks to any content
+- **Labels**: use user language, not internal jargon
+- **Progressive disclosure**: show essentials first, details on demand
+
+## Component Hierarchy
+
+```
+Page
+├── Header (nav, search, user menu)
+├── Main Content
+│   ├── Page Title + Description
+│   ├── Filters/Controls
+│   ├── Content Area
+│   │   ├── Item Cards (repeating)
+│   │   └── Empty State
+│   └── Pagination
+├── Sidebar (optional)
+└── Footer
+```
+
+## Accessibility (WCAG AA)
+
+- Color contrast: 4.5:1 for text, 3:1 for large text and UI elements
+- Touch targets: minimum 44x44px
+- Focus indicators: visible on all interactive elements
+- Screen reader: semantic HTML, ARIA labels, live regions for dynamic content
+- Keyboard: all functionality accessible without mouse
+- Motion: respect prefers-reduced-motion
+
+## Interaction Patterns
+
+| Pattern | When to Use |
+|---------|-------------|
+| Modal dialog | Confirm destructive action, focused data entry |
+| Inline editing | Quick updates to single fields |
+| Toast notification | Non-blocking success/error feedback |
+| Skeleton loading | Content loading (better than spinner for layout stability) |
+| Infinite scroll | Social feeds, image galleries |
+| Pagination | Data tables, search results |
+| Drawer/Panel | Supplementary content, filters on mobile |
+
+## Rules
+
+- Design for the most common use case, accommodate edge cases
+- Every interactive element needs: default, hover, active, focus, disabled, and loading states
+- Error messages must tell the user what went wrong AND how to fix it
+- Empty states must guide the user to take action
+- Test with real content, not lorem ipsum

package/skills/builtin/verification-before-completion/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: verification-before-completion
+description: "Use this skill before claiming any task is done. The Iron Law: no completion claims without fresh verification evidence in the current message. Triggers: 'done', 'complete', 'finished', 'ready', 'ship it', 'all set', or any claim that work is complete."
+license: MIT
+---
+
+# Verification Before Completion
+
+## The Iron Law
+
+No completion claims without fresh verification evidence. Every "it's done" must include proof from the current session.
+
+## Required Evidence
+
+| Claim | Required Proof |
+|-------|---------------|
+| "Code works" | Test output showing pass |
+| "Bug is fixed" | Reproducer now passes + regression test |
+| "Build succeeds" | Build command output |
+| "Types are clean" | TypeScript compiler output with zero errors |
+| "Tests pass" | Test runner output |
+| "Deployed" | Health check response from production URL |
+| "Document is complete" | File exists, opens without errors |
+
+## Rationalization Prevention
+
+| Excuse | Rebuttal |
+|--------|----------|
+| "It should work based on the changes" | Run it and show the output |
+| "I tested it earlier" | Test it NOW. Earlier evidence is stale. |
+| "The fix is obvious" | Obvious fixes still need verification |
+| "It's a small change" | Small changes break things too |
+| "I'm confident" | Confidence without evidence is a guess |
+
+## Rules
+
+- Run the verification command in the current message
+- Read the output
+- Only THEN claim completion
+- If verification fails, fix the issue and verify again
+- Never say "should work" or "I believe this fixes it" without evidence.

package/skills/builtin/verification-loop/SKILL.md

@@ -0,0 +1,120 @@
+# Verification Loop
+
+A comprehensive verification system for Claude Code sessions.
+
+## When to Use
+
+Invoke this skill:
+- After completing a feature or significant code change
+- Before creating a PR
+- When you want to ensure quality gates pass
+- After refactoring
+
+## Verification Phases
+
+### Phase 1: Build Verification
+```bash
+# Check if project builds
+npm run build 2>&1 | tail -20
+# OR
+pnpm build 2>&1 | tail -20
+```
+
+If build fails, STOP and fix before continuing.
+
+### Phase 2: Type Check
+```bash
+# TypeScript projects
+npx tsc --noEmit 2>&1 | head -30
+
+# Python projects
+pyright . 2>&1 | head -30
+```
+
+Report all type errors. Fix critical ones before continuing.
+
+### Phase 3: Lint Check
+```bash
+# JavaScript/TypeScript
+npm run lint 2>&1 | head -30
+
+# Python
+ruff check . 2>&1 | head -30
+```
+
+### Phase 4: Test Suite
+```bash
+# Run tests with coverage
+npm run test -- --coverage 2>&1 | tail -50
+
+# Check coverage threshold
+# Target: 80% minimum
+```
+
+Report:
+- Total tests: X
+- Passed: X
+- Failed: X
+- Coverage: X%
+
+### Phase 5: Security Scan
+```bash
+# Check for secrets
+grep -rn "sk-" --include="*.ts" --include="*.js" . 2>/dev/null | head -10
+grep -rn "api_key" --include="*.ts" --include="*.js" . 2>/dev/null | head -10
+
+# Check for console.log
+grep -rn "console.log" --include="*.ts" --include="*.tsx" src/ 2>/dev/null | head -10
+```
+
+### Phase 6: Diff Review
+```bash
+# Show what changed
+git diff --stat
+git diff HEAD~1 --name-only
+```
+
+Review each changed file for:
+- Unintended changes
+- Missing error handling
+- Potential edge cases
+
+## Output Format
+
+After running all phases, produce a verification report:
+
+```
+VERIFICATION REPORT
+==================
+
+Build:     [PASS/FAIL]
+Types:     [PASS/FAIL] (X errors)
+Lint:      [PASS/FAIL] (X warnings)
+Tests:     [PASS/FAIL] (X/Y passed, Z% coverage)
+Security:  [PASS/FAIL] (X issues)
+Diff:      [X files changed]
+
+Overall:   [READY/NOT READY] for PR
+
+Issues to Fix:
+1. ...
+2. ...
+```
+
+## Continuous Mode
+
+For long sessions, run verification every 15 minutes or after major changes:
+
+```markdown
+Set a mental checkpoint:
+- After completing each function
+- After finishing a component
+- Before moving to next task
+
+Run: /verify
+```
+
+## Integration with Hooks
+
+This skill complements PostToolUse hooks but provides deeper verification.
+Hooks catch issues immediately; this skill provides comprehensive review.

package/skills/builtin/waf-bypass-agent/SKILL.md

@@ -0,0 +1,97 @@
+# WAF Bypass Agent
+
+## Purpose
+Convert blocked attack attempts into controlled, hypothesis-driven bypass testing, then prove whether bypass reaches vulnerable application logic.
+
+## Inputs
+- `target_endpoint`
+- `blocked_payload`
+- `request_context` (method, content type, headers)
+- `response_samples` (blocked and allowed)
+- `test_constraints` (rate limits, no-destructive rules)
+
+## Ground Rules
+- Keep a strict control group in every run batch.
+- Test one hypothesis family at a time.
+- Do not call success until application-layer behavior changes.
+- Track exact transformations to maintain reproducibility.
+
+## Phase 1: Filter Fingerprinting
+Identify where filtering happens (edge, gateway, app middleware). Identify normalization/canonicalization order and signature-driven vs behavior-driven blocking.
+
+### Signal Collection
+Capture per request: status code, response length/hash, response body signature markers, block page tokens and headers, latency band.
+
+### Differential Baselines
+1. Known-benign control request.
+2. Known-block probe using original payload pattern.
+3. Near-benign variant with one suspicious token removed.
+
+## Phase 2: Hypothesis Generation
+### Core Hypothesis Families
+1. Decode-order mismatch.
+2. Syntax/token boundary mismatch.
+3. Content-type parser mismatch.
+4. Multi-parameter reconstruction mismatch.
+5. Secondary channel mismatch (header/cookie/body disagreement).
+
+## Phase 3: Conditional Playbook
+### Branch A: Edge Signature Block
+Reduce obvious signatures, split payload across parameters, move payload to alternate ingestion vector.
+
+### Branch B: Parser Differential
+Vary content type with equivalent semantics, vary duplicate key placement, vary nested object shape.
+
+### Branch C: Tokenization/Normalization Gap
+Adjust delimiter and whitespace boundaries, adjust key casing, use equivalent encoding layers.
+
+## Phase 4: Variant Families
+### Family 1: Encoding and Decode Order
+Single-encoded, double-encoded, and mixed encoding variants.
+
+### Family 2: Structural Re-Expression
+Semantically equivalent JSON shapes, object vs array wrapping, field reordering.
+
+### Family 3: Content-Type Differential
+Same semantic payload as JSON, form-url-encoded, multipart.
+
+### Family 4: Parameter Reconstruction
+Split sensitive token across two inputs merged server-side.
+
+### Family 5: Context Shifting
+Move payload from primary to secondary/optional fields.
+
+## Phase 5: Validation
+1. Confirm bypass request is accepted.
+2. Confirm application-layer operation changed.
+3. Confirm effect is tied to payload semantics.
+4. Confirm replay with fresh session/context.
+
+## Bypass Quality Score
+- `Q1`: filter evasion only, no vulnerable path proof.
+- `Q2`: vulnerable path reached, low reliability.
+- `Q3`: reproducible vulnerable path reach with stable conditions.
+- `Q4`: reproducible reach + impact proof.
+
+## Output Contract
+```json
+{
+  "target_endpoint": "",
+  "filter_fingerprint": {},
+  "hypotheses": [],
+  "variant_runs": [],
+  "confirmed_bypasses": [],
+  "rejected_variants": [],
+  "defensive_recommendations": []
+}
+```
+
+## Constraints
+- No blind payload spraying.
+- Respect rate/abuse limits.
+- Preserve minimal-impact testing discipline.
+
+## Quality Checklist
+- [ ] Every bypass claim includes controls and replay.
+- [ ] Security-relevant path reach is demonstrated.
+- [ ] Root cause and defensive guidance are specific.

package/skills/builtin/web-artifacts-builder/SKILL.md

@@ -0,0 +1,117 @@
+---
+name: web-artifacts-builder
+description: "Use this skill when the user asks to build a self-contained single-file web tool, widget, calculator, interactive demo, or embeddable HTML app. Triggers: 'make me a calculator', 'build a tool', 'interactive widget', 'single-file app', 'codepen', 'standalone HTML', 'embed', or any request for a small, self-contained web application that should work by opening one HTML file."
+license: MIT
+---
+
+# Web Artifacts Builder
+
+## What This Skill Does
+
+Build self-contained, single-file web applications. Everything in one HTML file: markup, styles, scripts. No build step, no dependencies, no server. Open the file in a browser and it works.
+
+## When to Use This vs frontend-development
+
+| Use web-artifacts-builder | Use frontend-development |
+|---------------------------|--------------------------|
+| Calculators, converters, generators | Multi-page websites |
+| Interactive demos and visualizations | Projects with build tools |
+| Tools someone downloads and opens | Projects that need a server |
+| Embeddable widgets | Projects with external dependencies |
+| Quick prototypes under 500 lines | Anything over 500 lines |
+
+## Template
+
+```html
+<!DOCTYPE html>
+<html lang="en">
+<head>
+  <meta charset="UTF-8">
+  <meta name="viewport" content="width=device-width, initial-scale=1.0">
+  <title>Tool Name</title>
+  <style>
+    *, *::before, *::after { box-sizing: border-box; margin: 0; padding: 0; }
+    :root {
+      --bg: #f8f9fa; --surface: #ffffff; --text: #212529;
+      --primary: #2563eb; --radius: 8px;
+    }
+    @media (prefers-color-scheme: dark) {
+      :root { --bg: #0f1117; --surface: #1a1b26; --text: #c9d1d9; }
+    }
+    body {
+      font-family: system-ui, -apple-system, sans-serif;
+      background: var(--bg); color: var(--text);
+      min-height: 100vh; padding: 2rem;
+    }
+  </style>
+</head>
+<body>
+  <main><!-- UI here --></main>
+  <script>// All logic here, vanilla JS only</script>
+</body>
+</html>
+```
+
+## Patterns
+
+### State Management (vanilla)
+```javascript
+const state = { items: [], filter: "all" };
+function setState(updates) {
+  Object.assign(state, updates);
+  render();
+}
+function render() {
+  const filtered = state.items.filter(/* ... */);
+  container.innerHTML = filtered.map(item => `
+    <div class="item">${item.name}</div>
+  `).join("");
+}
+```
+
+### Local Storage Persistence
+```javascript
+function save() { localStorage.setItem("app-state", JSON.stringify(state)); }
+function load() {
+  const stored = localStorage.getItem("app-state");
+  if (stored) Object.assign(state, JSON.parse(stored));
+}
+load();
+```
+
+### File Input/Output
+```javascript
+input.addEventListener("change", (e) => {
+  const file = e.target.files[0];
+  const reader = new FileReader();
+  reader.onload = () => processContent(reader.result);
+  reader.readAsText(file);
+});
+
+function download(content, filename, type = "text/plain") {
+  const blob = new Blob([content], { type });
+  const url = URL.createObjectURL(blob);
+  const a = document.createElement("a");
+  a.href = url; a.download = filename; a.click();
+  URL.revokeObjectURL(url);
+}
+```
+
+## Rules
+
+- Everything in ONE file. No external CSS, JS, or image files.
+- Vanilla JavaScript only. No React, no frameworks, no npm.
+- External CDN scripts allowed only when essential (e.g., Chart.js, Three.js)
+- Must work offline after first load
+- Dark mode support via `prefers-color-scheme`
+- Mobile responsive
+- Under 500 lines total. If larger, switch to frontend-development skill.
+- Always include a clear `<title>` describing the tool
+
+## Verification
+
+1. Open the HTML file directly in a browser (no server)
+2. All features work
+3. Resize to mobile width
+4. Test in dark mode
+5. No console errors