opencode-agent-skill 7.7.0

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

@@ -0,0 +1,10 @@
+---
+name: django-engineering
+description: Work on Django including models, migrations, ORM, views, DRF, permissions, forms, admin, and tests.
+---
+
+# Django Engineering
+
+Inspect settings/app structure and migration state. Use ORM efficiently and watch N+1. Keep authorization server-side. Preserve DRF serializer/viewset/permission conventions. Create migrations for schema changes; do not casually edit applied migrations. Test affected behavior.
+
+Read [workflow.md](references/workflow.md) when the task reaches domain-specific behavior, compatibility, failure, or verification boundaries.

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

@@ -0,0 +1,11 @@
+# Django engineering workflow
+
+Trace request/command -> URL/view/serializer/form -> service/domain logic -> ORM -> response/template.
+
+For ORM work, inspect generated query shape, select_related/prefetch_related opportunities, transaction boundaries, uniqueness constraints and migration compatibility. Avoid fixing N+1 problems with indiscriminate prefetching.
+
+For DRF, keep request/response serializers explicit, enforce object-level permissions in the server path that retrieves or mutates the object, preserve status/error conventions and check pagination/filter behavior.
+
+For migrations, inspect existing rows before NOT NULL/unique constraints, prefer additive compatible steps for live systems, and avoid editing already-applied migrations casually.
+
+Verification should include focused tests, permission negative cases, migration checks and query-count/SQL inspection when performance or data access changed.

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

@@ -0,0 +1,10 @@
+---
+name: documentation-engineering
+description: Write developer/user documentation that matches actual code, commands, configuration, APIs, and setup.
+---
+
+# Documentation Engineering
+
+Verify commands, paths, environment names and configuration from the repository. Document implemented behavior, not hypothetical features. Prefer concise executable examples. Update docs when setup/API/workflow materially changes.
+
+Read [workflow.md](references/workflow.md) when the task reaches domain-specific behavior, compatibility, failure, or verification boundaries.

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

@@ -0,0 +1,15 @@
+# Documentation engineering workflow
+
+Treat the repository and executable behavior as the source of truth.
+
+Before writing:
+- verify commands, paths, package names, environment variables and supported versions
+- distinguish required setup from optional examples
+- identify whether the audience is user, operator, contributor or API consumer
+- check the nearest existing documentation style and navigation
+
+Examples should be copyable and minimal. Mark placeholders clearly. Do not present future/planned behavior as implemented.
+
+When documenting APIs or configuration, include defaults, failure behavior and compatibility constraints that materially affect use. When behavior changed, search for stale references across README, docs, examples and release notes.
+
+Verification should run important commands when practical, validate links/paths, and compare documented outputs against current behavior. Prefer one accurate path over several speculative alternatives.

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

@@ -0,0 +1,10 @@
+---
+name: dotnet-engineering
+description: Work on .NET/ASP.NET Core including APIs, services, EF Core, DI, configuration, auth, async code, and tests.
+---
+
+# Dotnet Engineering
+
+Detect target framework/layout. Respect nullable settings, DI lifetimes, async/await, cancellation when meaningful, configuration/options, middleware/auth and EF Core tracking/migrations/query patterns. Do not suppress warnings instead of fixing correctness.
+
+Read [workflow.md](references/workflow.md) when the task reaches domain-specific behavior, compatibility, failure, or verification boundaries.

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

@@ -0,0 +1,11 @@
+# .NET / ASP.NET Core workflow
+
+Establish target framework, nullable mode, SDK pinning, project references and test layout first.
+
+Trace endpoint -> model binding/validation -> service -> persistence/external I/O -> response. Respect DI lifetimes; do not inject scoped services into singletons. Carry CancellationToken through meaningful async I/O and avoid sync-over-async.
+
+For EF Core, inspect tracking needs, query projection, Include usage, transaction boundaries, concurrency tokens, migration output and database-provider differences. Avoid loading whole aggregates when a projection is enough.
+
+For auth, verify policy/claim/resource authorization at the server boundary and include negative cases.
+
+Verification should use dotnet restore/build/test as appropriate, targeted endpoint/integration tests, migration/script inspection for schema changes, and analyzer/nullability output rather than suppressing warnings.

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

