feat: add runtime-neutral DeepSeek Harness skill projection

.dsh/skills/engineer-software/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: engineer-software
+description: >-
+  Route substantive software engineering work through the smallest evidence-driven workflow:
+  close unclear requirements or plans, trace an unknown failure, run a disposable decision probe,
+  deliver and verify a defined code change or refactor, inspect structural redundancy, or draft
+  local work items. Use when software behavior, diagnosis, architecture, implementation, or
+  acceptance evidence materially matters. Do not use for ordinary explanations, simple code
+  reading, translation or formatting, or mechanical file and Git operations whose method and
+  outcome are already clear.
+---
+
+# Engineer Software
+
+Use the least workflow that can produce a trustworthy outcome. The modules below are
+alternative starting modes, not phases that every task must traverse.
+
+## Operating contract
+
+1. Read repository instructions and inspect existing user changes before any edit.
+2. Check the bypass boundary before choosing a module.
+3. Select the first module from the user's current uncertainty, not from the eventual task type.
+4. Read exactly one primary module before acting. Do not pre-read other modules for completeness.
+5. Stay in that module until it finishes or its exit evidence proves another module is necessary.
+6. Before a transition, state the evidence that closed the current module and the unresolved need
+   the next module must handle. Then return here and read only that next module.
+7. Bind completion claims to fresh evidence from the final relevant state. Label manual, missing,
+   flaky, or environment-dependent evidence instead of calling it a pass.
+8. Never repeat a module or traverse a cycle without new evidence. Stop with the unresolved blocker
+   when another pass would only repeat questions, probes, or patches.
+
+## Bypass
+
+Bypass this workflow and answer or act directly for factual explanations, code reading,
+translation, formatting, obvious text corrections, specified reversible file operations, and
+explicitly authorized mechanical Git operations. Upgrade into a module only if inspection reveals
+a material software decision, unknown cause, structural risk, or nontrivial acceptance burden.
+
+## Choose the first module
+
+| Current need | Read |
+| --- | --- |
+| Outcome, behavior, scope, compatibility, or plan is materially unresolved | [Shape work](references/shape-work.md) |
+| A reported symptom exists but its cause or failure mechanism is unknown | [Trace failure](references/trace-failure.md) |
+| One bounded design or interaction question needs a disposable experiment | [Probe choice](references/probe-choice.md) |
+| Production behavior and edit scope are closed enough to change and verify | [Deliver change](references/deliver-change.md) |
+| The task is to find or assess architecture, design, policy, or implementation redundancy | [Inspect structure](references/inspect-structure.md) |
+| The requested output is a local PRD, task breakdown, or triage draft | [Manage work items](references/manage-work-items.md) |
+
+## Tie breakers
+
+- Route an unknown cause to `trace-failure`, even when the user also asks for a fix.
+- Route a known cause with a closed fix boundary directly to `deliver-change`.
+- Route an assessment of structure to `inspect-structure`; route an already-approved structural
+  change to `deliver-change`, which still applies its conditional structure gate.
+- Use `probe-choice` only when an experiment can resolve a named decision. It is never a routine
+  pre-implementation stage.
+- For a mixed request, start with the earliest unresolved condition that can invalidate later work.
+  Skip `shape-work` when the request and repository already close the contract.
+- Keep work-item output local or in the conversation. Remote publication is outside this skill.
+
+## Shared boundaries
+
+- Preserve pre-existing work and stay inside the requested scope.
+- Inspect facts that are cheap to obtain before asking the user. Ask only when the answer can
+  change visible behavior, compatibility, data, security, external state, or task scope.
+- Do not add speculative abstractions, options, interfaces, migration lanes, or coordination
+  machinery.
+- Do not commit, push, publish, deploy, or mutate remote systems unless the user separately and
+  explicitly authorizes that action.

.dsh/skills/engineer-software/references/deliver-change.md

