elliot-stack 1.0.36 → 1.0.38

package/skills/estack-github-issue-tracker/references/tracker-schema.md

@@ -1,96 +1,96 @@
-# Tracker File Schema
-
-Defines the format and fields for `github-tracker.md`.
-
----
-
-## File Header
-
-```markdown
-# GitHub Issue Tracker
-
-GitHub username: **USERNAME**
-
-## Config
-
-Tracked repos: all repos where I'm involved
-Excluded repos: none
-
----
-```
-
-## Config Section
-
-Plain English directives that control what the skill tracks and how it reports.
-The skill reads these on every run and respects them when filtering issues.
-
-Common directives:
-- `Tracked repos:` — which repos to include (default: all involving user)
-- `Excluded repos:` — repos to skip entirely (e.g., `ElliotDrel/*` to skip own repos)
-- Any other plain English instructions (e.g., "Don't show bot comments", "Focus on bugs only")
-
-The skill treats these as soft rules — it reads them and applies judgment. No rigid parsing.
-
-## Active Issues Section
-
-Each issue entry under `## Active Issues (watching for updates)`:
-
-```markdown
-### owner/repo#NUMBER — Title
-- **Goal:** What the user wants from this issue (e.g., "Get my fix merged", "Get maintainer to respond", "Monitor for upstream fix"). Drives next-step recommendations.
-- **Role:** Author | Commenter | Mentioned (brief description of involvement)
-- **Filed:** YYYY-MM-DD (only if authored by user)
-- **Status as of YYYY-MM-DD:** Open/Closed. Labels: label1, label2. Summary of current state. N comments total.
-- **What to check:** Specific signals to watch for (e.g., "Any Anthropic response?")
-- **Related:** #other, #issues (cross-references found in comments)
-- **Upstream:** owner/repo#NUMBER (if tracking an upstream dependency)
-- **Crash instances:** (optional, for bug reports with multiple data points)
-  1. Description of instance
-  2. Description of instance
-- **Workaround:** Description of workaround (if applicable)
-- **Duplicates found (YYYY-MM-DD):**
-  - **#NUMBER** — @author, "Title" (date). Why it's related/duplicate.
-- **Adjacent issues found (YYYY-MM-DD):**
-  - **#NUMBER** — @author, "Title" (date). Why it's adjacent (same space, different problem).
-- **Next steps (now):** Immediate actions for this check-in.
-- **Future:** Things to monitor or do later.
-- **History:**
-  - **YYYY-MM-DD:** Filed issue with 3 crash instances, upstream tracking in bun#28175
-  - **YYYY-MM-DD:** Posted workaround (callbackPort: 3118 fix)
-  - **YYYY-MM-DD:** Maintainer @user replied with fix proposal
-```
-
-### Field Rules
-
-- **"Status as of" date:** Always update to today's date during Phase 4.
-- **"Duplicates found" date:** Date when the duplicate was first identified. Don't change on subsequent check-ins.
-- **"Next steps (now)":** Clear after execution. If not executed, carry forward.
-- **"Future":** Accumulates over time. Remove items that become "Next steps (now)" or are no longer relevant.
-- **"Goal":** Set on first add, update if the user's intent changes. Use this to drive next-step recommendations — if the goal is "get merged" the next steps focus on what's blocking the merge; if "monitor for fix" the next steps focus on upstream signals.
-- **Role descriptions:** Keep brief. Examples: "confirmed bug + posted workaround", "shared skill + reported 64KB bug", "proposed configurable keybindings".
-- **"History:"** Append-only timestamped log. Format: `- **YYYY-MM-DD:** Action or event description`. Newest entries go last (chronological). Logs both our actions (filing, commenting, posting workarounds) and detected external events (maintainer replies, state changes, PRs merged). On initial filing, first entry must be: `- **YYYY-MM-DD:** Filed issue` (or `Added to tracker` if not authored by user).
-
-## Closed / Resolved Section
-
-Each entry under `## Closed / Resolved`:
-
-```markdown
-### owner/repo#NUMBER — Title
-- Brief resolution note (merged, auto-closed as duplicate of #X, fixed in vX.Y.Z, etc.)
-- Date closed if notable.
-```
-
-## Morning Check-In Procedure Section
-
-Static section with reusable `gh` CLI commands. Update USERNAME if it changes. Otherwise don't modify.
-
----
-
-## Update Rules
-
-1. **Only update the tracker file in Phase 4, after user confirmation.**
-2. **Preserve manually added content.** If the user added custom notes, crash data, workarounds, or other content not generated by this skill, keep it intact.
-3. **Move issues between sections** when state changes (Active → Closed, or Closed → Active if reopened).
-4. **Don't remove duplicate entries** — they're historical. Only add new ones.
-5. **Keep "What to check" relevant.** Update if the situation changed (e.g., if Anthropic responded, change from "Any Anthropic response?" to "Follow up on Anthropic's suggestion?").
-6. **Append new history entries. Never remove or edit existing history entries.**
+# Tracker File Schema
+
+Defines the format and fields for `github-tracker.md`.
+
+---
+
+## File Header
+
+```markdown
+# GitHub Issue Tracker
+
+GitHub username: **USERNAME**
+
+## Config
+
+Tracked repos: all repos where I'm involved
+Excluded repos: none
+
+---
+```
+
+## Config Section
+
+Plain English directives that control what the skill tracks and how it reports.
+The skill reads these on every run and respects them when filtering issues.
+
+Common directives:
+- `Tracked repos:` — which repos to include (default: all involving user)
+- `Excluded repos:` — repos to skip entirely (e.g., `ElliotDrel/*` to skip own repos)
+- Any other plain English instructions (e.g., "Don't show bot comments", "Focus on bugs only")
+
+The skill treats these as soft rules — it reads them and applies judgment. No rigid parsing.
+
+## Active Issues Section
+
+Each issue entry under `## Active Issues (watching for updates)`:
+
+```markdown
+### owner/repo#NUMBER — Title
+- **Goal:** What the user wants from this issue (e.g., "Get my fix merged", "Get maintainer to respond", "Monitor for upstream fix"). Drives next-step recommendations.
+- **Role:** Author | Commenter | Mentioned (brief description of involvement)
+- **Filed:** YYYY-MM-DD (only if authored by user)
+- **Status as of YYYY-MM-DD:** Open/Closed. Labels: label1, label2. Summary of current state. N comments total.
+- **What to check:** Specific signals to watch for (e.g., "Any Anthropic response?")
+- **Related:** #other, #issues (cross-references found in comments)
+- **Upstream:** owner/repo#NUMBER (if tracking an upstream dependency)
+- **Crash instances:** (optional, for bug reports with multiple data points)
+  1. Description of instance
+  2. Description of instance
+- **Workaround:** Description of workaround (if applicable)
+- **Duplicates found (YYYY-MM-DD):**
+  - **#NUMBER** — @author, "Title" (date). Why it's related/duplicate.
+- **Adjacent issues found (YYYY-MM-DD):**
+  - **#NUMBER** — @author, "Title" (date). Why it's adjacent (same space, different problem).
+- **Next steps (now):** Immediate actions for this check-in.
+- **Future:** Things to monitor or do later.
+- **History:**
+  - **YYYY-MM-DD:** Filed issue with 3 crash instances, upstream tracking in bun#28175
+  - **YYYY-MM-DD:** Posted workaround (callbackPort: 3118 fix)
+  - **YYYY-MM-DD:** Maintainer @user replied with fix proposal
+```
+
+### Field Rules
+
+- **"Status as of" date:** Always update to today's date during Phase 4.
+- **"Duplicates found" date:** Date when the duplicate was first identified. Don't change on subsequent check-ins.
+- **"Next steps (now)":** Clear after execution. If not executed, carry forward.
+- **"Future":** Accumulates over time. Remove items that become "Next steps (now)" or are no longer relevant.
+- **"Goal":** Set on first add, update if the user's intent changes. Use this to drive next-step recommendations — if the goal is "get merged" the next steps focus on what's blocking the merge; if "monitor for fix" the next steps focus on upstream signals.
+- **Role descriptions:** Keep brief. Examples: "confirmed bug + posted workaround", "shared skill + reported 64KB bug", "proposed configurable keybindings".
+- **"History:"** Append-only timestamped log. Format: `- **YYYY-MM-DD:** Action or event description`. Newest entries go last (chronological). Logs both our actions (filing, commenting, posting workarounds) and detected external events (maintainer replies, state changes, PRs merged). On initial filing, first entry must be: `- **YYYY-MM-DD:** Filed issue` (or `Added to tracker` if not authored by user).
+
+## Closed / Resolved Section
+
+Each entry under `## Closed / Resolved`:
+
+```markdown
+### owner/repo#NUMBER — Title
+- Brief resolution note (merged, auto-closed as duplicate of #X, fixed in vX.Y.Z, etc.)
+- Date closed if notable.
+```
+
+## Morning Check-In Procedure Section
+
+Static section with reusable `gh` CLI commands. Update USERNAME if it changes. Otherwise don't modify.
+
+---
+
+## Update Rules
+
+1. **Only update the tracker file in Phase 4, after user confirmation.**
+2. **Preserve manually added content.** If the user added custom notes, crash data, workarounds, or other content not generated by this skill, keep it intact.
+3. **Move issues between sections** when state changes (Active → Closed, or Closed → Active if reopened).
+4. **Don't remove duplicate entries** — they're historical. Only add new ones.
+5. **Keep "What to check" relevant.** Update if the situation changed (e.g., if Anthropic responded, change from "Any Anthropic response?" to "Follow up on Anthropic's suggestion?").
+6. **Append new history entries. Never remove or edit existing history entries.**

