elliot-stack 1.0.13 → 1.0.15

package/skills/estack-active-learning-tutor/paths/practice-walkthrough.md

@@ -0,0 +1,113 @@
+# Path D — Practice Test Walkthrough
+
+You and the student work through a practice test together, one question at a time. For each question you help build up the underlying concepts via clarification questions, then the student attempts the actual practice question. Concepts are added to `teach_list.md` per-question — the journal builds incrementally as questions surface them. The "do not preload" guidance is about *initialization* (don't seed the journal with concepts no question has surfaced yet); once a question surfaces a concept, teach the full sub-concept cluster of its parent topic per the **Teaching approach** rule in `SKILL.md`.
+
+This is the only path that uses the `=== ACTIVE QUESTION ===` footer.
+
+---
+
+## Path D footer type — `=== ACTIVE QUESTION ===`
+
+Displays the verbatim practice exam question the student is attempting. The question text and options match the source material exactly — no paraphrasing, no transcribed answer key, no reasoning hints in the footer block.
+
+The footer holds everything the student needs to answer: question text, data tables, answer choices, setup context. The body holds framing or teaching; the footer holds the question and only the question.
+
+While the `=== ACTIVE QUESTION ===` footer is in flight, every turn until the student submits an attempt is a **Teaching turn** (see SKILL.md's TURN TYPES section). The student submitting an attempt is what flips the next turn to a **Scoring turn**.
+
+---
+
+## Teaching turns during Path D
+
+<goal>
+When the active question is in flight and the student needs teaching, the teaching turn produces concept-general material that equips the student to bridge to *any* analogous problem on this concept.
+</goal>
+
+<success-criterion>
+Take the teaching turn in isolation. A peer who has never seen the active question could read the body and learn the concept fully. Every sentence is concept-general — applicable to any analogous problem. If a sentence only makes sense given the active question's specific setup (its variables, comparative structure, inferential map, MCQ option logic), that sentence belongs in a Scoring turn instead.
+</success-criterion>
+
+<reasoning>
+The student's job is to bridge concept → specific problem. If the teaching turn does the bridging for them, the student parrots rather than learns. This generalizes the V3 "variable isolation" idea (rename numbers and dates) to cover *logical* structure, not just values: the comparative shape of the question, the way the options carve up the concept space, and the inferential chain to the answer all live in the active question's territory. They belong to scoring.
+</reasoning>
+
+### Concrete shape of a Teaching turn during Path D
+
+1. **Lead with the concept cluster, not a worked example.** The default teaching segment per `SKILL.md` is concept → definition → mechanics → formula → pitfalls. A worked example is added only on escalation per the **Teaching approach** rule.
+
+2. **Use entirely fresh dummy values when illustrating mechanics.** Different names, dates, percentages, dollar/unit values. If the active question is about March collections at 35/45/20, an illustration uses something like August collections at 10/60/30.
+
+3. **Teach the cluster, not the option labels.** When the active question is multiple choice, the teaching turn explains the underlying concept(s) so the student maps the options to the concept themselves. Walking through each option's category is a Scoring-turn move.
+
+4. **Confirm understanding with a fresh dummy probe.** After teaching, run the **Confirming understanding** flow from `SKILL.md`: a `=== CLARIFICATION QUESTION ===` on a fresh dummy scenario, or — if the student spontaneously demonstrates the concept by answering the active question correctly with reasoning — that satisfies the checkpoint.
+
+5. **One footer in flight at a time.** Per the FOOTER PROTOCOL in `SKILL.md`: when a Socratic probe is the right next move, the probe **becomes** that turn's footer (`=== CLARIFICATION QUESTION ===`). The active question is paused for that turn and returns next turn after the probe resolves.
+
+6. **Diagnose by asking, not telling.** When the student is stuck, ask them to walk through their reasoning. Use what they say to identify the missing concept, then teach it.
+
+### Worked example: GOOD vs. comparison teaching turn
+
+For 2–3 fully written GOOD/comparison teaching turns with annotation, see `references/teaching-turn-examples.md`. The risk-preferences MCQ example is the most useful for Path D — read it before the first teaching segment of a Path D session.
+
+A short illustrative contrast for the same active question ("Which of these gambles would a risk-averse person reject?"):
+
+- **Concept-general body (GOOD):** *"Risk preferences classify how a decision-maker trades expected value against variance. A risk-averse person prefers a certain payoff to a gamble of equal expected value — the spread itself is a cost. Mechanically: given two prospects with the same expected value, a risk-averse person picks the one with lower variance. The exam trap to watch for: a higher EV gamble can still be rejected when the variance gap is large enough to outweigh the EV gain."*
+- **Question-shaped body (drift):** *"Look at option A — it has higher expected value but more spread. Option B is a sure thing. A risk-averse person would..."* This sentence only exists because the active question structured itself this way. It's a Scoring-turn move.
+
+---
+
+## Step 1 — Confirm and read
+
+1. Confirm with the student which practice test (or section) they want to walk through.
+2. Read the practice exam file fully. Read the student's notes fully. Read the relevant slides and transcripts fully.
+
+Footer: `=== CONFIRM TO PROCEED ===` "Practice test loaded: {name}. Start with question {N}?"
+
+## Step 2 — Per-question loop
+
+Repeat for every question in the practice test the student wants to cover.
+
+### 2a. Display the active question
+
+Append journal entries for question N's concept(s) per the **TEACH LIST PROTOCOL** in `SKILL.md`:
+
+- One `Q-OPEN` line for question N with its parent topic.
+- One or more `SUB-ADD` lines per the sub-concept granularity guidance (default one; decompose when the parent topic genuinely clusters into multiple distinct testable ideas).
+
+Body: brief framing of the question — no setup hints, no formula previews.
+
+Footer: `=== ACTIVE QUESTION ===` with question N's text, data tables, and options exactly as written in the source.
+
+### 2b. Branch on the student's response
+
+- **Student attempts the question directly** → next turn is a Scoring turn → go to **2d**.
+- **Student asks for help, says they don't get it, or shows clear gaps in their reasoning** → next turn is a Teaching turn → go to **2c**.
+
+### 2c. Teach the concepts (Teaching turns)
+
+1. Diagnose by asking. Use a `=== CLARIFICATION QUESTION ===` that asks the student to walk through their current thinking and where it stops making sense.
+2. Run the gap sub-process from `SKILL.md`. Teach using the **Teaching template** with the concept-general shape described above. The teach queue (tracked via `SUB-ADD` and `MASTERED` lines) handles any prerequisite or adjacent gaps that surface — the active question does not return until the queue is empty.
+3. Confirm understanding per `SKILL.md` (clarification question on a fresh dummy scenario, or skip per the skip condition). Append `CLARIFY-FAIL` if the student missed it; on pass, the next step's `MASTERED` records the result.
+4. Append a `TEACH-TURN` line listing the sub-concepts taught this turn. Append `MASTERED` lines as sub-concepts demonstrate mastery.
+5. When the primary concept(s) of question N are MASTERED and the teach queue is empty, ask if the student is ready to attempt the question.
+   - Footer: `=== CONFIRM TO PROCEED ===` "Ready to take question {N}?"
+   - Yes → next turn switches back to `=== ACTIVE QUESTION ===`. No → continue with whatever else they need (return to 2c.1).
+
+### 2d. Evaluate the active question (Scoring turn)
+
+When the student submits an answer to question N, this turn is a Scoring turn:
+
+1. **Look up the answer key just-in-time.** Read it from its original source location — the chat message where the student first provided it, the practice exam file, or the project file containing it. Do not transcribe it elsewhere; this turn's reference is enough.
+2. State the verdict on the active question (correct / incorrect / partial, and which option) before discussing reasoning. Append an `ATTEMPT` line to the journal with the verdict.
+3. **Correct + reasoning** → append `MASTERED` lines for every concept question N tested. Move to question N+1 (return to 2a).
+4. **Correct + shallow** → ask for the reasoning before counting it.
+5. **Wrong** → run the gap sub-process. Apply the **Helping the student arrive at the answer themselves** rule from `SKILL.md`: hold the answer until the student earns it. Teach (next turn flips back to Teaching), confirm understanding, then re-display question N as `=== ACTIVE QUESTION ===` for a retry. Cycle 2c → 2d until the student reaches the answer themselves.
+
+The retry result and the next question are always different turns — present Question N+1 only on the turn after Question N's retry has been scored.
+
+## Step 3 — Close
+
+Use the **UNIVERSAL CLOSE** in `SKILL.md`. Path D's path-specific completion criterion: every targeted practice question is answered correctly with reasoning explained.
+
+### Early-close branch
+
+If the student announces they're out of time or stops mid-session, run the Universal Close immediately using the journal's current state. Scan the journal bottom-up: anything whose most recent line is `MASTERED` is owned; anything else is a cram item. Highlight unmastered concepts as the cram list for the student's remaining study time.

package/skills/estack-active-learning-tutor/references/teaching-turn-examples.md

@@ -0,0 +1,202 @@
+# Teaching Turn — Worked Examples
+
+Three fully written example Teaching turns. Read these before your first teaching segment so the shape of a good Teaching turn is concrete in context.
+
+Each example shows:
+- The active question (header only — for example purposes; not part of the teaching turn body)
+- The student's prompt that triggered the teaching turn
+- The teaching turn body, written as an actual response
+- A "why this passes the success criterion" annotation
+
+The success criterion (from `SKILL.md` TURN TYPES > Teaching): a peer who never saw the active question could read the body in isolation and learn the concept fully. Every sentence is concept-general — applicable to any analogous problem on this concept.
+
+---
+
+## Example 1 — MCQ logical-trap, cold start ("teach me X")
+
+<active-question> *(for context only — does not appear in the teaching turn body)*
+
+> Which of the following describes the choice a risk-averse decision-maker would make?
+>
+> A) Always choose the prospect with the highest expected value, regardless of variance.
+> B) Always choose the prospect with the lowest variance, regardless of expected value.
+> C) Among prospects with the same expected value, choose the one with the lowest variance.
+> D) Among prospects with the same variance, choose the one with the lowest expected value.
+
+</active-question>
+
+<student-prompt>
+"idk teach me risk"
+</student-prompt>
+
+<teaching-turn-body>
+
+### Risk preferences
+
+In decision theory, **risk preferences** classify how a decision-maker trades expected value against the variability of outcomes. Three preference types describe how a person ranks gambles whose payoffs differ in spread.
+
+- **Expected value (EV)** is the probability-weighted average of the possible payoffs of a prospect. EV measures the *center* of the distribution.
+- **Variance / standard deviation (SD)** measures the *spread* of the payoffs around the EV. In risk theory, variance is the standard quantitative proxy for "how risky" a prospect is.
+- **Risk-averse** decision-makers experience the spread as a cost. Given two prospects with the *same* expected value, a risk-averse person prefers the one with lower variance. Given two prospects with the *same* variance, they prefer the one with higher expected value. The ordering is: lower spread is better, all else equal.
+- **Risk-neutral** decision-makers care only about expected value. They are indifferent to variance and rank prospects purely by EV.
+- **Risk-loving** decision-makers experience the spread as a benefit. Given equal EV, they prefer higher variance.
+
+**Formula sketch.** Expected value of a prospect with payoffs `x_i` and probabilities `p_i`:
+
+```
+EV = Σ p_i · x_i
+```
+
+Variance of the same prospect:
+
+```
+Var = Σ p_i · (x_i − EV)²
+```
+
+Standard deviation is the square root of variance and lives in the same units as the payoffs.
+
+**The trap to watch for.** The defining behavior of risk-aversion is conditional: it is the choice between prospects of **equal expected value**. Many exam questions describe a risk-averse person and offer gambles with *different* expected values, betting that the student will assume "risk-averse means always pick the lower variance." That is a stronger claim than the definition — risk-aversion does not mean ignoring EV. A risk-averse person can still take a higher-variance gamble if the expected value gain is large enough.
+
+**Quick illustrative scenario** *(invented, not the active question's setup):*
+
+A risk-averse investor faces two assets. Asset Q yields $200 for sure. Asset R yields $400 with probability 0.5 and $0 with probability 0.5. EV of Q = $200; EV of R = $200. The variance of Q is 0; the variance of R is positive. A risk-averse investor picks Q.
+
+</teaching-turn-body>
+
+<annotation>
+The body never references the active question's option labels (A, B, C, D), never narrates "the trap" relative to the active question's specific options, and never says "the answer is C." The illustrative scenario uses different names ($200/$400, Asset Q/R) than anything in the active question. A peer who never saw the active question could read this and independently identify which option captures the risk-averse rule.
+</annotation>
+
+---
+
+## Example 2 — Multi-step calculation, wrong attempt
+
+<active-question> *(for context only)*
+
+> A company expects March sales of 1,200 units. Its policy is to hold ending finished-goods inventory equal to 25% of next month's sales. Beginning March inventory was 280 units. April sales are forecast at 1,400 units. How many units must be produced in March?
+
+</active-question>
+
+<student-prompt>
+"I tried 1,200 + 280 = 1,480. That's wrong, isn't it? I'm lost."
+</student-prompt>
+
+<teaching-turn-body>
+
+### Production budget
+
+The **production budget** answers a single question: how many units does a manufacturer have to *produce* in a given period to (a) satisfy the period's sales and (b) leave the desired ending inventory on hand for the next period? Inventory at the start of the period reduces the production requirement; desired inventory at the end of the period adds to it.
+
+- **Budgeted unit sales** are the units forecast to be sold during the period. They are the "demand" the budget must meet.
+- **Desired ending finished-goods inventory** is the policy-driven cushion the firm wants on hand at the close of the period. A common policy is "X% of next period's budgeted sales," because future sales drive future production lead times.
+- **Beginning finished-goods inventory** is the units on hand at the start of the period, carried over from the prior period's ending inventory. Those units are already produced — they reduce what production must contribute this period.
+
+**The formula:**
+
+```
+Production (units) = Budgeted sales (units)
+                   + Desired ending inventory (units)
+                   − Beginning inventory (units)
+```
+
+**Why the formula has that shape.** Sales drain inventory; production refills it. To end with the desired cushion, the firm needs to produce enough to (1) replace what sales took, and (2) build the cushion up to (or down to) the desired ending level. Beginning inventory is a head start — units already on the shelf don't have to be produced.
+
+**The trap to watch for.** Two patterns trip students up:
+
+1. Confusing "ending inventory of *this* period" with "next period's sales." The policy is usually expressed as a percentage of *next period's* sales, but the policy is referring to the inventory at the *end of this period*. The percentage of next period's sales gives you the ending-inventory-this-period number directly.
+2. Adding rather than subtracting beginning inventory. Beginning inventory is already on hand — it's a credit against required production, not an addition to it.
+
+**Quick illustrative scenario** *(invented values):*
+
+A bakery forecasts August sales of 600 cakes. Its policy is to hold ending inventory equal to 30% of September's forecast sales. September sales are forecast at 800 cakes. Beginning August inventory is 150 cakes.
+
+- Desired ending inventory = 30% × 800 = 240 cakes.
+- Production = 600 (sales) + 240 (desired ending) − 150 (beginning) = **690 cakes**.
+
+</teaching-turn-body>
+
+<annotation>
+The body teaches the production-budget formula without using March, April, 1,200, 1,400, 280, or 25%. It explains both the structure of the formula and the two most common mistakes (one of which the student just made — adding beginning inventory instead of subtracting it). The student now has the conceptual material to redo the active question themselves. The illustrative scenario uses August/September/cakes/600/800/150 — entirely different values.
+</annotation>
+
+---
+
+## Example 3 — "I don't get it" cold start, calculation-heavy concept
+
+<active-question> *(for context only)*
+
+> A project costs $50,000 today and is expected to return $18,000 per year for 4 years. The firm's required rate of return is 9%. What is the project's NPV?
+
+</active-question>
+
+<student-prompt>
+"I don't get it. What even is NPV?"
+</student-prompt>
+
+<teaching-turn-body>
+
+### Net present value (NPV)
+
+**Net present value** is the dollar value today of the future cash flows a project generates, *minus* the cost of the project. It answers: "After accounting for the time value of money, does this project make me richer or poorer?"
+
+- **Time value of money** is the principle that a dollar received in the future is worth less than a dollar today, because today's dollar can be invested. The further out a future dollar is, the less it is worth right now.
+- **Discount rate** is the per-period rate used to translate a future dollar into today's dollar. It typically equals the firm's required rate of return — the minimum yield the firm demands of any project given its risk and the firm's cost of capital.
+- **Present value of one future cash flow** is that cash flow divided by `(1 + r)^t`, where `r` is the discount rate per period and `t` is the number of periods until the cash flow is received.
+- **NPV** sums the present value of every future cash flow the project produces and subtracts the project's up-front cost (which is already in today's dollars and so is not discounted).
+
+**The formula:**
+
+```
+NPV = − C₀ + Σ (CF_t / (1 + r)^t),  for t = 1 to N
+```
+
+Where:
+- `C₀` is the initial investment (a positive number subtracted at the front, or written as a negative cash flow at t=0)
+- `CF_t` is the net cash flow received at the end of period `t`
+- `r` is the discount rate per period
+- `N` is the number of periods over which the project runs
+
+**The decision rule.** A project with **NPV > 0** adds value — the discounted future cash flows more than cover the cost. A project with **NPV < 0** destroys value. A project with **NPV = 0** breaks even at the required rate.
+
+**The trap to watch for.** Two recurring errors:
+
+1. Forgetting to subtract the initial investment. The "P" in NPV is the present *value* of inflows; the "N" (net) is what makes it net of the cost. Computing only the discounted cash inflows gives you PV, not NPV.
+2. Discounting the initial investment. The initial cost is paid today (t=0) and is already in today's dollars — it does not get divided by `(1 + r)`.
+
+**Quick illustrative scenario** *(invented values):*
+
+A project costs $1,000 today and pays $600 at the end of year 1 and $700 at the end of year 2. Required rate is 10%.
+
+- PV of year 1 cash flow = 600 / 1.10 = $545.45
+- PV of year 2 cash flow = 700 / (1.10)² = $578.51
+- NPV = −1,000 + 545.45 + 578.51 = **$123.96**.
+
+The project's NPV is positive, so it adds value at the 10% required rate.
+
+</teaching-turn-body>
+
+<annotation>
+The body never uses $50,000, $18,000, 4 years, or 9%. It explains the concept end-to-end (definition, mechanics, formula, decision rule, two common traps) and walks a single 2-period dummy example to make the discounting mechanics concrete. The student now has every piece they need to set up and solve the active question themselves. The illustrative scenario's numbers are deliberately small and clean ($1,000 / $600 / $700 / 10%) to keep arithmetic from competing with the concept.
+</annotation>
+
+---
+
+## Pattern summary
+
+Across all three examples, the Teaching turn body:
+
+1. **Names the concept** as a heading.
+2. **Defines** the concept and its component pieces.
+3. **States the formula** when the concept has one, with variables labeled.
+4. **Explains the structure** — why the formula has its shape, what the decision rule is.
+5. **Calls out the traps** — the recurring exam mistakes for this concept, framed independently of the active question.
+6. **Walks one dummy illustration** (only when the concept benefits from concrete arithmetic; for purely conceptual topics this can be skipped).
+
+What never appears in the body:
+
+- The active question's specific variable values.
+- The active question's option labels.
+- A sentence that maps a concept piece to the active question ("so for option B, this means...").
+- The correct answer or the reasoning chain that distinguishes the correct answer from distractors.
+
+Those moves all belong to the **Scoring turn** that comes after the student attempts.

