@fenixforce/edition-pro 0.1.0

package/skills/builtin/systematic-debugging/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: systematic-debugging
+description: "Use this skill when encountering a bug, error, test failure, or unexpected behavior. Triggers: 'error', 'bug', 'broken', 'failing', 'crash', 'stack trace', 'not working', 'unexpected behavior', 'fix this', or any situation where code doesn't behave as expected."
+license: MIT
+---
+
+# Systematic Debugging
+
+## What This Skill Does
+
+Find and fix bugs through a structured 4-phase process. No guessing, no random changes, no "try this and see."
+
+## The 4 Phases
+
+### Phase 1: INVESTIGATE
+Gather evidence before forming theories.
+
+- Read the error message completely (including the stack trace)
+- Identify the exact input that triggers the bug
+- Check recent changes (git log, git diff)
+- Reproduce the bug consistently
+- Note what works and what doesn't
+
+### Phase 2: DIAGNOSE
+Form a hypothesis based on evidence.
+
+- Trace execution from input to error
+- Add targeted logging at key decision points
+- Bisect: find the exact commit/line where behavior changed
+- Check assumptions: are types what you think? Are values populated?
+- Isolate: can you reproduce with a minimal example?
+
+### Phase 3: FIX
+Apply the minimal change that resolves the root cause.
+
+- Fix the root cause, not the symptom
+- Write a test that fails before the fix and passes after
+- Keep the fix as small as possible
+- Check for the same bug pattern elsewhere in the codebase
+
+### Phase 4: VERIFY
+Prove the fix works and doesn't break anything.
+
+- Run the reproducer. Bug is gone.
+- Run the full test suite. Nothing new is broken.
+- Test edge cases around the fix
+- Document what the bug was and why the fix works
+
+## Rules
+
+- Never guess. Gather evidence first.
+- Reproduce before fixing. If you can't reproduce it, you can't verify it's fixed.
+- One change at a time. Never make multiple changes and test them together.
+- Root causes only. Band-aids create future bugs.
+- Always write a regression test for the bug
+
+## Stuck Detection (The Ralph Wiggum Loop)
+
+If you've tried the same fix approach 3 times without progress:
+1. Stop immediately
+2. State explicitly: "I've tried X three times and it's not working"
+3. Try a fundamentally different approach (different hypothesis, different tool, different angle)
+4. If the alternative also fails after 2 attempts, escalate to the user with a summary of what was tried
+
+Never keep applying the same fix hoping for a different result.
+
+## Verbose Reasoning Transparency
+
+During debugging sessions, inspect the model's reasoning blocks for hidden assumptions:
+
+### When to Use
+- Bug fix attempts that silently fail (code changes but behavior unchanged)
+- Debugging non-deterministic issues where the model may be guessing
+- Complex multi-step debugging where reasoning chain integrity matters
+
+### Pattern
+1. Enable extended thinking / reasoning blocks for debugging calls
+2. After each debugging step, review the reasoning block for:
+   - Unstated assumptions ("I assume X is always true")
+   - Skipped verification ("this should work because...")
+   - Contradictions between reasoning and action
+3. If reasoning reveals a faulty assumption, address the assumption directly rather than the symptom
+
+### Rules
+- Reasoning transparency is a debugging aid, not a performance optimization
+- Use only when standard debugging phases aren't converging
+- Flag any reasoning that contains "probably", "likely", or "should" without evidence

package/skills/builtin/tailwind-css/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: tailwind-css
+description: "Use this skill when styling with Tailwind CSS. Triggers: 'Tailwind', 'utility classes', 'tailwind config', 'tailwind.config', or any request specifying Tailwind for styling. Always fetch Context7 docs first as classes change between versions."
+license: MIT
+---
+
+# Tailwind CSS
+
+## What This Skill Does
+
+Style applications with Tailwind utility classes. Configuration, responsive design, dark mode, component extraction, and custom plugins.
+
+## Before You Start
+
+**Context7:** ALWAYS fetch current Tailwind docs. Tailwind 4 changed significantly from Tailwind 3.
+
+## Core Patterns
+
+```html
+<!-- Responsive: mobile-first -->
+<div class="p-4 md:p-6 lg:p-8">
+
+<!-- Dark mode -->
+<div class="bg-white dark:bg-gray-900 text-gray-900 dark:text-gray-100">
+
+<!-- Hover/Focus states -->
+<button class="bg-blue-600 hover:bg-blue-700 focus:ring-2 focus:ring-blue-500">
+
+<!-- Flexbox layout -->
+<div class="flex items-center justify-between gap-4">
+
+<!-- Grid layout -->
+<div class="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-6">
+```
+
+## Component Extraction
+
+When a utility pattern repeats 3+ times, extract to a component (React) or @apply (CSS):
+
+```css
+/* Only use @apply for very common patterns */
+@layer components {
+  .btn-primary {
+    @apply px-4 py-2 bg-blue-600 text-white rounded-lg hover:bg-blue-700 transition-colors;
+  }
+}
+```
+
+## Rules
+
+- Fetch Context7 docs before writing Tailwind classes
+- Mobile-first: write base styles for mobile, add breakpoint prefixes for larger screens
+- Prefer semantic HTML + utilities over div soup
+- Extract components, not utility classes (prefer React components over @apply)
+- Use CSS variables via theme() for values used in JavaScript