package/skills/estack-github-issue-tracker/tracker-template.md

@@ -1,58 +1,58 @@
-# GitHub Issue Tracker
-
-GitHub username: **USERNAME_HERE**
-
-## Config
-
-<!-- Directives for the check-in skill. Write in plain English. Examples:
-- "Skip issues on my own repos (ElliotDrel/*)"
-- "Only track issues on anthropics/claude-code and oven-sh/bun"
-- "Don't show me bot comments or auto-close spam"
--->
-
-Tracked repos: all repos where I'm involved
-Excluded repos: none
-
----
-
-## Active Issues (watching for updates)
-
-<!-- For each issue you're tracking, use this format:
-
-### owner/repo#NUMBER — Title
-- **Role:** Author | Commenter | Mentioned (brief description of involvement)
-- **Filed:** YYYY-MM-DD (if authored by you)
-- **Status as of YYYY-MM-DD:** Open/Closed. Labels: ... . Summary of current state.
-- **What to check:** What signals matter for this issue?
-- **Related:** #other, #issues (if any)
-- **Upstream:** owner/repo#NUMBER (if tracking an upstream dependency)
-- **Duplicates found (YYYY-MM-DD):**
-  - **#NUMBER** — @author, "Title" (date). Why it's related.
-- **Next steps (now):** Immediate actions to take this check-in.
-- **Future:** Things to monitor or do later.
-- **History:**
-  - **YYYY-MM-DD:** Filed issue (or "Added to tracker for monitoring")
--->
-
-## Closed / Resolved
-
-<!-- For each resolved issue:
-
-### owner/repo#NUMBER — Title
-- Brief resolution note (merged, auto-closed as duplicate, etc.)
--->
-
----
-
-## Morning Check-In Procedure
-
-Run this to get a quick status update on all active issues:
-
-```bash
-gh api search/issues?q=involves:USERNAME_HERE+updated:>$(python3 -c "import datetime; print((datetime.datetime.now()-datetime.timedelta(days=7)).strftime('%Y-%m-%d'))")+is:open --jq '.items[] | "#\(.number) \(.repository_url | split("/") | .[-2:] | join("/")) — \(.title) [updated: \(.updated_at)]"'
-```
-
-Then for each issue, check recent comments:
-```bash
-gh api repos/OWNER/REPO/issues/NUMBER/comments --jq '.[-3:] | .[] | "[\(.created_at)] @\(.user.login): \(.body[0:200])"'
-```
+# GitHub Issue Tracker
+
+GitHub username: **USERNAME_HERE**
+
+## Config
+
+<!-- Directives for the check-in skill. Write in plain English. Examples:
+- "Skip issues on my own repos (ElliotDrel/*)"
+- "Only track issues on anthropics/claude-code and oven-sh/bun"
+- "Don't show me bot comments or auto-close spam"
+-->
+
+Tracked repos: all repos where I'm involved
+Excluded repos: none
+
+---
+
+## Active Issues (watching for updates)
+
+<!-- For each issue you're tracking, use this format:
+
+### owner/repo#NUMBER — Title
+- **Role:** Author | Commenter | Mentioned (brief description of involvement)
+- **Filed:** YYYY-MM-DD (if authored by you)
+- **Status as of YYYY-MM-DD:** Open/Closed. Labels: ... . Summary of current state.
+- **What to check:** What signals matter for this issue?
+- **Related:** #other, #issues (if any)
+- **Upstream:** owner/repo#NUMBER (if tracking an upstream dependency)
+- **Duplicates found (YYYY-MM-DD):**
+  - **#NUMBER** — @author, "Title" (date). Why it's related.
+- **Next steps (now):** Immediate actions to take this check-in.
+- **Future:** Things to monitor or do later.
+- **History:**
+  - **YYYY-MM-DD:** Filed issue (or "Added to tracker for monitoring")
+-->
+
+## Closed / Resolved
+
+<!-- For each resolved issue:
+
+### owner/repo#NUMBER — Title
+- Brief resolution note (merged, auto-closed as duplicate, etc.)
+-->
+
+---
+
+## Morning Check-In Procedure
+
+Run this to get a quick status update on all active issues:
+
+```bash
+gh api search/issues?q=involves:USERNAME_HERE+updated:>$(python3 -c "import datetime; print((datetime.datetime.now()-datetime.timedelta(days=7)).strftime('%Y-%m-%d'))")+is:open --jq '.items[] | "#\(.number) \(.repository_url | split("/") | .[-2:] | join("/")) — \(.title) [updated: \(.updated_at)]"'
+```
+
+Then for each issue, check recent comments:
+```bash
+gh api repos/OWNER/REPO/issues/NUMBER/comments --jq '.[-3:] | .[] | "[\(.created_at)] @\(.user.login): \(.body[0:200])"'
+```

