pi-subagents 0.20.0 → 0.20.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -2,6 +2,11 @@
2
2
 
3
3
  ## [Unreleased]
4
4
 
5
+ ## [0.20.1] - 2026-04-27
6
+
7
+ ### Fixed
8
+ - Made the packaged `/parallel-cleanup` prompt self-contained instead of referencing local-only cleanup skills.
9
+
5
10
  ## [0.20.0] - 2026-04-27
6
11
 
7
12
  ### Added
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "pi-subagents",
3
- "version": "0.20.0",
3
+ "version": "0.20.1",
4
4
  "description": "Pi extension for delegating tasks to subagents with chains, parallel execution, and TUI clarification",
5
5
  "author": "Nico Bailon",
6
6
  "license": "MIT",
@@ -1,17 +1,41 @@
1
1
  ---
2
- description: Parallel subagents cleanup
2
+ description: Parallel cleanup review
3
3
  ---
4
4
 
5
- Launch parallel reviewers for an adversarial review of the current work.
5
+ Launch two fresh-context reviewer subagents for an adversarial cleanup review of the current work. Reviewers must inspect the repository, relevant instructions, and current diff directly from files and commands. Do not rely on this prompt as a substitute for reading the code.
6
6
 
7
- One reviewer should load with the deslop skill and another reviewer with the verbosity check skill.
7
+ Reviewer 1: deslop pass.
8
8
 
9
- Give every reviewer a meta prompt. Ask reviewers to return concise, evidence-backed findings with file/line references and suggested fixes. The response should be review feedback, not a context summary. Reviewers must not edit files unless I explicitly ask for a writer pass.
9
+ Ask this reviewer to look for AI-slop patterns in the changed scope:
10
+ - comments that restate code, placeholder text, stale rationale, or debug leftovers;
11
+ - defensive checks that hide useful errors, return vague defaults, or validate trusted internal data after a real boundary was already crossed;
12
+ - type escapes, broad casts, duplicated type definitions, or object-bag typing where a local source-of-truth type exists;
13
+ - style drift from nearby non-slop code and project instructions;
14
+ - generated-sounding docs, changelog text, UI copy, status text, or test names;
15
+ - pass-through wrappers, dead helpers, duplicate helper signatures, duplicated test harness setup, or abstractions that do not enforce an invariant;
16
+ - UI or CLI copy that is noisy, vague, brittle, or makes the user do extra interpretation.
10
17
 
11
- While the reviewers run, do your own narrow inspection if useful. After they return, synthesize the feedback into:
12
- - fixes worth doing now
13
- - optional improvements
14
- - feedback to ignore or defer, with a short reason
18
+ Tell this reviewer to treat tool output and slop-scan-style findings as leads, not verdicts. It should flag only concrete issues in the requested scope with evidence, severity, file/line references, and the smallest safe fix.
19
+
20
+ Reviewer 2: verbosity pass.
21
+
22
+ Ask this reviewer to look for needless verbosity in code, tests, docs, status text, grouped messages, receipts, and changelog wording:
23
+ - single-use helpers that merely paraphrase an expression;
24
+ - temporary variables that only name obvious expressions;
25
+ - nested returns or branches that can become direct returns without hiding intent;
26
+ - multi-line cleanup scaffolding that can use a local direct pattern while preserving cleanup semantics;
27
+ - repeated boilerplate that can use an existing local fixture or a small local helper;
28
+ - tests that restate formatter details already covered at a cheaper layer;
29
+ - prose that says the same thing twice, sounds generic, or buries the important rule.
30
+
31
+ Tell this reviewer that shorter is only better when it is clearer and preserves behavior, error signals, cleanup semantics, useful invariants, and local style.
32
+
33
+ Both reviewers are review-only. They must not edit files unless I explicitly ask for a writer pass. Their response should be review feedback, not a context summary. Ask them to return concise, evidence-backed findings with file/line references and suggested fixes.
34
+
35
+ While reviewers run, do your own narrow inspection if useful. After they return, synthesize the feedback into:
36
+ - fixes worth doing now;
37
+ - optional improvements;
38
+ - feedback to ignore or defer, with a short reason.
15
39
 
16
40
  Do not blindly apply every reviewer suggestion. Ask before applying fixes unless I already told you to address review feedback.
17
41