elliot-stack 1.0.33 → 1.0.36

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "elliot-stack",
-  "version": "1.0.33",
+  "version": "1.0.36",
   "description": "Elliot's skill stack for Claude Code — install via npx elliot-stack@latest",
   "bin": {
     "elliot-stack": "bin/install.cjs"

package/skills/estack-prompt-builder-coach/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: estack-prompt-builder-coach
-version: 1.0.2
+version: 1.0.5
 description: (prompt-builder-coach) Use whenever you or the user need to write, sharpen, audit, or scope a prompt or work request for an AI agent or model. This is a four-part kit covering shaping a fuzzy idea into a decided goal, building a prompt from scratch, auditing a draft request that feels vague, and defining what "done" looks like when the task is fuzzy. Trigger when the user says "help me write a prompt", "build me a prompt", "audit this prompt", "make this request better", "why is the AI giving me generic output", "I don't know what I want", "I have a rough idea", "what should done look like", or when handing a task to another agent and wanting it to land. Use it even when the user did not say the word "prompt" but is clearly trying to get an AI to do consequential work. Do not use for quick factual lookups or for executing an already well-defined task.
 ---
 
@@ -71,7 +71,7 @@ A separate file, examples.md, holds annotated examples of strong prompts: thin a
 </examples>
 
 <output>
-Every finished prompt or brief gets saved to a markdown file with a descriptive snake_case name. In this environment, save to /mnt/user-data/outputs/. If present_files is available, present the file. When the auditor revises a prompt, save the revision as a new file rather than overwriting the original, so the user keeps the before and after.
+When a finished prompt or brief is ready, output it in full in chat. Then ask the user: "Would you like me to save this as a file?" Only save if they say yes. When saving, use a descriptive snake_case filename in the current working directory. When the auditor revises a prompt, treat the revision as a new finished brief: output it in chat and ask the same question — do not automatically overwrite or create files.
 </output>
 
 <guardrails>

package/skills/estack-prompt-builder-coach/definition-of-done-generator.md

@@ -23,7 +23,7 @@ This part runs two ways. Standalone: SKILL.md routes the user here because they
 
 4. Deliver in two forms. A compact version, 2 to 4 sentences, ready to paste at the end of any work brief. An expanded version with the labeled breakdown above, for reference. Both must be specific to the user's actual task, not generic project-management language.
 
-5. Confirm and route. Ask: "Does this match what you'd consider done? Anything I should adjust?" If running standalone, save the definition of done to a markdown file in /mnt/user-data/outputs/ and present it if possible. If running mid-flow from the builder, do not save separately; carry the confirmed definition of done back to the builder, return to prompt-builder.md, re-read it per SKILL.md Rule 1, and resume the interview using this definition of done as the answer to that field.
+5. Confirm and route. Ask: "Does this match what you'd consider done? Anything I should adjust?" If running standalone, output the definition of done in full in chat, then ask: "Would you like me to save this as a file?" Only save if they say yes. If running mid-flow from the builder, do not save or ask; carry the confirmed definition of done back to the builder, return to prompt-builder.md, re-read it per SKILL.md Rule 1, and resume the interview using this definition of done as the answer to that field.
 </instructions>
 
 <output>

package/skills/estack-prompt-builder-coach/prompt-builder.md

@@ -20,7 +20,7 @@ You are a work-briefing partner, Part 1 of a four-part prompt kit, the Useful Qu
 
 4. Assemble the brief. Write it as a single natural-language paragraph or short set of paragraphs, not a labeled form. It should read like something said to a trusted senior colleague in two minutes, and be immediately usable without editing. Aim for the shortest version that is still complete. If you want a concrete reference for the target shape, read examples.md. Then run three checks before delivering: a flashlight check, that the brief names both the center (intent, focus) and the edges (what is out of scope); a vague-word check, replacing "better", "cleaner", "sharper", "strategic", "good" with what they concretely mean here; a mode check, that if the thesis is unresolved the brief asks for thinking or options first, not a finished artifact.
 
-5. Confirm, save, and hand off. Show the brief and ask: "Does this capture the work? Anything I got wrong, or anything missing that would change the answer?" Once confirmed, save it to a markdown file in /mnt/user-data/outputs/ with a descriptive name and present it if present_files is available. Then hand off to the Vague Ask Auditor per SKILL.md Rule 2. Do not declare the work finished until the audit has run against the brief just built.
+5. Confirm, output, and hand off. Show the brief and ask: "Does this capture the work? Anything I got wrong, or anything missing that would change the answer?" Once confirmed, output the finished brief in full in chat, then ask: "Would you like me to save this as a file?" Only save if they say yes. Then hand off to the Vague Ask Auditor per SKILL.md Rule 2. Do not declare the work finished until the audit has run against the brief just built.
 </instructions>
 
 <output>

package/skills/estack-prompt-builder-coach/vague-ask-auditor.md

@@ -17,7 +17,7 @@ This part runs two ways. Standalone: SKILL.md routes the user here because they
 
 5. Rebuild the prompt, re-reading the builder first. Before producing the corrected version, re-read prompt-builder.md in full. This is SKILL.md Rule 1: you are switching back to the builder's job, so you reload the builder's instructions and assembly method. Do not patch the prompt from memory. Then rebuild the request using the builder's assembly approach, incorporating the user's answers and filling the gaps. Keep the same tone and register as the original; if the original was casual, keep it casual but clear. Do not inflate the request beyond what the task requires.
 
-6. Show before and after, then save. Show the original and the rewritten version side by side so the user can see what changed and why. Save the rewritten prompt to a new markdown file in /mnt/user-data/outputs/, a new file rather than overwriting the original, so the before and after are both kept. Present it if present_files is available.
+6. Show before and after, then ask to save. Show the original and the rewritten version side by side in chat so the user can see what changed and why. Then ask: "Would you like me to save this as a file?" Only save if they say yes — and if so, save the rewritten version as a new file with a descriptive name, not overwriting any original.
 </instructions>
 
 <output>

package/skills/estack-repo-search/SKILL.md

@@ -1,68 +1,70 @@
----
-name: estack-repo-search
-version: 1.0.2
-description: >-
-  (repo-search) Clone and search external GitHub repositories to answer questions about their
-  code. Use this skill whenever the user references a repo you don't have local
-  context for, asks about code in an external project, wants to compare
-  implementations across repos, or needs information from a codebase that isn't
-  in the current working directory. Also use when the user says things like
-  "check how X does it", "look at the source for Y", "search that repo",
-  "clone it and find...", or references a GitHub URL. If you're unsure whether
-  you have enough context about an external codebase to answer accurately,
-  use this skill to clone it and look.
----
-
-# Repo Search
-
-Search external repositories by cloning them into a persistent sandbox and exploring with subagents.
-
-## Available repos
-
-```!
-mkdir -p ~/repo-search-storage
-echo "=== Repo Sandbox: ~/repo-search-storage ==="
-echo ""
-found=0
-for dir in ~/repo-search-storage/*/; do
-  [ -d "$dir/.git" ] || continue
-  found=1
-  name=$(basename "$dir")
-  url=$(cd "$dir" && git remote get-url origin 2>/dev/null || echo "(no remote)")
-  echo "- $name  →  $url"
-  echo "  Updating..."
-  (cd "$dir" && git pull --ff-only 2>&1) | sed 's/^/  /'
-  echo ""
-done
-if [ "$found" -eq 0 ]; then
-  echo "(no repos cached yet)"
-fi
-```
-
-Present the user with the repos listed above and offer to search any of them or clone a new one.
-
-## Finding the correct repo
-
-Before cloning, you must have the exact GitHub URL. Follow these rules:
-
-- **If the user gave a full GitHub URL** (e.g. `https://github.com/org/repo`), use it directly.
-- **If the user gave only a name** (e.g. "openclaw", "langchain"), use WebSearch to find the correct GitHub repository URL first. Never guess a repo URL — confirm it via search.
-- **Always verify** the search result matches what the user is asking about before cloning. It doesn't hurt to confirm with the user — "I found X repo, is that the one you meant?" — before spending time cloning. Wrong repo = wasted time and misleading answers.
-
-## Cloning
-
-Once you have a confirmed URL, shallow clone into the sandbox:
-
-```bash
-git clone --depth 1 <repo-url> ~/repo-search-storage/<repo-name>
-```
-
-## Searching
-
-To explore a repo, spawn one or more **Haiku** subagents using the Agent tool with `model: "haiku"` and `subagent_type: "Explore"`. In the prompt, always include the **full absolute path** to the cloned repo (e.g. `C:/Users/2supe/repo-search-storage/gstack`) and tell the subagent to search within that directory. Without this, the subagent won't know where to look.
-
-If the question spans multiple areas of the repo, spawn multiple subagents in parallel — each focused on a different aspect — to get answers faster.
-
+---
+name: estack-repo-search
+version: 1.0.3
+description: >-
+  (repo-search) Clone and search external GitHub repositories to answer questions about their
+  code. Use this skill whenever the user references a repo you don't have local
+  context for, asks about code in an external project, wants to compare
+  implementations across repos, or needs information from a codebase that isn't
+  in the current working directory. Also use when the user says things like
+  "check how X does it", "look at the source for Y", "search that repo",
+  "clone it and find...", or references a GitHub URL. If you're unsure whether
+  you have enough context about an external codebase to answer accurately,
+  use this skill to clone it and look.
+---
+
+# Repo Search
+
+Search external repositories by cloning them into a persistent sandbox and exploring with subagents.
+
+## Available repos
+
+```!
+mkdir -p ~/repo-search-storage
+echo "=== Repo Sandbox: ~/repo-search-storage ==="
+echo ""
+found=0
+for dir in ~/repo-search-storage/*/; do
+  [ -d "$dir/.git" ] || continue
+  found=1
+  name=$(basename "$dir")
+  url=$(cd "$dir" && git remote get-url origin 2>/dev/null || echo "(no remote)")
+  echo "- $name  →  $url"
+  echo "  Updating..."
+  (cd "$dir" && git pull --ff-only 2>&1) | sed 's/^/  /'
+  echo ""
+done
+if [ "$found" -eq 0 ]; then
+  echo "(no repos cached yet)"
+fi
+```
+
+Present the user with the repos listed above and offer to search any of them or clone a new one.
+
+## Finding the correct repo
+
+Before cloning, you must have the exact GitHub URL. Follow these rules:
+
+- **If the user gave a full GitHub URL** (e.g. `https://github.com/org/repo`), use it directly.
+- **If the user gave only a name** (e.g. "openclaw", "langchain"), use WebSearch to find the correct GitHub repository URL first. Never guess a repo URL — confirm it via search.
+- **Always verify** the search result matches what the user is asking about before cloning. It doesn't hurt to confirm with the user — "I found X repo, is that the one you meant?" — before spending time cloning. Wrong repo = wasted time and misleading answers.
+
+## Cloning
+
+Once you have a confirmed URL, shallow clone into the sandbox:
+
+```bash
+git clone --depth 1 <repo-url> ~/repo-search-storage/<repo-name>
+```
+
+## Searching
+
+To explore a repo, spawn one or more **Haiku** subagents using the Agent tool with `model: "haiku"` and `subagent_type: "Explore"`. In the prompt, always include the **full absolute path** to the cloned repo (e.g. `C:/Users/2supe/repo-search-storage/gstack`) and tell the subagent to search within that directory. Without this, the subagent won't know where to look.
+
+If the question spans multiple areas of the repo, spawn multiple subagents in parallel — each focused on a different aspect — to get answers faster.
+
+**The subagent's job is navigation, not answers.** Use subagent results to identify which files are relevant, then **read those files yourself** with the Read tool before drawing conclusions. Never trust a subagent's summary of code verbatim — always verify by reading the source directly.
+
 ---
 
 ## Skill Feedback