@@ -0,0 +1,10 @@
+---
+name: ecommerce-engineering
+description: Build/review ecommerce and marketplace systems: catalog, sellers, carts, checkout, orders, inventory, pricing, images, and traceability.
+---
+
+# Ecommerce Engineering
+
+Check product/catalog consistency, prices/currency/units, seller identity, stock, cart calculations, order transitions, image fallbacks, filters/sort/pagination, async states and provenance/traceability. Enforce money/inventory rules on the server. Use realistic presentation without copying another brand.
+
+Read [workflow.md](references/workflow.md) when the task reaches domain-specific behavior, compatibility, failure, or verification boundaries.

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

@@ -0,0 +1,17 @@
+# Ecommerce / marketplace workflow
+
+Model catalog, seller, inventory, cart, pricing, order and payment state as separate responsibilities with explicit ownership.
+
+Check:
+- money stored/calculated in integer minor units or another exact representation
+- server-authoritative price, discounts, tax/shipping and inventory
+- seller/tenant ownership on product and order operations
+- stock reservation/release and oversell behavior under retries/concurrency
+- order state transitions and cancellation/refund constraints
+- image/media fallbacks and realistic loading/empty/error states
+- provenance/traceability fields preserved across catalog and order records
+- pagination/filter/sort contracts for large catalogs
+
+Never trust client-submitted totals or paid status. Coordinate payment idempotency with order idempotency.
+
+Verification should cover cart recalculation, stale price/stock, duplicate checkout, concurrent reservation, unauthorized seller access and order transition edge cases.

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

@@ -0,0 +1,29 @@
+---
+name: engineering-orchestrator
+description: Coordinate non-trivial engineering work by classifying scope, selecting focused skills, preserving reasoning state, planning, delegating analysis, verifying evidence, challenging assumptions, and applying bounded repair/finish gates.
+---
+
+# Engineering Orchestrator
+
+Use this as the process coordinator for non-trivial work.
+
+1. Classify the task as small, standard, or complex by risk and blast radius.
+2. Load process skills before domain skills, and keep the active set small.
+3. Establish observable acceptance criteria and the verification needed to prove them. Use deterministic `ocskill inspect` / `ocskill evidence` helpers when available to ground stack, test and working-tree facts cheaply.
+4. Inspect enough repository context to plan real files, interfaces, producers, and consumers.
+5. For complex or interruption-prone work, maintain a compact fact/assumption/decision/rejected-hypothesis ledger rather than relying on conversational memory.
+6. For long-horizon work explicitly using the persistent workflow, create a machine-checkable plan, validate it with `ues-plan-checker`, and execute dependency-safe tasks through fresh `ues-executor` contexts instead of carrying the whole implementation in one conversation.
+7. Implement in dependency order with verification after meaningful increments.
+8. If a check fails, switch to diagnosis rather than stacking speculative fixes.
+9. For substantial or high-risk behavior changes, run an independent critic pass that attempts to falsify assumptions and find counterexamples.
+10. Repair only evidence-backed blocking findings, re-run affected verification, and bound critic/repair cycles.
+11. Before completion, run the evidence gate, inspect the final diff, and disclose unresolved risks accurately.
+
+Read [routing.md](references/routing.md) when skill selection is ambiguous.
+Read [verification-matrix.md](references/verification-matrix.md) before verifying medium/high-risk changes.
+Read [retry-policy.md](references/retry-policy.md) when implementation or verification fails repeatedly.
+Read [delegation.md](references/delegation.md) before using subagents or parallel analysis.
+Read [evaluator-loop.md](references/evaluator-loop.md) for the critic/repair/re-verify loop on substantial changes.
+Read [long-horizon.md](references/long-horizon.md) when work spans many files/tasks, must survive compaction, or will be executed through fresh task agents.
+Read [model-escalation.md](references/model-escalation.md) when user-configured model tiers are available or repeated task failures justify escalation.
+

