feat(pstack): add /in-your-own-words to play back the goal before work

pstack/README.md

@@ -111,6 +111,7 @@ to keep [`/poteto-mode`](./skills/poteto-mode/SKILL.md) on across turns, pick it
 |---|---|
 | [`/poteto-mode`](./skills/poteto-mode/SKILL.md) | default entry point for any non-trivial task. |
 | [`/poteto-help`](./skills/poteto-help/SKILL.md) | you're new to pstack, or unsure which skill, playbook, or principle fits. finds out what you're trying to do, answers that part, and hands you a prompt to type. runs only when you type `/poteto-help`. |
+| [`/in-your-own-words`](./skills/in-your-own-words/SKILL.md) | you're about to hand off a long or messy ask and want the agent to play back your goal and the problem underneath it first, so you can catch a misreading before any work starts. runs only when you type `/in-your-own-words`. |
 | [`/how`](./skills/how/SKILL.md) | you want a walkthrough of how a subsystem works. |
 | [`/why`](./skills/why/SKILL.md) | you want to know why something was built this way. discovers available MCPs at run time and queries each evidence category in parallel (source control, issue tracker, long-form docs, real-time chat, infra observability, error tracking, analytics warehouse). |
 | [`/recall`](./skills/recall/SKILL.md) | you're starting or resuming work and want your recent context on a topic rebuilt from your own chat history and the shared record, handed back as a tight current-state brief. |

pstack/skills/in-your-own-words/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: in-your-own-words
+description: "Before any work, play back in your own plain words what the user wants and the problem underneath it, with the guesses you made, then stop so they can correct a misreading. Use for /in-your-own-words."
+disable-model-invocation: true
+---
+
+# In your own words
+
+Before you act, tell the user in your own plain words what you think they want and why, then stop. A misread goal can waste a whole run. A short play-back costs one reply, and the user can catch the misreading before any work starts.
+
+## Work it out
+
+Read the message and what it points at, such as a file, a log, a thread, or the conversation so far. With nothing after the command, use the task the conversation is about. Read only enough to understand the request. Don't investigate the cause, design a fix, or start the work.
+
+- Separate what the user asked for from the goal it serves. The request can be one route to the goal, and not the best one.
+- Find the problem underneath: what is wrong or missing, for whom, and what is different once it is solved.
+- Treat the user's theory of the cause as one hypothesis. If what they shared doesn't support it, or points somewhere else, say so and name the evidence.
+- Name details that look like noise, so the user can say whether they matter.
+- Fill each gap with your best guess, and mark it as a guess.
+
+## Write the play-back
+
+Use these parts, and leave out a part that has nothing in it:
+
+- **Goal**: what the user wants to end up with, and why. When one part has a deadline or a required result, put that part first.
+- **Problem**: what stands in the way, in one or two sentences.
+- **Assumptions**: the guesses you made.
+- **Not sure**: what you could not pin down.
+
+Use your own words. Don't copy the user's sentences back or go through their message line by line. Keep their exact words only for names, such as files, errors, fields, keys, and products, and for the values your reading rests on, such as amounts, IDs, limits, and dates. Keep it under 120 words. Don't propose a plan, a fix, or next steps, though **Problem** may name a fix or option that already exists in what they shared.
+
+Stay on what the user wants and why. Doubts about how to do the work belong to the work, not to the play-back. When the request is clear, say so in a line or two and don't fill the other parts.
+
+Ask at most one question. Ask it only about the goal or the problem, and only when the answer changes the work. Word it so that every answer is easy to give, and say in a few words what each answer would change. Don't say what you would do for each answer. Don't also list it under **Not sure**. Never ask the user to restate their request. When the play-back already shows the user's theory is wrong, state the evidence and don't ask whether to make their change anyway. Then end your turn.
+
+## After the user replies
+
+Apply the correction and start the work. If they only confirm, do the work as you described it. Don't play it back again unless they ask.

pstack/skills/poteto-help/SKILL.md

@@ -63,6 +63,7 @@ The default answer is `/poteto-mode`, which runs most of the others when its ste
 | The user wants to | Skill |
 |---|---|
 | Do any non-trivial task with rigor | [`/poteto-mode`](../poteto-mode/SKILL.md) |
+| Check that the agent understood their goal and the problem before it starts | [`/in-your-own-words`](../in-your-own-words/SKILL.md) |
 | Know how code works now, or where new code should live | [`/how`](../how/SKILL.md) |
 | Know why code is shaped this way, or where a number came from | [`/why`](../why/SKILL.md) |
 | Understand a change or subsystem, explained plainly | [`/teach`](../teach/SKILL.md) |

pstack/skills/poteto-help/references/recipes.md

@@ -5,6 +5,7 @@ Swap in the real paths, skills, and done checks. Informal wording works.
 ## Understand
 
 - `/poteto-mode read <thread>. restate the underlying issue in your own words, in plain english.`
+- `/in-your-own-words <long or messy ask>`
 - `/poteto-mode investigate why <symptom>. give me what we know, what data you used, and your best hypotheses. don't change any code yet.`
 - `use /how to understand <subsystem>. then use /why to find out why it broke recently.`
 - `/recall my work on <topic> from last week, then read <issue>.`