opencode-agent-skill 7.7.0

package/global-config/skills/nestjs-engineering/references/workflow.md

@@ -0,0 +1,11 @@
+# NestJS workflow
+
+Map module ownership before adding providers. Trace controller -> DTO/pipe -> guard/policy -> service/domain -> repository/external I/O -> response/interceptor.
+
+Keep providers in the narrowest module that owns them and export only intentional public dependencies. Avoid circular-module workarounds until the ownership problem is understood.
+
+Use DTO validation/transformation consistently and distinguish transport validation from business invariants. Enforce resource authorization in guards/policies or service logic that every entry point reaches.
+
+For async providers, close connections/listeners on shutdown and handle rejected promises explicitly. Preserve exception filters, response envelopes and OpenAPI decorators where they define a contract.
+
+Verification should include unit/integration tests around the changed provider path, validation and unauthorized cases, module compilation/bootstrap and contract/OpenAPI checks when endpoints change.

package/global-config/skills/nextjs-engineering/SKILL.md

@@ -0,0 +1,12 @@
+---
+name: nextjs-engineering
+description: Work on Next.js apps with version-aware App/Pages Router boundaries, server/client components, routes/actions, caching, data fetching, metadata, images, and deployment behavior.
+---
+
+# Next.js Engineering
+
+Detect Next.js version, App vs Pages Router, runtime target, package manager, deployment adapter, and existing data/cache conventions before changing code.
+
+Preserve server/client boundaries. Do not spread `use client` to bypass architecture problems. Treat caching/revalidation, route handlers/server actions, environment exposure, cookies/headers, metadata, static generation, image behavior, and edge/node runtime differences as explicit contracts.
+
+Read [workflow.md](references/workflow.md) for version-sensitive routing/data rules, cache diagnosis, security boundaries, and verification.

package/global-config/skills/nextjs-engineering/references/workflow.md

@@ -0,0 +1,15 @@
+# Next.js workflow
+
+Start from the route/layout/page or handler involved and identify:
+- router type and exact Next.js version
+- server vs client component ownership
+- data source and cache/revalidation semantics
+- runtime: node, edge, static/prerendered
+- auth/session/cookie boundary
+- deployment-specific constraints
+
+For App Router changes, keep secrets and privileged data on the server, serialize only client-safe props, and avoid importing server-only modules into client graphs. For route handlers/actions, verify validation, authorization, error/status behavior and cache invalidation after mutations.
+
+For stale-data bugs, inspect fetch/cache options, tags/paths, dynamic APIs, mutation invalidation and hosting behavior before adding forced-dynamic/no-store globally.
+
+Verification should include the affected route behavior plus Next build/type checks. For cache/auth changes, test both fresh and repeated requests and unauthorized/expired cases where applicable.

package/global-config/skills/nodejs-engineering/SKILL.md

@@ -0,0 +1,12 @@
+---
+name: nodejs-engineering
+description: Work on Node.js services and tooling with version-aware modules, async behavior, validation, APIs, files/processes, lifecycle, logging, and tests.
+---
+
+# Node.js Engineering
+
+Detect Node version, ESM/CommonJS mode, package manager, framework, test runner, runtime/deployment model, and repository error conventions.
+
+Trace async failures through promise ownership and lifecycle rather than swallowing them. Validate external input at boundaries, clean up resources, preserve cancellation/shutdown behavior where relevant, and use safe filesystem/process APIs.
+
+Read [workflow.md](references/workflow.md) for async/error propagation, streams/processes, module boundaries, lifecycle and verification.

package/global-config/skills/nodejs-engineering/references/workflow.md