package/global-config/skills/engineering-orchestrator/references/delegation.md

@@ -0,0 +1,22 @@
+# Delegation guide
+
+Subagents are useful when isolated context improves analysis. They are overhead when the task is tiny.
+
+Good delegation:
+- independent repository research
+- architecture/blast-radius mapping
+- root-cause investigation
+- final read-only review
+- independent verification planning or execution
+
+Keep inline:
+- one-file obvious edits
+- tasks where delegation would duplicate the same reads
+- sequential work where each step depends on the previous edit
+
+Rules:
+- do not ask multiple agents to edit the same working tree concurrently
+- give each agent a narrow question and concrete scope
+- prefer read-only subagents for review/research/verification
+- verify subagent claims against repository state or command output
+- the parent integrates results and owns the final completion claim

package/global-config/skills/engineering-orchestrator/references/evaluator-loop.md

@@ -0,0 +1,18 @@
+# Evaluator and repair loop
+
+Use this loop for substantial behavior changes, risky fixes, public contracts, auth/security, payments, migrations, or work where a hidden regression would be costly.
+
+1. **Implement** the smallest coherent change.
+2. **Self-check** the diff against each observable acceptance criterion.
+3. **Verify** the narrowest behavior that proves the change.
+4. **Critic pass**: use an independent read-only critic/reviewer to search for counterexamples and unsupported assumptions.
+5. **Repair** only evidence-backed blocking findings.
+6. **Re-verify** the exact checks affected by the repair, then any broader checks justified by blast radius.
+7. **Re-critic** only when the repair materially changed logic, contracts, permissions, persistence, concurrency, or failure behavior.
+
+Bound the loop:
+- at most two repair cycles from critic findings before pausing for a fresh root-cause/architecture review
+- do not churn code to satisfy speculative or style-only feedback
+- unresolved blocking findings must be fixed or explicitly surfaced; they cannot be silently converted into "done"
+
+The critic is a falsification step, not an authority. Repository state, tests, contracts, and runtime evidence remain the source of truth.

package/global-config/skills/engineering-orchestrator/references/long-horizon.md

@@ -0,0 +1,57 @@
+# Long-horizon execution
+
+Use this path for work that is too large or interruption-prone for one conversational context.
+
+## Durable artifacts
+
+When the user explicitly chooses the long-horizon workflow (for example with `/ues-run`) create:
+
+```text
+.ues-work/<slug>/
+  SPEC.md
+  PLAN.json
+  STATE.json
+  EVIDENCE.json
+  tasks/
+  reports/
+```
+
+The directory is git-ignored execution state, not hidden reasoning. Store requirements, decisions, task status, reports and fresh verification evidence. Never store secrets or chain-of-thought.
+
+## Machine-enforced gates
+
+The V6 engine enforces three boundaries:
+
+1. **Plan gate** — `work plan` leaves the item in `awaiting-plan-approval`. `work start` refuses to run until an independent plan checker PASS is recorded with `work approve-plan`.
+2. **Concurrent state gate** — all mutable `STATE.json` and `EVIDENCE.json` operations use a per-work-item lock plus atomic file replacement, preventing safe-wave executors from losing each other's state.
+3. **Integration gate** — finalization requires a recorded `verify-integration --verdict PASS`. The engine fingerprints the Git workspace at PASS time and rejects finalization if the workspace changes afterward.
+
+## Pipeline
+
+1. Map the relevant codebase using repository evidence and `ues-codebase-mapper` when useful.
+2. Write observable acceptance criteria into `SPEC.md`.
+3. Initialize state with `ocskill work init`.
+4. Create `PLAN.json` following the plan schema and import it with `ocskill work plan`.
+5. Run `ues-plan-checker`. If it returns PASS, persist that gate with `ocskill work approve-plan`.
+6. Use `ocskill task-graph` to compute dependency-safe waves.
+7. For each ready task:
+   - on OpenCode V2 prefer `ues.dispatch_task`, which performs `work start`, creates a fresh `ues-executor` session, selects the configured attempt-based model tier, prompts it with a bounded context pack and waits for completion;
+   - inspect the child diff and verification;
+   - persist `work complete --evidence ...` or `work fail --reason ...`.
+8. On failure, re-diagnose rather than stacking patches. A later `ues.dispatch_task` attempt can escalate from standard to heavy when configured.
+9. After all tasks complete, run `ues-integration-verifier`.
+10. Persist the verifier's actual result with `ocskill work verify-integration`.
+11. Only a recorded PASS with an unchanged workspace can be finalized.
+
+## Parallelism
+
+Parallel execution is allowed only when:
+- dependencies are satisfied;
+- safe-wave analysis does not detect declared-file overlap;
+- executors do not write shared implicit files or interfaces.
+
+UES serializes durable state writes, but it cannot make conflicting source-code edits safe. When write-surface independence is uncertain, execute sequentially.
+
+## Resume
+
+On resume, trust `STATE.json`, `EVIDENCE.json`, reports, and current Git status over conversational memory. Revalidate assumptions that could have changed. Do not replay completed tasks merely because the current context does not remember them.

