translate-post

name

translate-post

description

Translate a markdown post into every language declared in its frontmatter via the trigger-translations pipeline. Use whenever the user invokes /translate-post with a path to a .md file, or asks Claude to "translate this post", "run the translation pipeline", or "drop this into trigger.dev". Reads the file, calls the trigger.dev parent task via MCP, watches the run, and reports when the commits land in the target GitHub repo.

/translate-post

Trigger the trigger-translations pipeline for a single markdown post.

Usage

/translate-post <path-to-md-file>

Example:

/translate-post examples/sample.md

If the user invokes the skill without a path (just /translate-post), list the .md files under examples/ and ask them to pick one.

What to do

Step 1 — Resolve the file

• Treat the argument as a path relative to the repo root.
• Read it with the Read tool. If the file does not exist, stop and report the resolved absolute path so the user can see what you tried.

Step 2 — Derive the slug

Take the basename of the file, strip the .md extension, lowercase it. So examples/sample.md → sample. If the basename has spaces, replace them with dashes.

Step 3 — Sanity-check the frontmatter

The first 30 lines of the file must contain a languages: field pointing at a non-empty array. If it does not, stop and tell the user the file is missing required frontmatter — point them at examples/sample.md as the canonical shape.

Step 4 — Trigger the parent task via the trigger.dev MCP

Call mcp__trigger__trigger_task with:

• taskIdentifier: translate-post
• payload: { "slug": "<slug-from-step-2>", "content": "<full-file-contents>" }

The payload's content must be the complete file contents, frontmatter and body together. The parent task parses the frontmatter itself — do not strip it client-side.

Step 5 — Report the run id

Surface the run id and the trigger.dev dashboard link the MCP returns. Tell the user what to expect next: N parallel children, then a single commit landing on the target repo.

Step 6 — Wait for completion

Call mcp__trigger__wait_for_run_to_complete with the run id. Narrate meaningful state changes when they happen — "5 children triggered, waiting...", "all translations back, committing...", "publish scheduled for ". Do not spam status messages between checks.

Step 7 — Report final result

When the run completes:

• Link to the commit at https://github.com/<TARGET_REPO_OWNER>/<TARGET_REPO_NAME>/commit/<commitSha> (read the owner/name from .env if you need them — or fall back to the parent task's return payload).
• List the languages translated.
• If a publish was scheduled, mention the publishDate and that a second commit will land then.
• If anything failed, surface the error from the run's error field and don't pretend it succeeded.

Prerequisites

The trigger.dev dev server must be running locally — npm run dev in another terminal. If the trigger call returns Task not found or similar, the dev server probably isn't up yet. Tell the user to check that terminal before retrying.

.env must have TRIGGER_SECRET_KEY, DEEPL_API_KEY, GITHUB_TOKEN, TARGET_REPO_OWNER, TARGET_REPO_NAME.

Failure modes worth catching early

• File path doesn't resolve → report the absolute path you tried.
• Task not found → dev server isn't running.
• Child run failed → the parent throws and skips the commit. Surface the child error so the user knows what to fix (usually a DeepL key or a markdown formatting issue).