@funara/wevr 0.1.0

package/src/templates/skills/codebase-fact-finding/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: codebase-fact-finding
+description: Perform initial codebase exploration, fact-finding, and precedent checks before designing requirements or writing code. Use when asked to research technical context or precedents.
+---
+
+# Codebase Fact-Finding & Precedent Check
+
+## Core Principles
+
+- **Fail Fast**: If a recommended library or API is not verified as available or compatible in the codebase, flag it immediately. Never assume availability.
+- **Principle of Least Astonishment**: Prioritize patterns that already exist in the codebase over introducing new ones. Choose the most predictable solutions.
+- **DRY (Don't Repeat Yourself)**: Before researching a solution, check if a precedent already exists in the codebase.
+- **Source Verification**: Explicitly distinguish between "confirmed from codebase/docs" (with exact source citation) and "inferred/recommended" (with rationale).
+
+## Mandatory Output Schema
+You must output exactly these four sections, even if a section is empty:
+
+```markdown
+## confirmed_facts
+- <fact> — Source: <file:line | doc URL | command output>
+  (Only include what you directly observed/verified — read the file, ran the command, fetched the doc. No exceptions.)
+
+## inferred_facts
+- <inference> — Basis: <what confirmed_fact(s) this is inferred from>
+  (Label clearly. This is your reasoning extrapolated from confirmed facts.)
+
+## unknowns
+- <what you could not determine, and why>
+
+## risks
+- <risk introduced by an unknown or inference, if acted upon as-is>
+```
+
+## Hard Rules
+- Never put something in `confirmed_facts` unless you directly checked it.
+- Never blend confirmed and inferred in the same bullet.
+- If you didn't check something because it was out of scope, state it in `unknowns`.
+- If the research request involves UI elements or layout design, include a detailed ASCII mockup in your output.
+- Do not recommend a course of action. State facts/inferences/risks and hand back.

package/src/templates/skills/diff-review/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: diff-review
+description: Compare code implementations and diffs against PRD requirements and definitions-of-done. Act as a strict PASS/FAIL review gate.
+---
+
+# Diff Review & Implementation Verification
+
+## Core Principles
+
+- **Definition-of-Done Grounding**: Compare changes strictly against the PRD's explicit definition-of-done (DoD) for each task. Do not evaluate style/completeness against unstated standards.
+- **Binary Verdict per Task**: Each task receives PASS or FAIL individually. A partial pass is a FAIL.
+- **Regression Awareness**: Verify that code changes did not break previously passed requirements.
+- **Fail Fast**: If the implementation cannot be matched due to missing info or contradictions, flag it as a gap immediately. Do not guess.
+- **No Scope Creep Judgment**: Flag code that exists but does not map to any DoD item as "extra scope" — but do not fail it unless it contradicts a requirement.
+
+## Over-Engineering Lens (BLOAT List)
+Evaluate the implementation against the BLOAT list:
+- **B**: Boilerplate that nobody asked for.
+- **L**: Library or external dependencies added when stdlib/native features suffice.
+- **O**: Over-abstraction (classes, interfaces, wrappers) not explicitly requested.
+- **A**: Additional features or logic beyond the PRD definition-of-done.
+- **T**: Too many files where a simpler, single-file implementation would work.
+
+Report any found BLOAT as gaps.
+
+## Hard Rules
+- Output *only* PASS/FAIL and the Gap List (with task_id, expected, actual, and gap).
+- Do NOT suggest code, improvements, architectural re-designs, or decisions.
+- Any sentence starting with "I suggest..." or "it would be better to..." is strictly out of scope.
+
+## Mandatory Output Schema
+
+```markdown
+## Verdict: PASS | FAIL
+
+## Mapping
+| Requirement/Expectation | Found in artifact? | Note |
+|---|---|---|
+
+## Gaps (if FAIL)
+- <item>: <expected> vs <actual>
+```

package/src/templates/skills/general-coding/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: general-coding
+description: Implementation guidelines for writing clean, defensive, and modular code during feature construction. Follows the Decision Ladder.
+---
+
+# General Coding & Architecture (Decision Ladder)
+
+## Coding Principles
+
+- **KISS (Keep It Simple, Stupid)**: Choose the simplest implementation that satisfies the requirement. If a complex approach is chosen, explain why in a comment.
+- **DRY (Don't Repeat Yourself)**: Before writing new logic, check if equivalent logic already exists in the codebase.
+- **Fail Fast / Defensive Programming**: Validate all inputs at function/API boundaries. Never assume upstream data is valid — raise explicit errors.
+- **SOLID (Dependency Inversion)**: Depend on abstractions (interfaces, protocols) rather than concrete implementations, especially for external services (database, API clients).
+- **Clean Code Naming**: Meaningful names — no abbreviations unless domain-standard (e.g., `id`, `db`).
+- **Clean Code Structure**: Small functions (one function does one thing), no hidden side effects, and minimize comments (comment only "why", not "what").
+- **Single Level of Abstraction**: A function should not mix high-level orchestration with low-level details (e.g., business logic + raw SQL in the same function).
+
+## Decision Ladder
+Before writing any code, stop at the first rung that holds:
+1. Does this need to be built at all? (YAGNI)
+2. Does it already exist in this codebase? Reuse the helper, utility, or pattern that's already here, don't re-write it.
+3. Does the standard library already do this? Use it.
+4. Does a native platform feature cover it? Use it.
+5. Does an already-installed dependency solve it? Use it.
+6. Can this be one line? Make it one line.
+7. Only then: write the minimum code that works.
+
+The ladder runs after you understand the problem: read the task and the code it touches, trace the real flow end to end, then climb.
+
+## Never-Simplify Rules
+You must never cut corners on:
+- Understanding the problem: Trace the real flow before coding.
+- Input validation at trust boundaries.
+- Error handling that prevents data loss.
+- Security and accessibility.
+- Anything explicitly requested.
+- No abstractions that weren't explicitly requested.
+- No new dependency if it can be avoided.
+- No boilerplate nobody asked for.
+- Deletion over addition. Boring over clever. Fewest files possible.
+
+## Simplification Comment Convention
+Mark intentional simplifications with a `simplification:` comment. If the shortcut has a known ceiling (global lock, O(n²) scan, naive heuristic), the comment must name the ceiling and the upgrade path.

package/src/templates/skills/minimal-fixing/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: minimal-fixing
+description: Applying minimal, targeted bug fixes addressing the root cause identified in Brooks-Lint RCA findings.
+---
+
+# Minimal Corrective Fixing
+
+## Core Principles
+
+- **Minimal Change**: Apply only the change needed to fix the root cause. Do not refactor surrounding code, "improve" style, or fix unrelated issues in the same pass. If you see additional problems, flag them but do not fix them.
+- **Root-Cause Targeting**: The fix must address the root cause identified in the RCA findings, not just the symptom.
+- **Brooks-Lint Aligned**: The fix must address the *Source* of the bug, not just the *Symptom*. A fix that only addresses the symptom will not prevent recurrence.
+- **SOLID-S (Single Responsibility)**: If a proper fix would require a function to take on more than its original responsibility, flag this rather than recommending an inline patch. The fix should not create new SRP violations.
+- **Test-Aware**: Confirms the fix works and does not break existing behavior. If tests were missing for the buggy code, flag this.
+- **Revertible**: Each fix should be structured as a discrete change that can be easily reverted or reviewed independently. Do not bundle multiple logical fixes in the same edit.
+
+## Efficiency Constraints
+- **Smallest Diff**: Implement the most targeted fix possible.
+- **Delete the Cause**: Prefer deleting buggy code or the root cause over adding conditional guard patches.
+- **10-Line Limit**: If a fix requires more than 10 lines of changes, stop and surface this complexity to the primary agent before proceeding.
+
+## Output Format
+- Code changes, with a brief note on what root cause was addressed.
+- Test results confirming the fix.
+- Any residual risks or related issues discovered during the fix.

package/src/templates/skills/plan-checking/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: plan-checking
+description: Validate draft requirement documents (PRDs) against original user requests. Act as a strict PASS/FAIL gate with a Gap List.
+---
+
+# Plan Checking & PRD Validation
+
+## Core Principles
+
+- **Complete Coverage**: Every element of the original user request must map to at least one requirement in the PRD. Any request element with no corresponding requirement is a FAIL gap.
+- **Ambiguity Detection**: Flag any requirement that can be read in two or more materially different ways. The PRD must be unambiguous.
+- **Contradiction Detection**: Flag any pair of requirements whose literal reading conflicts.
+- **Principle of Least Astonishment**: Evaluate whether each requirement would be clear and unambiguous to the builder during implementation. Flag technically complete but surprising/misleading items.
+- **Scope Containment**: Flag any requirement that adds scope not traceable to the original request (scope creep).
+
+## Hard Rules
+- Output *only* the PASS/FAIL verdict, requirement-to-artifact mapping, and gap list.
+- Do NOT propose new features, redesign architecture, suggest alternative approaches, or make decisions.
+- Do NOT suggest improvements. Only report expectation vs. reality.
+- If you lack enough information to render a verdict, count it as a gap ("cannot verify X -- insufficient input"). Do not treat silence as PASS.
+
+## Mandatory Output Schema
+
+```markdown
+## Verdict: PASS | FAIL
+
+## Mapping
+| Requirement/Expectation | Found in artifact? | Note |
+|---|---|---|
+
+## Gaps (if FAIL)
+- <item>: <expected> vs <actual>
+```

package/src/templates/skills/ponytail-patching/SKILL.md

@@ -0,0 +1,20 @@
+---
+name: ponytail-patching
+description: Implement minimal, security-targeted patches for vulnerabilities under severe constraints using the Ponytail developer mindset.
+---
+
+# Ponytail Secure Patching
+
+## Ponytail Minimal Fix Constraints
+You must strictly apply the lazy senior developer mindset:
+- **Smallest Diff**: Implement the smallest possible correct change.
+- **Delete the Cause**: Prefer deleting vulnerable or dead code entirely over wrapping it in complex validations.
+- **Size Boundary**: If a patch requires changing or adding more than 10 lines of code, STOP and report this complexity to the primary agent instead of coding it.
+- **Boilerplate**: Write no abstractions or unnecessary helper functions.
+- **Safety**: Do not sacrifice input validation or error boundaries for brevity. Mark intentional simplifications with a `// ponytail:` comment.
+
+## Corrective Strategy
+If you receive a Gap List and BLOAT List:
+1. Treat it as your primary corrective requirements.
+2. Focus on fixing the remaining security vulnerabilities highlighted in the Gap List.
+3. Refactor and simplify any code structures flagged in the BLOAT List.

package/src/templates/skills/prd-formatting/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: prd-formatting
+description: Transform raw inputs, requirements, and codebase context into a formal Product Requirement Document (PRD).
+---
+
+# PRD Formatting
+
+## Core Principles
+
+- **Principle of Least Astonishment**: The PRD must follow a predictable structure. The implementer should not be surprised by the format, terminology, or requirements organization.
+- **Self-documenting**: Each section of the PRD should be intelligible on its own without requiring cross-references or external context.
+- **Separation of Concerns**: Each requirement must map to one concern. Do not bundle unrelated requirements.
+
+## Hard Rules
+- Do NOT make inferences about what the user "probably means."
+- Do NOT make decisions (e.g., which approach is better).
+- Do NOT add analysis, recommendations, or opinions.
+- If you lack enough information to fill a section, write `TBD` and move on. Never invent details or assume information.
+- Write ONLY to the `docs/plans/` directory.
+
+## Mandatory Output Schema
+
+```markdown
+# PRD: <title>
+
+## Goal
+<one sentence, as given>
+
+## Requirements
+- R1: <as given>
+- R2: ...
+
+## Assumptions
+- <as given, or "None">
+
+## Out of Scope
+- <as given, or "Not specified — TBD">
+```
+
+## Handoff Note
+When instructed to perform a handoff, append a **Handoff Note** section after Out of Scope containing:
+- Unresolved questions / open items (if any)
+- Key decisions made during planning (with rationale)
+- Summary of researcher's findings that may be relevant to implementation
+- Any assumptions that could affect implementation order or strategy

package/src/templates/skills/refactoring-patterns/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: refactoring-patterns
+description: Guidelines and step-by-step checklists for safely performing code refactoring patterns (Fowler) without breaking existing interfaces.
+---
+
+# Architectural Refactoring Patterns
+
+## Refactoring Best Practices
+
+- **Zero-Regression Focus**: Run the test suite after every incremental modification. Do not make multiple unrelated refactoring edits at the same time.
+- **Maintain Public Interfaces**: Do not change public function signatures or API endpoints unless explicitly requested. Use deprecation notices or adapters if structural changes are necessary.
+- **Separate Refactoring from Features**: Do not mix refactoring with adding new features. Refactor first, commit, then implement the new feature on top of the clean design.
+
+## Standard Fowler Checklists
+
+### 1. Extract Function
+1. Create a new function and name it after its intent (what it does, not how it does it).
+2. Copy the extracted code block into the new function.
+3. Pass any variables that are read but not modified inside the extracted block as arguments.
+4. Pass any variables that are modified inside the extracted block as return values.
+5. Replace the original code block with a call to the new function.
+6. Run tests to verify correctness.
+
+### 2. Move Field / Method
+1. Ensure the source object and target object are accessible in both scopes.
+2. Implement the method or field on the target object.
+3. Update the source method/field to delegate calls to the target object.
+4. Replace direct references to the source method/field across the codebase with references to the target object.
+5. Remove the source implementation once no references remain.
+6. Run tests to verify correctness.
+
+### 3. Replace Conditional with Polymorphism
+1. Identify the class or interface that represents the conditional variations.
+2. Create sub-classes or polymorphic implementations for each branch of the conditional statement.
+3. Move the branch-specific execution code into overridden methods in each sub-class.
+4. Replace the original conditional check with a polymorphic method call on the object instance.
+5. Run tests to verify correctness.

package/src/templates/skills/security-auditing/SKILL.md

@@ -0,0 +1,35 @@
+---
+name: security-auditing
+description: Act as a validation gate checking if security patches resolved vulnerabilities without introducing regressions or over-engineering (Bloat analysis).
+---
+
+# Security Auditing & Quality Gate
+
+## Core Work
+- Inspect modified codebase files and run test commands to verify vulnerability elimination.
+- Perform a security regression review: ensure the applied patches did not introduce new vulnerability pathways (e.g., input bypasses or insecure error handling).
+- Perform an over-engineering review (Ponytail audit lens).
+
+## Ponytail Audit Lens (Bloat Analysis)
+Analyze changes for cognitive overload, accidental complexity, or redundant logic. Check for:
+- Unrequested abstractions
+- Boilerplate
+- Excessive lines of code (more than necessary to resolve the vulnerability)
+- Redundant logic
+
+## Hard Rules
+- Output *only* the PASS/FAIL verdict, Gap List, and BLOAT List.
+- Do NOT propose remedies, suggest code adjustments, or edit code.
+
+## Mandatory Output Schema
+Your output must consist ONLY of:
+
+```markdown
+## Verdict: PASS | FAIL
+
+## Gap List
+- List of specific files/lines where vulnerabilities are still active or regression was detected (FAIL cases only).
+
+## BLOAT List
+- List of over-engineered constructs, abstractions, or boilerplate found in the patches.
+```

package/src/templates/skills/security-remediation/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: security-remediation
+description: Standard code patterns and recipes for safely fixing common OWASP Top 10 vulnerabilities (SQLi, XSS, CSRF, SSRF, broken auth) without introducing bloat.
+---
+
+# Secure Remediation Patterns
+
+## Vulnerability Remediation Recipes
+
+### 1. SQL Injection (SQLi)
+- **Remedy**: Always parameterize query bindings. Never concatenate or interpolate user input directly into query strings.
+- **Example (Bad)**:
+  `db.execute("SELECT * FROM users WHERE name = '" + input + "'")`
+- **Example (Good)**:
+  `db.execute("SELECT * FROM users WHERE name = ?", [input])`
+
+### 2. Cross-Site Scripting (XSS)
+- **Remedy**: Contextually encode all dynamic data output to HTML. Prioritize framework default binding mechanisms (e.g. JSX expression, textContent) over direct DOM injection.
+- **Example (Bad)**:
+  `element.innerHTML = userInput`
+- **Example (Good)**:
+  `element.textContent = userInput`
+
+### 3. Server-Side Request Forgery (SSRF)
+- **Remedy**: Implement a strict IP/Domain allow-list for external fetches. Block resolve paths pointing to internal private metadata or loopback addresses.
+- **Forbidden Ranges**: `127.0.0.0/8`, `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`, `169.254.169.254`.
+
+### 4. Broken Object Level Authorization (BOLA / IDOR)
+- **Remedy**: Check that the authenticated session user actually owns the resource identifier requested before executing read, update, or delete commands.
+- **Example (Bad)**:
+  `db.getInvoice(req.params.id)`
+- **Example (Good)**:
+  `invoice = db.getInvoice(req.params.id); if (invoice.userId !== req.session.userId) throw new UnauthorizedError();`
+
+## General Safety Checklist
+- Never log raw passwords, access tokens, or sensitive API keys.
+- Ensure all error messages returned to the API client are generic and do not expose internal stack traces or database configurations.

package/src/templates/skills/summary-reporting/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: summary-reporting
+description: Format raw facts, outcomes, RCA findings, and validation results into formal execution and summary reports.
+---
+
+# Summary & Execution Reporting
+
+## Core Principles
+
+- **Fidelity to Sources**: Every claim in the report must trace back verbatim to a source output (e.g. Tracer findings, Patcher changes, Auditor verdict, Debugger diagnosis). No claim or interpretation may originate from the reporter.
+- **Audience-First**: Tailor detail level and vocabulary for the target reader (technical lead, maintainer, end-user) if specified. Default to technical summary.
+- **DRY for Docs**: Present findings exactly once; use cross-references instead of repeating data across sections.
+- **Priority Ordering**: Order findings by severity (blocking failures/confirmed vulnerabilities first, then open risks/suspected vulnerabilities, then informational notes/bloat).
+- **Stateless formatting**: Do not remember context across runs. Do not make inferences or assumptions.
+- **Target Output Directory**: Write ONLY to the `docs/reports/` directory.
+
+## Hard Rules
+- Do NOT make inferences or assume facts. If input is missing or incomplete, write `TBD` or `N/A`.
+- Do NOT add analysis, recommendations, or opinions beyond what was provided.
+- Do NOT run bash commands.
+
+## Standard Formats
+
+### Format A: Compose Completion Report
+```markdown
+# Report: <subject>
+
+## For: <audience>
+
+## Outcome
+<PASS/FAIL or completion status, as given>
+
+## Details
+<compressed from input, no added interpretation>
+```
+
+### Format B: Brooks-Lint Diagnosis Report (Debugger)
+```markdown
+# Diagnosis Report: <subject>
+
+## For: <audience>
+
+## Decay Risk Classification
+<R1-R6 or T1-T6 risk(s) identified>
+
+## Findings
+### Finding 1: <decay risk> — <brief title>
+**Symptom:** ...
+**Source:** ...
+**Consequence:** ...
+**Remedy:** ...
+
+### Finding 2: ...
+```
+
+### Format C: Security & Quality Audit Report (Analyze)
+```markdown
+# Security & Quality Audit Report: <Date/Subject>
+
+## Executive Summary
+- **Auditor Verdict:** <PASS/FAIL>
+- **Confirmed Vulnerabilities:** <count>
+- **Suspected Vulnerabilities:** <count>
+- **Patches Applied:** <summary of Patcher changes, or "None">
+
+## Vulnerability Findings
+### Confirmed Vulnerabilities
+<verbatim from Tracer confirmed_vulns — OWASP category, location, data flow>
+
+### Suspected Vulnerabilities
+<verbatim from Tracer suspected_vulns>
+
+### Quality & Decay Risks
+<verbatim from Tracer quality & decay risks>
+
+## Patches Applied
+<verbatim diff summary from Patcher, or "N/A — audit only mode">
+
+## Auditor Verdict Detail
+- **Verdict:** <PASS/FAIL>
+- **Gap List:** <verbatim from Auditor — files/lines still vulnerable, or "None">
+- **BLOAT List:** <verbatim from Auditor — over-engineered constructs, or "None">
+```

package/src/templates/skills/test-assurance/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: test-assurance
+description: Write, run, and evaluate test suites to confirm correctness and identify regressions or coverage gaps.
+---
+
+# Test Validation & Test Assurance
+
+## Core Principles
+
+- **Regression Awareness**: Separate new failures (introduced by current changes) from pre-existing failures. Pre-existing failures are context, not a gap to close in this pass.
+- **Coverage Gaps**: Any code written or modified that lacks a corresponding test is a reportable gap.
+- **Test Independence**: If tests share mutable state or depend on execution order, flag it as a structural risk.
+- **Blocked Status**: If you cannot run the test suite (missing dependencies, no framework), report it as BLOCKED. Do not attempt to install packages or configure settings.
+
+## Efficiency Constraints (Minimal Testing)
+- **Minimal Testing**: Test only the smallest thing that fails if the logic breaks.
+- **No Speculative Edge Cases**: Write tests for actual requirements, not imagined inputs.
+- **One Assertion per Behavior**: Keep assertions focused on a single logical outcome.
+- **No Complex Fixtures**: Write the simplest assertions or test files possible.
+- **No Tests for Trivial Code**: Trivial one-liners need no tests.
+
+## Hard Rules
+- Report the PASS/FAIL/BLOCKED status, results table, regressions, and coverage gaps.
+- Do NOT fix failing tests, rewrite suites, or decide whether failures are blocking. Let the primary agent decide.
+- Do NOT install dependencies or configure frameworks.
+
+## Mandatory Output Schema
+
+```markdown
+## Status: PASS | FAIL | BLOCKED
+
+## Test Results
+| Test suite | Passed | Failed | New failure? |
+|---|---|---|---|
+
+## New Failures (regressions from current changes)
+- <test name>: <failure message>
+
+## Pre-existing Failures (not caused by current changes)
+- <test name>: <note>
+
+## Coverage Gaps (code written/modified without tests)
+- <file/function>: <note>
+```

package/src/templates/skills/test-mocking-strategy/SKILL.md

@@ -0,0 +1,18 @@
+---
+name: test-mocking-strategy
+description: Guidelines on when and how to mock external services (databases, network requests, third-party APIs) during test creation.
+---
+
+# Mocking & Test Double Strategy
+
+## Core Principles
+
+- **No Over-Mocking**: Limit mocks to external trust boundaries (e.g., external HTTP endpoints, third-party API clients). Never mock internal domain models, database queries, helper utilities, or core business logic unless absolutely necessary.
+- **Contract Verification**: Ensure mock payloads and responses strictly match the actual schema of the external API. Stale mocks that hide schema drift are a major regression risk.
+- **Prefer Stubs over Mocks**: Use simple stubs (returning canned data) over complex mock objects with verified call counts and expectations, keeping test setup clean and readable.
+- **Standardized Mock Tools**: Utilize standard community tools (e.g., `nock`, `msw`, `unittest.mock`) instead of writing custom, proprietary mock engines.
+
+## Decisions & Boundaries
+- **Database Mocks**: Prefer using a lightweight in-memory database (e.g., SQLite in-memory) or database transactions that rollback after each test over mocking SQL connections or ORM calls.
+- **HTTP Requests**: Mock network calls at the HTTP layer (using tools like `msw` or `nock`) rather than patching the application-level API client wrapper, ensuring client serialization logic is tested.
+- **Time/Date Mocking**: Use deterministic clock wrapper utilities or standard mock timers (e.g., `sinon.useFakeTimers`, `freezegun`) when testing time-sensitive operations (e.g., token expiration, transaction limits).

package/src/templates/skills/ui-design-audit/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: ui-design-audit
+description: Quality assurance playbook for auditing user interfaces for accessibility (WCAG), layout defects, responsive scaling, and over-engineering.
+---
+
+# UI Design Audit & QA Playbook
+
+## 1. Accessibility (WCAG 2.1 AA Compliance)
+- **Contrast Check**: Verify hex color values for text and interactive indicators against backgrounds. Normal text must satisfy $\ge 4.5:1$ contrast ratio, and large text must satisfy $\ge 3:1$.
+- **Focus Rings**: Verify that all interactive elements have visible `:focus` or `:focus-visible` outline rings to support keyboard-only navigation.
+- **Semantic Structure**: Ensure proper HTML heading hierarchy (never skip heading levels like `h1` directly to `h3`). Ensure proper ARIA roles and labels on dynamic components (modals, dropdowns).
+
+## 2. Layout & Responsiveness
+- **Breakpoint Overflows**: Check for hardcoded pixel widths (`width: 500px`) that cause horizontal scrolling on smaller viewports. Ensure flexible percentage or viewport-based units (`w-full`, `max-w-*`) are used.
+- **Alignment Integrity**: Check that grids, flexboxes, and columns do not overlap or misalign at intermediate screen widths.
+- **Empty States**: Ensure any dynamic layout accounts for loading or empty states with clean indicators.
+
+## 3. Performance & Asset Optimization
+- **Static Assets**: Verify that images are loaded in modern formats (e.g. `.webp` instead of high-resolution `.png` / `.jpg`) and contain explicit width/height parameters to avoid cumulative layout shifts (CLS).
+- **Fonts**: Ensure external web fonts are preloaded or styled with a proper fallback font stack (e.g., `font-family: 'Inter', sans-serif;`) to prevent layout flickering.
+
+## 4. Visual Over-Engineering Check
+- Ensure that the CSS is clean and organized, avoiding excessive layers of unneeded nested rules, duplicate styling declarations, or unused CSS utility classes.

package/src/templates/skills/ui-design-system/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: ui-design-system
+description: Playbook and guidelines for creating visually rich, innovative, and modern user interfaces (design system, spacing, typography, and micro-interactions).
+---
+
+# UI Design System & Guidelines
+
+## 1. Typography & Hierarchy
+- **Primary Font**: Use modern, clean typography (e.g., from Google Fonts like `Inter` for body/ui elements and `Outfit` or `Space Grotesk` for headings).
+- **Scale**:
+  - Headings (`h1`, `h2`): Semibold/Bold, tighter line-height (`1.2`), tracking tight.
+  - Body: Regular, line-height `1.5` or `1.6`, tracking normal.
+  - Labels/Buttons: Medium, uppercase or medium weight, tracking wide.
+
+## 2. Spacing & Grid System
+- **Spacing Scale**: Enforce a strict spacing scale based on multiples of 4px/8px (e.g., Tailwind's `p-2`, `p-4`, `p-6`, `p-8` scales). Never use random "magic numbers" for margins or padding.
+- **Grids & Flexbox**: Always align elements using responsive flexbox or grid layouts. Center content cleanly, keep columns proportional, and ensure proper padding at container edges.
+
+## 3. Visual Depth & Aesthetics
+- **Elevations & Depth**: Use subtle border strokes (e.g. `rgba(255,255,255,0.08)` in dark mode) paired with soft shadows to define elevation.
+- **Gradients**: Utilize smooth, harmonious color gradients for key accent elements, headers, and call-to-action buttons.
+- **Glassmorphism**: When creating modern panels or modals, prefer semi-transparent backgrounds with background blur (e.g., `backdrop-filter: blur(12px)`).
+- **Color Accents**: Avoid primary saturated primaries (e.g., plain `#ff0000`, `#0000ff`). Use tailored palettes (e.g. HSL tailored neon/pastel gradients, sleek slate/charcoal backgrounds).
+
+## 4. Micro-Interactions & Transitions
+- **Interactive States**: Every interactive element (buttons, cards, inputs) must have explicit `:hover`, `:focus-visible`, and `:active` styles.
+- **Transitions**: Apply smooth transition effects (`transition: all 0.2s cubic-bezier(0.4, 0, 0.2, 1)`) to avoid sudden visual snapping on hover or state change.
+
+## 5. Mobile-First Responsiveness
+- Start layouts mobile-first. Apply breakpoint prefixes (`sm:`, `md:`, `lg:`) to scale grids, font sizes, and container widths gracefully to desktop viewports.
+
+## 6. Mockup & Prototype Delivery Protocol
+When tasked with generating a visual layout, mockup, or interface prototype:
+- **No ASCII Drawing**: Do not output textual ASCII grids or drawings.
+- **Self-Contained File**: Generate a complete, valid HTML5 file.
+- **Embedded CSS**: Include a `<style>` block containing fonts (Inter/Outfit), layout variables, component styles, states (:hover, :focus), and smooth transition curves.
+- **Embedded JS**: Include a `<script>` block implementing DOM interactions (tab switching, theme toggles, modal open/close) so it works as a fully responsive, interactive live prototype.

package/src/templates/skills/wstg-recon/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: wstg-recon
+description: Scan project directory structure, map attack surfaces, and trace vulnerability data-flow paths using secure code review and WSTG principles.
+---
+
+# WSTG Threat Model & Vulnerability Tracing
+
+## Scope of Work
+- Scan the directory structure and codebase to identify potential entry points, routes, API endpoints, and security weaknesses.
+- Perform a breadth-first assessment: map outer interfaces and entry points before analyzing deep business logic.
+- Trace data flows from untrusted inputs to dangerous sinks (e.g., raw SQL query calls, shell execution points, eval functions).
+- Guide your checks using WSTG (Web Security Testing Guide) methodologies and secure code review practices.
+
+## Hard Rules
+- Focus on locating vulnerability paths. Do NOT propose remedies, write code fixes, or modify files.
+- Do NOT decide remediation priorities.
+- Classify findings strictly into the target output format.
+
+## Mandatory Output Schema
+Your output must be structured exactly as follows:
+
+```markdown
+### Confirmed Vulnerabilities
+1. **[OWASP Category / WSTG ID]** Description of vulnerability path.
+   - **Location:** [file path & line numbers]
+   - **Data Flow:** [input -> path -> sink]
+
+### Suspected Vulnerabilities
+- List potential issues requiring manual verification.
+
+### Quality & Decay Risks
+- List security-adjacent decay risks (e.g., hardcoded secrets, missing input validation rules, lack of trust boundaries).
+```