package/global-config/skills/engineering-orchestrator/references/model-escalation.md

@@ -0,0 +1,19 @@
+# Model-tier escalation
+
+UES can map agent roles to three user-configured model tiers:
+
+```text
+light -> cheap/mechanical work
+standard -> normal implementation/debugging/review
+heavy -> architecture, plan checking, critic and difficult integration
+```
+
+Configure explicit provider/model IDs with `ocskill models`. UES never invents model IDs.
+
+Default role tiers favor:
+- heavy: architect, plan-checker, critic, integration-verifier
+- standard: executor, debugger, researcher, reviewer, verifier, codebase-mapper
+
+A failed task attempt may escalate one tier through `ocskill model-policy <role> --attempt N`. Tier escalation is advice unless the runtime can launch the requested agent with that configured model.
+
+Do not use model escalation as a substitute for better evidence. First failure -> diagnose. Repeated failure -> fresh context and stronger tier. Three failed causal approaches -> reconsider the plan/architecture.

package/global-config/skills/engineering-orchestrator/references/retry-policy.md

@@ -0,0 +1,12 @@
+# Retry policy
+
+Failed verification is new evidence, not permission to guess faster.
+
+1. Capture the exact failed check and its output.
+2. Decide whether the failure is caused by the change, pre-existing, environmental, or unknown.
+3. For caused/unknown failures, form one explicit hypothesis and test the smallest causal change.
+4. Re-run the exact failing check before broader verification.
+5. After two failed fixes, stop stacking patches. Re-read the error, recent diff, nearest working analogue, and relevant contract from scratch.
+6. After three distinct failed hypotheses or widening symptoms, surface the possibility of an architectural assumption being wrong before another broad edit.
+
+Do not use package upgrades, cache deletion, lockfile deletion, disabled checks, broad rewrites, or retries-without-changes as generic repair strategies.

package/global-config/skills/engineering-orchestrator/references/routing.md