package/skills/builtin/taint-flow-tracer/SKILL.md

@@ -0,0 +1,89 @@
+# Taint Flow Tracer
+
+## Purpose
+Provide deterministic source-to-sink traces for exploitability decisions.
+
+## Inputs
+- `code_path`
+- `candidate_source`
+- `candidate_sink`
+- `execution_context`
+
+## Trace Method
+### Step 1: Source Definition
+1. Define exact taint origin.
+2. Classify taint trust level and attacker influence.
+
+### Step 2: Propagation Tracking
+1. Follow variable flow through wrappers and helpers.
+2. Track type conversion, serialization, and parsing boundaries.
+3. Track async/task boundary hops.
+
+### Step 3: Checkpoint Evaluation
+1. Record validation and canonicalization points.
+2. Determine context fitness of each sanitizer.
+3. Identify alternate branches that skip checks.
+
+### Step 4: Sink Reachability
+1. Confirm sink invocation path is executable.
+2. Confirm attacker control survives to sink-relevant bytes.
+3. Note control granularity (full, partial, none).
+
+### Step 5: Verdict
+1. `tainted_reachable`
+2. `tainted_blocked`
+3. `path_unknown`
+
+## Required Trace Fields
+- `source`
+- `path_nodes`
+- `checkpoints`
+- `sink`
+- `control_level`
+- `verdict`
+
+## Output Contract
+```json
+{
+  "trace_id": "",
+  "source": {},
+  "path_nodes": [],
+  "checkpoints": [],
+  "sink": {},
+  "verdict": ""
+}
+```
+
+## Failure Modes
+- Stopping at static reference without runtime-feasible path.
+- Treating generic sanitization as context-safe by default.
+
+## Quality Checklist
+- [ ] Cross-file and cross-layer flow included.
+- [ ] Checkpoints evaluated for bypassability.
+- [ ] Control level at sink is explicit.
+
+## 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/teaching-agent-team/SKILL.md

@@ -0,0 +1,32 @@
+# Teaching Agent Team
+## Pipeline
+1. **Researcher**: search ArXiv, web for current information on the topic
+2. **Curriculum Designer**: structure content into lessons with learning objectives
+3. **Content Generator**: produce lesson content (explanations, examples, analogies)
+4. **Quiz Creator**: generate assessment questions (multiple choice, short answer, exercises)
+
+## Lesson Format
+```markdown
+## Lesson: [Title]
+**Objective**: [What the learner will be able to do after this lesson]
+**Prerequisites**: [What they should already know]
+**Duration**: [Estimated time]
+
+### Explanation
+[Core concepts with examples and analogies]
+
+### Practice
+[Guided exercises]
+
+### Assessment
+[Questions testing the objective]
+
+### Further Reading
+[Resources for deeper exploration]
+```
+
+## Rules
+- Every lesson has a measurable learning objective
+- Examples before abstractions (show, then explain)
+- Increasing difficulty within each lesson
+- Assessment must test the stated objective, not trivia