@@ -0,0 +1,11 @@
+# Node.js workflow
+
+Establish runtime constraints from package.json engines, lockfile, tsconfig/module settings and deployment files.
+
+For services, trace request/job -> validation -> business logic -> I/O -> response/ack. Check rejected promises, missing awaits, double responses, timers/listeners, pool/socket/file cleanup, backpressure for streams, and graceful shutdown for owned resources.
+
+For subprocess/filesystem code, avoid shell interpolation when argument arrays work; validate paths and ownership; distinguish ENOENT/permission/data errors rather than broad catch-and-ignore.
+
+For ESM/CJS issues, inspect package type, file extensions, tsconfig output and dependency export maps before changing imports broadly.
+
+Verification should reproduce the original runtime path, then run focused tests plus repository-native typecheck/lint/build. For lifecycle/concurrency changes, test failure and shutdown/cleanup paths rather than only the happy path.

package/global-config/skills/payment-engineering/SKILL.md

@@ -0,0 +1,12 @@
+---
+name: payment-engineering
+description: Implement and review payments as high-integrity state machines with trusted amounts, provider webhooks, idempotency, retries, reconciliation, and order/payment separation.
+---
+
+# Payment Engineering
+
+Never trust client-calculated amount or a browser redirect as proof of payment. Model payment and order state transitions explicitly and assume provider events can be duplicated, delayed, retried, or arrive out of order.
+
+Verify server-side pricing, webhook authenticity, idempotency keys/event identity, atomic state transitions, retry behavior, refund/cancel paths, reconciliation and secret isolation.
+
+Read [workflow.md](references/workflow.md) for state-machine invariants, webhook handling, idempotency, failure injection and verification.

package/global-config/skills/payment-engineering/references/workflow.md

@@ -0,0 +1,19 @@
+# Payment engineering workflow
+
+Map order state and payment state separately. Define which transitions are legal and which source is authoritative.
+
+For checkout:
+- calculate currency/amount server-side from trusted product/order data
+- bind provider intent/session to internal order/customer identifiers
+- make creation/retry idempotent
+
+For webhooks:
+- verify provider signature using the raw/request representation required by the provider
+- persist or otherwise deduplicate event identity
+- handle duplicates and out-of-order delivery
+- make state transitions conditional/atomic
+- return retryable vs terminal responses intentionally
+
+Never mark paid from a client success URL alone.
+
+Verification should include success, decline/failure, duplicate webhook, out-of-order event, retry after timeout, wrong signature, amount mismatch and already-finalized order as applicable. For production-sensitive changes, include reconciliation/rollback strategy.

package/global-config/skills/performance-engineering/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: performance-engineering
+description: Diagnose and improve performance using evidence: rendering, database, network, memory, caching, bundles, concurrency, and hot paths.
+---
+
+# Performance Engineering
+
+Measure or inspect before optimizing. Look for repeated calls, N+1 queries, unnecessary rerenders, unbounded data, blocking work, oversized assets/bundles, missing useful caching and resource leaks. Prefer low-risk changes with measurable or strongly evidenced impact. Avoid premature micro-optimization.
+
+Read [workflow.md](references/workflow.md) when the task reaches domain-specific behavior, compatibility, failure, or verification boundaries.

package/global-config/skills/performance-engineering/references/workflow.md

@@ -0,0 +1,17 @@
+# Performance engineering workflow
+
+Define the user-visible or system metric first: latency percentile, throughput, CPU, memory, query count, bundle size, startup time or render frequency.
+
+Measure a representative baseline before changing code when practical. Find the dominant cost rather than optimizing a convenient line.
+
+Investigate by layer:
+- repeated network/database calls and N+1 patterns
+- blocking I/O or serialized independent work
+- excessive allocations, retained listeners/resources and unbounded caches
+- unnecessary rerenders/recomputation
+- oversized payloads/assets/bundles
+- missing indexes or cache keys derived from actual access patterns
+
+Preserve correctness under concurrency and failure; faster incorrect behavior is not an improvement.
+
+Verification should compare before/after under comparable inputs, repeat noisy measurements, include correctness regression checks and disclose when only static evidence—not runtime measurement—supports the expected improvement.