@@ -0,0 +1,39 @@
+# Routing guide
+
+Choose the smallest set of skills that changes the quality of the work.
+
+## Scope
+
+**Small**
+- one local concern
+- low-risk behavior
+- known conventions and quick verification
+
+Work inline. Exploration and a domain skill may be enough.
+
+**Standard**
+- behavior change
+- two to five related files
+- moderate uncertainty
+- focused API/data-flow impact
+
+Use a short plan, one process skill, relevant domain skill, and verification.
+
+**Complex**
+- public contracts, persistence, auth/security, payments, migrations
+- cross-package/cross-service work
+- major dependency change
+- many files or difficult rollback
+- task likely to span sessions
+
+Add planning, impact analysis, research/architecture, and long-task state when useful.
+
+## Process-first examples
+
+- bug -> bug-diagnosis -> domain skill -> test-verification
+- feature -> task-planner -> implementation/domain -> test-verification
+- unfamiliar repo -> repo-explorer -> context-engineering if large -> domain skill
+- API/version uncertainty -> research-verification before dependency/framework edits
+- release readiness -> code-review + test-verification + git-safety
+
+Avoid loading overlapping skills just because they exist. More context is not automatically better context.

package/global-config/skills/engineering-orchestrator/references/verification-matrix.md

@@ -0,0 +1,18 @@
+# Verification matrix
+
+Use repository-native commands where available. This matrix identifies the kind of evidence to seek, not literal commands.
+
+| Change | Minimum useful evidence | Add when risk is high |
+|---|---|---|
+| Local pure logic | focused unit/regression test | affected suite + typecheck |
+| UI behavior | component/interaction check + build/typecheck | accessibility + browser/device path |
+| Public API | provider test + consumer/contract check | backward-compatibility and error-shape checks |
+| Database/schema | migration/schema validation + affected data tests | dry-run/rollback/backup strategy |
+| Auth/permissions | positive and negative authorization cases | threat review + session/token edge cases |
+| Payment/idempotency | success/failure/retry/idempotency tests | reconciliation/duplicate-event checks |
+| Dependency change | clean install/lockfile + affected build/test | release notes, peer/runtime compatibility |
+| CI/deploy config | syntax/config validation + representative job | rollback/deployment smoke |
+| Performance change | correctness first + representative measurement | repeated benchmark under comparable conditions |
+| Bug fix | original reproduction fails before fix and passes after | adjacent regression suite |
+
+A passing unrelated check does not prove the changed behavior. Match evidence to the claim.

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

@@ -0,0 +1,10 @@
+---
+name: fastapi-engineering
+description: Work on FastAPI services including Pydantic models, dependencies, async endpoints, validation, auth, OpenAPI, and tests.
+---
+
+# Fastapi Engineering
+
+Respect FastAPI/Pydantic versions and project patterns. Keep request/response models explicit, use dependencies consistently, avoid blocking work in async endpoints, preserve status/error conventions, and verify OpenAPI-impacting changes/tests.
+
+Read [workflow.md](references/workflow.md) when the task reaches domain-specific behavior, compatibility, failure, or verification boundaries.

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

@@ -0,0 +1,13 @@
+# FastAPI workflow
+
+Confirm Python, FastAPI, Pydantic and server/runtime versions because validation and serialization behavior can differ materially.
+
+Trace route -> dependency graph -> request model -> service/data layer -> response model. Keep validation at explicit boundaries and avoid leaking ORM/internal objects accidentally.
+
+For async routes, identify blocking database/filesystem/network calls and move or replace them appropriately. Ensure dependency lifetimes clean up sessions/resources reliably.
+
+For auth, enforce identity and resource authorization through dependencies or service checks that cannot be bypassed by alternate routes.
+
+Preserve status codes, error schemas and OpenAPI-visible contracts. Be deliberate about response_model filtering and nullable/default semantics.
+
+Verification should include focused pytest/integration checks, invalid-input and unauthorized cases, OpenAPI/schema diff when contracts change, and startup/lifespan behavior when dependencies or resources changed.

package/global-config/skills/file-upload-engineering/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: file-upload-engineering
+description: Implement file/image uploads safely: validation, storage, naming, URLs, cleanup, permissions, progress, and errors.
+---
+
+# File Upload Engineering
+
+Validate type/size server-side, use safe object keys, enforce authorization/storage permissions, plan orphan cleanup and URL exposure, and handle client progress/errors. Do not trust extensions alone. Prevent path traversal and unrestricted executable uploads.
+
+Read [workflow.md](references/workflow.md) when the task reaches domain-specific behavior, compatibility, failure, or verification boundaries.