package/skills/estack-better-title/SKILL.md

@@ -60,3 +60,66 @@ __CLAUDE_TITLE__
 Replace `<chosen title>` with the actual chosen title. The quoted heredoc (`<<'__CLAUDE_TITLE__'`) prevents the shell from interpreting any special characters in the title — quotes, apostrophes, dollar signs, backticks, etc. are all passed through literally. After running, confirm the rename succeeded.
 
 **Important:** The live UI border won't update until the next session resume — the persisted title will show in the session list and on next `/resume`.
+
+---
+
+## Skill Feedback
+
+If the user shares feedback about this skill — a bug, something confusing, a missing feature, or a suggestion — ask them to describe it in a bit more detail (what they expected, what happened, and any relevant context). Then file the issue using whichever method is available:
+
+**If `gh` is installed** (`gh --version` succeeds), create the issue directly:
+
+```bash
+gh issue create \
+  --repo ElliotDrel/e-stack \
+  --title "estack-better-title: <concise summary>" \
+  --body "<description from user feedback — expected vs. actual behavior and context>"
+```
+
+**If `gh` is not installed**, build a pre-filled URL and share it so the user can click, review, and submit:
+
+```bash
+python3 -c "
+import urllib.parse
+title = 'estack-better-title: <concise summary>'
+body = '<description from user feedback — expected vs. actual behavior and context>'
+base = 'https://github.com/ElliotDrel/e-stack/issues/new'
+print(base + '?title=' + urllib.parse.quote(title) + '&body=' + urllib.parse.quote(body))
+"
+```
+
+Share the printed URL with the user. They click it, review the pre-filled title and body, then click **Submit new issue**.
+
+---
+
+## Skill Feedback
+---
+
+## Skill Feedback
+
+If the user shares feedback about this skill — a bug, something confusing, a missing feature, or a suggestion — ask them to describe it in a bit more detail (what they expected, what happened, and any relevant context). Then file the issue using whichever method is available:
+
+**If `gh` is installed** (`gh --version` succeeds), create the issue directly:
+
+```bash
+gh issue create \
+  --repo ElliotDrel/e-stack \
+  --title "estack-better-title: <concise summary>" \
+  --body "<description from user feedback — expected vs. actual behavior and context>"
+```
+
+**If `gh` is not installed**, build a pre-filled URL:
+
+```bash
+python3 -c "
+import urllib.parse
+title = 'estack-better-title: <concise summary>'
+body = '<description from user feedback — expected vs. actual behavior and context>'
+base = 'https://github.com/ElliotDrel/e-stack/issues/new'
+print(base + '?title=' + urllib.parse.quote(title) + '&body=' + urllib.parse.quote(body))
+"
+```
+
+Share the printed URL with the user and offer to open it in their browser.
+
+They can also click it directly, review the pre-filled title and body, and click **Submit new issue**.

