[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6BVHMWSZMNVE2HDN10GFDQ8":3,"skill-same:01M6BVHMWSZMNVE2HDN10GFDQ8":80},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":16,"sourceHtmlUrl":17,"categories":18,"keywords":24,"publishedAt":32,"linkOnly":33,"markdownContent":34,"markdownBody":35,"frontMatter":36,"refName":37,"commitSha":38,"skillDirectory":39,"forksCount":40,"repositoryHtmlUrl":41,"repositoryHomepageUrl":6,"ownerHtmlUrl":42,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":43,"install":44,"resources":57},"01M6BVHMWSZMNVE2HDN10GFDQ8","teach",null,"Explain code, changes, and subsystems by investigating how they work and why they were designed that way, then teach at the user's pace. Use for explicit teach requests, teach me this, help me understand this implementation, この実装を教えて, 仕組みと設計背景を知りたい, and understanding before review or modification. Do not trigger for every factual question or primarily implementation requests.","toku345\u002Fdotfiles","toku345","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F3142849?v=4","01M6BVHFC948X4EGTFPQF53G6Q","Fumitaka Tokumitsu","01M6BVHFGV7PA8A2QHR2H8YWMX",1,"MIT","https:\u002F\u002Fgithub.com\u002Ftoku345\u002Fdotfiles\u002Fblob\u002Fmain\u002Fdot_agents\u002Fskills\u002Fteach\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Ftoku345\u002Fdotfiles\u002Fblob\u002Fmain\u002Fdot_agents\u002Fskills\u002Fteach\u002FSKILL.md",[19],{"categoryNo":20,"categoryName":21,"taxonomyType":22,"taxonomyTypeDesc":23},"01JBSEEDCAT000000000000039","教师与教育","PROFESSION","适用职业",[5,25,26,27,28,29,30,31],"review","code","help","explain code","how","why","teach me","2026-11-10 10:12:30",false,"---\nname: teach\ndescription: Explain code, changes, and subsystems by investigating how they work and why they were designed that way, then teach at the user's pace. Use for explicit teach requests, teach me this, help me understand this implementation, この実装を教えて, 仕組みと設計背景を知りたい, and understanding before review or modification. Do not trigger for every factual question or primarily implementation requests.\n---\n\n\u003C!--\nAdapted from pstack teach\u002Fhow\u002Fwhy by Lauren Tan (@poteto).\nCopyright (c) 2026 Lauren Tan. MIT License; see LICENSE.\nSources, pinned upstream revision, and adaptation notes: references\u002Fsource.md.\n-->\n\n# Teach\n\nExplain what the thing is, how it works, and why it has this shape. Help the person understand; do not modify their code while teaching.\n\nThis is a self-contained adaptation of pstack's teach\u002Fhow\u002Fwhy workflow, not an official pstack installation. Read [source and attribution](references\u002Fsource.md) for provenance. The investigation tracks are bundled references; no separately installed how, why, or unslop skill is required.\n\n## Investigate\n\n1. Infer the target, existing knowledge, and purpose from the conversation: onboarding, debugging, review, or preparation for a change. Skip concepts the person knows. State a reasonable interpretation and proceed when ambiguity is minor; ask only when the missing target blocks useful work. Use the user's language, Japanese for Japanese requests.\n2. Orient yourself in the code, diff, or supplied material. Execute the [how track](references\u002Fhow.md) for behavior and the [why track](references\u002Fwhy.md) for rationale. Use both for a subsystem. A narrow behavior-only question may need only how. Scope why to history plus one or two promising sources initially, widening when rationale is central or sources conflict.\n3. Use the tools actually available. Run independent searches concurrently when practical. If permitted and useful, delegate bounded read-only investigations, then verify and synthesize their evidence. Otherwise perform the tracks directly. Require no specific platform or model. Never imply access to unavailable repositories, documents, or telemetry.\n4. Combine the results into one account. Preserve observed facts, documented intent, supported inference, competing explanations, and unknowns. Do not remove uncertainty to make the prose smoother. Check material claims against original evidence.\n\n## Teach\n\n- Start with a plain definition and connect it to the concrete case. Give the smallest complete answer in one or two sentences, then let the person respond. For a one-shot task or an explicit request for detail, provide the requested depth without artificial pauses.\n- Explain the problem being solved and walk through one concrete operation. Follow runtime events when helpful. Avoid a tour of function names and constants.\n- Deepen through the user's follow-up questions. Keep it conversational. Do not quiz, ask the user to repeat the answer, or announce theatrical pauses. Do not assume an explanation proves understanding.\n- Use concise diagrams, diffs, or examples when they clarify the mechanism. Introduce complex flows a small part at a time across the conversation. Do not force diagrams for simple points or repeat nearly identical diagrams in a short response.\n- Use edge cases or counterexamples when they test the explanation. Separate historical motivation from your assessment of whether the current design is appropriate. Do not assume every detail was intentional or optimal.\n- Cite original code, PRs, or documents near material claims. Mention unavailable sources when they materially limit the conclusion. Keep research notes internal unless requested.\n- Write natural, direct prose. Avoid stock framing labels, excessive headings, and walls of text. Return the explanation itself, not an activity report. Follow the person's lead about deepening or moving on.\n\n## Working with co-dev\n\n- Use teach alone for explanation without code changes, quizzes, or implementation approval requests. Invoking teach does not activate co-dev; do not require co-dev to answer a question.\n- When co-dev is explicitly active, use teach for investigation and explanation; co-dev owns the development checkpoints. Its single pre-implementation mini-quiz is the only exception to teach's no-quiz rule. Keep it at the transition into implementation, not inside the explanation or after every follow-up.\n- Treat questions as requests for explanation, quiz answers as evidence to discuss, and approval as a separate decision. Neither a correct answer nor an explanation authorizes implementation. Follow co-dev's start\u002Fresume and handoff agreement rules; returning to teach within an agreed scope does not reset those checkpoints.\n","\u003C!--\nAdapted from pstack teach\u002Fhow\u002Fwhy by Lauren Tan (@poteto).\nCopyright (c) 2026 Lauren Tan. MIT License; see LICENSE.\nSources, pinned upstream revision, and adaptation notes: references\u002Fsource.md.\n-->\n\n# Teach\n\nExplain what the thing is, how it works, and why it has this shape. Help the person understand; do not modify their code while teaching.\n\nThis is a self-contained adaptation of pstack's teach\u002Fhow\u002Fwhy workflow, not an official pstack installation. Read [source and attribution](references\u002Fsource.md) for provenance. The investigation tracks are bundled references; no separately installed how, why, or unslop skill is required.\n\n## Investigate\n\n1. Infer the target, existing knowledge, and purpose from the conversation: onboarding, debugging, review, or preparation for a change. Skip concepts the person knows. State a reasonable interpretation and proceed when ambiguity is minor; ask only when the missing target blocks useful work. Use the user's language, Japanese for Japanese requests.\n2. Orient yourself in the code, diff, or supplied material. Execute the [how track](references\u002Fhow.md) for behavior and the [why track](references\u002Fwhy.md) for rationale. Use both for a subsystem. A narrow behavior-only question may need only how. Scope why to history plus one or two promising sources initially, widening when rationale is central or sources conflict.\n3. Use the tools actually available. Run independent searches concurrently when practical. If permitted and useful, delegate bounded read-only investigations, then verify and synthesize their evidence. Otherwise perform the tracks directly. Require no specific platform or model. Never imply access to unavailable repositories, documents, or telemetry.\n4. Combine the results into one account. Preserve observed facts, documented intent, supported inference, competing explanations, and unknowns. Do not remove uncertainty to make the prose smoother. Check material claims against original evidence.\n\n## Teach\n\n- Start with a plain definition and connect it to the concrete case. Give the smallest complete answer in one or two sentences, then let the person respond. For a one-shot task or an explicit request for detail, provide the requested depth without artificial pauses.\n- Explain the problem being solved and walk through one concrete operation. Follow runtime events when helpful. Avoid a tour of function names and constants.\n- Deepen through the user's follow-up questions. Keep it conversational. Do not quiz, ask the user to repeat the answer, or announce theatrical pauses. Do not assume an explanation proves understanding.\n- Use concise diagrams, diffs, or examples when they clarify the mechanism. Introduce complex flows a small part at a time across the conversation. Do not force diagrams for simple points or repeat nearly identical diagrams in a short response.\n- Use edge cases or counterexamples when they test the explanation. Separate historical motivation from your assessment of whether the current design is appropriate. Do not assume every detail was intentional or optimal.\n- Cite original code, PRs, or documents near material claims. Mention unavailable sources when they materially limit the conclusion. Keep research notes internal unless requested.\n- Write natural, direct prose. Avoid stock framing labels, excessive headings, and walls of text. Return the explanation itself, not an activity report. Follow the person's lead about deepening or moving on.\n\n## Working with co-dev\n\n- Use teach alone for explanation without code changes, quizzes, or implementation approval requests. Invoking teach does not activate co-dev; do not require co-dev to answer a question.\n- When co-dev is explicitly active, use teach for investigation and explanation; co-dev owns the development checkpoints. Its single pre-implementation mini-quiz is the only exception to teach's no-quiz rule. Keep it at the transition into implementation, not inside the explanation or after every follow-up.\n- Treat questions as requests for explanation, quiz answers as evidence to discuss, and approval as a separate decision. Neither a correct answer nor an explanation authorizes implementation. Follow co-dev's start\u002Fresume and handoff agreement rules; returning to teach within an agreed scope does not reset those checkpoints.\n",{"name":5,"description":7},"main","dad20ea2a4096fe9379fdbee5efcec3ef838ab9e","dot_agents\u002Fskills\u002Fteach",0,"https:\u002F\u002Fgithub.com\u002Ftoku345\u002Fdotfiles","https:\u002F\u002Fgithub.com\u002Ftoku345","2026-11-13 17:02:22",{"source":8,"skillName":5,"commands":45,"prompt":55,"zipAvailable":56},[46,49,52],{"tool":47,"command":48},"npx","npx skills add toku345\u002Fdotfiles --skill teach",{"tool":50,"command":51},"bunx","bunx skills add toku345\u002Fdotfiles --skill teach",{"tool":53,"command":54},"pnpm","pnpm dlx skills add toku345\u002Fdotfiles --skill teach","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Ftoku345\u002Fdotfiles\u002Fblob\u002Fmain\u002Fdot_agents\u002Fskills\u002Fteach\u002FSKILL.md",true,[58,64,68,72,76],{"path":59,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":62,"sourceHtmlUrl":63},"agents\u002Fopenai.yaml","REFERENCE","参考文档",298,"https:\u002F\u002Fgithub.com\u002Ftoku345\u002Fdotfiles\u002Fblob\u002Fmain\u002Fdot_agents\u002Fskills\u002Fteach\u002Fagents\u002Fopenai.yaml",{"path":65,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":67,"sourceHtmlUrl":16},"LICENSE","许可证",1067,{"path":69,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":70,"sourceHtmlUrl":71},"references\u002Fhow.md",1202,"https:\u002F\u002Fgithub.com\u002Ftoku345\u002Fdotfiles\u002Fblob\u002Fmain\u002Fdot_agents\u002Fskills\u002Fteach\u002Freferences\u002Fhow.md",{"path":73,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":74,"sourceHtmlUrl":75},"references\u002Fsource.md",3098,"https:\u002F\u002Fgithub.com\u002Ftoku345\u002Fdotfiles\u002Fblob\u002Fmain\u002Fdot_agents\u002Fskills\u002Fteach\u002Freferences\u002Fsource.md",{"path":77,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":78,"sourceHtmlUrl":79},"references\u002Fwhy.md",2406,"https:\u002F\u002Fgithub.com\u002Ftoku345\u002Fdotfiles\u002Fblob\u002Fmain\u002Fdot_agents\u002Fskills\u002Fteach\u002Freferences\u002Fwhy.md",[81,107,134,154,179,191],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":32},"01M6BVJ23D24K530S7WK257HHK","pr-review","Comprehensive pre-PR review orchestrator. Runs named specialist subagents on the current branch's committed diff, conditionally checks simplification, verifies each normalized Critical\u002FImportant candidate with a dedicated finding-verifier, then synthesizes Critical \u002F Important \u002F Suggestions \u002F Strengths using the bundled `references\u002Freview-criteria.md` gate policy. Use before creating a pull request as a heavy quality gate. Intended successor to the legacy bash `triple-review` orchestrator.","https:\u002F\u002Fgithub.com\u002Ftoku345\u002Fdotfiles\u002Fblob\u002Fmain\u002Fprivate_dot_codex\u002Fskills\u002Fpr-review\u002FSKILL.md",[],[25,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106],"pr review","pr","as","simplification","references","critical","verifier","with","candidate","pull","Bash","pull request","quality gate","branch","orchestrator","policy","use","diff","Legacy",{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":113,"publishedAt":32},"01M6BVHZNFQBVQPV3NA8DA373N","pr-review-coach","Japanese-only PR understanding coach. Use when the user wants to prepare their own review, understand a branch diff, identify questions to ask, or build review judgment before running a merge gate. Requires an explicit --base \u003Cref-or-commit> for the first turn, then resumes from local state on answer turns. Asks at most one question at a time and stores resumable local state outside the target worktree. Single-agent only; does not spawn specialist reviewers, does not produce Critical\u002FImportant\u002FSuggestions gate findings, and does not decide merge readiness.","https:\u002F\u002Fgithub.com\u002Ftoku345\u002Fdotfiles\u002Fblob\u002Fmain\u002Fprivate_dot_codex\u002Fskills\u002Fpr-review-coach\u002FSKILL.md",[],[88,89,25,114,115,105,104,116,117,101,118,119,120,121,122,123,124,125,126,127,128,93,129,130,131,132,133],"pr review coach","coach","question","decide","merge gate","first","worktree","produce","state","prepare","single","running","only","for","answer","local","time","japanese","commit","merge",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":148,"publishedAt":32},"01M6BVHXZYDT858V8GQEJHKMPC","writing-proofreader","日本語ブログ・技術記事の校正スキル。Fumitakaの文体ガイドラインに基づいて表現・構成・トーンをチェックし、改善提案を行う。「校正して」「レビューして」「文章チェックして」「書いた記事を見て」「ブログ見てもらえる？」「おかしいところない？」「公開前に確認して」「この記事どう思う？」など、記事やブログの品質チェックに関するリクエスト全般で使う。Markdownやテキストの文章校正を依頼されたら必ずこのスキルを参照する。記事の「推敲」「添削」「赤入れ」といった表現でも発動すること。","https:\u002F\u002Fgithub.com\u002Ftoku345\u002Fdotfiles\u002Fblob\u002Fmain\u002Fprivate_dot_claude\u002Fskills\u002Fwriting-proofreader\u002FSKILL.md",[140,145],{"categoryNo":141,"categoryName":142,"taxonomyType":143,"taxonomyTypeDesc":144},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":146,"categoryName":147,"taxonomyType":22,"taxonomyTypeDesc":23},"01JBSEEDCAT000000000000036","内容创作者",[149,150,151,152,153],"proofreader","writing proofreader","writing","文章","提案",{"skillNo":155,"name":83,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":162,"publishedAt":32},"01M6BVHTTDAY7CYFMFR0HZX1YJ","Claude-side pre-PR review gate. Resolves the branch's base ref (gh PR view or explicit --base), pins an authoritative diff packet, then launches the pr-review dynamic workflow (~\u002F.claude\u002Fworkflows\u002Fpr-review.js) which fans out up to 8 review specialists (code-reviewer, security-reviewer, adversarial-reviewer, pr-test-analyzer, comment-analyzer, silent-failure-hunter, type-design-analyzer, code-simplifier), fails closed on coverage, and verifies Critical\u002FImportant findings. Use before creating a pull request as a quality gate for thick changes — especially where the Codex CLI `$pr-review` skill is unavailable. Triggers: \"pre-PR review\", \"PR 前レビュー\", \"レビュー gate を回して\", \"run the pr-review gate\".","https:\u002F\u002Fgithub.com\u002Ftoku345\u002Fdotfiles\u002Fblob\u002Fmain\u002Fprivate_dot_claude\u002Fskills\u002Fpr-review\u002FSKILL.md",[159],{"categoryNo":160,"categoryName":161,"taxonomyType":143,"taxonomyTypeDesc":144},"01JBSEEDCAT000000000000023","Skill与智能体开发",[89,88,25,163,164,165,166,167,168,169,170,171,83,93,172,173,101,174,175,97,26,176,99,100,177,178],"workflow","security","codex","cli","design","test","reviewer","request","which","up","coverage","gh pr","js","run","codex cli","workflows",{"skillNo":180,"name":181,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":185,"publishedAt":32},"01M6BVHRPQ77P9BF94T0VQ871E","codex-usage","Codex CLI による実装計画レビューの条件と手順、および `\u002Fcodex:adversarial-review` \u002F `\u002Fcodex:rescue` の使い分け。厚い変更の計画完成時や、調査委譲・別案試行・バックグラウンド実行を検討するときに参照する。","https:\u002F\u002Fgithub.com\u002Ftoku345\u002Fdotfiles\u002Fblob\u002Fmain\u002Fprivate_dot_claude\u002Fskills\u002Fcodex-usage\u002FSKILL.md",[],[186,187,165,25,188,189,190,177,166],"usage","codex usage","adversarial","adversarial-review","rescue",{"skillNo":192,"name":193,"nameZh":6,"description":194,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":195,"sourceHtmlUrl":196,"categories":197,"keywords":198,"publishedAt":32},"01M6BVHQ1QDEZJN8FFZ62X5PSV","brainstorming","ソクラテス式対話で要件と設計を詰めてから実装方針を固めるブレインストーミングスキル。「ブレスト」「設計を考えたい」「どう実装すべきか」「アーキテクチャを相談したい」「設計相談」「実装の前に整理したい」「方針を決めたい」などのリクエストで発動する。Triggers Socratic-dialogue design refinement before implementation; surfaces 2-3 approaches and records key decisions as ADRs.","https:\u002F\u002Fgithub.com\u002Ftoku345\u002Fdotfiles\u002Fblob\u002Fmain\u002Fprivate_dot_claude\u002Fskills\u002Fbrainstorming\u002FLICENSE.superpowers","https:\u002F\u002Fgithub.com\u002Ftoku345\u002Fdotfiles\u002Fblob\u002Fmain\u002Fprivate_dot_claude\u002Fskills\u002Fbrainstorming\u002FSKILL.md",[],[193,167,199,200,201,202,90,203,204,205,206,207],"socratic","refinement","整理","records","triggers","dialogue","surfaces","implementation","decisions"]