package/global-config/skills/file-upload-engineering/references/workflow.md

@@ -0,0 +1,17 @@
+# File upload workflow
+
+Treat filename, metadata and bytes as attacker-controlled.
+
+Validate server-side:
+- maximum size before unbounded buffering where possible
+- allowed content/MIME using trusted inspection when risk warrants it, not extension alone
+- safe generated storage keys rather than user-controlled paths
+- authorization for upload, read and delete operations
+- storage visibility and signed/public URL policy
+- archive extraction paths and executable/script content where relevant
+
+Design cleanup for abandoned multipart uploads, replaced files and failed transactions. Decide whether metadata/database state or object storage is authoritative and how partial failure is reconciled.
+
+For image processing, bound dimensions/resource use and strip dangerous metadata when required.
+
+Verification should test oversize, disallowed type, traversal names, duplicate/retry behavior, unauthorized access, cleanup after failure and successful download/render of a valid file.

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

@@ -0,0 +1,10 @@
+---
+name: flutter-engineering
+description: Work on Flutter/Dart apps including widgets, state management, navigation, async APIs, platform behavior, layout, and tests.
+---
+
+# Flutter Engineering
+
+Detect Flutter/Dart versions and state/navigation libraries. Follow existing widget/state architecture, keep builds lightweight, handle async states, dispose resources, respect platform differences and theme system. Verify analyzer/tests/build.
+
+Read [workflow.md](references/workflow.md) when the task reaches domain-specific behavior, compatibility, failure, or verification boundaries.

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

@@ -0,0 +1,13 @@
+# Flutter engineering workflow
+
+Establish Flutter/Dart versions, state-management library, router/navigation approach, generated-code conventions and target platforms.
+
+Trace widget -> state/controller/provider -> repository/API/storage -> navigation/platform boundary. Keep build methods free of expensive side effects and dispose controllers/subscriptions.
+
+For async UI, model loading/success/empty/error explicitly, prevent stale result updates after a newer request or disposal, and preserve state across navigation only when intended.
+
+Respect MediaQuery, safe areas, keyboard insets, text scaling and platform-specific behavior. Use stable keys where identity matters.
+
+For native/plugin changes, verify Android/iOS minimum versions and plugin compatibility rather than changing toolchains blindly.
+
+Verification should include dart/flutter analyze, focused widget/unit tests, the affected navigation/async interaction and platform build/smoke paths when platform-sensitive code changed.

package/global-config/skills/git-safety/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: git-safety
+description: Use Git safely: inspect status/diffs, preserve user work, stage intentional files, commit clearly, and avoid destructive history operations.
+---
+
+# Git Safety
+
+Start with git status and relevant diffs. Never discard uncommitted work unless explicitly requested. Do not hard reset, clean, force push or rewrite history without explicit intent. Stage only task-related files. Avoid committing secrets/build noise. Verify before commit when practical. Never claim push success unless it happened.
+
+Read [workflow.md](references/workflow.md) when the task reaches domain-specific behavior, compatibility, failure, or verification boundaries.

package/global-config/skills/git-safety/references/workflow.md

@@ -0,0 +1,15 @@
+# Git safety workflow
+
+Before changing history or staging, inspect branch, status, relevant diff and upstream relationship.
+
+Rules:
+- preserve uncommitted user work; never use reset --hard, clean, checkout/restore of user changes, force push or history rewrite without explicit intent
+- stage only task-related paths and inspect the staged diff before committing
+- do not commit secrets, generated noise or large binaries accidentally
+- prefer new commits over rewriting shared history
+- when resolving conflicts, understand both sides before choosing content
+- distinguish local success from remote success; verify push/PR state instead of assuming it
+
+For release/tag work, confirm the exact commit being tagged and version consistency first. For branch deletion, verify the work is merged or otherwise recoverable.
+
+Verification should include git status, the final diff/staged diff, current branch/HEAD and remote result when a remote operation was actually requested.