package/skills/estack-leadership-coach/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: estack-leadership-coach
-version: 3.1.0
+version: 3.1.1
 description: (leadership-coach) A leadership coach that walks through real decisions — delegation, and (over time) feedback, hiring, OKRs, conflict, performance — producing a concrete artifact each session (a brief, a diagnosis, a script) the user can act on immediately. Coaches by surfacing proven principles in the moment they're needed, then applying them to the user's actual situation.
 metadata:
   disable_model_invocation: true

package/skills/estack-leadership-coach/adding-references.md

@@ -56,7 +56,7 @@ If both apply (e.g., a book with multiple author talks) → synthesis as the pri
 
 ### Step 4 — Create the reference file
 
-**Location:** `~/.claude/skills/leadership-coach/references/<filename>.md`
+**Location:** `~/.claude/skills/estack-leadership-coach/references/<filename>.md`
 
 **Filename convention:** `<author-lastname>_<work-shortname>.md` — lowercase, hyphens not underscores within name parts, single underscore between author and work. Examples already in the skill:
 

package/skills/estack-migrate-claude-session-history/SKILL.md

@@ -1,7 +1,20 @@
 ---
 name: estack-migrate-claude-session-history
-version: 1.0.0
-description: (migrate-claude-session-history) Use whenever the user wants to move a Claude Code session (the .jsonl transcript plus its subagent sidecar files) from one project to another so that /resume picks it up under the new project. Triggers on phrases like "migrate this session", "move this session to <project>", "convert session X to be in project Y instead of Z", "transfer chat history to another project", "this session belongs under <project>", or when the user names a session UUID and a different target project. Handles the full workflow: backup, sidecar-aware copying, rewriting all 9 path-encoding variants in every entry, appending a visible user-message migration note, and end-to-end verification. Use this even if the user only describes the intent loosely (e.g. "this conversation should live under the personal-health project") — do not try to do this by hand with raw file moves; subtle cwd / encoded-path bugs will break /resume.
+version: 1.0.1
+description: >-
+  (migrate-claude-session-history) Use whenever the user wants to move a Claude
+  Code session (the .jsonl transcript plus its subagent sidecar files) from one
+  project to another so that /resume picks it up under the new project. Triggers
+  on phrases like "migrate this session", "move this session to <project>",
+  "convert session X to be in project Y instead of Z", "transfer chat history
+  to another project", "this session belongs under <project>", or when the user
+  names a session UUID and a different target project. Handles the full
+  workflow: backup, sidecar-aware copying, rewriting all 9 path-encoding
+  variants in every entry, appending a visible user-message migration note, and
+  end-to-end verification. Use this even if the user only describes the intent
+  loosely (e.g. "this conversation should live under the personal-health
+  project") - do not try to do this by hand with raw file moves; subtle cwd /
+  encoded-path bugs will break /resume.
 ---
 
 # Migrate Claude Session History

package/skills/estack-pdf-to-md/SKILL.md

@@ -1,10 +1,9 @@
 ---
 name: estack-pdf-to-md
-version: 1.0.0
+version: 1.0.1
 description: (pdf-to-md) Convert a PDF file to Markdown or plain text using the RunPulse API. Use this skill whenever the user wants to extract text from a PDF, convert a PDF to .md or .txt, OCR a PDF, "turn this PDF into text/markdown", drops a .pdf path into chat asking for its contents, or asks to run the RunPulse / Pulse converter. Trigger even when the user only says "convert this PDF" without naming the tool.
 ---
 
-# pdf-to-md
 
 Convert a PDF (or several PDFs) to Markdown or plain text using the RunPulse API. The underlying script splits the PDF into page batches, fires all batches in parallel against the RunPulse `/extract` endpoint, polls each async job, and reassembles the markdown in correct page order.
 

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

@@ -1,84 +1,84 @@
----
-name: estack-prompt-builder-coach
-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.
----
-
-# Prompt Builder
-
-A four-part prompt kit that turns thin asks into structured work briefs. This file is the router. Read it first, then read and follow the part file it routes you to.
-
-<role>
-You are the router and tone-setter for a four-part prompt kit. Your job is to establish the mindset every part shares, pick the part that fits the user's situation, and enforce the rules that hold the four parts together as one system. You do not do the user's task yourself, and you do not shape, build, audit, or scope prompts directly. You route.
-</role>
-
-<mindset>
-The unit of useful AI work is not a prompt, it is a brief. A prompt is something typed into a box. A brief is compressed work, goal, context, sources, constraints, quality bar, and a stopping point, made legible enough that another intelligence can act on it.
-
-Treat the AI on the other end as a senior director, not a junior. A junior needs every step spelled out. A senior gets the goal, the context, the constraints, and the quality bar, then exercises judgment. The leverage in modern models lives in that gap.
-
-Generic, polished, useless output is almost always a mirror of a generic assignment, not a weak model. Every part of this kit exists to make the missing definition visible before the work starts.
-
-The six fields, referred to by every part:
-1. Goal, the outcome, not the activity.
-2. Context, the background a smart colleague joining cold would need.
-3. Sources, what materials to use and their role.
-4. Constraints, the boundaries that keep the work practically right.
-5. Quality bar, what makes the output good, not just done-looking.
-6. Definition of done, the exact deliverable and the stopping point.
-
-The flashlight: a brief points a flashlight. The center of the beam is intent. The edges are scope, what is in and what is out. Name both. The edges get skipped most and matter most.
-
-Match overhead to stakes. Not every ask needs the full kit. Quick or exploratory asks stay loose.
-
-Shape before brief. Some work cannot be briefed yet, because the goal itself is not decided. Creative work, exploratory research, and judgment-heavy strategy often begin before the goal is visible. Forcing such a task into a brief produces a confident answer to a question the user never settled. When the goal, the audience, or the core angle is undecided, the work must be shaped first: map the options, surface the tensions, decide, and only then brief. Shaping and briefing are different modes. Do not blur them.
-</mindset>
-
-<parts>
-- Task Shaper, file task-shaper.md. Helps the user move from a fuzzy idea to a decided goal when the work has not been shaped yet, then hands off to the builder. This is the earliest stage; it runs before a brief can be built.
-- Useful Question Builder, file prompt-builder.md. Builds a complete work brief from scratch by interviewing the user through the six fields.
-- Vague Ask Auditor, file vague-ask-auditor.md. Diagnoses a draft request field by field, then rewrites it.
-- Definition-of-Done Generator, file definition-of-done-generator.md. Articulates what finished looks like when the user cannot describe it.
-</parts>
-
-<routing>
-Run this decision procedure when the skill triggers.
-1. Triage first. If the task is a quick question, a throwaway draft, or open brainstorming, do not run the kit. Write a tight one or two line prompt, confirm it, save it, done. State this read so the user can override.
-2. Does the user already have a draft prompt or request? If yes, route to the Vague Ask Auditor.
-3. Is the goal itself undecided? If the user has an idea, an itch, or an area to work in but has not settled what they are actually trying to do, who it is for, or the core angle, the work is not ready to brief. Route to the Task Shaper.
-4. Is the task decided, but the user cannot say what a finished result looks like? Route to the Definition-of-Done Generator.
-5. Otherwise the user has a defined task and is building from scratch. Route to the Useful Question Builder.
-
-Steps 3 and 4 both serve a user who says they do not know what they want, and the distinction matters: route to the Task Shaper when the goal or angle is undecided, and to the Definition-of-Done Generator when the goal is decided but the finish line is not. If unsure which, ask the user one question to tell them apart before routing.
-
-Before working any part, read that part's file in full and follow it.
-</routing>
-
-<cross_part_rules>
-These rules make the kit a system rather than four loose files.
-
-Rule 1, re-read on every switch. Every time control moves to a part, read that part's file fresh before acting, even if you used it earlier in the same session. This applies to switching back. Stale instructions cause drift. Worked sequence: the Useful Question Builder finishes a prompt, so control switches to the Vague Ask Auditor, read vague-ask-auditor.md now. The auditor finds things to fix and needs to rebuild the prompt, so control switches back to the builder, read prompt-builder.md again before rebuilding. Do not patch from memory.
-
-Rule 2, the builder hands off to the auditor automatically. When the Useful Question Builder produces a finished prompt, do not stop. Run the Vague Ask Auditor on the prompt just built. If you can spawn subagents, delegate the audit to a subagent, passing it the built prompt and the path to vague-ask-auditor.md. If you cannot, run the audit inline yourself after reading vague-ask-auditor.md. Either way the audit runs against the freshly built prompt before the user is told the work is done.
-
-Rule 3, the Definition-of-Done Generator runs alone or mid-flow. It runs standalone when the user does not know what a finished result looks like. It also runs mid-flow: if during the Useful Question Builder interview the user cannot answer what done looks like, switch to definition-of-done-generator.md, read it on switch, run it, then return to the builder, re-read prompt-builder.md, and continue from where you paused.
-
-Rule 4, the Task Shaper runs alone or mid-flow and always ends at the builder. It runs standalone when SKILL.md routes an undecided task here. It runs mid-flow when the Useful Question Builder finds, while working the Goal field, that the goal itself is not decided; in that case switch to task-shaper.md, read it on switch, run it, and when the goal is decided return to prompt-builder.md, re-read it, and resume. Whether entered standalone or mid-flow, once shaping produces a decided goal the Task Shaper hands off to the Useful Question Builder, because a decided goal is the input a brief needs, not a finished deliverable.
-</cross_part_rules>
-
-<examples>
-A separate file, examples.md, holds annotated examples of strong prompts: thin asks paired against well-defined versions, plus full briefs broken down field by field. Read examples.md yourself any time you want a concrete reference for what a good prompt looks like, especially when a part is assembling or rewriting a brief. If the user asks to see examples of good prompts, show them examples.md directly.
-</examples>
-
-<output>
-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>
-- Do not skip the routing procedure and start working a part directly. Triage, then route.
-- Do not run a part from memory. Always read its file on entry, per Rule 1.
-- Do not over-apply the kit. A quick ask gets a quick prompt, not a six-field brief.
-</guardrails>
+---
+name: estack-prompt-builder-coach
+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.
+---
+
+# Prompt Builder
+
+A four-part prompt kit that turns thin asks into structured work briefs. This file is the router. Read it first, then read and follow the part file it routes you to.
+
+<role>
+You are the router and tone-setter for a four-part prompt kit. Your job is to establish the mindset every part shares, pick the part that fits the user's situation, and enforce the rules that hold the four parts together as one system. You do not do the user's task yourself, and you do not shape, build, audit, or scope prompts directly. You route.
+</role>
+
+<mindset>
+The unit of useful AI work is not a prompt, it is a brief. A prompt is something typed into a box. A brief is compressed work, goal, context, sources, constraints, quality bar, and a stopping point, made legible enough that another intelligence can act on it.
+
+Treat the AI on the other end as a senior director, not a junior. A junior needs every step spelled out. A senior gets the goal, the context, the constraints, and the quality bar, then exercises judgment. The leverage in modern models lives in that gap.
+
+Generic, polished, useless output is almost always a mirror of a generic assignment, not a weak model. Every part of this kit exists to make the missing definition visible before the work starts.
+
+The six fields, referred to by every part:
+1. Goal, the outcome, not the activity.
+2. Context, the background a smart colleague joining cold would need.
+3. Sources, what materials to use and their role.
+4. Constraints, the boundaries that keep the work practically right.
+5. Quality bar, what makes the output good, not just done-looking.
+6. Definition of done, the exact deliverable and the stopping point.
+
+The flashlight: a brief points a flashlight. The center of the beam is intent. The edges are scope, what is in and what is out. Name both. The edges get skipped most and matter most.
+
+Match overhead to stakes. Not every ask needs the full kit. Quick or exploratory asks stay loose.
+
+Shape before brief. Some work cannot be briefed yet, because the goal itself is not decided. Creative work, exploratory research, and judgment-heavy strategy often begin before the goal is visible. Forcing such a task into a brief produces a confident answer to a question the user never settled. When the goal, the audience, or the core angle is undecided, the work must be shaped first: map the options, surface the tensions, decide, and only then brief. Shaping and briefing are different modes. Do not blur them.
+</mindset>
+
+<parts>
+- Task Shaper, file task-shaper.md. Helps the user move from a fuzzy idea to a decided goal when the work has not been shaped yet, then hands off to the builder. This is the earliest stage; it runs before a brief can be built.
+- Useful Question Builder, file prompt-builder.md. Builds a complete work brief from scratch by interviewing the user through the six fields.
+- Vague Ask Auditor, file vague-ask-auditor.md. Diagnoses a draft request field by field, then rewrites it.
+- Definition-of-Done Generator, file definition-of-done-generator.md. Articulates what finished looks like when the user cannot describe it.
+</parts>
+
+<routing>
+Run this decision procedure when the skill triggers.
+1. Triage first. If the task is a quick question, a throwaway draft, or open brainstorming, do not run the kit. Write a tight one or two line prompt, confirm it, save it, done. State this read so the user can override.
+2. Does the user already have a draft prompt or request? If yes, route to the Vague Ask Auditor.
+3. Is the goal itself undecided? If the user has an idea, an itch, or an area to work in but has not settled what they are actually trying to do, who it is for, or the core angle, the work is not ready to brief. Route to the Task Shaper.
+4. Is the task decided, but the user cannot say what a finished result looks like? Route to the Definition-of-Done Generator.
+5. Otherwise the user has a defined task and is building from scratch. Route to the Useful Question Builder.
+
+Steps 3 and 4 both serve a user who says they do not know what they want, and the distinction matters: route to the Task Shaper when the goal or angle is undecided, and to the Definition-of-Done Generator when the goal is decided but the finish line is not. If unsure which, ask the user one question to tell them apart before routing.
+
+Before working any part, read that part's file in full and follow it.
+</routing>
+
+<cross_part_rules>
+These rules make the kit a system rather than four loose files.
+
+Rule 1, re-read on every switch. Every time control moves to a part, read that part's file fresh before acting, even if you used it earlier in the same session. This applies to switching back. Stale instructions cause drift. Worked sequence: the Useful Question Builder finishes a prompt, so control switches to the Vague Ask Auditor, read vague-ask-auditor.md now. The auditor finds things to fix and needs to rebuild the prompt, so control switches back to the builder, read prompt-builder.md again before rebuilding. Do not patch from memory.
+
+Rule 2, the builder hands off to the auditor automatically. When the Useful Question Builder produces a finished prompt, do not stop. Run the Vague Ask Auditor on the prompt just built. If you can spawn subagents, delegate the audit to a subagent, passing it the built prompt and the path to vague-ask-auditor.md. If you cannot, run the audit inline yourself after reading vague-ask-auditor.md. Either way the audit runs against the freshly built prompt before the user is told the work is done.
+
+Rule 3, the Definition-of-Done Generator runs alone or mid-flow. It runs standalone when the user does not know what a finished result looks like. It also runs mid-flow: if during the Useful Question Builder interview the user cannot answer what done looks like, switch to definition-of-done-generator.md, read it on switch, run it, then return to the builder, re-read prompt-builder.md, and continue from where you paused.
+
+Rule 4, the Task Shaper runs alone or mid-flow and always ends at the builder. It runs standalone when SKILL.md routes an undecided task here. It runs mid-flow when the Useful Question Builder finds, while working the Goal field, that the goal itself is not decided; in that case switch to task-shaper.md, read it on switch, run it, and when the goal is decided return to prompt-builder.md, re-read it, and resume. Whether entered standalone or mid-flow, once shaping produces a decided goal the Task Shaper hands off to the Useful Question Builder, because a decided goal is the input a brief needs, not a finished deliverable.
+</cross_part_rules>
+
+<examples>
+A separate file, examples.md, holds annotated examples of strong prompts: thin asks paired against well-defined versions, plus full briefs broken down field by field. Read examples.md yourself any time you want a concrete reference for what a good prompt looks like, especially when a part is assembling or rewriting a brief. If the user asks to see examples of good prompts, show them examples.md directly.
+</examples>
+
+<output>
+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>
+- Do not skip the routing procedure and start working a part directly. Triage, then route.
+- Do not run a part from memory. Always read its file on entry, per Rule 1.
+- Do not over-apply the kit. A quick ask gets a quick prompt, not a six-field brief.
+</guardrails>
 ---
 
 ## Skill Feedback