teach-guidance
정보
이 Claude 스킬은 개발자에게 기술 개념을 효과적으로 가르치고 설명하는 방법을 코칭합니다. 콘텐츠 구조화, 다양한 청중에 맞춘 설명 수준 조정, 그리고 프레젠테이션, 문서화, 멘토링에서의 명확성 향상에 대한 지침을 제공합니다. 발표 준비, 튜토리얼 작성, 동료 멘토링 시 설명 기술을 향상시키기 위해 사용하세요.
빠른 설치
Claude Code
추천npx skills add pjt222/agent-almanac -a claude-code/plugin add https://github.com/pjt222/agent-almanacgit clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/teach-guidanceClaude Code에서 이 명령을 복사하여 붙여넣어 스킬을 설치하세요
문서
Teach (Guidance)
Guide a person in becoming a more effective teacher, explainer, or presenter. The AI acts as a teaching coach — helping assess what needs to be communicated and to whom, structuring content for clarity, rehearsing explanations, refining based on feedback, supporting delivery, and reflecting on what worked.
When to Use
- A person needs to present technical content to an audience and wants to prepare effectively
- Someone wants to write better documentation, tutorials, or explanations
- A person struggles to explain concepts to people with different expertise levels
- Someone is mentoring a colleague or junior developer and wants to be more effective
- A person is preparing for a talk, workshop, or knowledge-sharing session
- After
learn-guidancehas helped them acquire knowledge, they now need to transfer it to others
Inputs
- Required: What the person needs to teach or explain (topic, concept, system, process)
- Required: Who the audience is (expertise level, context, relationship to the person)
- Optional: Format of delivery (presentation, documentation, one-on-one mentoring, workshop)
- Optional: Time constraints (5-minute explanation, 30-minute talk, written document)
- Optional: Previous teaching attempts and what did not work
- Optional: The person's own comfort level with the topic (deep expert vs. recent learner)
Procedure
Step 1: Assess — Understand the Teaching Challenge
Before structuring content, understand the full context of the teaching situation.
- Ask what they need to teach and why: "What concept needs to land, and what happens if it does not?"
- Identify the audience: "Who will you be explaining this to? What do they already know?"
- Assess the person's own understanding: do they know the topic deeply enough to teach it? (If not, suggest
learn-guidancefirst) - Identify the format: presentation, document, conversation, code review, pair programming
- Determine success criteria: "How will you know the audience understood?"
- Surface fears or concerns: "What part of this makes you most nervous?"
Teaching Challenge Matrix:
┌──────────────────┬──────────────────────────┬──────────────────────────┐
│ Challenge Type │ Indicators │ Focus Area │
├──────────────────┼──────────────────────────┼──────────────────────────┤
│ Knowledge gap │ "I sort of know it │ Deepen their own under- │
│ │ but can't explain it" │ standing first (learn) │
├──────────────────┼──────────────────────────┼──────────────────────────┤
│ Audience gap │ "I don't know what │ Build audience empathy │
│ │ they already know" │ and calibration │
├──────────────────┼──────────────────────────┼──────────────────────────┤
│ Structure gap │ "I know it all but │ Organize content into │
│ │ don't know where to │ a narrative arc │
│ │ start" │ │
├──────────────────┼──────────────────────────┼──────────────────────────┤
│ Confidence gap │ "What if they ask │ Practice and preparation │
│ │ something I can't │ for edge cases │
│ │ answer?" │ │
└──────────────────┴──────────────────────────┴──────────────────────────┘
Got: A clear picture of the teaching challenge: what, to whom, in what format, with what constraints, and where the person feels least confident.
If fail: If the person cannot articulate their audience, help them create a persona: "Imagine one specific person who will hear this. What do they know? What do they care about?" If they cannot articulate the topic, they may need to learn it more deeply first.
Step 2: Structure — Organize Content for Clarity
Help the person build a clear narrative structure for their explanation.
- Identify the single core message: "If the audience remembers only one thing, what should it be?"
- Build outward from the core: what context is needed before the core message, and what details follow after?
- Apply the inverted pyramid: most important information first, supporting details after
- For technical content, choose a structural pattern:
- Concept explanation: What → Why → How → Example → Edge cases
- Tutorial: Goal → Prerequisites → Steps → Verification → Next steps
- Architecture overview: Problem → Constraints → Solution → Trade-offs → Alternatives considered
- Debugging walkthrough: Symptom → Investigation → Root cause → Fix → Prevention
- Ensure each section has a clear purpose: if a section does not serve the core message, cut it
- Plan transitions: "We covered X. Now, building on that, we need to understand Y because..."
Got: A structured outline where every element serves the core message. The structure should feel logical and inevitable — each section naturally leads to the next.
If fail: If the structure keeps growing, the scope is too broad — help them cut. If the structure feels flat (everything at the same level), the hierarchy needs work — identify which points are primary and which are supporting. If they resist structure ("I'll just explain it naturally"), note that natural explanations work for simple topics but fail for complex ones — structure is the scaffold.
Step 3: Practice — Rehearse the Explanation
Have the person practice explaining the concept, with the AI acting as the audience.
- Ask them to explain the concept as they would to their actual audience
- Listen without interrupting for the first pass — let them find their natural flow
- Note where the explanation is clear and where it becomes confused or vague
- Note where they use jargon the audience might not know
- Note where they skip steps or assume knowledge the audience may not have
- Note where they spend too long on easy parts and rush through hard parts
- Time the explanation if there is a time constraint
Got: A first-draft explanation that reveals the person's natural teaching patterns — strengths to build on and habits to adjust. The practice should feel low-stakes: "This is a rough draft, not a performance."
If fail: If the person freezes or says "I don't know where to start," return to the structure from Step 2 and have them explain one section at a time rather than the whole thing. If they are overly self-critical ("that was terrible"), redirect to specifics: "Actually, the way you explained X was very clear — let's focus on making Y match that quality."
Step 4: Refine — Improve Based on Feedback
Provide specific, actionable feedback on the practice explanation.
- Lead with strengths: "The part where you explained X using the analogy of Y was very effective because..."
- Identify the biggest improvement opportunity (not all the issues — focus on one or two)
- Suggest specific alternatives: "Instead of saying [complex version], try: [simpler version]"
- Check for the curse of knowledge: are there places where their expertise makes them skip steps the audience needs?
- Check for audience calibration: is the depth right for the audience, or is it too shallow/deep?
- If they use analogies, check if the analogies are accurate (misleading analogies are worse than no analogy)
- Have them re-explain the refined section to test the improvement
Got: Targeted feedback that improves the explanation measurably. The person can feel the difference between the first and second attempt. Feedback is framed constructively — what to do, not just what to avoid.
If fail: If the person is defensive about feedback, reframe from "this was unclear" to "the audience might not follow here — how could we make it even clearer?" If the refined version is not better, the issue may be structural (Step 2) rather than presentational — return to the outline.
Step 5: Deliver — Support During Teaching
If the teaching happens in real time, provide support during delivery.
- For live presentations: help prepare answers to likely questions in advance
- For documentation: review the written version for clarity, structure, and audience calibration
- Help them prepare for the "I don't know" moment: "If asked something you cannot answer, say: 'Great question — I'll look into that and follow up.' This is always acceptable."
- Encourage interaction: help them prepare check questions for the audience
- Prepare recovery plans: what to do if the audience is lost, bored, or ahead of the explanation
- If coaching during delivery: provide brief, specific prompts ("slow down here," "they look confused — check in")
Got: The person feels prepared and supported. They have answers for likely questions, strategies for unexpected situations, and confidence that not knowing everything is acceptable.
If fail: If anxiety is the primary blocker, address it directly: preparation reduces anxiety, and acknowledging nervousness to the audience often creates connection. If the delivery format keeps changing, help them accept the format and adapt rather than trying to control conditions.
Step 6: Reflect — Analyze What Worked
After the teaching event, guide reflection for continuous improvement.
- Ask: "What went well? What are you proud of?"
- Ask: "Where did you notice the audience was most engaged? Least engaged?"
- Ask: "Did anything surprise you about the audience's response?"
- Ask: "If you could change one thing, what would it be?"
- Connect the reflection to principles: "The part that worked used [technique]. You can apply that more broadly."
- Identify one specific improvement goal for next time
- Celebrate the accomplishment: teaching is a skill that improves with practice
Got: The person gains concrete insight about their teaching effectiveness — not vague feelings but specific observations about what worked and why. They leave with one actionable improvement for next time.
If fail: If they only see negatives, redirect to specific moments that worked. If they see only positives, gently probe for areas where the audience was confused. If no reflection happens (they move on immediately), note that reflection is where the most durable improvement happens — even 5 minutes of review matters.
Validation
- The teaching challenge was assessed before structuring began (audience, format, constraints)
- A core message was identified and the structure organized around it
- The person practiced the explanation at least once before delivery
- Feedback was specific, actionable, and led to measurable improvement
- The person was prepared for questions, uncertainty, and audience adaptation
- Post-delivery reflection identified at least one specific improvement for next time
- The coaching was encouraging throughout — teaching is hard and should be acknowledged
Pitfalls
- Coaching the content, not the teaching: Helping them learn the material instead of helping them present it. If they need to learn, use
learn-guidancefirst - Over-structuring: Making the structure so rigid that the person's natural teaching voice is lost. Structure should support their style, not replace it
- Perfectionism trap: Rehearsing endlessly instead of delivering. At some point, the practice has diminishing returns — push toward delivery
- Ignoring audience diversity: A mixed audience needs layered explanation — core idea for everyone, details for experts, analogies for newcomers
- Feedback overload: Giving too many notes at once overwhelms. Focus on the one or two changes with the highest impact
- Neglecting emotional preparation: Teaching anxiety is real. Addressing confidence is as important as addressing content
Related Skills
teach— the AI self-directed variant for calibrated knowledge transferlearn-guidance— coaching a person through learning; the prerequisite to teaching effectivelylisten-guidance— active listening skills help teachers respond to audience needs in real timemeditate-guidance— calming anxiety and achieving focus before a teaching event
GitHub 저장소
연관 스킬
executing-plans
디자인executing-plans 스킬은 검토 체크포인트가 포함된 통제된 배치로 실행할 완전한 구현 계획이 있을 때 사용합니다. 이 스킬은 계획을 불러와 비판적으로 검토한 후, 소규모 배치(기본값 3개 작업)로 작업을 실행하면서 각 배치 사이에 진행 상황을 아키텍트 검토를 위해 보고합니다. 이를 통해 내재된 품질 관리 체크포인트를 갖춘 체계적인 구현이 보장됩니다.
requesting-code-review
디자인이 스킬은 코드 변경 사항을 요구 사항에 따라 분석하기 위해 코드 리뷰어 하위 에이전트를 호출합니다. 작업 완료 후, 주요 기능 구현 후, 또는 메인 브랜치에 병합하기 전에 사용해야 합니다. 이 리뷰는 현재 구현체와 원래 계획을 비교하여 문제를 조기에 발견하는 데 도움이 됩니다.
connect-mcp-server
디자인이 스킬은 개발자들이 HTTP, stdio 또는 SSE 전송 방식을 통해 MCP 서버를 Claude Code에 연결하는 포괄적인 가이드를 제공합니다. GitHub, Notion 및 사용자 정의 API와 같은 외부 서비스를 통합하기 위한 설치, 구성, 인증 및 보안을 다룹니다. MCP 통합 설정, 외부 도구 구성 또는 Claude의 모델 컨텍스트 프로토콜 작업 시 활용하세요.
web-cli-teleport
디자인이 스킬은 작업 분석을 기반으로 개발자가 Claude Code 웹 인터페이스와 CLI 인터페이스 중 선택할 수 있도록 돕고, 두 환경 간 원활한 세션 텔레포트를 가능하게 합니다. 웹, CLI 또는 모바일 환경 전환 시 세션 상태와 컨텍스트를 관리하여 워크플로를 최적화합니다. 다양한 단계에서 서로 다른 도구가 필요한 복잡한 프로젝트에 사용하세요.
