tdmcp-docs-interactive — orchestrator
SkillDocs & knowledgeRestructure and enrich the tdmcp documentation site for artists — categorized/collapsible sidebar (EN+PT), interactive goal-based guide home, new step-by-step tutorials, copy-prompt/level-badge components. Use whenever the user asks to make the docs more interactive, easier to navigate, better organized, add categories/subcategories, add tutorials, improve docs UX/IA, or for follow-ups: re-run, continue, fix QA findings, add one more tutorial, re-organize a section, or update the docs structure. NOT for syncing docs with a release (tdmcp-docs-roadmap-update) or cookbook entries (tdmcp-cookbook-examples).
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the tdmcp-docs-interactive — orchestrator skill
What this skill tells your AI
The instructions your AI receives, as published by pantani/tdmcp in .claude/skills/tdmcp-docs-interactive/SKILL.md and read by ahel’s review.
Pipeline (sub-agents, no TeamCreate in this environment): architect → (builder ∥ tutorial writers) → QA → fix loop. Data flows through _workspace/docs-interactive/ files.
Phase 0: context check
_workspace/docs-interactive/missing → initial run (full pipeline).- Exists + user asks partial change ("add one tutorial", "fix QA items") → rerun only the relevant agent(s); every agent knows to revise, not restart.
- Exists + user gives a new direction → move it to
_workspace/docs-interactive_prev/and run fresh.
Phase 1: IA design
Spawn docs-ia-architect (model opus). Input: the user's complaint/goals + any prior proposal from conversation. Output: 01_ia_spec.md. Review the spec briefly; if it invents nonexistent tools/pages without NEW markers, send it back once.
Phase 2: build (parallel)
In ONE message spawn:
docs-interactive-builder(opus) — implements sidebar/home/components from the spec; creates stubs for tutorial pages so the build never breaks.- one
docs-tutorial-writer(opus) per tutorial in spec §3 — each owns only its EN+PT page pair. File ownership prevents conflicts: builder never writes tutorial prose; writers never touch config/theme.
Phase 3: QA
Spawn docs-roadmap-qa (opus): npm run docs:build gate, EN/PT structural parity, dead links, sidebar↔file existence cross-check, generated reference/tools.md untouched. Instruct it explicitly to write its findings to _workspace/docs-interactive/04_qa_report.md (its default from other harnesses is _workspace/docs_roadmap_qa.md — the fix loop reads the path above, so the prompt must override the default).
Phase 4: fix loop + wrap-up
- QA FAIL → route each finding to its owner agent (builder vs writer), rerun QA once. Second FAIL → report remaining issues to the user, do not loosen gates.
- PASS → summarize: structure changes, new pages, components, build status. Do NOT commit/tag unless the user asked; follow repo release policy (no premature tags).
Error handling
One retry per agent; on second failure continue without that slice and state the gap explicitly. Conflicting spec vs. reality (page missing, tool renamed) → prefer reality, note the deviation in the report.
Test scenarios
- Normal: "deixe os docs mais interativos com categorias e tutoriais" → full pipeline, docs:build green, sidebar grouped in EN+PT, ≥3 tutorials in both locales.
- Error: a tutorial writer references a nonexistent tool → QA flags it, writer revises against the cookbook, second QA passes.
Signals
- GitHub stars
- 41
- Forks
- 9
- Last commit
- Aug 2026
Advanced
- Catalog kind
- skill
- Gateway key
tdmcp-docs-interactive- Source
- github.com/pantani/tdmcp