package/global-config/skills/python-engineering/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: python-engineering
+description: Work on Python apps/services using project packaging, typing, async, tests, linting, environments, and framework conventions.
+---
+
+# Python Engineering
+
+Detect Python version, packaging/environment tool, formatter/linter, tests and framework. Follow typing/style conventions, avoid mutable defaults, handle async/sync boundaries, use context managers, avoid silently catching broad exceptions, and minimize dependency changes.
+
+Read [workflow.md](references/workflow.md) when the task reaches domain-specific behavior, compatibility, failure, or verification boundaries.

package/global-config/skills/python-engineering/references/workflow.md

@@ -0,0 +1,11 @@
+# Python engineering workflow
+
+Establish Python version, environment/package manager, project layout, typing mode, formatter/linter and test runner.
+
+Respect import/package boundaries and avoid changing environment tooling incidentally. Keep public types and validation explicit where the codebase uses them.
+
+For async code, do not call blocking I/O in the event loop; manage task cancellation and resource cleanup. For sync code, use context managers for files/connections and avoid broad exception swallowing.
+
+Watch mutable defaults, timezone-naive datetimes, implicit text/bytes conversions, iterator exhaustion and shared global state. Prefer standard-library solutions when a dependency adds little value.
+
+Verification should use the project interpreter/environment, focused tests, type checking/linting when configured, and the actual runtime path for packaging/CLI/import changes.

package/global-config/skills/react-engineering/SKILL.md

@@ -0,0 +1,14 @@
+---
+name: react-engineering
+description: Work on React apps using existing component, hooks, state, routing, data fetching, forms, performance, and testing conventions while preserving rendering and state invariants.
+---
+
+# React Engineering
+
+Detect React/framework version and the repository's component, state, routing, form, data-fetching, styling, and test conventions before editing.
+
+Prefer render-time derivation over duplicated state. Use effects for synchronization with external systems, not as a default data-flow mechanism. Preserve stable identity, ownership boundaries, controlled/uncontrolled form semantics, loading/empty/error states, and accessibility.
+
+Before performance changes, identify the actual render/data hot path rather than adding memoization mechanically.
+
+Read [workflow.md](references/workflow.md) for state/effect diagnosis, async race checks, rendering invariants, forms, and verification.

package/global-config/skills/react-engineering/references/workflow.md

@@ -0,0 +1,16 @@
+# React workflow
+
+Trace data ownership before editing: source -> transformation -> component props/state -> event -> mutation/refetch.
+
+Check:
+- whether state can be derived during render instead of synchronized by effect
+- effect dependencies, cleanup, stale closures, request races and unmounted updates
+- list keys based on stable identity rather than index when ordering can change
+- controlled form values, validation timing, submit/error/loading states
+- context/store selectors that cause broad rerenders
+- server/cache state kept in the repository's existing data library instead of duplicated locally
+- Suspense/error-boundary/framework behavior only when already supported by the stack
+
+For regressions, find the nearest working component with the same pattern and compare ownership/lifecycle differences.
+
+Verification should exercise user-visible behavior with the repository's component/integration tests where available, then typecheck/lint/build according to blast radius. Do not treat a successful render or TypeScript compile as proof that interaction/state timing is correct.

package/global-config/skills/react-native-engineering/SKILL.md

@@ -0,0 +1,14 @@
+---
+name: react-native-engineering
+description: Work on React Native/Expo apps: components, hooks, navigation, styling, APIs, native modules, Android/iOS build failures, platform behavior, and performance with version-aware verification.
+---
+
+# React Native Engineering
+
+Detect React Native version, Expo vs bare workflow, JS/TS, package manager, navigation/state/data libraries, Hermes/native structure, and the target platforms before changing code.
+
+Preserve existing component, styling, navigation, and state conventions. Treat Android/iOS build failures as compatibility problems first: inspect JDK, Gradle, AGP, Kotlin, SDK, CocoaPods/Xcode, Expo/RN versions and the exact failing task before cache deletion or dependency churn.
+
+For UI/data behavior, handle loading/empty/error/success states, lifecycle cleanup, keyboard/safe-area/platform differences, list identity, and accessibility. Avoid effects for derived state and avoid JS-thread work that belongs off the hot path.
+
+Read [workflow.md](references/workflow.md) for build-diagnosis order, platform invariants, performance checks, and verification.

