diff --git a/skills/brainstorming/ideation.md b/skills/brainstorming/ideation.md
new file mode 100644
index 0000000..3bd5dd2
--- /dev/null
+++ b/skills/brainstorming/ideation.md
@@ -0,0 +1,45 @@
+# 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
new file mode 100644
index 0000000..d896a48
--- /dev/null
+++ b/skills/brainstorming/roadmap-opportunity-prioritization.md
@@ -0,0 +1,45 @@
+# 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
new file mode 100644
index 0000000..bd69031
--- /dev/null
+++ b/skills/brainstorming/structured-brainstorming.md
@@ -0,0 +1,45 @@
+# 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
new file mode 100644
index 0000000..dd38b92
--- /dev/null
+++ b/skills/debugging/bug-triage.md
@@ -0,0 +1,46 @@
+# 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
new file mode 100644
index 0000000..ac6aba0
--- /dev/null
+++ b/skills/debugging/debugging-workflow.md
@@ -0,0 +1,46 @@
+# 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
new file mode 100644
index 0000000..34f4c27
--- /dev/null
+++ b/skills/debugging/incident-response-stabilization.md
@@ -0,0 +1,45 @@
+# 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
new file mode 100644
index 0000000..0f649b7
--- /dev/null
+++ b/skills/documentation/architecture-decision-records.md
@@ -0,0 +1,45 @@
+# 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
new file mode 100644
index 0000000..6a40528
--- /dev/null
+++ b/skills/documentation/onboarding-docs.md
@@ -0,0 +1,45 @@
+# 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
new file mode 100644
index 0000000..02f0870
--- /dev/null
+++ b/skills/documentation/technical-docs.md
@@ -0,0 +1,45 @@
+# 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
new file mode 100644
index 0000000..feeba4f
--- /dev/null
+++ b/skills/marketing/content-strategy-seo.md
@@ -0,0 +1,45 @@
+# 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
new file mode 100644
index 0000000..f255430
--- /dev/null
+++ b/skills/marketing/marketing-content.md
@@ -0,0 +1,45 @@
+# 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
new file mode 100644
index 0000000..fc1b4b4
--- /dev/null
+++ b/skills/marketing/messaging-positioning.md
@@ -0,0 +1,45 @@
+# 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
new file mode 100644
index 0000000..5c5c137
--- /dev/null
+++ b/skills/marketing/product-copy.md
@@ -0,0 +1,45 @@
+# 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
new file mode 100644
index 0000000..848c48c
--- /dev/null
+++ b/skills/software/api-backend.md
@@ -0,0 +1,45 @@
+# 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
new file mode 100644
index 0000000..d8dad30
--- /dev/null
+++ b/skills/software/architecture-system-design.md
@@ -0,0 +1,45 @@
+# 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
new file mode 100644
index 0000000..b8cf65e
--- /dev/null
+++ b/skills/software/code-review.md
@@ -0,0 +1,45 @@
+# 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
new file mode 100644
index 0000000..02924d7
--- /dev/null
+++ b/skills/software/database-migrations.md
@@ -0,0 +1,45 @@
+# 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
new file mode 100644
index 0000000..a7bba5b
--- /dev/null
+++ b/skills/software/dependency-lifecycle.md
@@ -0,0 +1,45 @@
+# 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
new file mode 100644
index 0000000..9119e01
--- /dev/null
+++ b/skills/software/feature-implementation.md
@@ -0,0 +1,48 @@
+# 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
new file mode 100644
index 0000000..f57e6eb
--- /dev/null
+++ b/skills/software/frontend-ui-implementation.md
@@ -0,0 +1,45 @@
+# 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
new file mode 100644
index 0000000..09c1e18
--- /dev/null
+++ b/skills/software/maintenance-technical-debt.md
@@ -0,0 +1,45 @@
+# 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
new file mode 100644
index 0000000..bde62a9
--- /dev/null
+++ b/skills/software/observability-operability.md
@@ -0,0 +1,45 @@
+# 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
new file mode 100644
index 0000000..6e97c1e
--- /dev/null
+++ b/skills/software/performance-optimization.md
@@ -0,0 +1,45 @@
+# 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
new file mode 100644
index 0000000..a049ccf
--- /dev/null
+++ b/skills/software/refactoring.md
@@ -0,0 +1,45 @@
+# 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
new file mode 100644
index 0000000..d9b59e3
--- /dev/null
+++ b/skills/software/release-change-summary.md
@@ -0,0 +1,45 @@
+# 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
new file mode 100644
index 0000000..ae45f00
--- /dev/null
+++ b/skills/software/repo-exploration.md
@@ -0,0 +1,44 @@
+# 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
new file mode 100644
index 0000000..351973c
--- /dev/null
+++ b/skills/software/security-review-hardening.md
@@ -0,0 +1,45 @@
+# 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
new file mode 100644
index 0000000..8412cf8
--- /dev/null
+++ b/skills/software/test-strategy.md
@@ -0,0 +1,45 @@
+# 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
new file mode 100644
index 0000000..fad7036
--- /dev/null
+++ b/skills/ui-ux/accessibility-review.md
@@ -0,0 +1,45 @@
+# 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
new file mode 100644
index 0000000..478f8ca
--- /dev/null
+++ b/skills/ui-ux/design-system-consistency.md
@@ -0,0 +1,45 @@
+# 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
new file mode 100644
index 0000000..160231b
--- /dev/null
+++ b/skills/ui-ux/ux-review.md
@@ -0,0 +1,45 @@
+# 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.