Scaffold the dsh-slopo bundle and port slopo's three agent skills

The three SKILL.md files are ports of the configs slopo 0.8.0 ships for
Claude Code, not new prose. What changed is the mechanics:

  * name + description frontmatter, both required by dsh
  * disable-model-invocation: true kept verbatim -- dsh has the same key,
    and slopo makes that choice for a reason (every one of these commands
    can spend minutes embedding)
  * allowed-tools / argument-hint / arguments dropped, not dsh keys
  * the !`slopo ...` shell-injection directive replaced with an
    instruction to call the slopo tool plus an explicit failure check,
    because dsh skill bodies do not execute commands

The guidance prose is quoted from slopo; NOTICE.md records the mapping and
the licence obligation that follows from it (AGPL-3.0-or-later, matching
upstream and the LICENSE file fetched from it).

skills/slopo-analyze-ignore/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: slopo-analyze-ignore
+description: Slopo reports similar code across the whole codebase and this skill triages the obvious false positives into the ignore file. Use for a first pass over a codebase's duplicate clusters.
+disable-model-invocation: true
+---
+
+# Initialization
+
+1. Call the `slopo` tool with `action: "analyze"`.
+   - The tool may answer that it started a background job. Wait for that job and read its output before continuing — the report is that output.
+2. If the call failed, report the error message and stop.
+
+# Report structure
+
+The report contains either:
+- a list of clusters with file paths and line ranges, or
+- the message "No duplicates found".
+
+If there are clusters to analyse:
+- the first line contains the path to the ignore file;
+- each cluster has a header line with a number and a hash, in the form `cluster N (hash):`.
+
+Similar code was detected using embedding models, so many results are likely similar by coincidence.
+
+# Instructions
+
+Your task is to take a quick look at each cluster and mark as ignored the ones containing code that is not a duplication worth taking action on. An ignored cluster contains duplication obviously not worth taking action on, or it is similar by coincidence. If justifying a keep or an ignore takes more than a short phrase, it is not obvious.
+
+For every ignored cluster, insert its hash into the ignore file. One hash per line. Inline comments are allowed, for example `78a8d42e60e8 # your short note`.
+
+This work is a quick check, not deep analysis. Decide each cluster from a single look. The report size should not change how you judge one cluster. A report with a few tens of clusters is not a reason to dig deeper. A report with a few hundred is not a reason to rush.
+
+Rules:
+- Load only the line ranges specified in the report. Do not read surrounding code or callers.
+- Ignore only obvious false positives, when a quick check is enough to decide. When unsure, keep the cluster.
+- If only part of the cluster is worth keeping, keep the whole cluster.
+
+Process clusters in batches; do not load everything at once.

skills/slopo-analyze-one/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: slopo-analyze-one
+description: Slopo reports the next unreviewed duplicate-code cluster and this skill judges whether it is worth acting on. Use to work through a codebase's clusters one at a time.
+disable-model-invocation: true
+---
+
+# Initialization
+
+1. Read any input supplied with the skill invocation. It may be empty, or it may contain a short cluster hash.
+2. Call the `slopo` tool with `action: "analyze-one"`. Pass `cluster` when a hash was supplied; omit it to take the next cluster in the report's order.
+   - The tool may answer that it started a background job. Wait for that job and read its output before continuing — the report is that output.
+   - If the input does not look like a short hash, say so and stop.
+3. If the call failed, report the error message and stop.
+
+# Report structure
+
+- The report contains one cluster with file paths and line ranges.
+- The first line contains the path to the ignore file.
+- The cluster has a header line with a hash, in the form `cluster 1 (hash):`.
+
+**Ignore file**
+If the cluster should be ignored, its hash goes into the ignore file. One hash per line. Inline comments are allowed, for example `78a8d42e60e8 # your short note`.
+
+# Instructions
+
+The report contains similar code. Take a quick look without deeper analysis and judge whether this is a duplication with potential to act on. If the code is only similar by coincidence, or is not an actionable duplicate:
+- state this fact immediately, without further analysis;
+- offer the user the choice to add this cluster to the ignore file or discuss it further;
+- stop and wait for the user's decision.
+
+Otherwise, or when unsure, continue with deeper analysis to confirm.
+
+Deeper analysis guidelines:
+- Recall this project's standards and conventions related to code duplication and base your judgment on them, if there are any.
+- State risks and trade-offs. Not every duplication or violation is worth solving, and the user is the one deciding.
+- Judge a full refactor against a minimal safe improvement. The user decides the scope of change.
+- Be aware that some duplication is by design, or is deliberate technical debt.
+- Take into account existing (or missing) tests — how well they protect, and whether they need changing during a refactor.
+- Take into account project context and broader impact, not only the local change.
+
+Include information allowing the user to locate the code, for example file paths, function or class names, but no line numbers.
+
+## Handling the user's decisions
+
+After your deeper analysis, the user has a few options to continue.
+
+The user may prefer to discuss this further before deciding. Offer this as one of the options.
+
+If the user decides to ignore this duplication:
+- add the cluster hash to the ignore file.
+
+If the user decides to note this for later:
+- recall this project's standards and conventions related to tickets, notes and TODOs;
+- help the user record a summary of the analysis and enough information to locate the affected code in future — the cluster hash alone is not sufficient;
+- before writing a note, confirm where it should be written;
+- add the cluster hash to the ignore file.
+
+If the user decides to refactor now:
+- follow the project's conventions and the user's preferences for implementing changes.