package/skills/builtin/tech-debt-manager/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: tech-debt-manager
+description: "Use this skill when the user asks about technical debt, code quality assessment, refactoring prioritization, or codebase health. Triggers: 'tech debt', 'refactor', 'cleanup', 'legacy code', 'code smell', 'TODO', 'HACK', 'architecture review', or requests to assess and plan codebase improvements."
+license: MIT
+---
+
+# Tech Debt Manager
+
+## What This Skill Does
+
+Classify, prioritize, and track technical debt. Automated detection, systematic reduction, and clear reporting.
+
+## Debt Classification
+
+- **Blocking**: Prevents new features or causes incidents. Fix immediately.
+- **Friction**: Slows development. Schedule within current sprint.
+- **Cosmetic**: Annoys developers but doesn't slow work. Fix opportunistically.
+
+## Priority Score
+
+```
+Priority = (Impact × Frequency) / Effort
+
+Impact:    1 (minor) to 5 (critical)
+Frequency: 1 (rare) to 5 (every day)
+Effort:    1 (trivial) to 5 (major refactor)
+```
+
+Score > 5: fix now. Score 2-5: schedule. Score < 2: defer.
+
+## Automated Detection
+
+```bash
+# TODOs and HACKs
+grep -rn "TODO\|HACK\|FIXME\|XXX\|WORKAROUND" src/ --include="*.ts"
+
+# Type gaps
+grep -rn "as any\|: any\|@ts-ignore\|@ts-expect-error" src/ --include="*.ts"
+
+# Skipped tests
+grep -rn "\.skip\|xit\|xdescribe\|test\.todo" src/ --include="*.test.*"
+
+# Large files (complexity indicator)
+find src/ -name "*.ts" | xargs wc -l | sort -rn | head -20
+```
+
+## Tracking Format
+
+```markdown
+# Tech Debt Register
+
+## Blocking
+- [ ] **[B-001]** Missing error handling on payment endpoint (Impact: 5, Freq: 3, Effort: 2, Score: 7.5)
+
+## Friction
+- [ ] **[F-001]** Duplicated validation logic in 3 route handlers (Impact: 3, Freq: 4, Effort: 2, Score: 6)
+
+## Cosmetic
+- [ ] **[C-001]** Inconsistent naming in user module (Impact: 1, Freq: 2, Effort: 1, Score: 2)
+```
+
+## Rules
+
+- Every "quick fix" must have a TODO with a ticket/issue reference
+- Review debt register weekly, reprioritize monthly
+- Allocate 20% of sprint capacity to debt reduction
+- Never add new debt without documenting it