package/global-config/skills/react-native-engineering/references/workflow.md

@@ -0,0 +1,16 @@
+# React Native workflow
+
+## Establish the stack
+Read package.json, RN/Expo config, Android Gradle files, iOS Podfile/project metadata when relevant, and the nearest working screen/native integration. Record exact RN/Expo, React, navigation, JDK/Gradle/AGP/Kotlin or Xcode/CocoaPods versions implicated by the task.
+
+## Behavior changes
+Trace screen -> state/data hook -> API/storage -> navigation/native boundary. Check stale async updates, effect cleanup, focus lifecycle, repeated requests, stable FlatList keys, keyboard/safe-area behavior, image sizing/caching, and platform-specific branches.
+
+## Android failures
+Use the first failing Gradle task and compatibility matrix evidence. Distinguish Java/JDK, Gradle wrapper, AGP, Kotlin, Android SDK/build-tools, CMake/NDK and native-module errors. Do not start with cache clearing.
+
+## iOS failures
+Separate JS/Metro issues from Pods, deployment target, Xcode toolchain, signing, native-module, and simulator/device architecture failures.
+
+## Verification
+Prefer the original reproduction plus project-native lint/typecheck/tests. For native changes, verify the affected Android/iOS build path. For UI regressions, exercise the interaction on the target platform or the strongest available component/device test. Recheck both platforms when shared code touches platform-sensitive APIs.

package/global-config/skills/repo-explorer/SKILL.md

@@ -0,0 +1,17 @@
+---
+name: repo-explorer
+description: Inspect unfamiliar repositories efficiently before changes by locating instructions, stack, entry points, nearest analogues, dependencies, data flow, tests, and conventions without inventing structure.
+---
+
+# Repo Explorer
+
+Read applicable instructions and manifests first. If `ocskill` is available, `ocskill inspect` can establish stack/package-manager/test-command facts before targeted source reads.
+
+Then:
+1. locate the task's exact entry point, symbol, route, error, or configuration
+2. find the nearest working analogue in the same repository
+3. trace direct imports, callers, and data flow only as far as needed
+4. identify tests, fixtures, build scripts, generated-code rules, and package boundaries
+5. note repository conventions and risky assumptions before editing
+
+Prefer exact search, shallow tree views, and relevant line ranges over recursive dumps. If the repository is large, load `ues-context-engineering`. Do not invent paths, framework behavior, or architecture that can be verified.

package/global-config/skills/research-verification/SKILL.md

@@ -0,0 +1,18 @@
+---
+name: research-verification
+description: Verify current external APIs, packages, versions, framework behavior, security guidance, and documentation with primary sources before coding when repository evidence is insufficient.
+---
+
+# Research Verification
+
+Use this when an answer depends on information that may have changed outside the repository.
+
+1. State the concrete uncertainty: API signature, package existence/version, compatibility, deprecation, platform behavior, security guidance, or release behavior.
+2. Check repository-pinned versions and local types/docs first.
+3. Prefer current primary sources: official documentation, package registry, release notes/changelog, or upstream source.
+4. Confirm that documentation matches the version actually used by the repository.
+5. Distinguish verified facts from inference. If primary evidence is unavailable, say so.
+6. Never invent package names or versions. Before adding a new dependency, verify that it exists and is appropriate.
+7. Record only the findings needed for the implementation; do not flood the coding context with unrelated research.
+
+Read [source-hierarchy.md](references/source-hierarchy.md) when sources disagree.

package/global-config/skills/research-verification/references/source-hierarchy.md

@@ -0,0 +1,12 @@
+# Source hierarchy
+
+For changing technical facts, prefer evidence in this order:
+
+1. repository lockfiles, generated types, vendored API surfaces, and exact runtime errors for what the project currently uses
+2. official documentation for the matching version
+3. official registry metadata, release notes, changelog, migration guide
+4. upstream source/tests for behavior not documented elsewhere
+5. high-quality secondary material
+6. community discussion for experience reports, clearly labeled as such
+
+When sources disagree, check dates and versions before deciding they conflict. Do not silently apply documentation for a newer or older major version to the current project.