@@ -0,0 +1,57 @@
+# Deliver Change
+
+Make the smallest sufficient production change and prove the final state.
+
+## Enter
+
+Use this module when the intended outcome, protected behavior, edit scope, and acceptance evidence are
+closed enough to implement. Carry forward an established reproduction or decision contract instead of
+restarting discovery. Return to `trace-failure` when the cause is still unknown.
+
+## Execute
+
+1. Inspect repository rules, the working tree, nearby tests, public contracts, and affected callers.
+   Preserve changes that predate the task.
+2. Establish before-change evidence at the cheapest decisive seam:
+   - changed behavior: a focused check rejects the desired behavior for the expected reason;
+   - defect: the real symptom reproduces;
+   - behavior-preserving refactor: characterization or affected checks pass first;
+   - performance: a repeatable baseline and target exist;
+   - configuration or generated output: a parser, schema, build, snapshot, or smoke check exists.
+3. Apply the conditional **structure-risk gate** only when the change adds or moves a module,
+   interface, policy, validation rule, state owner, data representation, adapter, migration lane,
+   broad responsibility, or copied nontrivial logic. Search for the existing owner, comparable
+   capability, and real callers.
+   Then check:
+   - extend the authoritative owner instead of creating a parallel implementation;
+   - keep policy, validation, state, and data representation single-sourced;
+   - require wrappers and public interfaces to remove more complexity than they expose;
+   - preserve dependency direction and avoid cycles or permanent dual paths;
+   - give compatibility or migration paths an explicit end state and removal condition.
+   Skip the full gate for a narrow local edit once ownership is obvious. If the gate cannot be judged
+   locally, stop and enter `inspect-structure`.
+4. Change one independently verifiable behavior slice at a time. For new or changed behavior, write
+   or strengthen the decisive check before production code when a correct seam exists, observe the
+   expected failure, implement only enough to pass, and inspect the actual result.
+5. Refactor only to remove evidenced duplication, leakage, or accidental complexity needed by the
+   current change. Do not add speculative flags, factories, interfaces, extension points, or future
+   behavior.
+6. Re-run direct evidence after every later edit that can affect it. Then run affected checks and
+   only the broader build, type, lint, schema, compatibility, or end-to-end checks justified by risk.
+7. Inspect the final diff for scope drift, user-work damage, debug probes, disabled checks, stale
+   dual paths, accidental generated output, and new responsibilities with no clear owner.
+
+When no correct automated seam exists, use the strongest honest behavioral or manual evidence and
+report the missing seam; do not add a shallow test that cannot observe the real contract.
+
+## Exit
+
+- If the structure-risk gate cannot establish an owner or safe boundary, stop before the structural
+  edit, report the uncertainty, and enter `inspect-structure`.
+- If evidence invalidates the assumed cause, stop stacking patches and enter `trace-failure`.
+- If evidence invalidates the product or compatibility contract, enter `shape-work`.
+- Otherwise report the changed behavior and scope, decisive starting evidence, fresh final
+  verification with exact outcomes, structural-gate result when it ran, and any pre-existing failure
+  or remaining uncertainty.
+
+Commit, push, publish, or deploy only when separately authorized.

.dsh/skills/engineer-software/references/inspect-structure.md

@@ -0,0 +1,45 @@
+# Inspect Structure
+
+Find architecture, design, policy, and implementation redundancy with code evidence.
+
+## Enter
+
+Use this module for a read-only structural audit or when a local change cannot establish the correct
+owner or abstraction boundary. Do not treat aesthetic preference, file count, or unfamiliarity as a
+finding. Implementation is out of scope until the user accepts a change boundary.
+
+## Execute
+
+1. Define the inspected subsystem, user-visible behavior, protected contracts, and evidence needed
+   for a credible finding. Read relevant domain terms and decision records before judging intent.
+2. Trace responsibilities from public entry points through callers, dependencies, data ownership,
+   state transitions, and tests. Identify the current authoritative owner for each rule or concept.
+3. Look for evidenced candidates:
+   - duplicate responsibility, policy, validation, state, or data representation;
+   - parallel implementations or adapters with no distinct contract;
+   - pass-through wrappers or public interfaces that expose as much complexity as they hide;
+   - knowledge scattered across callers, dependency cycles, or ownership leakage;
+   - permanent old/new paths, dead adapters, or configuration that preserves two sources of truth;
+   - tests forced onto private helpers because no stable behavioral seam exists.
+4. For each candidate, cite paths, symbols, callers, and observable maintenance or correctness cost.
+   Apply a deletion or merge thought experiment: say where the complexity would go and whether the
+   result concentrates ownership or merely moves code.
+5. Exclude or qualify intentional duplication before reporting it:
+   - migration or compatibility paths with a documented end condition;
+   - real platform or deployment differences;
+   - generated code, vendor code, fixtures, snapshots, and protocol mirrors;
+   - security, safety, or fault isolation;
+   - measured performance-critical duplication;
+   - an explicit architecture decision record whose trade-off still applies.
+6. Rank only surviving findings by evidence, user impact, change leverage, and reversibility. For each,
+   recommend keep, merge, delete, re-home, or investigate; include blast radius and verification needs.
+
+Prefer a concise evidence table or prose report. Generate diagrams or a separate visual artifact only
+when relationships are otherwise hard to understand or the user requests one.
+
+## Exit
+
+- If no candidate survives the false-positive checks, say so and identify the inspected boundary.
+- Report findings without changing production structure.
+- Before a system-level refactor, obtain user confirmation of the selected finding and boundary.
+  Then enter `shape-work` if behavior or compatibility remains open; otherwise enter `deliver-change`.