package/global-config/skills/implementation-engineer/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: implementation-engineer
+description: Implement features and refactors carefully while preserving architecture, compatibility, types, validation, tests, and conventions.
+---
+
+# Implementation Engineer
+
+Read relevant code first. Make the smallest coherent implementation. Reuse existing abstractions. Update coupled types, validation, APIs, UI state, tests and docs/config only when required. Handle relevant edge cases. Re-read the diff and run verification. No placeholders presented as complete; no fabricated results; no unrelated cleanup.
+
+Read [workflow.md](references/workflow.md) when the task reaches domain-specific behavior, compatibility, failure, or verification boundaries.

package/global-config/skills/implementation-engineer/references/workflow.md

@@ -0,0 +1,14 @@
+# Implementation workflow
+
+Start from observable acceptance criteria and the smallest repository-compatible design.
+
+Before editing:
+- identify the real entry point, nearest working analogue and direct callers/consumers
+- map public contracts, persisted state and validation touched by the change
+- choose the smallest coherent file set and define how behavior will be proven
+
+During implementation, preserve existing abstractions unless they are the cause of the problem. Update coupled types, validation, serialization, UI states, tests and docs only where the changed contract requires them. Handle failure paths and cleanup alongside the happy path.
+
+Avoid placeholder logic, silent catch-all fallbacks and speculative refactors.
+
+After each meaningful increment, run the narrowest behavior-matched check. Before completion, inspect the full diff, re-run acceptance behavior, check accidental files and use independent review/critic for substantial or risky changes.

package/global-config/skills/java-spring-engineering/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: java-spring-engineering
+description: Work on Java/Spring Boot including controllers, services, repositories, validation, transactions, security, JPA, and tests.
+---
+
+# Java Spring Engineering
+
+Detect Java/Spring versions and build tool. Respect constructor injection, transactions, validation, exception mapping, Spring Security, JPA fetch/cascade semantics and project DTO/entity conventions. Verify Maven/Gradle tests/build.
+
+Read [workflow.md](references/workflow.md) when the task reaches domain-specific behavior, compatibility, failure, or verification boundaries.

package/global-config/skills/java-spring-engineering/references/workflow.md

@@ -0,0 +1,13 @@
+# Java / Spring workflow
+
+Establish Java version, Spring Boot version, Maven/Gradle setup, active profiles and persistence/security conventions.
+
+Trace controller -> validation -> service/domain -> transaction -> repository/external I/O -> response. Keep controllers thin and transaction boundaries aligned with invariants rather than convenience.
+
+For JPA, inspect fetch type, cascades, ownership, orphan behavior, query count, locking/concurrency and entity/DTO boundaries. Avoid exposing mutable persistence entities as public contracts when the project uses DTOs.
+
+For Spring Security, verify authentication plus role/tenant/resource authorization and method/filter ordering. Include negative cases.
+
+For migrations, inspect Flyway/Liquibase ordering and mixed-version compatibility.
+
+Verification should include focused tests, Maven/Gradle build, relevant integration/security cases, generated SQL/query behavior where needed and startup/profile configuration when wiring changed.