package/global-config/skills/rest-api-design/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: rest-api-design
+description: Design/review REST APIs: resources, methods, status codes, pagination, validation, errors, versioning, and idempotency.
+---
+
+# Rest Api Design
+
+Prefer the existing API style. Check HTTP semantics, stable contracts, validation, consistent errors, pagination/filter/sort, idempotency for retryable writes, compatibility/versioning and resource-level authorization. Avoid changing established style without strong reason.
+
+Read [workflow.md](references/workflow.md) when the task reaches domain-specific behavior, compatibility, failure, or verification boundaries.

package/global-config/skills/rest-api-design/references/workflow.md

@@ -0,0 +1,18 @@
+# REST API design workflow
+
+Start from existing repository conventions and the consumer contract.
+
+Model resources and operations first, then choose method/path/status semantics. Distinguish create vs replace vs partial update and make retryable writes idempotent when duplicate execution is unsafe.
+
+Define:
+- request validation and unknown-field policy
+- success and error schemas
+- pagination/filter/sort semantics and stable ordering
+- null vs missing field behavior
+- resource-level authorization
+- concurrency/precondition behavior where lost updates matter
+- versioning/deprecation strategy for breaking changes
+
+Avoid exposing persistence layout directly when it makes compatibility brittle.
+
+Verification should cover representative success, malformed input, unauthorized/not-found distinction where appropriate, pagination boundaries, duplicate/retry behavior and at least one real consumer or contract test for public changes.

package/global-config/skills/software-architect/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: software-architect
+description: Design boundaries, modules, data flow, interfaces, migrations, and tradeoffs for non-trivial changes without unnecessary rewrites.
+---
+
+# Software Architect
+
+Evaluate current architecture, ownership boundaries, state/data flow, API contracts, persistence, failure behavior, compatibility, testability and rollout needs. Prefer incremental designs that fit existing code. Document tradeoffs briefly; avoid abstraction for its own sake.
+
+Read [workflow.md](references/workflow.md) when the task reaches domain-specific behavior, compatibility, failure, or verification boundaries.

package/global-config/skills/software-architect/references/workflow.md

@@ -0,0 +1,18 @@
+# Software architecture workflow
+
+Architecture work starts with constraints, not preferred patterns.
+
+Map:
+- entry points and responsibility ownership
+- data/control flow and state ownership
+- public/internal contracts
+- persistence and external side effects
+- failure boundaries, retries and observability
+- deployment/migration compatibility
+- existing extension seams and nearest working analogues
+
+Evaluate options by change surface, coupling, reversibility, operational risk, testability and fit with current code. Prefer an incremental seam over a rewrite when both satisfy the requirement.
+
+Call out assumptions that require repository or production evidence. Do not introduce a service, queue, abstraction layer or generic framework solely for theoretical future scale.
+
+A useful architecture recommendation includes the smallest viable direction, material rejected alternatives, rollout/rollback concerns and concrete verification needed before declaring the design safe.

package/global-config/skills/task-planner/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: task-planner
+description: Create an executable, file-aware plan for multi-file, architectural, ambiguous, migration, or risky coding work with acceptance criteria, dependencies, risks, and verification.
+---
+
+# Task Planner
+
+Build the plan from repository evidence, not generic architecture guesses.
+
+Include:
+- required outcome and observable acceptance criteria
+- relevant existing files, interfaces, and the nearest working analogue
+- ordered implementation steps with real dependencies
+- compatibility, migration, and rollback concerns where applicable
+- explicit verification for each risky boundary
+- user decisions or destructive actions that require approval
+
+Keep steps small enough to verify but large enough to be meaningful. Separate required work from optional cleanup. Re-plan when new evidence invalidates an assumption rather than forcing execution through a stale plan.
+
+For persistent long-horizon execution, emit a machine-checkable `PLAN.json` and read [plan-schema.md](references/plan-schema.md). Validate it with `ocskill task-graph` and an independent `ues-plan-checker` before any executor edits files.
+