package/skills/estack-chris-voss/SKILL.md

@@ -76,3 +76,66 @@ quick index of when to reach for each tool:
 
 Use calm, confident language. If the situation is high-stakes, slow down and be precise. Never
 rush the user into a compromise — no deal is better than a bad deal.
+
+---
+
+## Skill Feedback
+
+If the user shares feedback about this skill — a bug, something confusing, a missing feature, or a suggestion — ask them to describe it in a bit more detail (what they expected, what happened, and any relevant context). Then file the issue using whichever method is available:
+
+**If `gh` is installed** (`gh --version` succeeds), create the issue directly:
+
+```bash
+gh issue create \
+  --repo ElliotDrel/e-stack \
+  --title "estack-chris-voss: <concise summary>" \
+  --body "<description from user feedback — expected vs. actual behavior and context>"
+```
+
+**If `gh` is not installed**, build a pre-filled URL and share it so the user can click, review, and submit:
+
+```bash
+python3 -c "
+import urllib.parse
+title = 'estack-chris-voss: <concise summary>'
+body = '<description from user feedback — expected vs. actual behavior and context>'
+base = 'https://github.com/ElliotDrel/e-stack/issues/new'
+print(base + '?title=' + urllib.parse.quote(title) + '&body=' + urllib.parse.quote(body))
+"
+```
+
+Share the printed URL with the user. They click it, review the pre-filled title and body, then click **Submit new issue**.
+
+---
+
+## Skill Feedback
+---
+
+## Skill Feedback
+
+If the user shares feedback about this skill — a bug, something confusing, a missing feature, or a suggestion — ask them to describe it in a bit more detail (what they expected, what happened, and any relevant context). Then file the issue using whichever method is available:
+
+**If `gh` is installed** (`gh --version` succeeds), create the issue directly:
+
+```bash
+gh issue create \
+  --repo ElliotDrel/e-stack \
+  --title "estack-chris-voss: <concise summary>" \
+  --body "<description from user feedback — expected vs. actual behavior and context>"
+```
+
+**If `gh` is not installed**, build a pre-filled URL:
+
+```bash
+python3 -c "
+import urllib.parse
+title = 'estack-chris-voss: <concise summary>'
+body = '<description from user feedback — expected vs. actual behavior and context>'
+base = 'https://github.com/ElliotDrel/e-stack/issues/new'
+print(base + '?title=' + urllib.parse.quote(title) + '&body=' + urllib.parse.quote(body))
+"
+```
+
+Share the printed URL with the user and offer to open it in their browser.
+
+They can also click it directly, review the pre-filled title and body, and click **Submit new issue**.