skills/slopo-review/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: slopo-review
+description: Slopo reports similar code involving the current Git changes, and this skill reviews them as a note-taker for you. Use when a diff, branch or working tree should be checked for duplicated logic.
+disable-model-invocation: true
+---
+
+# Initialization
+
+1. Read any input supplied with the skill invocation. It may be empty, or it may contain a Git base ref.
+2. Call the `slopo` tool with `action: "review"`. Pass `base` when a base ref was supplied; omit it otherwise.
+   - The tool may answer that it started a background job. Wait for that job and read its output before continuing — the report is that output.
+3. If the call failed, report the error message and stop.
+
+# Report structure
+
+The report contains either:
+- a list of clusters with file paths and line ranges, or
+- the message "No duplicates found".
+
+Similar code was detected using embedding models, so many results are likely just similar by coincidence.
+Lines marked with `*` are the user's changes. Unmarked lines are pre-existing similar code.
+Line ranges point to similar code.
+
+# Instructions
+
+Judge whether the `*`-marked code introduces real duplication. The duplication may be between the changes and existing code, or between the changes themselves.
+
+Recall this project's standards and conventions related to code duplication.
+
+## Investigation is internal. Only the summary is external.
+
+You may read surrounding code and callers to judge whether a similarity matters. Do it if the outcome needs it. The response says what the problem is, not what you saw to figure it out. Everything else is for follow-up if the user asks.
+
+## First-turn output rules
+
+For this response you are not acting as a coding assistant giving analysis. You are a note-taker for the user's own review. The user will read the source themselves. Your job is to say what is worth their attention, not to explain what the code does or how it works.
+
+For a similarity that is not real duplication, summarise it briefly in a high-level way.
+
+For each similarity that matters:
+- Include information allowing the user to locate the code, for example file paths, function or class names, but no line numbers.
+- Name only the most important thing that is duplicated, in one simple short paragraph, as a high-level generalisation without internals.
+- Name the real problem it creates, in one simple short paragraph. Do not make up a problem to justify your choice. Do not propose a solution, do not describe the final shape.
+- If the project's standards or conventions related to code duplication are violated, name them. Otherwise do not mention it.
+
+Do NOT, in the first turn:
+- describe how the code works — no variable names, no library calls, no algorithm steps, no walk-through
+- sketch, name, or hint at a refactor, shared helper, or unification
+- edit files
+
+Group findings by how the code is actually related (same feature, same file, same underlying problem). Do not reference clusters or their numbers in your response.
+
+## Follow-up analysis
+
+The user may ask for more information, a deeper analysis, a follow-up question, or advice.
+In that case:
+- State risks and trade-offs. Not every duplication or violation is worth solving, and the user is the one deciding.
+- Judge a full refactor against a minimal safe improvement. The user decides the scope of change.
+- Be aware that some duplication is by design, or is deliberate technical debt.
+- Take into account existing (or missing) tests — how well they protect, and whether they need changing during a refactor.
+- Take into account project context and broader impact, not only the local change.