diff --git a/skills/brainstorming/ideation.md b/skills/brainstorming/ideation.md
deleted file mode 100644
index 3bd5dd2..0000000
--- a/skills/brainstorming/ideation.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# Ideation
-
-## Purpose
-
-Generate strong options quickly without locking too early onto the first plausible idea.
-
-## When to use
-
-- The user wants multiple concepts, approaches, or product directions
-- Requirements are early and the solution space is still wide
-- A team needs creative alternatives before choosing a path
-- You want to escape local maxima in product or technical thinking
-
-## Inputs to gather
-
-- Goal, audience, constraints, and success criteria
-- What is already known, tried, or ruled out
-- Time, complexity, and implementation constraints
-- The desired balance of novelty versus practicality
-
-## How to work
-
-- Produce several meaningfully different options, not minor variations of one idea.
-- Cover a range from safer to bolder approaches when useful.
-- Make tradeoffs explicit so ideas are easy to compare.
-- Keep ideas concrete enough that someone can imagine implementation or execution.
-- Narrow only after the option space is genuinely explored.
-
-## Output expectations
-
-- Distinct options with concise descriptions
-- Tradeoffs, strengths, and risks for each option
-- A recommended direction when appropriate
-
-## Quality checklist
-
-- Options are genuinely different in mechanism or strategy.
-- Ideas respect the stated constraints.
-- Tradeoffs are visible rather than implied.
-- Recommendations, if given, follow from the comparison.
-
-## Handoff notes
-
-- Note whether the ideas are exploratory, implementation-ready, or need structured narrowing next.
-- Pair with structured brainstorming when the next step is selecting and shaping one path.
diff --git a/skills/brainstorming/roadmap-opportunity-prioritization.md b/skills/brainstorming/roadmap-opportunity-prioritization.md
deleted file mode 100644
index d896a48..0000000
--- a/skills/brainstorming/roadmap-opportunity-prioritization.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# Roadmap and Opportunity Prioritization
-
-## Purpose
-
-Choose what to do next by comparing opportunities, maintenance work, and strategic bets against explicit decision criteria.
-
-## When to use
-
-- Too many plausible initiatives compete for limited time
-- Feature work and maintenance work need to be balanced
-- A team needs a more defensible roadmap discussion
-- Promising ideas need sequencing rather than more generation
-
-## Inputs to gather
-
-- Candidate initiatives or workstreams
-- Decision criteria such as impact, urgency, effort, risk reduction, or strategic fit
-- Dependencies, timing constraints, and team capacity
-- Evidence for expected payoff or avoided risk
-
-## How to work
-
-- Make prioritization criteria explicit before ranking work.
-- Compare user value, strategic value, and risk reduction together.
-- Treat maintenance and enabling work as first-class opportunities when they materially improve future delivery.
-- Distinguish what is urgent, what is high leverage, and what is merely attractive.
-- Produce a sequence that a team can actually act on.
-
-## Output expectations
-
-- Prioritized list or roadmap recommendation
-- Clear rationale for order and tradeoffs
-- Notes on what to defer, revisit, or validate next
-
-## Quality checklist
-
-- Priorities reflect stated criteria rather than intuition alone.
-- Sequencing respects dependencies and capacity.
-- Lower-priority items are deferred for a reason, not forgotten accidentally.
-- Maintenance work is evaluated on outcomes, not optics.
-
-## Handoff notes
-
-- Note what new evidence would most change the ranking.
-- Pair with maintenance and technical debt planning or structured brainstorming when the decision needs deeper shaping.
diff --git a/skills/brainstorming/structured-brainstorming.md b/skills/brainstorming/structured-brainstorming.md
deleted file mode 100644
index bd69031..0000000
--- a/skills/brainstorming/structured-brainstorming.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# Structured Brainstorming
-
-## Purpose
-
-Turn rough ideas into decision-ready options by comparing them systematically, narrowing intelligently, and shaping the chosen direction into actionable next steps.
-
-## When to use
-
-- Many ideas exist and the team needs a clear recommendation
-- A promising concept needs scoping before implementation
-- Tradeoffs need to be surfaced explicitly
-- The next step is choosing, sequencing, or planning rather than generating more ideas
-
-## Inputs to gather
-
-- Candidate ideas or possible approaches
-- Decision criteria such as impact, effort, risk, speed, or strategic fit
-- Constraints on time, team, technical feasibility, or audience needs
-- Any assumptions that materially change the choice
-
-## How to work
-
-- Define the decision criteria before ranking options.
-- Compare options on the criteria that actually matter for the request.
-- Remove weak options quickly once the reason is clear.
-- Turn the selected direction into a scoped set of next steps or a buildable outline.
-- Keep the analysis proportional; do not over-formalize simple decisions.
-
-## Output expectations
-
-- Clear comparison of options
-- Recommended direction with reasoning
-- A scoped next-step plan or action outline
-
-## Quality checklist
-
-- Decision criteria are explicit and relevant.
-- The recommendation follows from the comparison rather than preference alone.
-- The chosen path is actionable, not just inspirational.
-- Key assumptions are visible.
-
-## Handoff notes
-
-- Note what would most likely change the recommendation.
-- Pair with feature implementation, repo exploration, or messaging skills when moving from choice to execution.
diff --git a/skills/debugging/bug-triage.md b/skills/debugging/bug-triage.md
deleted file mode 100644
index dd38b92..0000000
--- a/skills/debugging/bug-triage.md
+++ /dev/null
@@ -1,46 +0,0 @@
-# Bug Triage
-
-## Purpose
-
-Frame a defect clearly before or during debugging so the team understands impact, reproduction, suspected scope, and next actions.
-
-## When to use
-
-- A bug report arrives with incomplete detail
-- A failing test or regression needs initial framing
-- Multiple issues compete for attention and severity matters
-- You need a reliable reproduction path before deeper debugging
-
-## Inputs to gather
-
-- Reported symptoms, expected behavior, and actual behavior
-- Reproduction steps, environment, and frequency
-- User impact, severity, and likely affected surfaces
-- Recent changes, logs, or tests that may be related
-
-## How to work
-
-- Turn vague symptoms into a concrete problem statement.
-- Reproduce the issue when possible and tighten the reproduction steps.
-- Separate confirmed facts from assumptions.
-- Estimate impact and likely blast radius before diving into fixes.
-- Identify the next best debugging step if root cause is not yet known.
-
-## Output expectations
-
-- Clear bug statement and reproduction status
-- Impact and severity assessment
-- Suspected scope or likely component area
-- Recommended next debugging or fix step
-
-## Quality checklist
-
-- The issue is described in observable terms rather than guesses.
-- Reproduction details are specific enough to be reused.
-- Impact is clear enough to prioritize intelligently.
-- Unknowns are named instead of hidden.
-
-## Handoff notes
-
-- Record environment details and whether the issue is deterministic, intermittent, or unconfirmed.
-- Pair with debugging workflow once the problem is framed well enough to investigate deeply.
diff --git a/skills/debugging/debugging-workflow.md b/skills/debugging/debugging-workflow.md
deleted file mode 100644
index ac6aba0..0000000
--- a/skills/debugging/debugging-workflow.md
+++ /dev/null
@@ -1,46 +0,0 @@
-# Debugging Workflow
-
-## Purpose
-
-Find root cause efficiently and verify fixes with a disciplined workflow that avoids premature assumptions and shallow symptom treatment.
-
-## When to use
-
-- The defect is real but the cause is unclear
-- A failing test needs investigation
-- The system has inconsistent or environment-specific behavior
-- A regression may have multiple plausible causes
-
-## Inputs to gather
-
-- Reproduction path or failing signal
-- Relevant code paths, logs, traces, state transitions, and recent changes
-- Existing tests or ways to validate a hypothesis
-- Environment details that may influence behavior
-
-## How to work
-
-- Reproduce first when possible, then narrow scope by isolating the smallest failing path.
-- Form hypotheses from evidence, not instinct alone, and invalidate them aggressively.
-- Inspect boundaries: inputs, outputs, state mutations, async timing, external dependencies, and configuration.
-- Fix the root cause rather than only masking symptoms when feasible.
-- Re-run the original failing signal and add regression protection if appropriate.
-
-## Output expectations
-
-- Root cause explanation tied to evidence
-- Fix or recommended fix approach
-- Verification that the original issue is resolved
-- Remaining uncertainty, if any
-
-## Quality checklist
-
-- The explanation connects cause to symptom clearly.
-- The chosen fix addresses the real failure mechanism.
-- Verification includes the original failing path.
-- Regression protection is considered when the bug is likely to recur.
-
-## Handoff notes
-
-- Note whether the issue was fully reproduced, partially inferred, or fixed based on a probable cause.
-- Mention monitoring or follow-up checks if confidence is limited by environment or observability.
diff --git a/skills/debugging/incident-response-stabilization.md b/skills/debugging/incident-response-stabilization.md
deleted file mode 100644
index 34f4c27..0000000
--- a/skills/debugging/incident-response-stabilization.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# Incident Response and Stabilization
-
-## Purpose
-
-Guide high-pressure response to live or high-impact issues by separating immediate stabilization from deeper root-cause correction.
-
-## When to use
-
-- A production issue is actively impacting users or operators
-- A regression needs containment before a complete fix is ready
-- The team needs a calm sequence for triage, mitigation, and follow-up
-- Communication and operational clarity matter as much as code changes
-
-## Inputs to gather
-
-- Current symptoms, severity, affected users, and timing
-- Available logs, metrics, alerts, dashboards, and recent changes
-- Safe rollback, feature flag, degrade, or traffic-shaping options
-- Stakeholders who need updates and what they need to know
-
-## How to work
-
-- Stabilize user impact first if a safe containment path exists.
-- Keep mitigation, diagnosis, and communication distinct but coordinated.
-- Prefer reversible steps under uncertainty.
-- Record what is confirmed versus assumed while the incident is active.
-- After stabilization, convert the incident into structured debugging and prevention work.
-
-## Output expectations
-
-- Stabilization plan or incident response summary
-- Clear mitigation status and next actions
-- Follow-up work for root cause, observability, and prevention
-
-## Quality checklist
-
-- User impact reduction is prioritized appropriately.
-- Risky irreversible changes are avoided under pressure.
-- Communication is clear enough for collaborators to act.
-- Post-incident follow-up is not lost after immediate recovery.
-
-## Handoff notes
-
-- Note what was mitigated versus actually fixed.
-- Pair with debugging workflow and observability once the system is stable enough for deeper work.
diff --git a/skills/documentation/architecture-decision-records.md b/skills/documentation/architecture-decision-records.md
deleted file mode 100644
index 0f649b7..0000000
--- a/skills/documentation/architecture-decision-records.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# Architecture Decision Records
-
-## Purpose
-
-Capture significant technical decisions so future contributors understand what was chosen, why it was chosen, and what tradeoffs were accepted.
-
-## When to use
-
-- A meaningful architectural or platform choice has been made
-- Multiple alternatives were considered and context would otherwise be lost
-- A decision will affect future implementation, migration, or team habits
-- You want to prevent repeated re-litigation of the same tradeoff
-
-## Inputs to gather
-
-- The decision being made
-- Alternatives considered
-- Relevant constraints, drivers, and consequences
-- Current status: proposed, accepted, superseded, or rejected
-
-## How to work
-
-- Record the decision close to when it is made.
-- Keep the record concise but concrete enough to survive future context loss.
-- Explain why the selected option won, not just what it is.
-- Include consequences so future readers understand the cost of the choice.
-- Update or supersede older records rather than leaving conflicting guidance unresolved.
-
-## Output expectations
-
-- A crisp decision record with context, choice, alternatives, and consequences
-- Status that reflects whether the decision is still tentative or settled
-- Links to implementation or follow-up docs when useful
-
-## Quality checklist
-
-- The decision is clear and specific.
-- Alternatives and tradeoffs are visible.
-- Future readers can understand the reasoning without redoing the whole discussion.
-- The record stays short enough to remain useful.
-
-## Handoff notes
-
-- Reference the implementation, technical docs, or migration plan that operationalizes the decision.
-- Pair with architecture and system design for major system changes.
diff --git a/skills/documentation/onboarding-docs.md b/skills/documentation/onboarding-docs.md
deleted file mode 100644
index 6a40528..0000000
--- a/skills/documentation/onboarding-docs.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# Onboarding Documentation
-
-## Purpose
-
-Help new contributors or users become productive quickly by reducing ambiguity, setup friction, and missing context.
-
-## When to use
-
-- Improving setup or first-run guidance
-- Writing contributor onboarding docs
-- Creating "start here" guides for internal or external users
-- Simplifying confusing developer or product entry points
-
-## Inputs to gather
-
-- Current setup steps and prerequisites
-- Common failure points, hidden assumptions, and missing context
-- Existing onboarding flow and repository conventions
-- Intended audience: contributor, operator, customer, or teammate
-
-## How to work
-
-- Optimize for first success, not exhaustiveness.
-- Put prerequisites, setup order, and validation steps in the order a new person needs them.
-- Surface gotchas early rather than burying them after failures occur.
-- Use concrete commands, examples, and expected outcomes when they reduce confusion.
-- Trim insider jargon unless it is explained.
-
-## Output expectations
-
-- A cleaner onboarding path with clear first steps
-- Documentation that reduces setup ambiguity and dead ends
-- Helpful validation or troubleshooting guidance where needed
-
-## Quality checklist
-
-- A new person can tell where to start.
-- Steps are ordered logically and are easy to verify.
-- Prerequisites and common failures are not hidden.
-- The doc avoids assuming too much existing context.
-
-## Handoff notes
-
-- Note any setup steps you could not verify directly.
-- Pair with technical docs when onboarding depends on deeper conceptual explanation.
diff --git a/skills/documentation/technical-docs.md b/skills/documentation/technical-docs.md
deleted file mode 100644
index 02f0870..0000000
--- a/skills/documentation/technical-docs.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# Technical Documentation
-
-## Purpose
-
-Create or update documentation that helps developers, operators, or advanced users understand how the system works and how to use it correctly.
-
-## When to use
-
-- Updating docs after engineering changes
-- Writing usage guides, architecture notes, or operational docs
-- Explaining APIs, workflows, configuration, or system behavior
-- Improving stale or incomplete technical documentation
-
-## Inputs to gather
-
-- The current implementation and the user-visible workflow
-- Existing docs, terminology, and structure in the repo
-- Intended audience and their technical depth
-- Any setup steps, caveats, or common failure points
-
-## How to work
-
-- Document the real behavior of the system, not the hoped-for design.
-- Prefer task-oriented structure when users need to get something done.
-- Use precise terminology that matches the code and UI.
-- Include examples, prerequisites, and pitfalls when they materially improve clarity.
-- Keep docs aligned with adjacent pages and avoid fragmenting the source of truth.
-
-## Output expectations
-
-- Clear, accurate documentation update or new draft
-- Audience-appropriate level of technical detail
-- Explicit caveats, prerequisites, and compatibility notes when relevant
-
-## Quality checklist
-
-- Instructions are accurate against the current implementation.
-- The document helps someone complete a real task or understand a real concept.
-- Terms and examples are consistent with the product and codebase.
-- Important caveats are easy to find.
-
-## Handoff notes
-
-- Mention what was verified directly in code versus inferred from context.
-- Note any related docs that should be updated later to stay consistent.
diff --git a/skills/marketing/content-strategy-seo.md b/skills/marketing/content-strategy-seo.md
deleted file mode 100644
index feeba4f..0000000
--- a/skills/marketing/content-strategy-seo.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# Content Strategy and SEO
-
-## Purpose
-
-Create durable content plans and search-aligned messaging that compound over time instead of only supporting one launch moment.
-
-## When to use
-
-- Planning evergreen content around a product area
-- Improving discoverability for technical or product topics
-- Aligning content to audience intent and search behavior
-- Deciding which topics deserve durable written assets
-
-## Inputs to gather
-
-- Audience segments and their recurring questions
-- Product strengths, proof points, and topic authority
-- Existing content library and content gaps
-- Desired business outcome: discovery, education, conversion, or retention
-
-## How to work
-
-- Start from audience intent and recurring problems, not isolated keywords alone.
-- Organize content into durable themes that the product can support credibly.
-- Align titles, structure, and calls to action with user intent.
-- Avoid search-driven copy that weakens clarity or trust.
-- Prefer content that stays useful as the product evolves.
-
-## Output expectations
-
-- Content strategy, topic map, or SEO-aware draft direction
-- Prioritized content opportunities with rationale
-- Notes on how content connects to product positioning and documentation
-
-## Quality checklist
-
-- Recommendations reflect real audience needs.
-- Content ideas support durable value, not shallow traffic grabs.
-- Search alignment does not distort message clarity.
-- The strategy can inform multiple future assets.
-
-## Handoff notes
-
-- Note which assumptions are based on audience reasoning versus actual search data.
-- Pair with messaging/positioning and technical docs for strong, credible long-tail content.
diff --git a/skills/marketing/marketing-content.md b/skills/marketing/marketing-content.md
deleted file mode 100644
index f255430..0000000
--- a/skills/marketing/marketing-content.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# Marketing Content
-
-## Purpose
-
-Create external-facing content that explains, promotes, or launches product capabilities in a way that is accurate, audience-aware, and compelling.
-
-## When to use
-
-- Drafting launch posts, emails, feature pages, announcements, or social content
-- Turning product or engineering work into outward-facing communication
-- Adapting one core message into multiple channels
-- Creating content tied to a release or campaign
-
-## Inputs to gather
-
-- Audience, channel, and desired action
-- The actual product change or offer being communicated
-- Supporting proof points, examples, and differentiators
-- Voice, tone, and length constraints
-
-## How to work
-
-- Lead with why the audience should care.
-- Ground claims in the real product and its benefits.
-- Structure content so it is easy to scan and repurpose.
-- Tailor tone and density to the channel instead of reusing the same draft everywhere.
-- Keep technical explanations accurate while translating them into audience-relevant outcomes.
-
-## Output expectations
-
-- A polished draft for the requested channel
-- Supporting variations or headline options when useful
-- Clear call to action where appropriate
-
-## Quality checklist
-
-- The content is audience-centered, not feature-dump centered.
-- Claims are specific and defensible.
-- The narrative is easy to scan and follow.
-- The output matches the requested medium and length.
-
-## Handoff notes
-
-- State which audience and channel the draft targets.
-- Pair with messaging/positioning when the strategic framing is not yet settled.
diff --git a/skills/marketing/messaging-positioning.md b/skills/marketing/messaging-positioning.md
deleted file mode 100644
index fc1b4b4..0000000
--- a/skills/marketing/messaging-positioning.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# Messaging and Positioning
-
-## Purpose
-
-Clarify who the product or feature is for, what value it provides, why it matters now, and how it differs from alternatives.
-
-## When to use
-
-- Defining or refining product narrative
-- Preparing launches, landing pages, or feature announcements
-- Choosing how to frame a new capability for a target audience
-- Aligning product, UX, and marketing language around one story
-
-## Inputs to gather
-
-- Target audience and their pain points
-- Product capability, strengths, and evidence
-- Competitive or alternative solutions
-- Business goal of the messaging effort
-
-## How to work
-
-- Start with audience pain or desired outcome, then connect the product to that need.
-- Distinguish core value, supporting proof, and differentiators.
-- Avoid vague slogans unless they are backed by a concrete explanation.
-- Stress-test the message against realistic alternatives and skeptical readers.
-- Produce a tight core narrative that other copy can inherit.
-
-## Output expectations
-
-- Clear positioning statement or message framework
-- Defined audience, value proposition, and differentiators
-- Candidate headlines, pillars, or narrative directions when useful
-
-## Quality checklist
-
-- The message is specific about audience and value.
-- Differentiation is real, not generic category language.
-- Claims are supportable by the product.
-- The narrative can guide product copy and campaign content consistently.
-
-## Handoff notes
-
-- Note open questions about audience, market, or product maturity if they limit confidence.
-- Pair with product copy or marketing content to turn the narrative into shipped assets.
diff --git a/skills/marketing/product-copy.md b/skills/marketing/product-copy.md
deleted file mode 100644
index 5c5c137..0000000
--- a/skills/marketing/product-copy.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# Product Copy
-
-## Purpose
-
-Write concise, user-facing product language that is clear, useful, on-brand, and matched to the immediate interface or conversion context.
-
-## When to use
-
-- Naming buttons, labels, helper text, empty states, and error messages
-- Tightening landing page or feature page copy
-- Improving clarity and persuasion in product-adjacent text
-- Rewriting awkward or confusing interface wording
-
-## Inputs to gather
-
-- Audience, goal, and context of the text
-- Current product voice and terminology
-- UI constraints such as length, hierarchy, and surrounding elements
-- Desired action or decision the copy should support
-
-## How to work
-
-- Optimize for clarity first, persuasion second, cleverness last.
-- Use the words users expect based on the product and task.
-- Match the level of confidence and urgency to the action being requested.
-- Keep text tight and scannable, especially in UI contexts.
-- Offer alternatives when tone or positioning is uncertain.
-
-## Output expectations
-
-- Final copy or strong candidate options
-- Brief rationale when choosing between meaningful directions
-- Notes on character, tone, or placement constraints when relevant
-
-## Quality checklist
-
-- Copy is clear on first read.
-- The wording fits the user's moment and intent.
-- Claims are credible and specific.
-- Text length is appropriate to the surface.
-
-## Handoff notes
-
-- Note if final selection depends on brand voice or product strategy not yet defined.
-- Pair with UX review for interface clarity and with messaging/positioning for strategic alignment.
diff --git a/skills/software/api-backend.md b/skills/software/api-backend.md
deleted file mode 100644
index 848c48c..0000000
--- a/skills/software/api-backend.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# API and Backend Work
-
-## Purpose
-
-Guide server-side, service, API, data, and integration changes with attention to contracts, compatibility, failure handling, and operational impact.
-
-## When to use
-
-- Modifying endpoints, handlers, services, jobs, or data flows
-- Adding or changing schemas, persistence, or integration behavior
-- Working on backend business logic or infrastructure-facing code
-- Investigating performance, reliability, or contract issues on the server side
-
-## Inputs to gather
-
-- API contracts, schema, storage models, and service boundaries
-- Existing validation, auth, error handling, and observability patterns
-- Compatibility constraints for clients, data, and deployments
-- Current tests and representative request or event flows
-
-## How to work
-
-- Trace the full request or job lifecycle before changing a boundary.
-- Preserve compatibility intentionally or document the break clearly.
-- Handle validation, authorization, error responses, and retries in line with existing system behavior.
-- Consider migration, rollout, and operational visibility when data or contracts change.
-- Add or update tests at the right layer for the change.
-
-## Output expectations
-
-- Working backend change with contract implications made explicit
-- Notes on schema, config, data, or rollout impact
-- Verification results covering the critical paths
-
-## Quality checklist
-
-- Inputs and outputs are validated appropriately.
-- Failure handling is explicit and consistent.
-- Compatibility and migration impact are understood.
-- Logging, metrics, or observability concerns are addressed when relevant.
-
-## Handoff notes
-
-- Call out any required coordination with frontend, data migration, configuration, or deployment steps.
-- Note backwards-incompatible changes clearly and early.
diff --git a/skills/software/architecture-system-design.md b/skills/software/architecture-system-design.md
deleted file mode 100644
index d8dad30..0000000
--- a/skills/software/architecture-system-design.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# Architecture and System Design
-
-## Purpose
-
-Shape meaningful technical direction so systems stay understandable, evolvable, and aligned with product needs over time.
-
-## When to use
-
-- Designing a major feature or subsystem
-- Changing service boundaries, module boundaries, or core data flow
-- Evaluating multiple implementation approaches with long-term consequences
-- Preparing work that will influence maintainability, scale, or team velocity
-
-## Inputs to gather
-
-- Current architecture, boundaries, and pain points
-- Product goals, scale expectations, and reliability constraints
-- Existing patterns, platform constraints, and team operating model
-- Compatibility, migration, and rollout concerns
-
-## How to work
-
-- Start from the user or system outcome, then identify the simplest architecture that supports it well.
-- Make tradeoffs explicit: complexity, performance, reliability, maintainability, and delivery speed.
-- Preserve useful existing boundaries unless there is a clear reason to change them.
-- Prefer designs that are easy to operate and easy for the team to understand.
-- Document why the chosen path is better than the main alternatives.
-
-## Output expectations
-
-- Clear recommended design or architecture direction
-- Explicit tradeoffs and constraints
-- Interfaces, boundaries, and rollout considerations that matter for implementation
-
-## Quality checklist
-
-- The design solves the actual problem, not a hypothetical future one.
-- Tradeoffs are named clearly enough to guide later decisions.
-- Complexity is justified by concrete needs.
-- Operational and migration consequences are not ignored.
-
-## Handoff notes
-
-- Pair with architecture decision records when the choice should be preserved for future contributors.
-- Call out which parts are decided versus intentionally deferred.
diff --git a/skills/software/code-review.md b/skills/software/code-review.md
deleted file mode 100644
index b8cf65e..0000000
--- a/skills/software/code-review.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# Code Review
-
-## Purpose
-
-Review code with a bug-finding mindset that prioritizes correctness, regressions, risky assumptions, edge cases, and missing tests over style commentary.
-
-## When to use
-
-- Reviewing a pull request or patch
-- Auditing a risky change before merge
-- Evaluating whether a change is safe to ship
-- Checking for test and documentation gaps
-
-## Inputs to gather
-
-- The diff or changed files
-- Nearby code paths and contracts affected by the change
-- Existing tests, especially those intended to cover the modified behavior
-- Context on expected behavior, rollout risk, and compatibility requirements
-
-## How to work
-
-- Start with correctness, then move to regressions, then test gaps, then maintainability risks.
-- Trace changed code through call sites, error paths, and data flow rather than reading only the edited lines in isolation.
-- Focus comments on issues that materially affect behavior, safety, or maintainability.
-- Be explicit about severity and the concrete consequence of each issue.
-- Keep summary brief after listing the findings.
-
-## Output expectations
-
-- A prioritized list of findings with clear reasoning
-- Open questions or assumptions that affect confidence
-- Brief summary of overall risk after the findings
-
-## Quality checklist
-
-- Findings identify real behavior or verification risk, not cosmetic preferences.
-- Severity is proportional to user impact and likelihood.
-- Missing tests are called out where they reduce confidence materially.
-- If no issues are found, residual risk and coverage gaps are still noted.
-
-## Handoff notes
-
-- Include file references and tight line references when available.
-- Distinguish confirmed issues from lower-confidence concerns.
diff --git a/skills/software/database-migrations.md b/skills/software/database-migrations.md
deleted file mode 100644
index 02924d7..0000000
--- a/skills/software/database-migrations.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# Database Migrations and Data Evolution
-
-## Purpose
-
-Change schemas and data safely while protecting compatibility, correctness, rollout reliability, and recovery options.
-
-## When to use
-
-- Adding, removing, or changing database schema
-- Backfilling or transforming data
-- Introducing compatibility windows between old and new code
-- Planning rollout for data-sensitive changes
-
-## Inputs to gather
-
-- Current schema, access patterns, and data volume
-- Migration tooling and deployment model
-- Compatibility requirements across services, jobs, or clients
-- Rollback constraints and data recovery options
-
-## How to work
-
-- Prefer staged migrations when compatibility matters: expand, backfill, switch reads or writes, then contract.
-- Minimize lock risk, data loss risk, and long-running migration risk.
-- Consider how old and new code will coexist during rollout.
-- Define verification steps for schema state and critical data correctness.
-- Document irreversible steps and operator actions clearly.
-
-## Output expectations
-
-- Safe migration plan or implementation
-- Compatibility and rollout notes
-- Verification and rollback considerations
-
-## Quality checklist
-
-- The migration is safe for the repository's deployment model.
-- Data correctness is protected during and after rollout.
-- Backwards and forwards compatibility are considered when needed.
-- Irreversible or risky steps are made explicit.
-
-## Handoff notes
-
-- Call out sequencing requirements across application code, migrations, and background jobs.
-- Pair with release/change summary and technical docs when operators or teammates need a clear rollout path.
diff --git a/skills/software/dependency-lifecycle.md b/skills/software/dependency-lifecycle.md
deleted file mode 100644
index a7bba5b..0000000
--- a/skills/software/dependency-lifecycle.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# Dependency Lifecycle Management
-
-## Purpose
-
-Keep dependencies healthy over time by balancing security, compatibility, maintainability, and upgrade cost.
-
-## When to use
-
-- Upgrading libraries, frameworks, runtimes, or tooling
-- Auditing dependency risk or staleness
-- Reducing upgrade backlog and ecosystem drift
-- Planning how to adopt breaking changes safely
-
-## Inputs to gather
-
-- Current dependency versions and their role in the system
-- Changelogs, upgrade guides, and breaking changes
-- Existing test coverage and high-risk integration points
-- Security, support-window, or maintenance concerns
-
-## How to work
-
-- Prefer focused upgrade batches that are easy to validate and revert.
-- Separate mechanical version bumps from behavior-changing adaptation when possible.
-- Read authoritative release notes before changing usage patterns.
-- Verify the highest-risk integration paths, not just installation success.
-- Capture follow-up work when a safe incremental upgrade leaves known deprecated patterns behind.
-
-## Output expectations
-
-- Upgrade plan or completed upgrade with adaptation notes
-- Risk summary for changed dependencies
-- Verification results and known remaining debt
-
-## Quality checklist
-
-- The upgrade reduces risk or maintenance burden meaningfully.
-- Breaking changes are understood before implementation.
-- Validation covers the most likely failure surfaces.
-- Residual deprecations or postponed steps are documented clearly.
-
-## Handoff notes
-
-- Note whether the work is a full upgrade, a safe intermediate step, or a reconnaissance pass.
-- Pair with test strategy and release/change summary when adoption affects developer workflow or runtime behavior.
diff --git a/skills/software/feature-implementation.md b/skills/software/feature-implementation.md
deleted file mode 100644
index 9119e01..0000000
--- a/skills/software/feature-implementation.md
+++ /dev/null
@@ -1,48 +0,0 @@
-# Feature Implementation
-
-## Purpose
-
-Guide implementation of new behavior or meaningful changes to existing behavior with a bias toward working software, repository alignment, and practical verification.
-
-## When to use
-
-- Building a new feature
-- Expanding an existing workflow
-- Making a multi-file change that affects user or developer behavior
-- Turning a scoped request into implemented code
-
-## Inputs to gather
-
-- Relevant entrypoints, modules, and surrounding patterns
-- Existing interfaces, types, schema, and tests
-- User goal, success criteria, constraints, and impacted surfaces
-- Any repository instructions that override generic defaults
-
-## How to work
-
-- Inspect the codebase before editing and identify the smallest coherent change set.
-- Prefer existing patterns over introducing novel structure unless the current patterns are clearly limiting.
-- Implement end-to-end behavior, not just partial scaffolding, when feasible.
-- Keep logic changes close to the relevant module boundaries and avoid unrelated cleanup unless it materially helps the task.
-- Validate with targeted tests, builds, or manual checks appropriate to the repository.
-- Update docs, examples, or change notes when the feature alters usage or expectations.
-
-## Output expectations
-
-- A working implementation or a clearly explained blocker
-- Concise summary of what changed and why
-- Validation results and any gaps that remain
-- Notes on follow-up work only when it is genuinely important
-
-## Quality checklist
-
-- The change matches the stated goal and avoids unrelated churn.
-- Naming, structure, and style fit the existing codebase.
-- Errors, edge cases, and obvious failure paths are handled.
-- Verification is appropriate for the size and risk of the change.
-- User-facing or developer-facing behavior changes are documented when needed.
-
-## Handoff notes
-
-- Mention touched subsystems and any assumptions made because the repo did not answer them.
-- Call out migration or rollout concerns if the feature affects data, config, or compatibility.
diff --git a/skills/software/frontend-ui-implementation.md b/skills/software/frontend-ui-implementation.md
deleted file mode 100644
index f57e6eb..0000000
--- a/skills/software/frontend-ui-implementation.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# Frontend UI Implementation
-
-## Purpose
-
-Guide interface implementation that balances correctness, usability, clarity, performance, and consistency with the existing product experience.
-
-## When to use
-
-- Building or updating pages, components, and interactions
-- Implementing client-side state or view logic
-- Adjusting layout, form flows, states, and visual feedback
-- Shipping UI changes tied to product behavior
-
-## Inputs to gather
-
-- Existing design system, component patterns, and styling conventions
-- User flow, content requirements, and responsive constraints
-- State, API, and error/loading behavior tied to the UI
-- Current tests, stories, screenshots, or acceptance criteria if available
-
-## How to work
-
-- Preserve the established visual language unless the task explicitly calls for a new direction.
-- Design for the full experience: loading, empty, error, success, and edge states.
-- Keep interaction logic understandable and avoid overengineering small UI behavior.
-- Use content, hierarchy, and spacing intentionally so the UI communicates clearly.
-- Validate on the most important screen sizes or states that the repository can reasonably support.
-
-## Output expectations
-
-- A functional UI change that is coherent visually and behaviorally
-- Clear notes on user-facing behavior and state handling
-- Verification appropriate to the stack, such as tests, stories, or manual checks
-
-## Quality checklist
-
-- The UI is understandable without hidden assumptions.
-- Important states are handled, not just the happy path.
-- Visual and code patterns fit the existing app.
-- Accessibility, responsiveness, and copy quality are considered.
-
-## Handoff notes
-
-- Mention any UX debts, unresolved visual questions, or browser/device gaps that remain.
-- Pair with UX review or product copy when usability or wording is central to the task.
diff --git a/skills/software/maintenance-technical-debt.md b/skills/software/maintenance-technical-debt.md
deleted file mode 100644
index 09c1e18..0000000
--- a/skills/software/maintenance-technical-debt.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# Maintenance and Technical Debt Planning
-
-## Purpose
-
-Turn vague maintenance needs into a practical, sequenced plan that improves delivery speed, reliability, and future change safety over time.
-
-## When to use
-
-- The codebase has accumulated risky or slowing debt
-- A team needs to prioritize cleanup against feature work
-- Repeated friction suggests structural maintenance investment is overdue
-- You need to explain why maintenance work matters in product terms
-
-## Inputs to gather
-
-- Known pain points, repeated failures, and slow areas in delivery
-- Architectural hotspots, obsolete patterns, and fragile dependencies
-- Team constraints, roadmap pressure, and acceptable disruption
-- Evidence of cost: incidents, churn, slowed feature work, or support burden
-
-## How to work
-
-- Focus on debt that materially changes future delivery, reliability, or risk.
-- Group issues into themes rather than a flat list of annoyances.
-- Prioritize by impact, urgency, and dependency relationships.
-- Prefer incremental sequences that can ship safely between feature work.
-- Translate maintenance value into outcomes the team can defend.
-
-## Output expectations
-
-- Prioritized maintenance plan or backlog proposal
-- Clear rationale for what should happen now versus later
-- Sequencing guidance and expected payoff
-
-## Quality checklist
-
-- Recommendations are tied to real delivery or reliability pain.
-- Prioritization is explicit and defensible.
-- The plan is incremental enough to execute.
-- Work is framed in terms of reduced risk or increased velocity, not vague cleanliness.
-
-## Handoff notes
-
-- Note what evidence would strengthen or change the prioritization.
-- Pair with roadmap and opportunity prioritization when balancing debt against new initiatives.
diff --git a/skills/software/observability-operability.md b/skills/software/observability-operability.md
deleted file mode 100644
index bde62a9..0000000
--- a/skills/software/observability-operability.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# Observability and Operability
-
-## Purpose
-
-Make systems easier to understand, debug, and run by improving signals, diagnostics, and operational readiness around important behavior.
-
-## When to use
-
-- A system is hard to diagnose in production or staging
-- New functionality needs useful logs, metrics, traces, or alerts
-- Operational ownership is unclear during failures or rollout
-- Reliability work needs better visibility before deeper changes
-
-## Inputs to gather
-
-- Critical workflows, failure modes, and current diagnostic signals
-- Existing logging, metrics, tracing, dashboards, and alerts
-- Operator needs during rollout, incident response, and debugging
-- Noise constraints and performance or cost considerations
-
-## How to work
-
-- Instrument the questions a responder will need answered during failure.
-- Prefer signals tied to user-impacting behavior over vanity metrics.
-- Make logs structured and actionable when possible.
-- Add observability close to important boundaries and state transitions.
-- Keep signal quality high by avoiding low-value noise.
-
-## Output expectations
-
-- Improved observability or an operability plan for the target area
-- Clear explanation of what new signals reveal
-- Notes on alerting, dashboard, or rollout support when relevant
-
-## Quality checklist
-
-- Signals help detect and diagnose meaningful failures.
-- Instrumentation is focused and not excessively noisy.
-- Operational usage is considered, not just implementation convenience.
-- Added visibility maps to critical user or system outcomes.
-
-## Handoff notes
-
-- Mention what incidents or debugging tasks the new observability should make easier.
-- Pair with debugging workflow, incident response, or performance optimization when diagnosis is the main bottleneck.
diff --git a/skills/software/performance-optimization.md b/skills/software/performance-optimization.md
deleted file mode 100644
index 6e97c1e..0000000
--- a/skills/software/performance-optimization.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# Performance Optimization
-
-## Purpose
-
-Improve responsiveness and efficiency by focusing on the bottlenecks that matter most to users, systems, or operating cost.
-
-## When to use
-
-- Investigating slow pages, endpoints, jobs, or queries
-- Reducing memory, CPU, network, or rendering overhead
-- Preventing regressions in critical paths
-- Prioritizing optimization work with limited time
-
-## Inputs to gather
-
-- Performance symptoms, target metrics, and critical user or system paths
-- Existing measurements, profiles, logs, traces, or benchmarks
-- Current architecture and known hot spots
-- Acceptable tradeoffs in complexity, cost, and feature scope
-
-## How to work
-
-- Measure or inspect evidence before optimizing.
-- Focus on the dominant bottleneck rather than broad cleanup.
-- Prefer changes that improve the critical path without making the system harder to maintain.
-- Re-measure after changes when possible.
-- Capture the conditions under which the optimization matters so future work does not cargo-cult it.
-
-## Output expectations
-
-- Bottleneck diagnosis and recommended or implemented improvement
-- Before-and-after evidence when available
-- Notes on tradeoffs, limits, and remaining hot spots
-
-## Quality checklist
-
-- Optimization targets a real bottleneck.
-- Claimed gains are grounded in evidence, not assumption alone.
-- Complexity added by the optimization is justified.
-- Regression risk is considered for correctness and maintainability.
-
-## Handoff notes
-
-- Note whether the result is measured, estimated, or hypothesis-driven.
-- Pair with observability and operability when instrumentation is weak.
diff --git a/skills/software/refactoring.md b/skills/software/refactoring.md
deleted file mode 100644
index a049ccf..0000000
--- a/skills/software/refactoring.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# Refactoring
-
-## Purpose
-
-Improve code structure, readability, maintainability, or modularity without intentionally changing externally observable behavior.
-
-## When to use
-
-- Simplifying complex logic
-- Extracting clearer abstractions
-- Reducing duplication or coupling
-- Preparing code for future work while preserving behavior
-
-## Inputs to gather
-
-- Current behavior and tests that define expected outcomes
-- Structural pain points in the relevant modules
-- Constraints around public APIs, compatibility, or performance
-- Existing patterns for abstraction and module boundaries
-
-## How to work
-
-- Preserve behavior intentionally and define what must remain unchanged before editing.
-- Favor small, reviewable moves over sweeping rewrites unless the code is already unsafe to work in incrementally.
-- Keep interface changes minimal and justified.
-- Add or strengthen tests when behavior preservation is important and current coverage is weak.
-- Separate cleanup that supports the refactor from unrelated aesthetic changes.
-
-## Output expectations
-
-- Cleaner code with behavior preserved
-- Clear explanation of the structural improvement
-- Verification evidence that the refactor did not break expected behavior
-
-## Quality checklist
-
-- Intended behavior is unchanged unless explicitly documented otherwise.
-- The resulting structure is easier to understand or extend.
-- Interface changes are minimal, justified, and documented.
-- Added complexity is avoided unless it buys meaningful maintainability.
-
-## Handoff notes
-
-- Call out any areas where behavior preservation is inferred rather than strongly verified.
-- Note future cleanup opportunities only if they naturally follow from the refactor.
diff --git a/skills/software/release-change-summary.md b/skills/software/release-change-summary.md
deleted file mode 100644
index d9b59e3..0000000
--- a/skills/software/release-change-summary.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# Release and Change Summary
-
-## Purpose
-
-Explain shipped or proposed changes clearly for developers, operators, collaborators, or end users, with emphasis on what changed, why it matters, and what action is required.
-
-## When to use
-
-- Writing release notes or changelog entries
-- Summarizing completed engineering work
-- Explaining migration or rollout impact
-- Turning technical changes into clear stakeholder communication
-
-## Inputs to gather
-
-- The actual code or product changes
-- Intended audience and their level of technical depth
-- Any rollout, migration, compatibility, or operational considerations
-- Linked docs, issues, or feature context that explains why the change exists
-
-## How to work
-
-- Lead with the user-meaningful change, not internal implementation trivia.
-- Group related changes into a few clear themes rather than a raw diff dump.
-- Call out required actions, migrations, or risks explicitly.
-- Tailor the level of detail to the audience.
-- Keep the summary accurate to the implementation that actually landed.
-
-## Output expectations
-
-- Clear release notes, summary, or change communication draft
-- Audience-appropriate explanation of impact and required action
-- Explicit mention of follow-up items only when relevant
-
-## Quality checklist
-
-- The summary matches the real change, not the original intent alone.
-- Important caveats, migrations, and compatibility notes are visible.
-- Wording is concise and easy to scan.
-- Audience knowledge level is respected.
-
-## Handoff notes
-
-- Say who the summary is for and what medium it targets if that is not obvious.
-- Pair with technical docs or marketing skills when the output needs deeper explanation or stronger positioning.
diff --git a/skills/software/repo-exploration.md b/skills/software/repo-exploration.md
deleted file mode 100644
index ae45f00..0000000
--- a/skills/software/repo-exploration.md
+++ /dev/null
@@ -1,44 +0,0 @@
-# Repository Exploration
-
-## Purpose
-
-Rapidly build accurate context before implementation, debugging, or planning by identifying the right files, flows, conventions, and constraints in the repository.
-
-## When to use
-
-- Starting in an unfamiliar repository
-- Locating the right implementation area for a request
-- Understanding current architecture before proposing changes
-- Reducing ambiguity in a vague task
-
-## Inputs to gather
-
-- Repository layout, entrypoints, and key modules
-- Build, test, and dependency configuration
-- Existing patterns for similar features or workflows
-- Any local instructions, docs, or conventions already in the repo
-
-## How to work
-
-- Start broad, then narrow quickly to the files and flows relevant to the task.
-- Favor authoritative sources in the repo such as configs, types, interfaces, docs, and existing implementations.
-- Identify where decisions are already made by the codebase so you do not reinvent them.
-- Summarize findings in terms of how they affect the next action.
-- Stop exploring once the path to execution is clear enough.
-
-## Output expectations
-
-- Concise map of the relevant code paths and conventions
-- Recommended starting points for changes or further investigation
-- Key unknowns that still require validation
-
-## Quality checklist
-
-- Exploration answers practical implementation questions rather than producing generic architecture prose.
-- Findings are tied to concrete files, modules, or workflows.
-- Enough context is gathered to act confidently without over-reading the entire repo.
-
-## Handoff notes
-
-- Mention the most relevant files, commands, and repo conventions discovered.
-- Flag ambiguous areas where multiple plausible implementation paths exist.
diff --git a/skills/software/security-review-hardening.md b/skills/software/security-review-hardening.md
deleted file mode 100644
index 351973c..0000000
--- a/skills/software/security-review-hardening.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# Security Review and Hardening
-
-## Purpose
-
-Reduce avoidable security risk by reviewing trust boundaries, sensitive data handling, exposure paths, and abuse opportunities in the relevant system area.
-
-## When to use
-
-- Shipping authentication, authorization, input handling, or sensitive workflows
-- Reviewing an externally exposed feature or API
-- Auditing risky changes for common security failures
-- Hardening an existing system area with known gaps
-
-## Inputs to gather
-
-- Trust boundaries, user roles, and entry points
-- Sensitive data flows, secrets, tokens, or privileged operations
-- Existing auth, validation, logging, and rate limiting patterns
-- Relevant compliance or threat concerns if known
-
-## How to work
-
-- Start with who can do what, from where, and with which inputs.
-- Check validation, authorization, data exposure, secret handling, and abuse resistance.
-- Prefer concrete mitigations over vague warnings.
-- Align with existing security controls unless they are clearly insufficient.
-- Call out unverified areas when the environment or tooling limits confidence.
-
-## Output expectations
-
-- Concrete risks found or a scoped hardening plan
-- Recommended mitigations tied to the actual threat surface
-- Clear statement of confidence and any blind spots
-
-## Quality checklist
-
-- Review covers the real trust boundaries and attack surface.
-- Findings describe exploit consequence, not just theoretical concern.
-- Mitigations are practical for the system and team.
-- Residual risk is visible where hardening is incomplete.
-
-## Handoff notes
-
-- Separate must-fix risks from defense-in-depth improvements.
-- Pair with code review, API/backend work, and observability when the issue spans implementation and detection.
diff --git a/skills/software/test-strategy.md b/skills/software/test-strategy.md
deleted file mode 100644
index 8412cf8..0000000
--- a/skills/software/test-strategy.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# Test Strategy
-
-## Purpose
-
-Choose and evaluate the right level of verification so changes are covered proportionally to their risk, behavior, and maintenance cost.
-
-## When to use
-
-- Adding or updating tests for a feature or bug fix
-- Deciding what verification is necessary before shipping
-- Auditing coverage gaps in existing code
-- Designing regression protection for risky areas
-
-## Inputs to gather
-
-- The behavior being changed or protected
-- Current test layout, tooling, and conventions
-- Known failure modes, regressions, or edge cases
-- Constraints on test speed, environment, and confidence needs
-
-## How to work
-
-- Match test level to risk: unit for logic, integration for boundaries, end-to-end for critical workflows.
-- Prefer the smallest test that meaningfully protects the behavior.
-- Cover success paths, likely failure paths, and regressions suggested by the change.
-- Reuse existing fixtures and patterns where possible.
-- If tests are not feasible, define alternate validation steps and explain the gap.
-
-## Output expectations
-
-- Specific recommended or implemented tests
-- Clear rationale for test level and scope
-- Any remaining uncovered risks or follow-up test ideas
-
-## Quality checklist
-
-- Tests target behavior, not implementation trivia.
-- Coverage includes the change's highest-risk paths.
-- Test design fits repository conventions and runtime cost expectations.
-- Non-tested areas are called out explicitly when important.
-
-## Handoff notes
-
-- Note flaky, expensive, or environment-dependent checks separately from fast local confidence checks.
-- Mention whether the test plan is implemented, recommended, or partially blocked.
diff --git a/skills/ui-ux/accessibility-review.md b/skills/ui-ux/accessibility-review.md
deleted file mode 100644
index fad7036..0000000
--- a/skills/ui-ux/accessibility-review.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# Accessibility Review
-
-## Purpose
-
-Improve inclusive usability by checking whether interfaces are operable, understandable, and robust for people using different devices, input methods, and assistive technologies.
-
-## When to use
-
-- Reviewing or implementing user-facing UI
-- Checking forms, dialogs, navigation, or interactive states
-- Improving keyboard support, semantics, contrast, or feedback
-- Raising the quality bar for long-lived interface patterns
-
-## Inputs to gather
-
-- Relevant screens, components, and interaction flows
-- Existing design system, semantic patterns, and accessibility goals
-- Keyboard, screen reader, focus, contrast, and motion considerations
-- Known constraints in the stack or component library
-
-## How to work
-
-- Check the main user path with keyboard and semantics in mind first.
-- Review labels, focus order, state announcements, contrast, and error clarity.
-- Prioritize issues that block task completion or create major confusion.
-- Recommend changes that fit the current implementation model and team capacity.
-- Treat accessibility as product quality, not a final polish pass.
-
-## Output expectations
-
-- Clear accessibility findings or implementation guidance
-- Prioritized fixes by impact on usability and inclusion
-- Notes on what was inspected directly versus inferred
-
-## Quality checklist
-
-- Findings focus on real interaction barriers.
-- Recommendations are specific enough to implement.
-- The review covers both semantics and user experience.
-- High-impact accessibility gaps are surfaced early.
-
-## Handoff notes
-
-- Mention whether checks were code-based, visual, or manually reasoned.
-- Pair with frontend UI implementation and design system consistency when shipping durable fixes.
diff --git a/skills/ui-ux/design-system-consistency.md b/skills/ui-ux/design-system-consistency.md
deleted file mode 100644
index 478f8ca..0000000
--- a/skills/ui-ux/design-system-consistency.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# Design System and UI Consistency
-
-## Purpose
-
-Promote reusable, scalable UI patterns so the interface stays coherent as the product grows.
-
-## When to use
-
-- A UI area is drifting from existing patterns
-- Reusable components or patterns should replace one-off implementations
-- A feature adds new patterns that may affect future screens
-- You want to improve consistency without a full redesign
-
-## Inputs to gather
-
-- Existing components, tokens, layout patterns, and style conventions
-- The new or changed UI requirements
-- Current inconsistencies, duplication, or local hacks
-- Constraints from the stack, theme system, or design resources
-
-## How to work
-
-- Reuse existing components and conventions before inventing new ones.
-- Introduce new patterns only when the current system cannot express the need cleanly.
-- Optimize for maintainability and consistency, not just a one-screen outcome.
-- Keep component APIs and styling patterns understandable.
-- Document new reusable patterns when they materially expand the design system.
-
-## Output expectations
-
-- More consistent UI implementation or a clear plan for pattern consolidation
-- Notes on reused versus newly introduced patterns
-- Guidance on where the system should expand carefully
-
-## Quality checklist
-
-- The UI becomes more coherent, not more fragmented.
-- Reuse is meaningful and does not force a poor fit.
-- New abstractions are justified by repeated or durable need.
-- The solution helps future features move faster.
-
-## Handoff notes
-
-- Note whether the work is local cleanup, reusable component work, or system-level direction.
-- Pair with UX review and frontend implementation when consistency changes affect behavior and clarity.
diff --git a/skills/ui-ux/ux-review.md b/skills/ui-ux/ux-review.md
deleted file mode 100644
index 160231b..0000000
--- a/skills/ui-ux/ux-review.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# UX Review
-
-## Purpose
-
-Evaluate an interface or flow for clarity, usability, friction, trust, and task completion quality, then turn those observations into actionable improvements.
-
-## When to use
-
-- Reviewing a screen or flow before or after implementation
-- Looking for usability issues in forms, navigation, settings, or onboarding
-- Improving hierarchy, copy clarity, state handling, or feedback
-- Assessing whether an interface supports the intended user goal well
-
-## Inputs to gather
-
-- Screens, flows, components, or descriptions of the experience
-- Target user goal and success criteria
-- Existing design system or product patterns
-- Constraints such as device, context, accessibility, or content requirements
-
-## How to work
-
-- Review from the user's task perspective rather than from the component tree outward.
-- Check whether the next action is obvious at each step.
-- Evaluate hierarchy, wording, spacing, feedback, and state transitions together.
-- Prioritize issues by how much they block comprehension, confidence, or completion.
-- Suggest improvements that fit the current product language unless redesign is requested.
-
-## Output expectations
-
-- Clear list of UX issues or strengths
-- Prioritized recommendations with rationale
-- Notes on where UI changes, copy changes, or research would help most
-
-## Quality checklist
-
-- Feedback is tied to user outcomes, not vague aesthetic preference.
-- Important states such as empty, loading, error, and success are considered.
-- Recommendations are specific enough to act on.
-- Suggestions fit the product's current level of complexity and style.
-
-## Handoff notes
-
-- Distinguish between usability issues, visual polish issues, and copy issues.
-- Pair with frontend implementation or product copy when turning review into shipped changes.