package/global-config/skills/task-planner/references/plan-schema.md

@@ -0,0 +1,56 @@
+# UES PLAN.json schema
+
+A long-horizon plan is machine-checkable JSON:
+
+```json
+{
+  "schemaVersion": 1,
+  "goal": "Observable engineering outcome",
+  "tasks": [
+    {
+      "id": "T1",
+      "title": "Short task title",
+      "summary": "What changes and why",
+      "files": {
+        "create": [],
+        "modify": ["src/example.ts"],
+        "test": ["test/example.test.ts"]
+      },
+      "dependsOn": [],
+      "acceptance": [
+        "Specific externally observable behavior"
+      ],
+      "verification": [
+        "npm test -- example"
+      ],
+      "risk": "medium"
+    }
+  ]
+}
+```
+
+Valid risk values are `low`, `medium`, `high`, and `critical`.
+
+## Task boundaries
+
+Each task should:
+- produce an independently reviewable behavior or contract;
+- name files/interfaces precisely enough for a fresh executor;
+- carry its own verification;
+- depend only on tasks whose outputs it consumes.
+
+Avoid plans where every task touches the same central file; those cannot safely execute in parallel.
+
+## Acceptance quality
+
+Acceptance criteria describe behavior, not implementation steps. Prefer:
+- "Duplicate webhook delivery cannot create a second charge"
+
+over:
+- "Add an idempotency check".
+
+## Verification quality
+
+Verification must be concrete enough for another agent to run. High-risk tasks need negative cases and compatibility evidence where applicable.
+
+Before execution run `ocskill task-graph PLAN.json` and an independent `ues-plan-checker`.

package/global-config/skills/test-driven-development/SKILL.md

@@ -0,0 +1,22 @@
+---
+name: test-driven-development
+description: Use a pragmatic red-green-refactor loop for behavior changes and bug fixes when the repository has a practical test harness or a focused regression test can reasonably be added.
+---
+
+# Test-Driven Development
+
+Prefer behavior-first tests when they will provide durable evidence.
+
+1. Define one observable behavior or regression.
+2. Write the smallest test that would fail if the desired behavior is absent.
+3. Run it and confirm it fails for the intended reason, not because the test is broken.
+4. Implement the minimum coherent production change.
+5. Re-run the focused test until green.
+6. Run adjacent regression checks.
+7. Refactor only while tests stay green.
+
+Do not test implementation trivia merely to satisfy the ritual. Avoid mocks when real behavior is cheap and stable to exercise.
+
+TDD may be inappropriate for generated files, documentation/config-only changes, throwaway prototypes, or repositories with no practical harness. In those cases, use the strongest realistic verification instead and state the limitation.
+
+Read [writing-good-tests.md](references/writing-good-tests.md) when adding or changing tests.

package/global-config/skills/test-driven-development/references/writing-good-tests.md

@@ -0,0 +1,21 @@
+# Writing useful tests
+
+A useful test protects an observable behavior.
+
+Before writing it, answer:
+- what production change would make this test fail?
+- does the assertion come from the requirement/contract rather than copying the implementation?
+- can the test exercise real code instead of only a mock?
+- is one behavior being tested clearly?
+
+Prefer:
+- stable public behavior over private implementation details
+- small deterministic fixtures
+- explicit edge cases that caused the bug
+- failure messages that explain the violated behavior
+
+Avoid:
+- assertions that only check text/source presence when runtime behavior matters
+- mocks that reproduce the implementation's own mistake
+- snapshots for logic that deserves explicit assertions
+- tests that pass before the behavior exists without explaining why

package/global-config/skills/test-verification/SKILL.md

