# Ryomurakami1983 Happy AI Life Copilot Authoring > Copilot authoring を進める - Skill: `tomevault-io/ryomurakami1983-happy-ai-life-copilot-authoring` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/ryomurakami1983-happy-ai-life-copilot-authoring` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/ryomurakami1983-happy-ai-life-copilot-authoring/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/ryomurakami1983-happy-ai-life-copilot-authoring --- # Copilot authoring を進める Skill と Agent はどちらも「Copilot に何をどう任せるか」を定義する資産ですが、設計の単位と検証観点は同じではありません。この skill は入口だけを 1 本化し、対象に応じて適切な authoring ルートへ分けるための router です。入口を 1 つにする理由は、会話の途中で「新規作成 → 改善 → 検証」へ自然に遷移しても、同じ文脈のまま扱えるようにするためです。 ゴール駆動で使うため、最初に達成したいゴール、成功条件、確認手段を短く固定します。 この skill は **作成・改善・責務整理の通常入口**です。ここで扱う検証は、発見しやすさ、責務境界、trigger / body の整合、構造確認が中心です。別実行者にも通じるかを実動で測りたい場合は `skill-eval` を評価窓口にし、明瞭性評価なら `empirical-prompt-tuning` へ進みます。 ## 共通の改善型: 抽象 -> review -> 発展 skill / agent / hooks の改善では、いきなり具体実装へ入らず、まず変更の型を 3〜6 行で抽象化します。次にその抽象を review へ渡し、責務境界、入力、失敗時の扱い、共有先を見直してから具体へ降ろします。途中で閉じない改善種は、その時点で Issue 化して次回に回します。 ### hooks を題材にした最小例 - `pre-commit` に secret guard を足したい、ではなく「Git client hooks で staged diff の secret 検査を前段に置く」と抽象化する。 - review では、hook の責務、同期先、失敗時の挙動、README との整合を先に確認する。 - 実装具体に入るのは、抽象化と review で形がそろった後だけにする。 ## こんなときに使う - 新しい custom skill を `plugins/happy-core/skills/` または `plugins/happy-coding/skills/` に追加したいとき - 新しい custom agent を `plugins/happy-coding/agents/` に追加したいとき - `works/` で育てた草案を `plugins/*` 配布前提へ昇格し、name / description / trigger を整えたいとき - `.github/copilot-instructions.md` や `.github/instructions/*.instructions.md` を作りたいとき - 既存の skill / agent / instructions の説明、境界、検証導線を改善したいとき - 公開や sync の前に authoring 資産の責務、構造、静的な品質を確かめたいとき - skill / agent / hooks 改善の共通型を先に整えたいとき ## 判断表 | やりたいこと | ルート | 次にやること | | --- | --- | --- | | 新しい skill を作る | `sub_skills/new-skill/` | scope、trigger、構造を決め、既存 template と validator を使って立ち上げる。 | | 新しい agent を作る | `sub_skills/new-agent/` | 役割境界、model、tools を決め、agent template から起こす。 | | repo-wide / path-specific instructions を作る・直す | `sub_skills/instructions-authoring/` | repo-wide と path-specific の責務を分け、最小の rule と review checklist を整える。 | | 既存の skill / agent を改善する | `sub_skills/improve-existing/` | evidence を読み、説明・境界・関連資料を同期して磨き直す。 | | 変更を出荷前に検証する | `sub_skills/validate-authoring/` | skill は既存 validator、agent は同梱 validator で構造確認する。 | | 実動で別実行者にも通じるか測る | `skill-eval` / `empirical-prompt-tuning` | authoring では閉じず、評価窓口または明瞭性の実証検査へ送る。 | ## ワークフロー: authoring を進める ### ステップ 1 — 対象と変更の種類を切り分ける まず対象が skill か agent か instructions か、新規作成か改善か、構造確認かを分けます。ここを混ぜると、skill に必要な routing 設計と、agent に必要な責務境界、instructions に必要な常駐 rule の設計がぶつかりやすくなるためです。 ### ステップ 1.5 — 変更の型を抽象化する 改善なら、まず「何を変えるか」ではなく「どんな型の改善か」を短く書きます。たとえば hooks 追加なら、対象、責務、失敗時の扱い、共有先の 4 点を 3〜6 行で並べるだけで十分です。 ### ステップ 2 — 既存資産を再利用する skill では `_skill` の雛形 / 検証資産、agent では `_agent` の雛形、instructions では既存の `.github/copilot-instructions.md` と `.github/instructions/*.instructions.md` の責務分離を優先して使います。理由は、新しい入口を作っても下位の型まで独自化すると、将来の修正箇所が増えてメンテナンスが難しくなるからです。 ### ステップ 3 — create / improve / validate の順で進める 新規作成でも改善でも、最後は検証に戻します。authoring 資産は prose が中心なので、書けたかどうかより「発見できるか」「境界が明確か」「次の利用者が迷わないか」を確かめることが重要です。 この段階で「別エージェントが読んでも同じ行動を取れるか」が主な不安なら、`skill-eval` で評価ルートを選びます。明瞭性や裁量補完の検出が目的なら `empirical-prompt-tuning` を使い、behavioral A/B 比較が目的なら skill-eval の benchmark へ進みます。 `plugins/*` 配下で plugin 配布中の skill / agent を改善した場合だけ、**利用者体験が変わる改善か**を最後に確認します。変わるなら、その plugin の `plugin.json` と marketplace entry の version 更新が必要かを判断します。詳細は `references/plugin-versioning.md` を参照してください。 ### ステップ 4 — その場で閉じるか Issue 化するかを決める - その場で閉じる: 抽象化と review の時点で、既存資産の書き換えだけで済む - Issue 化する: 変更先が複数にまたがる、別の review が必要、次回以降に再利用したい - 迷うとき: まず小さく issue 化し、具体実装は次の着手点に残す ## 共通リソース - `./_skill/_foundation/` — skill authoring の規約と雛形 - `./_skill/_eval/` — skill の評価 / 検証資産 - `./_skill/scripts/` — skill 作成と梱包の補助スクリプト - `./_agent/references/agent-template.md` — agent 定義の雛形 - `./_eval/scripts/validate_agent.py` — agent markdown の構造 validator - `./sub_skills/instructions-authoring/` — repo-wide / path-specific instructions の authoring ルート - `./sub_skills/improve-existing/` — 既存資産の改善ルート - `./references/plugin-versioning.md` — plugin 配布中 skill / agent を更新したときの version 判断 ## 注意点 - **built-in と競合する名前を新設しない**: `/plan` `/review` `/research` `/session` と紛らわしい 1 語名は、到達性より混乱を増やします。 - **router を重くしすぎない**: 実行手順を親に詰め込むと、sub-skill の役割が消えて入口の価値が落ちます。 - **Skill と Agent を同じ観点で採点しない**: skill は workflow と routing、agent は責務と権限が主眼なので、同じ checklist を無理に当てないほうが保守しやすいです。 - **instructions に手順を書き込みすぎない**: 常時読み込まれる rule には短い guidance だけを置き、詳細 workflow は skill へ逃がします。 --- > Source: [RyoMurakami1983/happy_ai_life](https://github.com/RyoMurakami1983/happy_ai_life) — distributed by [TomeVault](https://tomevault.io).