package/skills/estack-customer-discovery/SKILL.md

@@ -56,3 +56,66 @@ At the end of each step, offer to produce a written summary the user can referen
 ### Step 5: Continue the flow
 
 After completing a step, offer to continue to the next one by name (e.g., "Would you like to continue to **Step 3: Interview Execution**?"). Never reference a step by number alone — always include the name so the user knows what it covers. If the user jumped into a specific step, still offer the next step — they might want to keep going.
+
+---
+
+## Skill Feedback
+
+If the user shares feedback about this skill — a bug, something confusing, a missing feature, or a suggestion — ask them to describe it in a bit more detail (what they expected, what happened, and any relevant context). Then file the issue using whichever method is available:
+
+**If `gh` is installed** (`gh --version` succeeds), create the issue directly:
+
+```bash
+gh issue create \
+  --repo ElliotDrel/e-stack \
+  --title "estack-customer-discovery: <concise summary>" \
+  --body "<description from user feedback — expected vs. actual behavior and context>"
+```
+
+**If `gh` is not installed**, build a pre-filled URL and share it so the user can click, review, and submit:
+
+```bash
+python3 -c "
+import urllib.parse
+title = 'estack-customer-discovery: <concise summary>'
+body = '<description from user feedback — expected vs. actual behavior and context>'
+base = 'https://github.com/ElliotDrel/e-stack/issues/new'
+print(base + '?title=' + urllib.parse.quote(title) + '&body=' + urllib.parse.quote(body))
+"
+```
+
+Share the printed URL with the user. They click it, review the pre-filled title and body, then click **Submit new issue**.
+
+---
+
+## Skill Feedback
+---
+
+## Skill Feedback
+
+If the user shares feedback about this skill — a bug, something confusing, a missing feature, or a suggestion — ask them to describe it in a bit more detail (what they expected, what happened, and any relevant context). Then file the issue using whichever method is available:
+
+**If `gh` is installed** (`gh --version` succeeds), create the issue directly:
+
+```bash
+gh issue create \
+  --repo ElliotDrel/e-stack \
+  --title "estack-customer-discovery: <concise summary>" \
+  --body "<description from user feedback — expected vs. actual behavior and context>"
+```
+
+**If `gh` is not installed**, build a pre-filled URL:
+
+```bash
+python3 -c "
+import urllib.parse
+title = 'estack-customer-discovery: <concise summary>'
+body = '<description from user feedback — expected vs. actual behavior and context>'
+base = 'https://github.com/ElliotDrel/e-stack/issues/new'
+print(base + '?title=' + urllib.parse.quote(title) + '&body=' + urllib.parse.quote(body))
+"
+```
+
+Share the printed URL with the user and offer to open it in their browser.
+
+They can also click it directly, review the pre-filled title and body, and click **Submit new issue**.