.dsh/skills/engineer-software/references/manage-work-items.md

@@ -0,0 +1,35 @@
+# Manage Work Items
+
+Turn known context into reviewable local planning and triage artifacts.
+
+## Enter
+
+Use this module when the requested deliverable is a local PRD, vertical task breakdown, acceptance
+brief, or triage draft. It does not discover an unknown failure or publish work to a remote tracker.
+
+## Execute
+
+1. Use the current conversation, repository evidence, domain vocabulary, accepted decisions, and
+   supplied issue text. Inspect missing facts only when they can change the draft.
+2. Choose the smallest requested artifact:
+   - PRD: problem, outcome, users, behavior, constraints, acceptance, decisions, and exclusions;
+   - tasks: thin end-to-end slices, acceptance checks, dependencies, and human decision points;
+   - triage: type, current evidence, reproduction status when relevant, missing information, proposed
+     state, and a durable implementation brief when ready.
+3. Keep requirements observable and tasks independently verifiable. Prefer vertical slices that
+   deliver a narrow complete behavior over layer-by-layer work packages.
+4. Mark assumptions, unresolved product or architecture choices, and external prerequisites. Do not
+   label a task autonomous when it still depends on an unstated human decision.
+5. Return the local draft in the conversation or write it only to a user-selected repository path.
+   Preserve parent material and avoid duplicating an existing authoritative plan.
+
+Do not publish, comment, label, close, or mutate any remote tracker. If the user asks for remote
+publication, prepare the reviewable draft and state that publication requires a separate explicitly
+authorized workflow outside this skill.
+
+## Exit
+
+Report the artifact location or inline draft, source evidence, dependencies, unresolved decisions,
+and the acceptance rule that makes each item ready. Stop after the requested artifact. If the user
+also requested implementation and the first executable slice is closed, return to the router and
+enter `deliver-change` for that slice only.

.dsh/skills/engineer-software/references/probe-choice.md

@@ -0,0 +1,34 @@
+# Probe Choice
+
+Use throwaway code to answer one decision, then remove the experiment.
+
+## Enter
+
+Use this module only when a named logic, state, data-model, feasibility, performance, or interaction
+question can be resolved more cheaply by running a bounded experiment than by discussion. A probe is
+not a draft production implementation.
+
+## Execute
+
+1. State the question, competing outcomes, observation method, stop condition, and decision each
+   possible result would support.
+2. Place the probe where its context is clear but mark it unmistakably disposable. Avoid changing
+   production paths unless the experiment specifically requires a controlled integration seam.
+3. Build the minimum runnable slice. Reuse the repository's runner and dependencies; avoid new
+   persistence, abstractions, error frameworks, generalized options, or polish.
+4. Make relevant state and results visible. Keep inputs fixed when comparing alternatives and use
+   one command or scenario to repeat the observation.
+5. Run the probe and record the result, uncertainty, and decision consequence. A runnable artifact
+   without an observed result is not evidence.
+6. Delete the probe after it answers the question, or retain it only with explicit user agreement
+   and a clear expiry. Capture the decision in the requested durable artifact when one exists.
+
+Do not promote a disposable implementation by renaming it. Reimplement the accepted behavior under
+production constraints and tests.
+
+## Exit
+
+- If the result closes implementation, return to the router and enter `deliver-change`.
+- If the result changes or leaves open the intended behavior, enter `shape-work`.
+- If the experiment uncovers an unexplained failure, enter `trace-failure`.
+- Otherwise report the answered question, observation, decision, and cleanup state.

.dsh/skills/engineer-software/references/shape-work.md

