# Templates

> <!--

- Skill: `turntuptechnologies-ai/templates` (Agent Skill)
- Install (CLI): `npx skillmds@latest add turntuptechnologies-ai/templates`
- Raw SKILL.md: https://api.skillmd.com/api/skills/turntuptechnologies-ai/templates/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: turntuptechnologies-ai (https://skillmd.com/u/turntuptechnologies-ai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/turntuptechnologies-ai/templates

---

<!--
作る前に: これは本当に「Skill」向きか？（→ ../README.md「Skill と他の操縦手段」）
  - 呼び出して使う手順（procedure）            → Skill（このテンプレ）
  - 常に守る制約（〜してはいけない / 〜であること）→ Rules（.claude/rules/。paths でスコープ可）
  - モデルの判断を介さず確実に走らせる/止める   → Hook（.claude/settings.json の PreToolUse 等）
  - 別コンテキストで調査して結果だけ返したい     → Subagent（.claude/agents/）
Skill だと確定したら、この説明コメントごと中身を書き換える。
-->
---
name: skill-name
description: いつこの Skill を使うか・何をするかを一文で。name と description だけは常時ロードされ（progressive disclosure）、Claude はこれを読んで発動可否を判断する。だから「どんな状況・どんな指示で使うか」のトリガーを具体的に書く。例) "PR を作成するとき。「PR 作って」等で発動。ブランチを切り、Conventional Commits タイトルとテンプレ本文で PR を作成する。"
---

# <Skill のタイトル>

## このスキルがやること

<何を達成するスキルか、1〜2 行で>

## 手順

1. <ステップ 1>
2. <ステップ 2>
3. <ステップ 3>

## ルール・コツ

- <守ってほしい制約>
- <ありがちな失敗とその回避>
- <他の Skill / Rules / Hook と連携するなら、その関係>

## 完了条件

以下を全て満たしたら完了。**満たせない項目があれば、黙って省略せず理由を報告する。**

- [ ] <検証可能な条件 1（実行結果・成果物で確認できること）>
- [ ] <検証可能な条件 2>
- [ ] <検証可能な条件 3>

## 補足

- 社内固有情報（社名・内部 URL・認証情報など）は書かない。環境差は引数や環境変数で受け取る。
- 「毎回必ず実行/ブロックしたい」処理が出てきたら、それは Skill ではなく Hook に切り出す。

<!--
書き方のコツ（どのモデルでも品質を安定させる）:
- 完了条件は「〜を確認した」「〜が通る」など検証可能な形で書く。「適切に」「十分に」等の曖昧語は避ける。
- 本文に載せる確認系コマンド（読み取り・`--check`・`--dry-run` 等）は一度実行して確かめてから書く。適用系（設定変更・書き込み）は `--help` や公式ドキュメントで構文を確認する（skill-lint の項目 10 が検証する）。
- 手順は目標と制約を示す粒度に留め、過度にステップを細分化しない（細かすぎる指示はかえって品質を下げる）。モデルが既に知っている操作（VCS の基本コマンド等）を手順書にしない。正確なコマンドを載せるのは、間違えると壊れる操作（設定変更・リリース・削除）に限る。
- 制約には理由を添える（「〜しない。理由: …」）。理由が分かるとモデルは想定外の場面にも正しく汎化する。強調語（必ず・絶対・太字）は本当に譲れない 1〜2 の制約に限り、全体を強調で塗らない。
- 「旧 ◯◯」「今は〜に変わった」等の移行相対表現や、過去の経緯の語りは書かない（現行ルールだけを書く）。
- 判断が分かれる場面には if/then の判断基準を書く（例: 軽微→その場で修正 / 大きい→Issue化）。
- 報告・成果物に決まった形があるなら「出力フォーマット」を表テンプレで示す（モデル間の出力ブレを直接抑える）。
- 曖昧になりがちな規約（命名・タイトル書式等）は、良い例/悪い例の対比表で固定する。
- 不明・判定不能なケースの扱い（推測せず確認する / 「不明」と明記する）を書いておく。
-->