@@ -0,0 +1,20 @@
+---
+name: test-verification
+description: Prove engineering claims with fresh project-native tests, type checks, lint, builds, reproductions, contract checks, and final-diff inspection; never report success from expectation alone.
+---
+
+# Test Verification
+
+Verification must match the claim.
+
+1. Identify the observable acceptance criterion or original failure.
+2. Choose the narrowest project-native check that proves it.
+3. Run the check fresh and read the actual output and exit status.
+4. Expand verification based on blast radius: adjacent tests, typecheck, lint, affected build, integration or contract checks, or the full suite when justified.
+5. Re-test the original behavior, not only compilation.
+6. Inspect the final diff and working tree for accidental changes.
+7. Report passed, failed, and not-run checks separately.
+
+For bug regressions, a strong test demonstrates that it can fail when the fix is absent where practical. For configuration or migration changes, verify the resulting behavior or state rather than only syntax.
+
+Do not weaken valid tests, hide warnings that indicate real failure, or claim "done", "fixed", "passes", "builds", or "deployed" without fresh evidence.

package/global-config/skills/ui-ux-engineering/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: ui-ux-engineering
+description: Improve production UI/UX: hierarchy, responsive layout, components, forms, states, accessibility, realistic content, and design consistency.
+---
+
+# Ui Ux Engineering
+
+Inspect the existing design system first. Check hierarchy, responsive behavior, spacing/typography, forms/validation, loading/empty/error/success states, keyboard/focus basics, image fallbacks, overflow/long text and component reuse. Use common interaction patterns without pixel-copying proprietary products.
+
+Read [workflow.md](references/workflow.md) when the task reaches domain-specific behavior, compatibility, failure, or verification boundaries.

package/global-config/skills/ui-ux-engineering/references/workflow.md

@@ -0,0 +1,17 @@
+# UI/UX engineering workflow
+
+Start from the existing design system, component primitives and real user flow.
+
+Check the complete state model:
+- default, hover/focus/pressed/disabled
+- loading, empty, validation error, server error and success
+- long text, missing images/data and slow network
+- narrow/mobile, large viewport and zoom/text scaling
+
+Preserve visual hierarchy through spacing, typography and grouping before adding decoration. Reuse components/tokens instead of creating near-duplicates.
+
+Forms need clear labels, inline actionable errors, submission state and prevention of accidental duplicate actions. Navigation and dialogs should preserve focus and back/escape expectations.
+
+For data-heavy UI, design pagination/filter/sort and stale/loading transitions deliberately.
+
+Verification should exercise the actual interaction at representative breakpoints, keyboard/focus behavior, overflow/long-content cases and accessibility checks where relevant—not only compare a static screenshot.

package/global-config/skills/web-security-review/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: web-security-review
+description: Review web applications for reachable, evidence-backed security risks including injection, XSS, broken access control, CSRF, SSRF, traversal, unsafe uploads, secrets, deserialization, and dangerous execution.
+---
+
+# Web Security Review
+
+Prioritize exploitability and concrete data/control flow. Start from attacker-controlled inputs and trace them to sensitive sinks or authorization decisions. Do not report a vulnerability from a risky-looking function name alone.
+
+Read [workflow.md](references/workflow.md) for source-to-sink analysis, access-control review, SSRF/upload/path checks, false-positive discipline and security verification.

package/global-config/skills/web-security-review/references/workflow.md

@@ -0,0 +1,22 @@
+# Web security review workflow
+
+For each candidate issue identify:
+1. attacker-controlled source
+2. transformations/validation
+3. sensitive sink or authorization decision
+4. preconditions and reachable path
+5. concrete impact
+6. existing mitigation that may break the exploit chain
+
+High-value checks:
+- SQL/command/template injection
+- stored/reflected/DOM XSS with actual escaping context
+- broken object/function-level authorization and tenant isolation
+- CSRF for credential-bearing browser requests where applicable
+- SSRF including redirect/DNS/private-network controls
+- path traversal and archive extraction
+- upload type/content/storage/execution controls
+- secret/token leakage
+- unsafe deserialization or dynamic code execution
+
+Separate confirmed findings from hardening opportunities. Verification should use safe tests that demonstrate the violated security invariant without harming external systems. Recheck negative authorization and malicious-input cases after a fix.