package/skills/builtin/technical-documentation/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: technical-documentation
+description: "Use this skill when the user asks to write API documentation, architecture docs, onboarding guides, runbooks, or any technical reference material. Triggers: 'API docs', 'documentation', 'onboarding guide', 'runbook', 'architecture doc', 'technical reference', 'developer guide', or requests for documentation that developers will use."
+license: MIT
+---
+
+# Technical Documentation
+
+## What This Skill Does
+
+Write clear, accurate technical documentation. API references, architecture guides, onboarding docs, runbooks, and troubleshooting guides.
+
+## Document Types
+
+### API Reference
+- Endpoint, method, URL, parameters (required/optional), request body schema, response schema, error codes, example request/response
+- Use OpenAPI/Swagger for REST APIs
+
+### Architecture Doc
+- System overview diagram (describe, don't draw unless asked)
+- Component descriptions and responsibilities
+- Data flow between components
+- Technology choices with rationale
+- Deployment topology
+
+### Onboarding Guide
+- Prerequisites (with version numbers)
+- Step-by-step setup from zero
+- "Hello world" equivalent to verify setup works
+- Common gotchas and solutions
+- Where to find help
+
+### Runbook
+- When to use this runbook (trigger conditions)
+- Step-by-step procedure with exact commands
+- Expected output at each step
+- Rollback procedure
+- Escalation path if steps fail
+
+## Rules
+
+- Every code example must be tested and working
+- Version numbers on all dependencies
+- Commands must include the full context (which directory, which user)
+- Assume the reader is competent but unfamiliar with this specific system
+- Update docs when code changes (docs and code in the same PR)
+- Link to related docs, never duplicate content across documents.

package/skills/builtin/test-driven-development/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: test-driven-development
+description: "Use this skill when implementing new features, building new code, or when the user asks for test-first development. Triggers: 'implement', 'build feature', 'write code', 'TDD', 'test first', 'test-driven', 'write tests', or any request to build new functionality. The Iron Law: no production code without a failing test first."
+license: MIT
+---
+
+# Test-Driven Development
+
+## What This Skill Does
+
+Build features using the red-green-refactor cycle. Write a failing test, make it pass with minimal code, then refactor. Produces code that works correctly and has test coverage by default.
+
+## The Cycle
+
+```
+1. RED:    Write a test that describes the desired behavior. Run it. It fails.
+2. GREEN:  Write the minimum code to make the test pass. Nothing more.
+3. REFACTOR: Clean up the code. Tests still pass.
+4. REPEAT
+```
+
+## Test Structure
+
+```typescript
+describe("UserService", () => {
+  describe("createUser", () => {
+    it("creates a user with valid input", async () => {
+      const user = await createUser({ email: "test@example.com", name: "Test" });
+      expect(user.id).toBeDefined();
+      expect(user.email).toBe("test@example.com");
+    });
+
+    it("rejects duplicate email", async () => {
+      await createUser({ email: "test@example.com", name: "First" });
+      await expect(
+        createUser({ email: "test@example.com", name: "Second" })
+      ).rejects.toThrow("Email already exists");
+    });
+
+    it("validates email format", async () => {
+      await expect(
+        createUser({ email: "not-an-email", name: "Test" })
+      ).rejects.toThrow("Invalid email");
+    });
+  });
+});
+```
+
+## What to Test
+
+- Happy path (valid input produces expected output)
+- Edge cases (empty, null, boundary values, max length)
+- Error cases (invalid input, missing data, network failure)
+- Business rules (permissions, calculations, state transitions)
+
+## What NOT to Test
+
+- Framework internals (React rendering, Express routing)
+- Third-party library behavior
+- Trivial getters/setters with no logic
+- Implementation details (test behavior, not structure)
+
+## Rules
+
+- The Iron Law: no production code without a failing test first
+- Tests must be independent (no shared mutable state between tests)
+- Tests must be fast (mock external services, use in-memory databases)
+- Test names describe behavior, not implementation
+- One assertion per test (or one logical assertion group)
+- Run the full test suite before marking any task complete

package/skills/builtin/theme-factory/SKILL.md

@@ -0,0 +1,244 @@
+---
+name: theme-factory
+description: "Use this skill when the user asks to create a design system, theme, dark mode, brand styling, or CSS variable system. Triggers: 'theme', 'design system', 'dark mode', 'light mode', 'brand colors', 'CSS variables', 'styling system', 'color palette', or any request for consistent visual theming across a project."
+license: MIT
+---
+
+# Theme Factory
+
+## What This Skill Does
+
+Create complete theming systems: color palettes, CSS variable architectures, dark/light mode switching, design tokens, and brand styling. From a single color to a full design system.
+
+## When to Activate
+
+- User wants dark mode / light mode
+- User wants brand colors applied consistently
+- User wants a design system or style guide
+- User wants to theme an existing project
+- User says "make it look professional" or "consistent styling"
+
+## Color System
+
+### Generate from a single brand color
+
+```css
+:root {
+  /* Brand seed color */
+  --brand: #2563eb;
+
+  /* Derived palette */
+  --brand-50:  #eff6ff;
+  --brand-100: #dbeafe;
+  --brand-200: #bfdbfe;
+  --brand-300: #93c5fd;
+  --brand-400: #60a5fa;
+  --brand-500: #3b82f6;  /* Primary */
+  --brand-600: #2563eb;  /* Brand */
+  --brand-700: #1d4ed8;
+  --brand-800: #1e40af;
+  --brand-900: #1e3a8a;
+  --brand-950: #172554;
+}
+```
+
+### Semantic Colors
+
+```css
+:root {
+  /* Surface hierarchy */
+  --color-bg: #ffffff;
+  --color-surface: #f8fafc;
+  --color-surface-raised: #ffffff;
+  --color-surface-overlay: rgba(0, 0, 0, 0.5);
+
+  /* Text hierarchy */
+  --color-text: #0f172a;
+  --color-text-secondary: #475569;
+  --color-text-muted: #94a3b8;
+  --color-text-inverse: #ffffff;
+
+  /* Interactive */
+  --color-primary: var(--brand-600);
+  --color-primary-hover: var(--brand-700);
+  --color-primary-text: #ffffff;
+
+  /* Feedback */
+  --color-success: #16a34a;
+  --color-warning: #d97706;
+  --color-error: #dc2626;
+  --color-info: #2563eb;
+
+  /* Borders */
+  --color-border: #e2e8f0;
+  --color-border-strong: #cbd5e1;
+  --color-focus-ring: var(--brand-500);
+}
+```
+
+## Dark Mode
+
+### CSS-only (prefers-color-scheme)
+```css
+@media (prefers-color-scheme: dark) {
+  :root {
+    --color-bg: #0f172a;
+    --color-surface: #1e293b;
+    --color-surface-raised: #334155;
+    --color-text: #f1f5f9;
+    --color-text-secondary: #94a3b8;
+    --color-text-muted: #64748b;
+    --color-border: #334155;
+    --color-border-strong: #475569;
+  }
+}
+```
+
+### User-toggleable (class-based)
+```css
+.dark {
+  --color-bg: #0f172a;
+  --color-surface: #1e293b;
+  --color-text: #f1f5f9;
+  /* ... */
+}
+```
+
+```javascript
+// Toggle
+function toggleTheme() {
+  const isDark = document.documentElement.classList.toggle("dark");
+  localStorage.setItem("theme", isDark ? "dark" : "light");
+}
+
+// Initialize from stored preference
+const stored = localStorage.getItem("theme");
+const prefersDark = window.matchMedia("(prefers-color-scheme: dark)").matches;
+if (stored === "dark" || (!stored && prefersDark)) {
+  document.documentElement.classList.add("dark");
+}
+```
+
+## Design Tokens
+
+### Spacing
+```css
+:root {
+  --space-1: 0.25rem;   /* 4px */
+  --space-2: 0.5rem;    /* 8px */
+  --space-3: 0.75rem;   /* 12px */
+  --space-4: 1rem;      /* 16px */
+  --space-6: 1.5rem;    /* 24px */
+  --space-8: 2rem;      /* 32px */
+  --space-12: 3rem;     /* 48px */
+  --space-16: 4rem;     /* 64px */
+}
+```
+
+### Typography
+```css
+:root {
+  --font-sans: system-ui, -apple-system, "Segoe UI", Roboto, sans-serif;
+  --font-mono: "JetBrains Mono", "Fira Code", monospace;
+
+  --text-xs: 0.75rem;
+  --text-sm: 0.875rem;
+  --text-base: 1rem;
+  --text-lg: 1.125rem;
+  --text-xl: 1.25rem;
+  --text-2xl: 1.5rem;
+  --text-3xl: 1.875rem;
+
+  --leading-tight: 1.25;
+  --leading-normal: 1.5;
+  --leading-relaxed: 1.75;
+}
+```
+
+### Shadows and Borders
+```css
+:root {
+  --radius-sm: 4px;
+  --radius-md: 8px;
+  --radius-lg: 12px;
+  --radius-full: 9999px;
+
+  --shadow-sm: 0 1px 2px rgba(0, 0, 0, 0.05);
+  --shadow-md: 0 4px 6px -1px rgba(0, 0, 0, 0.1);
+  --shadow-lg: 0 10px 15px -3px rgba(0, 0, 0, 0.1);
+  --shadow-xl: 0 20px 25px -5px rgba(0, 0, 0, 0.1);
+}
+```
+
+### Transitions
+```css
+:root {
+  --transition-fast: 150ms ease;
+  --transition-normal: 200ms ease;
+  --transition-slow: 300ms ease;
+}
+
+@media (prefers-reduced-motion: reduce) {
+  :root {
+    --transition-fast: 0ms;
+    --transition-normal: 0ms;
+    --transition-slow: 0ms;
+  }
+}
+```
+
+## Component Styling Patterns
+
+### Button variants
+```css
+.btn {
+  padding: var(--space-2) var(--space-4);
+  border-radius: var(--radius-md);
+  font-weight: 500;
+  transition: all var(--transition-fast);
+  cursor: pointer;
+  border: none;
+}
+
+.btn-primary {
+  background: var(--color-primary);
+  color: var(--color-primary-text);
+}
+.btn-primary:hover { background: var(--color-primary-hover); }
+
+.btn-secondary {
+  background: transparent;
+  color: var(--color-text);
+  border: 1px solid var(--color-border);
+}
+.btn-secondary:hover { background: var(--color-surface); }
+
+.btn-danger {
+  background: var(--color-error);
+  color: white;
+}
+```
+
+## Rules
+
+- Always define semantic color names, never use raw hex in components
+- Always support dark mode (at minimum via `prefers-color-scheme`)
+- Always respect `prefers-reduced-motion`
+- Test contrast ratios: 4.5:1 minimum for normal text, 3:1 for large text
+- Keep the number of unique colors under 20 (including shades)
+- Export theme as CSS custom properties (universal, framework-agnostic)
+- Provide both CSS-only and JS-toggle dark mode options
+
+## Verification
+
+1. Light mode and dark mode both render correctly
+2. All text meets WCAG AA contrast ratios
+3. Focus states are visible in both modes
+4. Animations respect reduced-motion preference
+5. Theme toggle persists across page reloads
+
+## Integration with Other Skills
+
+- **frontend-development:** Apply theme to web projects
+- **react-development:** Use CSS variables in React component styles
+- **web-artifacts-builder:** Embed minimal theme in single-file apps