From ship
Generates a structured GitHub Issue with title and body, verifying drafted claims via premise check and adversarial challenge before posting.
How this skill is triggered — by the user, by Claude, or both
Slash command
/ship:issue [issue description]When to use
Issue作って, Issue書いて, Issue作成, GitHub Issue
[issue description]opusThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Generate a GitHub Issue with a structured title and body, verifying drafted claims via premise check and critic-design challenge before posting.
Generate a GitHub Issue with a structured title and body, verifying drafted claims via premise check and critic-design challenge before posting.
$ARGUMENTS is the issue description. If empty, prompt for it via AskUserQuestion.
Read language from ${CLAUDE_SKILL_DIR}/../../settings.json and translate the issue body and templates into that language. If unset, default to English. Keep technical terms, code, and identifiers untranslated.
.claude/OUTCOME.md; if absent, generate the stub via /outcome${CLAUDE_SKILL_DIR}/references/prose-review.md plus the empty-phrase file matching the body language (${CLAUDE_SKILL_DIR}/references/phrases.ja.md for Japanese, ${CLAUDE_SKILL_DIR}/references/phrases.en.md for English)/challenge (GO / NO-GO), feature / bug only (§ Adversarial Challenge)gh issue create --body-file (§ Labels; sandbox-compatible, avoids escaping a long body)Default to feature if unclear. The title takes a bracketed prefix of the capitalized type.
| Type | When to use |
|---|---|
| bug | Something existing is broken or not working as expected |
| feature | New capability or enhancement request |
| docs | Documentation additions or corrections |
| chore | Maintenance, config, or dependency updates |
Prefer a repository Issue template; fall back to the skill's bundled template. Detect by listing .md files via gh api "repos/{owner}/{repo}/contents/.github/ISSUE_TEMPLATE" --jq '.[].name'. Whichever becomes the skeleton, the rest of the flow (Confidence Marking → Premise Check → prose review → challenge) runs the same.
| Priority | Condition | Template to use |
|---|---|---|
| 1 | A GitHub template matches the type (filename or name contains the type) | Read its body; strip the leading frontmatter (name / about / labels / title) for the skeleton |
| 2 | No match | ${CLAUDE_SKILL_DIR}/templates/<type>.md |
Mark which parts of the body are fixed vs tentative, so the implementer can tell a requirement to honor from an undecided judgment or unverified fact.
${CLAUDE_SKILL_DIR}/../../settings.json (仮 under Japanese).| Origin | State | Notation | Action phrase |
|---|---|---|---|
| User decided it, or it is the ask (What & Why, Acceptance Criteria, explicit Scope / Constraints) | fixed | unmarked | - |
| AI-inferred HOW (placement, approach, format), or a decision the user left open | tentative | (tentative: ...) | "decide at pickup" / "change if a better fit appears" |
| Fact not yet verified (residual Premise Check could not settle) | tentative | (tentative: ...) | "recheck at pickup" |
Sifts the claims already drafted into the body. Not a discovery phase. No agent spawns inside this check, no cross-codebase audit, no digging beyond the drafted claims themselves. A factual claim resolves into an assertion by default; downgrade to tentative only when it cannot.
| Claim type | Action |
|---|---|
| Current-code claim | Verify with 2-3 targeted Read / ugrep checks; annotate the basis in body ("grep-confirmed") |
| Claim still ambiguous after checking | Downgrade to tentative; never assert it as fact |
| Claim contradicted by the source | Rewrite the body to match the source. If the mismatch itself matters, state it under Premises with the verification ask |
| External design ref | Always unverified; the skill cannot judge whether the source is current, so add a link + "confirm latest before starting" |
| Target file list | Annotate "candidates as of writing; recheck on pickup" |
| Code example in body | Annotate as a reference, not the implementation ("reference shape; final form decided at pickup") |
Run Skill("challenge", <drafted title + body>) only for feature or bug (skip when empty). The returned verdict and findings never enter the issue body; collect them into the preview's challenge block. They are review material at confirm time, and the final call to fold or dismiss stays with the user.
| Verdict | Handling |
|---|---|
| GO | Proceed to preview. If conditions are appended, present them as ephemeral critique; fold only what belongs in the body, once |
| NO-GO | Present the refuting evidence at preview; leave post / revise / drop to the user |
priority:* is required, set to critical / high / medium / low by impact. For other labels, follow the repository's conventions.
npx claudepluginhub thkt/dotclaude --plugin shipCreates well-structured GitHub issues using gh CLI with templates for bugs, features, tasks including titles, descriptions, acceptance criteria, and labels. Use for filing bugs or feature requests.
Analyzes codebase impact for a given request and creates structured GitHub issues with AI-verified and human-judgment-needed sections.
Creates and manages GitHub issues for bugs, features, and tasks with enforced quality standards like reproducibility steps, acceptance criteria, and severity assessment.