dsh-slopo agent
3490e5aba0
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).
62 lines
3.6 KiB
Markdown
62 lines
3.6 KiB
Markdown
---
|
|
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.
|