package/global-config/skills/long-task-state/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: long-task-state
+description: Preserve confirmed facts, assumptions, rejected hypotheses, decisions, progress, blockers, next actions, and verification for large or interruptible engineering tasks so work resumes without reconstructing or repeating reasoning.
+---
+
+# Long Task State
+
+Use for work likely to span many steps, context compaction, or multiple sessions.
+
+Prefer session-native task tracking for ordinary work. For an explicitly requested long-horizon run (for example `/ues-run`), use the deterministic `.ues-work/<slug>/` workspace managed by `ocskill work`. For ad-hoc persistence outside that explicit workflow, ask before adding repository-level state.
+
+The V6 long-horizon workspace keeps `SPEC.md`, `PLAN.json`, `STATE.json`, `EVIDENCE.json`, task briefs, and reports. For smaller persistent notes that do not need task execution state, the concise [STATE.md](templates/STATE.md) ledger remains suitable.
+
+Update it only at meaningful boundaries:
+- acceptance criteria changed
+- a fact or assumption materially changed the plan
+- a hypothesis was disproved
+- an architecture/implementation decision was made
+- a work unit completed
+- verification produced new evidence
+- a blocker or risk appeared
+- the next resumable action changed
+
+Read [context-ledger.md](references/context-ledger.md) for the distinction between confirmed facts, assumptions, rejected hypotheses, and decisions.
+
+On resume, read the state file plus current Git diff/status before acting. Revalidate assumptions that may have gone stale. Treat recorded success as historical evidence; rerun verification when a fresh completion claim depends on it.
+
+Do not store secrets, hidden chain-of-thought, raw logs, or large copied source files in task state. Store concise evidence and decisions that another session can act on.

package/global-config/skills/long-task-state/references/context-ledger.md

@@ -0,0 +1,27 @@
+# Context ledger
+
+For long, complex, or interruption-prone work, preserve reasoning state compactly instead of preserving the whole conversation.
+
+Track four different kinds of knowledge:
+
+## Confirmed facts
+Repository or runtime facts with evidence, such as paths, symbols, commands, outputs, versions, and contracts.
+
+## Assumptions
+Claims currently used for planning that are not yet proven. Include confidence and the cheapest way to verify each one.
+
+## Rejected hypotheses
+Failed debugging or design hypotheses and the evidence that rejected them. This prevents a resumed session from retrying already-disproved ideas.
+
+## Decisions
+Chosen implementation/architecture decisions, material alternatives considered, and the evidence or constraint that justified the choice.
+
+Also keep:
+- acceptance criteria and their current status
+- a compact producer/consumer or boundary map when cross-module behavior matters
+- changed files and why they changed
+- fresh verification evidence with timestamps or run order
+- unresolved risks/blockers
+- exactly one resumable next action
+
+Keep the ledger concise. Link to files and commands rather than copying source or raw logs. Historical verification is context, not proof for a new completion claim; rerun checks when freshness matters.

package/global-config/skills/long-task-state/templates/STATE.md

@@ -0,0 +1,48 @@
+# UES Task State
+
+## Goal
+
+Describe the requested outcome in one paragraph.
+
+## Acceptance criteria
+
+- [ ] Observable requirement and current status.
+
+## Confirmed facts
+
+- Fact — evidence: path/symbol/command/output.
+
+## Assumptions
+
+- Assumption — confidence: low/medium/high — verify by: cheapest concrete check.
+
+## System map
+
+- Entry point:
+- Producers:
+- Consumers:
+- Contracts / persisted state:
+
+## Decisions
+
+- Decision — reason/evidence — alternatives rejected if material.
+
+## Rejected hypotheses
+
+- Hypothesis — evidence that disproved it.
+
+## Changed files
+
+- Path — why it changed.
+
+## Verification evidence
+
+- Check/command — result — run order/time if useful.
+
+## Blockers / risks
+
+- Current blocker, unresolved critic finding, or known risk.
+
+## Next action
+
+Exactly one concrete resumable next step.

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

@@ -0,0 +1,10 @@
+---
+name: nestjs-engineering
+description: Work on NestJS apps: modules, controllers, providers, DTO validation, guards, interceptors, persistence, and tests.
+---
+
+# Nestjs Engineering
+
+Respect module boundaries and DI. Keep controllers thin and business rules in existing services/domain layers. Use DTO validation consistently. Enforce auth with guards/policies. Preserve exception/response conventions and OpenAPI patterns if present.
+
+Read [workflow.md](references/workflow.md) when the task reaches domain-specific behavior, compatibility, failure, or verification boundaries.