メニュー
Systematic research methodology for deep-diving into topics, frameworks, and tech stacks before course creation. Defines source quality standards, research artifact formats, and framework extraction criteria.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | research-methodology |
| description | Systematic research methodology for deep-diving into topics, frameworks, and tech stacks before course creation. Defines source quality standards, research artifact formats, and framework extraction criteria. |
This skill activates when you need to investigate a topic deeply enough to teach it. It applies before any course content is written — the research phase that produces the knowledge artifacts (platform-summary.md, teaching-context.md, framework-extraction.md) that the content creation pipeline consumes.
Use this when:
Extract architecture, not features. Anyone can list what a tool does. Course authors need to understand HOW it works, WHEN to use each part, and WHERE things go wrong. Architecture → decision points → frameworks → course content.
Not all sources are equal. Rate every source:
| Tier | Source Type | Trust Level | Use For |
|---|---|---|---|
| S | Official documentation | Highest | Architecture, API, terminology, key numbers |
| A | Official blog posts, changelogs | High | Recent changes, design decisions, roadmap |
| A | Official GitHub repos, examples | High | Patterns, conventions, working code |
| B | Community-maintained docs | Medium | Verify against official before using |
| B | Expert blog posts (recognized contributors) | Medium | Insights, opinions, worked examples |
| C | Forum discussions, Stack Overflow | Low | Common mistakes, gotchas, real-world issues |
| D | Random blog posts, tutorials | Lowest | Cross-reference only, never trust alone |
Rule: Every fact in a platform-summary.md must trace to a Tier S or A source. Tier B-D sources are useful for identifying WHAT to investigate, not for stating facts.
Every research session produces artifacts under the consumer plugin's research directory (path convention is consumer-specific; dojo-academy uses content/courses/{course-slug}/research/). Each artifact follows a specific format defined in the resources:
RESEARCH.md — session log (what was investigated, key findings, open questions)sources.md — registry of all sources with tier ratingsframework-extraction.md — named frameworks ready for text classesrepo-analysis-{name}.md — per-repo analysis documentscompetitive-landscape.md — what other courses/tutorials cover this topicFor every topic researched, extract these 5 categories:
| Category | What to Capture | Why It Matters for Course |
|---|---|---|
| Architecture | How it works — layers, components, data flow | Students need mental models, not feature lists |
| Terminology | Exact official names and definitions | Wrong terms in course content = lost credibility |
| Key Numbers | Limits, defaults, thresholds, pricing | Students need these for real-world decisions |
| Decision Points | When to use X vs Y, trade-offs | These become named frameworks in text classes |
| Common Mistakes | Gotchas, anti-patterns, misconceptions | These become "What Goes Wrong" sections |
A research finding becomes a named framework when it meets ALL of these:
See resources/framework-extraction.md for the full extraction methodology.
resources/research-template.md — standard RESEARCH.md structureresources/source-quality.md — detailed source evaluation criteriaresources/framework-extraction.md — how to identify and name teachable frameworksInteractive course workbook design system — turns a course's text classes into one standalone, accessible, interactive HTML explainer (a navigable document chunked by module, Articulate-Rise lesson model; stepped mode for screen-recording). Defines the curated component kit, the content-shape -> component mapping rules, the accessibility contract, and the consumer-spec (instruction-bundle-spec.yaml) consumption + graceful-degrade rules. Consumer plugins own the brand tokens and the component vocabulary via their `workbooks` spec section; this skill stays voice-neutral.
Diálogo guiado para diseñar un Path — una super-estructura SOBRE la capa cmi5-curso que agrupa cursos existentes en milestones ordenados y los envuelve en una credential OpenBadge 3.0. NO modifica ningún course.json (aditivo). Produce path.json (fuente de verdad, validado contra path.schema.json) + content/paths/<slug>/path-overview.md (frontmatter alineado con el contrato dojo-academy). Use when user asks to "create a path", "design a path", "new path", "crear un path", "diseñar un path", "nuevo path", "ruta de aprendizaje", "learning path", "armar un path", "/new-path".
Builder's Bloom's — cognitive scaffolding for course design. Use when planning learning objectives, sequencing modules, writing assessment criteria, designing challenge progression, or reviewing whether a course builds toward higher-order thinking. Activated when discussing cognitive levels, objective writing, or skill progression.
Learning Evaluation — measuring whether courses actually work. Use when designing post-course surveys, analyzing course metrics, planning retention strategies, reviewing challenge rubrics, or discussing how to measure learning outcomes beyond quiz scores. Reference skill for evaluation planning.
Ship-First Design — backward design for builders. Use when planning a new course, structuring modules, aligning assessments to objectives, designing challenges, or reviewing whether content connects to ship milestones. Activated when discussing course planning, curriculum design, assessment alignment, or backward design.
Hormozi-style slide design system for course videos — slide types, accent rules, typography hierarchy, and anti-patterns. Consumer plugins ship the actual HTML/CSS templates referenced here (e.g. dojo-academy ships `content/_templates/slides/dojo-slides-light.html` and `dojo-slides-dark.html`).