@@ -0,0 +1,38 @@
+# Shape Work
+
+Close only the decisions that can invalidate implementation or its acceptance.
+
+## Enter
+
+Use this module when the intended behavior, scope, compatibility boundary, success condition,
+or decision path is materially unresolved. Do not enter merely because a task is large.
+
+## Execute
+
+1. Inspect the current repository behavior, instructions, domain vocabulary, decision records,
+   public contracts, and nearby conventions that can answer the open questions.
+2. Frame the work in observable terms: user or system outcome, affected surface, constraints,
+   non-goals, acceptance evidence, and irreversible or externally visible choices.
+3. Separate confirmed facts, evidence-backed inferences, safe reversible defaults, and decisions
+   that genuinely require the user.
+4. Stress-test uncertain behavior with concrete examples, boundary cases, failure cases, and
+   compatibility scenarios. Prefer a small example over abstract debate.
+5. Ask at most one to three independent blocking questions together. Ask dependent questions
+   only after their prerequisite is resolved. Include a recommendation when evidence supports one.
+6. Record a durable architecture decision only when the choice is hard to reverse, surprising
+   without context, and the result of a real trade-off. Otherwise keep the decision with the work.
+7. Produce the smallest sufficient contract: outcome, scope, protected behavior, constraints,
+   acceptance checks, and remaining explicit exclusions.
+
+Do not force an interview, a repository map, multiple candidate plans, or a document artifact.
+Stop shaping as soon as the next action is safe and testable.
+
+## Exit
+
+- If the user requested only a decision or plan, return the contract and its unresolved risks.
+- If implementation is ready, return to the router and enter `deliver-change`.
+- If a named uncertainty is best answered by a disposable experiment, enter `probe-choice`.
+- If a symptom still lacks a cause, enter `trace-failure`.
+- If the desired output is a PRD or task set, enter `manage-work-items`.
+
+Exit evidence is a closed outcome and acceptance boundary, not agreement that every detail is known.

.dsh/skills/engineer-software/references/trace-failure.md

@@ -0,0 +1,43 @@
+# Trace Failure
+
+Find an evidenced cause before editing production behavior.
+
+## Enter
+
+Use this module for a bug, exception, failing check, intermittent symptom, or performance regression
+whose cause or failure mechanism is not yet established. If the cause and change boundary are already
+known, use `deliver-change` instead.
+
+## Execute
+
+1. Build the cheapest decisive feedback signal at the smallest stable seam: a focused test, command,
+   request replay, browser scenario, trace replay, benchmark, or bounded harness.
+2. Reproduce the user's exact symptom. Distinguish a failing assertion from broken setup and record
+   pre-existing unrelated failures separately.
+3. Minimize the reproduction while preserving the failure. Raise the reproduction rate before
+   debugging a flaky case; control time, randomness, concurrency, or inputs when possible.
+4. Form only the competing hypotheses the evidence justifies. Rank them by observed facts and give
+   each a falsifiable prediction. Do not require a ceremonial fixed count.
+5. Test one prediction or causal variable at a time. Prefer a debugger or targeted boundary probe;
+   tag temporary instrumentation so it can be found and removed.
+6. For performance, establish a repeatable metric and baseline before changing code. Use profiling,
+   query plans, or bisection rather than general logging.
+7. Confirm the cause by showing that it predicts the symptom and that a controlled change or probe
+   removes or alters the symptom as expected. Check a plausible alternative when confusion remains.
+8. Remove temporary instrumentation and retain the minimized reproduction as regression evidence
+   when it exercises the real failure path.
+
+When debugging an agent or live process, do not ingest an actively written transcript or event log
+wholesale. Use bounded tails, time filters, completed runs, external logs, or a stable copied snapshot
+so the observation cannot recursively consume its own output.
+
+If no reliable signal can be built, stop with the exact attempts and request the smallest missing
+artifact or access: logs, trace, fixture, environment, or permission for bounded instrumentation.
+Do not fill the gap with speculation.
+
+## Exit
+
+- Report the reproduced symptom, causal evidence, affected boundary, and ruled-out alternatives.
+- If the user requested a fix and its scope is now closed, return to the router and enter
+  `deliver-change`, carrying the reproduction as baseline evidence.
+- If the cause exposes a broader unresolved design choice, enter `shape-work` before implementation.

.github/workflows/ci.yml

@@ -23,8 +23,6 @@ jobs:
       - uses: actions/setup-python@v5
         with:
           python-version: ${{ matrix.python-version }}
-          cache: pip
-          cache-dependency-path: requirements-dev.txt
       - name: Install validation dependency
         run: python -m pip install -r requirements-dev.txt
       - name: Validate public plugin package

.gitignore

@@ -14,3 +14,8 @@ venv/
 Thumbs.db
 evals/runs/
 dist/
+
+# DeepSeek Harness runtime state is local; the checked-in skill projection is intentional.
+.dsh/*
+!.dsh/skills/
+!.dsh/skills/**