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).
60 lines
3.2 KiB
Markdown
60 lines
3.2 KiB
Markdown
---
|
|
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.
|