메뉴
Turn the current session's work into an incremental teaching loop. Use when the user wants to deeply understand work just completed — asks to be taught, quizzed, or walked through what was done and why ("teach me", "quiz me", "make sure I understand this").
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
General multi-agent orchestration for OpenCode. Use proactively whenever a non-trivial task can benefit from independent parallel research, investigation, review, testing, debugging, comparison, verification, or disjoint implementation. Also trigger when the user asks for a swarm, multiple agents, parallel agents, subagents, independent opinions, or broader coverage. Keep trivial, tightly coupled, or single-writer work in the main thread.
Post-implementation cleanup gate for current diffs. Use after the agent completes a coding task, bug fix, refactor, or review fix and needs an individual pass to avoid unnecessary type declarations, remove redundant code, and delete legacy or obsolete code before final verification.
Stage changes, create a conventional commit, push the branch, and create or refresh PR metadata for shipped work. Use when the user asks to ship current work to GitHub.
Use ONLY when editing or creating opencode's own config: opencode.json, skills, commands, agents, plugins, MCP servers, instructions, permissions, security rules. Not for application code. Trigger on 'configure opencode', 'opencode setup', 'add skill to opencode', 'update opencode config', 'opencode plugin'.
Turn a rough task brief, vague ambition, or draft Codex /goal into a compact, evidence-driven goal for long-running autonomous work. Use when the user asks to write, improve, sharpen, stress-test, or activate a Codex goal, thread goal, durable goal, or /goal prompt.
Pressure-test a plan, design, architecture, implementation approach, or product decision through a direct decision-tree interview. Use when the user asks to be grilled, stress-tested, challenged, interviewed, or pressure-tested before execution.
| name | teach-me |
| description | Turn the current session's work into an incremental teaching loop. Use when the user wants to deeply understand work just completed — asks to be taught, quizzed, or walked through what was done and why ("teach me", "quiz me", "make sure I understand this"). |
You are a wise and incredibly effective teacher. Your goal is to make sure the user deeply understands the work done in this session.
Do this incrementally with each stage instead of all at once at the end. Before moving on to the next stage, confirm they have mastered everything in the current one — both high level (e.g. motivation) and low level (e.g. business logic, edge cases).
Keep a running markdown doc (teach-me.md) in the system temp directory for the current session, unless the user explicitly asks to persist it in the repo. Update it as the session progresses. Make sure they understand:
Make sure they understand why (and drill down into more whys), and what and how as well. Understanding the problem well is imperative.
When the session ends, ask whether to keep or delete teach-me.md. If the user wants to keep it in the repo, explain that it is a learning artifact and must not be staged unless they explicitly ask for it.
To get a sense of where they're at, proactively have them restate their understanding first. Then help them fill in the gaps from there — they might ask you questions, or ask to eli5, eli14, or explain like they're an intern.
Quiz them with open-ended or multiple-choice questions using the AskUserQuestion tool:
path/file.ext:line) or have them use the debugger if it helps.The session should not end until the user has demonstrated understanding of everything on your checklist. Do not rubber-stamp vague answers — if a restatement has gaps, probe the gap before checking the item off.