superpowers-mcp 6.4.4 → 6.4.5

package/package.json

@@ -2,7 +2,7 @@
   "name": "superpowers-mcp",
   "displayName": "Superpowers MCP",
   "description": "Superpowers skills library (TDD, debugging, collaboration workflows) as an MCP server for VSCode and Antigravity",
-  "version": "6.4.4",
+  "version": "6.4.5",
   "engines": {
     "node": ">=18"
   },
@@ -39,7 +39,7 @@
   ],
   "overrides": {
     "@hono/node-server": "^2.1.1",
-    "fast-uri": "^4.1.3",
+    "fast-uri": "^4.2.1",
     "hono": "^4.13.7",
     "qs": "^6.16.0"
   },

package/scripts/upstream-drift.js

@@ -93,11 +93,18 @@ function readBaseline(baselinePath = BASELINE_PATH) {
     return parsed;
 }
 
+/** OS metadata Finder/Explorer drop into folders; never upstream content. */
+const OS_JUNK = new Set([".DS_Store", "Thumbs.db", "desktop.ini"]);
+const isOsJunk = (name) => OS_JUNK.has(name) || name.startsWith("._");
+
 /** Walk the fork's skills tree and return the upstream-style paths it covers. */
 function localSkillPaths(skillsDir = SKILLS_DIR) {
     const found = new Set();
     const walk = (dir, relative) => {
         for (const entry of fs.readdirSync(dir, { withFileTypes: true })) {
+            if (isOsJunk(entry.name)) {
+                continue;
+            }
             const nextRelative = relative ? `${relative}/${entry.name}` : entry.name;
             if (entry.isDirectory()) {
                 walk(path.join(dir, entry.name), nextRelative);
@@ -378,4 +385,4 @@ if (require.main === module) {
     });
 }
 
-module.exports = { parseArgs, skillNameOf, readBaseline, localSkillPaths, classifyDrift, classifyCoverage, requireCompleteTreeForRecord };
+module.exports = { parseArgs, skillNameOf, isOsJunk, readBaseline, localSkillPaths, classifyDrift, classifyCoverage, requireCompleteTreeForRecord };

package/skills/writing-plans/SKILL.md

@@ -7,9 +7,7 @@ description: Use when you have a spec or requirements for a multi-step task, bef
 
 ## Overview
 
-Write comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.
-
-Assume they are a skilled developer, but know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.
+Write implementation plans for an engineer who has not seen this codebase or this spec. Assume they write idiomatic code in the project's language once they know the exact interface and the exact test, and that they will make a reasonable choice wherever the plan leaves one open. What they cannot know is what you decided: which files, which names and signatures, which values from the spec, which tests prove each task. Document those. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.
 
 **Announce at start:** "I'm using the writing-plans skill to create the implementation plan."
 
@@ -66,9 +64,9 @@ deliverable needs them; split only where a reviewer could meaningfully
 reject one task while approving its neighbor. Each task ends with an
 independently testable deliverable.
 
-## Bite-Sized Task Granularity
+## Step Granularity
 
-**Each step is one action (2-5 minutes):**
+**Each step is one action with a checkable result:**
 - "Write the failing test" - step
 - "Run it to make sure it fails" - step
 - "Implement the minimal code to make the test pass" - step
@@ -147,12 +145,11 @@ def test_specific_behavior():
 Run: `pytest tests/path/test.py::test_name -v`
 Expected: FAIL with "function not defined"
 
-- [ ] **Step 3: Write minimal implementation**
+- [ ] **Step 3: Implement `function(input: InputType) -> ResultType` in `exact/path/to/file.py`**
 
-```python
-def function(input):
-    return expected
-```
+One line on the approach when the signature and the test leave a choice
+(which library call, which data structure); a code block only for an
+algorithm they do not determine.
 
 - [ ] **Step 4: Run test to verify it passes**
 
@@ -167,15 +164,28 @@ git commit -m "feat: add specific feature"
 ```
 ````
 
-## No Placeholders
-
-Every step must contain the actual content an engineer needs. These are **plan failures** — never write them:
-- "TBD", "TODO", "implement later", "fill in details"
-- "Add appropriate error handling" / "add validation" / "handle edge cases"
-- "Write tests for the above" (without actual test code)
-- "Similar to Task N" (repeat the code — the engineer may be reading tasks out of order)
-- Steps that describe what to do without showing how (code blocks required for code steps)
-- References to types, functions, or methods not defined in any task
+## What a Step Contains
+
+A step is done when the implementer can write exactly one reasonable thing
+from it. That is the whole requirement: unambiguous, not complete. Each kind
+of step carries what makes it unambiguous and nothing more:
+
+- **A test step:** the test's name and its assertions, as code, with the
+  spec's exact values in them.
+- **A code step:** the exact signature (name, parameters, return type), the
+  file it lives in, and the specific values the spec pins. The implementer
+  writes the body. A body appears only for an algorithm the signature and
+  tests do not determine, or for exact copy the spec fixes.
+- **A verification step:** the command to run and the output that means it
+  passed.
+- **A reference to another task:** that task's Interfaces block says what
+  to use; the plan does not repeat that task's code.
+
+A plan is the set of decisions the implementer cannot make alone. A plan
+longer than the code it describes has written the code instead. Lines that
+decide nothing ("TBD", "handle edge cases", "add appropriate validation",
+"write tests for the above", a type or function no task defines) are the
+opposite failure, and the self-review catches both.
 
 ## Self-Review
 
@@ -183,12 +193,14 @@ After writing the complete plan, look at the spec with fresh eyes and check the
 
 **1. Spec coverage:** Skim each section/requirement in the spec. Can you point to a task that implements it? List any gaps.
 
-**2. Placeholder scan:** Search your plan for red flags — any of the patterns from the "No Placeholders" section above. Fix them.
+**2. Step scan:** Every step must let the implementer write exactly one reasonable thing, and no step may carry more than that: a line that decides nothing is a gap, a function body the signature and tests already determine is a transcript. Fix both.
 
 **3. Type consistency:** Do the types, method signatures, and property names you used in later tasks match what you defined in earlier tasks? A function called `clearLayers()` in Task 3 but `clearFullLayers()` in Task 7 is a bug.
 
 **4. Review Focus:** For each input class or failure mode the spec implies, is there a task whose tests exercise it? The five uncovered ones most likely to bite a person go in the Review Focus section, and each line there gets its test added to the owning task. An empty section means you checked and found none, not that you skipped the check.
 
+**5. Proportion:** Compare the plan's length to the spec's. A plan several times longer than the spec it implements is a transcript of the program, not a plan. If code blocks are most of the document, replace bodies with signatures, test names and assertions, and check that each step is still unambiguous.
+
 If you find issues, fix them inline. No need to re-review — just fix and move on. If you find a spec requirement with no task, add the task.
 
 ## Execution Handoff

package/skills/writing-plans/skeleton-first-plans.md

@@ -117,8 +117,9 @@ are **plan failures** — never write them:
 
 ## Self-Review
 
-Run SKILL.md's Self-Review checklist, reading step 2 against "No Vague
-Contracts" above rather than "No Placeholders".
+Run SKILL.md's Self-Review checklist, reading step 2 against
+"No Vague Contracts" above rather than against the step template in
+"What a Step Contains".
 
 ## Red Flags