tdmcp submission orchestrator
SkillAI & modelsOrchestrates the tdmcp Anthropic Connectors Directory (Desktop Extension / MCPB) submission prep — designs the package, writes the privacy page, migrates .dxt→.mcpb, drafts all form answers, and QAs the result. Use for ANY work on the tdmcp directory/marketplace submission, including re-runs after a rejection ("update the submission", "redo the form answers", "re-migrate the bundle", "fix the privacy page", "the directory rejected us"). Drives a 4-agent pipeline (architect → docs-author ∥ bundle-engineer → QA).
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 submission orchestrator skill
What this skill tells your AI
The instructions your AI receives, as published by pantani/tdmcp in .agents/skills/tdmcp-submission/SKILL.md and read by ahel’s review.
Coordinates four agents to prepare (and re-prepare) tdmcp's submission to the Anthropic Connectors Directory via the Desktop Extension (MCPB) path. Defines who works when; each agent's skill defines how.
Execution mode — sub-agents (this environment has no TeamCreate)
TeamCreate/SendMessage are not available here, so run agents as
sub-agents with the Agent tool. For every agent:
subagent_type: "general-purpose",model: "opus".- Prompt MUST tell it to read its definition file in
.codex/agents/*.tomland its required skill(s) first, then do the task. Use this exact mapping:architect→.codex/agents/submission-architect.toml,docs-author→.codex/agents/docs-author.toml,bundle-engineer→.codex/agents/bundle-engineer.toml, andsubmission-qa→.codex/agents/submission-qa.toml. The definition file is the source of truth (reusable next session); the prompt just points at it + passes the task and the relevant_workspace/paths. - Parallelize independent agents by sending multiple
Agentcalls in one message (orrun_in_background: true).
Data passing — file-based via _workspace/
Create _workspace/ at the repo root for inter-agent artifacts:
00_submission-spec.md— architect → everyone01_migration-notes.md— bundle-engineer → QA/human02_form-answers.md— docs-author → QA/human (paste-ready form draft)03_qa-report.md— QA → human
Final deliverables (privacy page, edited repo files, tdmcp.mcpb) land in the
repo proper. _workspace/ is preserved for audit / re-runs.
Phase 0: context check (initial vs re-run)
- If
_workspace/is absent → initial run: full pipeline below. - If
_workspace/exists and the user asks to fix/update one part → partial re-run: re-invoke only the affected agent(s), pass the prior artifacts + the new feedback (e.g. a directory rejection reason). E.g. "privacy page rejected" → docs-author only, then QA. - If
_workspace/exists and the user gives fresh inputs → move it to_workspace_prev/and start a new initial run.
Pipeline (initial run)
- architect (solo, first). Produces
00_submission-spec.md. Everything downstream depends on it — do not parallelize anything before it finishes. - docs-author ∥ bundle-engineer (parallel — disjoint file sets):
- docs-author owns: privacy page(s),
config.tsnav additions,02_form-answers.md. (Prose lane.) - bundle-engineer owns:
dxt/manifest.json,scripts/build-mcpb.mjs,package.jsonscripts,scripts/setup.mjs,.dxt→.mcpbtext sweep in existing docs,.github/release workflow,01_migration-notes.md. (Code lane.) - They never edit the same file — that's why they can run together safely.
- docs-author owns: privacy page(s),
- submission-qa (solo, last). Runs builds + checks, writes
03_qa-report.md. If it reports blocking issues, loop back to the owning agent (partial re-run), then re-run QA on the affected checks.
Error handling
- An agent failing once → retry once with the failure context. Still failing → proceed and record the gap in the final summary; never silently drop it.
- Never bypass a failing gate (
--no-verify, deleting a check). A red QA gate is the signal to fix, not to suppress. - Conflicting facts (e.g. spec says manifest_version X, packer wants Y) → trust the live tool/repo, and have the architect update the spec rather than forcing the stale value.
After the run
Summarize to the user (in Portuguese): what changed in the repo, the contents of
02_form-answers.md and the QA verdict, and the explicit Needs human before
submit list (support email, privacy contact, cutting a new release so the
.mcpb asset exists, and the actual form click — which only the user can do).
Then offer to address any QA nits or feedback.
Test scenarios
- Happy path: no
_workspace/→ architect spec → privacy page + form draft +.mcpbmigration →npm run docs:buildandbuild:mcpbpass → QA all-PASS except human-input items → summary lists those items. - Rejection re-run: user says "directory rejected: privacy policy incomplete"
→ Phase 0 detects existing
_workspace/→ re-invoke docs-author with that feedback → QA re-checks the privacy gate only → updated summary.
Signals
- GitHub stars
- 41
- Forks
- 9
- Last commit
- Aug 2026
Advanced
- Catalog kind
- skill
- Gateway key
tdmcp-submission- Source
- github.com/pantani/tdmcp