メニュー
When piping markdown into `gh issue create --body "$(cat <<'EOF' ... EOF)"` (or any single-quoted heredoc), use literal backticks. Do NOT escape them -- escapes survive into the output and break the markdown.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when deciding whether to dispatch a runner or a worker for a subtask. Describes the decision boundary, the failure mode when runner is used where worker is intended, and the safe composition pattern.
When a repo has no GitHub remote (or is not yet a git repo) -- use this to route survey, sweep, and dispatch off the GitHub-centric path. Detect with `git remote` empty; treat blank GitHub columns as expected, not an error; route work to commits + CLAUDE.md instead of issues + PRs; degrade a maintenance sweep to the local-only axes.
When the directive is "status check," "what's new across my projects," or "sweep maintenance" -- run a per-project, read-mostly, non-PR sweep. For each project under the owner-prefixed layout, gather stars/forks, open issues/PRs split into mine vs community vs bots, package downloads, release-due (unreleased conventional commits), a test run, a stale-CLAUDE.md flag, and branch-cleanup candidates. Emit a fresh per-project report every sweep; NEVER cache status back into a workspace/manager CLAUDE.md.
Before making any non-trivial code, docs, or config change -- create a feature branch first, then open a PR. Never commit directly to main. Apply by default before any edit; this is the baseline branch discipline that all other git skills build on.
When the issue or PR queue has open unlabeled items -- run a read-only triage pass that labels each one by component, category, priority, and size, flags duplicates, closes noise, and reports the p1 queue before runners are dispatched.
When writing any issue, PR, or commit message, use this for the authoring standard. Covers structure (headings, lists, tables, fenced blocks, the bug block, the before/after) and voice (factual, no emdashes, no editorializing labels, conventional-commit prefixes, no commit trailers).
| name | heredoc-backticks |
| description | When piping markdown into `gh issue create --body "$(cat <<'EOF' ... EOF)"` (or any single-quoted heredoc), use literal backticks. Do NOT escape them -- escapes survive into the output and break the markdown. |
When piping markdown into gh issue create --body "$(cat <<'EOF' ... EOF)" or gh pr create --body "$(cat <<'EOF' ... EOF)" (or
any single-quoted heredoc), use literal backticks. Do NOT write
the backslash-escaped form.
A single-quoted heredoc delimiter (<<'EOF') already disables
variable, command, and history expansion in the body. Backslash-
backtick is not interpreted by the shell -- it passes through as
the literal two-character sequence \ + `.
GitHub's markdown renderer then treats the backslash as an escape,
converting each \`` into a literal backtick *character* (not a code- fence delimiter). Result: code fences fail to open/close, the TOML/code block renders as plain prose, and any #` inside the
unclosed block becomes an H1.
Caught on roba 2026-05-27 after a screenshot showed issue #1's schema block rendered as broken text.
Whenever piping markdown body text into a gh pr create, gh issue create, or any gh command via a single-quoted heredoc.
In a <<'EOF' heredoc, write fences as:
```toml
...
```
and inline code as `--flag` -- no backslashes anywhere. Same
for any other text that the shell would normally interpret ($VAR,
`cmd`, \n): inside single-quoted EOF, all of it is literal
already.
If the delimiter is unquoted (<<EOF instead of <<'EOF'),
backticks WOULD do command substitution and would need escaping.
But prefer single-quoted EOF and avoid that situation entirely:
gh issue create --title "..." --body "$(cat <<'EOF'
markdown body with literal `backticks` and ```code fences```
EOF
)"
orchestration-prompt-template
-- the orchestration loop pipes a lot of markdown into
gh pr create; this skill keeps those bodies rendering correctly.