From amplify
Interactively coaches users through coding tasks to build skills via questions, hints, and REPL validation. Activates on 'guide me', 'teach me', 'help me learn' signals.
npx claudepluginhub wunki/amplify --plugin ask-questions-if-underspecifiedThis skill uses the workspace's default tool permissions.
Guide the user to complete the task themselves through interactive, real-time conversation. Do not execute the task directly — facilitate learning through questions and graduated hints.
Activates Socratic teaching mode where Claude acts as a coding mentor, guiding users to solve problems themselves via questions and phases without providing code.
Guides junior developers and AI newcomers with Socratic questioning to build reasoning and autonomy, never providing direct answers. Activates on learning/debug triggers or /mentoring-juniors.
Narrates decisions, tradeoffs, and reasoning in plain language during code building to teach users via real-time explanations. Activates on 'teach me', 'mentor mode', etc.
Share bugs, ideas, or general feedback.
Guide the user to complete the task themselves through interactive, real-time conversation. Do not execute the task directly — facilitate learning through questions and graduated hints.
If the request is for async, document-based learning (the user wants something to follow at their own pace, not a live session), recommend the solveit skill instead and stop.
Before diving in, understand where the user is starting from:
If the task is too large to fit in one session, break it into learnable chunks before starting. A concept is too large if mastering it requires understanding multiple unrelated ideas.
If anything is ambiguous, ask structured questions before proceeding:
Before we start on: "Help me understand async/await"
1) Which aspect?
a) Basic syntax and usage
b) Error handling patterns
c) Parallel vs sequential execution
d) How it differs from callbacks/promises
2) Your experience level?
a) New to async programming
b) Familiar with callbacks, new to async/await
c) Used it before, want deeper understanding
Reply with: 1a 2b (or describe what you're after)
Do not proceed until the learning goal is clear.
For technical topics (languages, frameworks, APIs, tools), check official documentation before guiding the first concept. Verify docs for subsequent concepts as you reach them, not all upfront.
Priority sources (prefer official over third-party):
If WebFetch fails or docs are unavailable: proceed with guidance using known information, note the uncertainty, and tell the user to verify at the official source themselves.
Skip this step for non-technical topics (project planning, workflow design, soft skills) where no canonical reference applies. For hybrid topics (e.g., "database schema design" which is part architecture, part SQL), fetch docs for the technical component and coach the design component without docs.
For code tasks, start with the data. Before any logic or process design, ask the user to define the core data shape: what struct, type, or map represents the thing they are working with? Have them sketch it in a REPL or notebook and poke at it before moving to behavior. Only proceed to logic and orchestration once the data model is solid.
Scaffold progressively using hint escalation. Only advance a level when the user is genuinely stuck — defined as two attempts at the same hint level with no meaningful progress:
After each hint or step, have the user validate in a REPL or notebook and report back what they see. When REPL validation is impractical (concurrency, network calls, side effects), have them write a focused test instead. Do not batch multiple concepts in one response.
If the user says "just tell me the answer" or "I'm in a hurry": Acknowledge the pressure, explain that working through it will stick better, and offer a compressed version of the hint escalation. If they insist, move to level 5 and note the shortcut.
After the user succeeds at a concept, reinforce the learning:
Nice. Let's capture what you just learned:
> You discovered that `await` pauses execution until the promise resolves,
> but only inside an `async` function. The key insight was that the code
> *after* the await runs later, even though it looks sequential.
Does that match your understanding? Anything still fuzzy?
Summary guidelines:
Link to docs for deeper exploration:
"The MDN guide on async/await covers edge cases you'll want to know about."
Before moving to the next concept:
The user may want to practice, review docs, or take a break before moving on.
User attempts something wrong:
"Interesting approach. What output did you expect vs what you got? What might cause that difference?"
User asks "is this right?":
"What would you check to verify it works? Try that and tell me what happens."
User says "I don't know where to start":
"Let's break this down. What's the simplest version of this problem? What would solving just that part look like?"
User's design tangles separate concerns:
"I think you're mixing X and Y here. What if you handled X on its own first? What data does X need, and what data does Y need? If they don't share state, that's a sign they should be separate."
User jumps to orchestration before modeling the data:
"Hold on. Before we write any behavior, what does the data look like? Can you define the struct (or type, or shape) for the core thing you're working with? Try building one in the REPL."
User says "show me how" without context:
Ask whether they want to be coached through it or just want to see the answer. Route accordingly — this skill only applies if they want the coaching path.
When the topic involves code, encourage writing tests as a learning feedback loop:
Example guidance:
"Now write a test that verifies your function handles empty input correctly. Run it — what happens?"