diff --git a/CHANGELOG.md b/CHANGELOG.md index 7af58e1..c04eadf 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,19 @@ # Changelog +## v1.4.0 (2026-07-17) + +### New + +- **スキル名の区切り文字（ハイフン / ドット）を選択可能に** — 一部の LLM プラットフォームは Agent Skills 準拠のハイフン区切りのスキル名しか使えないため、インストール時にどこでも動作するハイフン区切り（`/miko-setup`、デフォルト）とドット区切り（`/miko.setup`）を選択できるようにした。設定は `.miko/config` の `separator=` に保存され、スキルディレクトリ名とファイル内のスキル名参照（handoffs 含む）がインストール・アップグレード時に自動変換される。後から変更する場合は miko を削除して再インストールする。tone_guide に「出力でスキル名に言及するときは config の separator に従う」を明記 + +### Changed + +- **スキル名のアンダースコアをハイフンに統一** — `miko.new_cap` → `miko.new-cap` のように、スキル名内の `_` を `-` に変更（対象: new-cap / new-harae / quick-catchup / quick-impl / split-proposal / catchup-system-hld）。ハイフン区切り選択時に `miko-new_harae` のような混在表記になるのを避けるため。既存インストールはアップグレード時に旧名スキルが削除され新名で再配置される + +### Fixed + +- **upgrade.sh が macOS 標準の bash 3.2 で中断する問題を修正** — `.miko/protected_skills` にプロテクト対象がない場合、`set -u` 下での空配列展開により処理が中断していた + ## v1.3.2 (2026-06-26) ### Changed diff --git a/README.en.md b/README.en.md index 5aa47f4..ca1a23c 100644 --- a/README.en.md +++ b/README.en.md @@ -46,13 +46,13 @@ Organizing by capability gathers related business rules in one place, which make ### Other design decisions -- **speckit is a surveying tool** — speckit artifacts are disposable. For heavy changes, we use speckit as a device to make Claude read the codebase deeply. Day-to-day implementation goes through `/miko.quick_impl`, without speckit +- **speckit is a surveying tool** — speckit artifacts are disposable. For heavy changes, we use speckit as a device to make Claude read the codebase deeply. Day-to-day implementation goes through `/miko.quick-impl`, without speckit - **Division of labor between documents** — the rules themselves (conclusions) go in `business_rules.md`; why they were decided (history) goes in proposals ## 🌿 Prerequisites - [Claude Code](https://docs.anthropic.com/en/docs/claude-code) is installed -- (Optional) The [speckit](https://github.com/github/spec-kit) skills — needed only if you use the full flow (`/miko.speckit.*`). Not required for the standard `/miko.quick_impl` flow +- (Optional) The [speckit](https://github.com/github/spec-kit) skills — needed only if you use the full flow (`/miko.speckit.*`). Not required for the standard `/miko.quick-impl` flow ## ✨ Installation @@ -70,6 +70,14 @@ The installer asks you to choose an output language (日本語 / English). Your MIKO_LANG=en bash <(curl -fsSL https://raw.githubusercontent.com/studyplus/miko/main/install.sh) ``` +The installer then asks you to choose a skill name separator. Because some LLM platforms only accept [Agent Skills](https://agentskills.io/)-compliant hyphenated names, hyphen-separated names (`/miko-setup`), which work everywhere, are the default. On platforms that support dots in skill names you can choose dots (`/miko.setup`) instead. To change the separator later, remove miko and reinstall: + +```bash +rm -rf .claude/skills/miko.* .claude/skills/miko-* .miko # remove, then reinstall +``` + +Skill names in this README are written with dots. If you use hyphens, read them as `/miko-setup` and so on. + After installation, set up your project: ```bash @@ -98,7 +106,7 @@ miko.my-custom-skill miko.another-skill ``` -Protected skills are excluded from upgrades — never removed or overwritten. +Protected skills are excluded from upgrades — never removed or overwritten. If you chose the hyphen separator, write the names hyphenated, e.g. `miko-my-custom-skill`. ### Usage @@ -127,11 +135,11 @@ miko/ | File | Role | Maintenance | |---|---|---| -| `system_high_level_design.md` | System-wide architecture, including the code exploration guide | Generated by `/miko.setup`, kept current by `/miko.catchup_system_hld` | +| `system_high_level_design.md` | System-wide architecture, including the code exploration guide | Generated by `/miko.setup`, kept current by `/miko.catchup-system-hld` | | `glossary.md` | Term definitions (organized in per-capability sections) | Maintained by miko | | `business_rules.md` | Domain decision criteria. Records the "why" that cannot be read from code | Maintained by miko | | `high_level_design.md` | Structure and overview of the capability | Maintained by miko | -| `harae.md` | Findings from adversarial verification, with status tracking | Generated by `/miko.new_harae`, updated by `/miko.harae` | +| `harae.md` | Findings from adversarial verification, with status tracking | Generated by `/miko.new-harae`, updated by `/miko.harae` | | `proposals/` | Change proposals for the capability and their history | Nushi-sama provides the raw material; written together with miko | ## ⛩️ Skills @@ -148,25 +156,25 @@ miko/ | Skill | Purpose | |---|---| | `/miko.setup [overview]` | Introduces miko to your project. Surveys the codebase and generates `miko/system_high_level_design.md` | -| `/miko.catchup_system_hld` | Brings `system_high_level_design.md` up to date with the codebase. Detects and fixes directory-structure drift | +| `/miko.catchup-system-hld` | Brings `system_high_level_design.md` up to date with the codebase. Detects and fixes directory-structure drift | ### Document authoring | Skill | Purpose | |---|---| -| `/miko.new_cap [overview]` | Interactively creates business_rules.md and high_level_design.md for a new capability, drawing on existing code where available | +| `/miko.new-cap [overview]` | Interactively creates business_rules.md and high_level_design.md for a new capability, drawing on existing code where available | | `/miko.catchup ` | Reconciles existing business_rules.md and high_level_design.md against the full codebase | -| `/miko.quick_catchup [diff]` | Creates a proposal from a code change (git diff / PR) and updates the BR/HLD. For after emergency fixes, etc. | +| `/miko.quick-catchup [diff]` | Creates a proposal from a code change (git diff / PR) and updates the BR/HLD. For after emergency fixes, etc. | | `/miko.propose [raw material]` | Interactively creates a change proposal | -| `/miko.split_proposal ` | Splits a proposal into an umbrella (parent) + sub-proposals by phase | -| `/miko.new_harae ` | First adversarial verification of the business rules. Generates harae.md from scratch | +| `/miko.split-proposal ` | Splits a proposal into an umbrella (parent) + sub-proposals by phase | +| `/miko.new-harae ` | First adversarial verification of the business rules. Generates harae.md from scratch | | `/miko.harae [proposal]` | Reviews and extends an existing harae.md. With a proposal, records the findings inside the proposal | ### Implementation (standard flow) | Skill | Purpose | |---|---| -| `/miko.quick_impl ` | The standard flow: implements changes directly, without speckit. Accepts change instructions without a proposal (refactoring, etc.). Changes to BR text require a proposal. Heavy changes beyond its scope are routed to the full flow | +| `/miko.quick-impl ` | The standard flow: implements changes directly, without speckit. Accepts change instructions without a proposal (refactoring, etc.). Changes to BR text require a proposal. Heavy changes beyond its scope are routed to the full flow | ### Implementation (full flow — speckit extensions, for heavy changes) @@ -193,10 +201,10 @@ Available only when speckit is installed. ### Defining a new capability ``` -/miko.new_cap +/miko.new-cap → Interactively creates business_rules.md + high_level_design.md -/miko.new_harae +/miko.new-harae → Adversarially probes the defined rules for contradictions and gaps. Generates harae.md → After fixing the findings, re-verification with /miko.harae is recommended @@ -220,14 +228,14 @@ Proceed in three stages: **Propose → Verify → Implement.** Propose gathers t → Adversarially verifies the rule set as it would be after the proposal. Findings are recorded in the proposal # Optional -/miko.split_proposal +/miko.split-proposal → For large changes only, splits into umbrella (parent) + subs by phase (run after harae) ``` -**Implementation phase (standard: quick_impl)** +**Implementation phase (standard: quick-impl)** ``` -/miko.quick_impl +/miko.quick-impl → Implements directly, without speckit (for single-intent changes within the existing structure) → Afterwards, business_rules.md + high_level_design.md + harae.md are updated automatically → If the change exceeds this scope, you are guided to the full flow @@ -262,10 +270,10 @@ When a change involves multiple intents, requires exploration to pin down its im ### Refactoring without a proposal -Changes that do not alter business-rule text (renames, moves, redistributing responsibilities, etc.) can be implemented by passing the instruction directly to `/miko.quick_impl`, without a proposal. +Changes that do not alter business-rule text (renames, moves, redistributing responsibilities, etc.) can be implemented by passing the instruction directly to `/miko.quick-impl`, without a proposal. ``` -/miko.quick_impl +/miko.quick-impl → Afterwards, affected implementation mappings are updated across all capabilities → If a BR text change turns out to be needed, you are guided to /miko.propose → If the change exceeds the scope (single intent, clear impact, mechanical or local), you are guided to the full flow @@ -275,7 +283,7 @@ Changes that do not alter business-rule text (renames, moves, redistributing res ``` # Bring system_high_level_design.md up to date -/miko.catchup_system_hld +/miko.catchup-system-hld → Detects directory-structure drift and updates system_high_level_design.md # Full scan (reconcile the whole capability) @@ -283,16 +291,16 @@ Changes that do not alter business-rule text (renames, moves, redistributing res → Reconciles BR/HLD against the full codebase, detecting and applying differences # Diff-based (apply a specific code change only) -/miko.quick_catchup +/miko.quick-catchup → Creates a proposal from the current branch's diff + updates the BR/HLD -/miko.quick_catchup #8250 +/miko.quick-catchup #8250 → Creates a proposal from the PR's diff + updates the BR/HLD ``` ## 🌾 Quality improvement during implementation -`/miko.quick_impl` (after implementing) and `/miko.speckit.implement` (per feature) automatically run the following self-reviews: +`/miko.quick-impl` (after implementing) and `/miko.speckit.implement` (per feature) automatically run the following self-reviews: 1. **Self-review** -- checks responsibility placement, naming, and framework conventions 2. **/simplify** -- checks for duplication, quality, and efficiency diff --git a/README.md b/README.md index 7d0648b..3fcf496 100644 --- a/README.md +++ b/README.md @@ -46,13 +46,13 @@ miko はドキュメントを**ケイパビリティ単位**で整理いたし ### その他の設計判断 -- **speckit はお調べの道具** — speckit の成果物は使い捨て。重い変更のとき、Claude に深くコードを読ませるための仕掛けとして使います。普段の実装は `/miko.quick_impl` で speckit を通さず行います +- **speckit はお調べの道具** — speckit の成果物は使い捨て。重い変更のとき、Claude に深くコードを読ませるための仕掛けとして使います。普段の実装は `/miko.quick-impl` で speckit を通さず行います - **ドキュメントの役割分担** — ルールそのもの（結論）は `business_rules.md` に、なぜそう決めたか（経緯）は proposals に書きます ## 🌿 前提 - [Claude Code](https://docs.anthropic.com/en/docs/claude-code) がインストール済みであること -- （Optional）[speckit](https://github.com/github/spec-kit) スキル — フルフロー（`/miko.speckit.*`）をお使いの場合のみ必要でございます。基本フローの `/miko.quick_impl` だけなら不要です +- （Optional）[speckit](https://github.com/github/spec-kit) スキル — フルフロー（`/miko.speckit.*`）をお使いの場合のみ必要でございます。基本フローの `/miko.quick-impl` だけなら不要です ## ✨ インストール @@ -70,6 +70,14 @@ bash <(curl -fsSL https://raw.githubusercontent.com/studyplus/miko/main/install. MIKO_LANG=en bash <(curl -fsSL https://raw.githubusercontent.com/studyplus/miko/main/install.sh) ``` +続けてスキル名の区切り文字の選択を求められます。一部の LLM プラットフォームは [Agent Skills](https://agentskills.io/) 準拠のハイフン区切りの名前しか使えないため、どこでも動作するハイフン区切り（`/miko-setup`）がデフォルトです。ドット区切りに対応したプラットフォームではドット区切り（`/miko.setup`）も選べます。後から変更する場合は、miko を削除して再インストールくださいませ。 + +```bash +rm -rf .claude/skills/miko.* .claude/skills/miko-* .miko # 削除して再インストール +``` + +本 README のスキル名はドット区切りで表記しています。ハイフン区切りをお使いの場合は `/miko-setup` のように読み替えくださいませ。 + インストール後、プロジェクトのセットアップを行います。 ```bash @@ -98,7 +106,7 @@ miko.my-custom-skill miko.another-skill ``` -アップグレード時にプロテクト済みスキルは更新対象から除外され、削除・上書きされません。 +アップグレード時にプロテクト済みスキルは更新対象から除外され、削除・上書きされません。ハイフン区切りを選択している場合は `miko-my-custom-skill` のようにハイフン区切りで記述くださいませ。 ### 使い方 @@ -127,11 +135,11 @@ miko/ | ファイル | 役割 | メンテ | |---|---|---| -| `system_high_level_design.md` | システム全体のアーキテクチャ。コード探索ガイドを含む | `/miko.setup` で生成、`/miko.catchup_system_hld` で追従 | +| `system_high_level_design.md` | システム全体のアーキテクチャ。コード探索ガイドを含む | `/miko.setup` で生成、`/miko.catchup-system-hld` で追従 | | `glossary.md` | 用語の定義（ケイパビリティごとのセクションで管理） | miko がメンテ | | `business_rules.md` | ドメインの判断基準。コードからは読み取れない「なぜ」を記録 | miko がメンテ | | `high_level_design.md` | ケイパビリティの構造と全体像 | miko がメンテ | -| `harae.md` | 攻撃的検証の指摘リストとステータス管理 | `/miko.new_harae` が生成、`/miko.harae` が更新 | +| `harae.md` | 攻撃的検証の指摘リストとステータス管理 | `/miko.new-harae` が生成、`/miko.harae` が更新 | | `proposals/` | ケイパビリティへの変更提案と経緯 | 主さまが元ネタを出し、miko と相談しながら書く | ## ⛩️ スキル一覧 @@ -148,25 +156,25 @@ miko/ | スキル | 用途 | |---|---| | `/miko.setup [概要]` | プロジェクトに miko を導入。コードベースをお調べし `miko/system_high_level_design.md` を生成 | -| `/miko.catchup_system_hld` | `system_high_level_design.md` をコードベースの現状に追従。ディレクトリ構成の乖離を検出・更新 | +| `/miko.catchup-system-hld` | `system_high_level_design.md` をコードベースの現状に追従。ディレクトリ構成の乖離を検出・更新 | ### ドキュメント作成 | スキル | 用途 | |---|---| -| `/miko.new_cap [概要]` | 新規ケイパビリティの business_rules.md と high_level_design.md を対話しながら作成。既存コードがあれば活用 | +| `/miko.new-cap [概要]` | 新規ケイパビリティの business_rules.md と high_level_design.md を対話しながら作成。既存コードがあれば活用 | | `/miko.catchup ` | 既存の business_rules.md と high_level_design.md をコード全体と突き合わせて追従 | -| `/miko.quick_catchup [diff]` | コード変更（git diff / PR）から proposal を作成し BR/HLD を更新。緊急 FIX 後などに | +| `/miko.quick-catchup [diff]` | コード変更（git diff / PR）から proposal を作成し BR/HLD を更新。緊急 FIX 後などに | | `/miko.propose [元ネタ]` | 変更プロポーザルを対話しながら作成 | -| `/miko.split_proposal ` | プロポーザルを親（umbrella）+ サブにフェーズ分割 | -| `/miko.new_harae ` | ビジネスルールの初回攻撃的検証。harae.md をゼロから生成 | +| `/miko.split-proposal ` | プロポーザルを親（umbrella）+ サブにフェーズ分割 | +| `/miko.new-harae ` | ビジネスルールの初回攻撃的検証。harae.md をゼロから生成 | | `/miko.harae [proposal]` | 既存 harae.md の棚卸し・差分探索。proposal 付きなら proposal 内に検証結果を記録 | ### 実装（基本フロー） | スキル | 用途 | |---|---| -| `/miko.quick_impl ` | 変更を speckit を通さず直接実装する基本フロー。proposal なしの変更指示（リファクタリング等）も受け付ける。BR 本文の変更を伴う場合は proposal が必要。スコープを超える重い変更はフルフローにご誘導 | +| `/miko.quick-impl ` | 変更を speckit を通さず直接実装する基本フロー。proposal なしの変更指示（リファクタリング等）も受け付ける。BR 本文の変更を伴う場合は proposal が必要。スコープを超える重い変更はフルフローにご誘導 | ### 実装（フルフロー — speckit 拡張、重い変更向け） @@ -193,10 +201,10 @@ speckit がインストールされている場合のみ使えます。 ### 新規ケイパビリティの定義 ``` -/miko.new_cap +/miko.new-cap → 対話しながら business_rules.md + high_level_design.md を作成 -/miko.new_harae +/miko.new-harae → 定義したルールの矛盾・穴を攻撃的に検証。harae.md を生成 → 指摘を修正したら /miko.harae で再検証をお勧めする @@ -220,14 +228,14 @@ speckit がインストールされている場合のみ使えます。 → proposal 適用後のルール体系を攻撃的に検証。指摘は proposal 内に記録 # Optional -/miko.split_proposal +/miko.split-proposal → 変更が大きい場合のみ、親（umbrella）+ サブにフェーズ分割（harae の後に実施） ``` -**実装フェーズ（基本: quick_impl）** +**実装フェーズ（基本: quick-impl）** ``` -/miko.quick_impl +/miko.quick-impl → speckit を通さず直接実装（単一の意図・既存構造の範囲内の変更が対象） → 実装後、business_rules.md + high_level_design.md + harae.md を自動更新 → スコープを超える場合はフルフローにご誘導 @@ -262,10 +270,10 @@ speckit がインストールされている場合のみ使えます。 ### proposal を通さないリファクタリング -ビジネスルール本文を変えない変更（リネーム・移動・責務の再配置等）は、proposal を通さず `/miko.quick_impl` に変更指示を直接渡して実装できる。 +ビジネスルール本文を変えない変更（リネーム・移動・責務の再配置等）は、proposal を通さず `/miko.quick-impl` に変更指示を直接渡して実装できる。 ``` -/miko.quick_impl <変更指示> +/miko.quick-impl <変更指示> → 実装後、影響する実装マッピングを全ケイパビリティ横断で自動更新 → BR 本文の変更が必要と判定された場合は /miko.propose にご誘導 → スコープ（意図の単一性・影響範囲の明瞭さ・機械性 or 局所性）を超える場合はフルフローにご誘導 @@ -275,7 +283,7 @@ speckit がインストールされている場合のみ使えます。 ``` # system_high_level_design.md の追従 -/miko.catchup_system_hld +/miko.catchup-system-hld → ディレクトリ構成の乖離を検出し、system_high_level_design.md を更新 # フルスキャン（ケイパビリティ全体を突き合わせ） @@ -283,16 +291,16 @@ speckit がインストールされている場合のみ使えます。 → コード全体と BR/HLD を突き合わせて差分を検出・更新 # 差分ベース（特定のコード変更だけ反映） -/miko.quick_catchup +/miko.quick-catchup → カレントブランチの diff から proposal 作成 + BR/HLD 更新 -/miko.quick_catchup #8250 +/miko.quick-catchup #8250 → PR の diff から proposal 作成 + BR/HLD 更新 ``` ## 🌾 実装時の品質改善 -`/miko.quick_impl` は実装後に、`/miko.speckit.implement` は機能ごとに、以下のセルフレビューを自動実行いたします: +`/miko.quick-impl` は実装後に、`/miko.speckit.implement` は機能ごとに、以下のセルフレビューを自動実行いたします: 1. **セルフレビュー** -- 責務の配置、命名、フレームワーク規約のチェック 2. **/simplify** -- コードの重複・品質・効率のチェック diff --git a/business_rules_driven_development.md b/business_rules_driven_development.md index 8cfbd8f..51110d3 100644 --- a/business_rules_driven_development.md +++ b/business_rules_driven_development.md @@ -96,10 +96,10 @@ speckit は SDD のためではなく、**Claude に丁寧にコードベース 2. 検証フェーズ — harae で proposal 適用後のルール体系を攻撃的に検証（AI） /miko.harae - 矛盾・穴・悪用耐性などを攻撃的に確かめる。指摘は proposal 内に記録 - - 変更が大きい場合は harae の後に /miko.split_proposal で親 + サブに分割できる + - 変更が大きい場合は harae の後に /miko.split-proposal で親 + サブに分割できる 3. 実装フェーズ — proposal に基づいて実装（AI） - - 基本: /miko.quick_impl（speckit を通さず直接実装） + - 基本: /miko.quick-impl（speckit を通さず直接実装） - 重い変更: speckit で仕様策定・実装 /speckit.specify → /speckit.clarify → /speckit.plan → /speckit.tasks → /speckit.analyze → /speckit.implement - speckit の成果物は使い捨て。Claude に深く調査させるための道具 @@ -117,7 +117,7 @@ speckit は SDD のためではなく、**Claude に丁寧にコードベース ↓ 検証: harae（AI が攻撃的に検証、指摘は proposal 内に記録） ↓ -実装: quick_impl / speckit（AI が実装） +実装: quick-impl / speckit（AI が実装） ↓ business_rules.md（AI が更新：ドメインの判断基準） high_level_design.md（AI が更新：構造の変化） @@ -340,12 +340,12 @@ proposal は business_rules.md への変更提案ではなく、**ケイパビ 大きな変更を PR 単位でフェーズ分割して実装したい場合、親プロポーザル + サブプロポーザル方式を使う。 -**フロー:** `/miko.propose` で通常通り 1 本のプロポーザルを作成し、`/miko.harae` で検証した後、`/miko.split_proposal` で分割する。 +**フロー:** `/miko.propose` で通常通り 1 本のプロポーザルを作成し、`/miko.harae` で検証した後、`/miko.split-proposal` で分割する。 ``` /miko.propose → 1 本のプロポーザル作成 /miko.harae → 検証（推奨。分割前にやると手戻りが少ない） -/miko.split_proposal → 親（umbrella）+ サブに分割 +/miko.split-proposal → 親（umbrella）+ サブに分割 → 各サブに対して /miko.speckit.specify → 実装フロー ``` @@ -381,7 +381,7 @@ miko//proposals/ ### 複数ケイパビリティにまたがる変更 -**決定（v0.6.0〜）:** umbrella/sub パターンに統一する。propose で横断影響を含む 1 本のプロポーザルを作成し、split_proposal で影響先ケイパビリティに影響先サブプロポーザルを作成する。implement は各サブの BR 変更に従って各ケイパビリティの business_rules.md を更新する。 +**決定（v0.6.0〜）:** umbrella/sub パターンに統一する。propose で横断影響を含む 1 本のプロポーザルを作成し、split-proposal で影響先ケイパビリティに影響先サブプロポーザルを作成する。implement は各サブの BR 変更に従って各ケイパビリティの business_rules.md を更新する。 **フロー:** @@ -391,9 +391,9 @@ miko//proposals/ → 「他ケイパビリティへの影響を調査しますか？」と確認 → サブエージェントが business_rules.md 存在するケイパビリティを走査 → 調査結果をもとに proposal の「他ケイパビリティへの影響」セクション + マーカーを付与 - → 完了報告で /miko.split_proposal の実行を案内 + → 完了報告で /miko.split-proposal の実行を案内 -/miko.split_proposal 時: +/miko.split-proposal 時: → 「他ケイパビリティへの影響」セクションから影響先サブプロポーザルを作成 → 影響先ケイパビリティの proposals/ に配置 → 親プロポーザルのフェーズ構成に列挙（パスからケイパビリティが判別可能） diff --git a/install.sh b/install.sh index 93e90de..9e0a27a 100755 --- a/install.sh +++ b/install.sh @@ -28,6 +28,44 @@ case "$LANG_CHOICE" in *) LANG_CHOICE="ja" ;; esac +# スキル名の区切り文字選択: 対話プロンプト > デフォルト - +# 一部の LLM プラットフォームは Agent Skills 準拠のハイフン区切りの名前しか使えないため、 +# どこでも動くハイフン区切り (miko-setup) をデフォルトとし、ドット区切り (miko.setup) も選択できる。 +# インストール後に変更する場合は、miko を削除して再インストールする +SEP="-" +if [ -t 0 ]; then + if [ "$LANG_CHOICE" = "en" ]; then + echo "⛩️ Please select the skill name separator:" + echo " 1) hyphen (/miko-setup) — works on every platform" + echo " 2) dot (/miko.setup) — for platforms that support dots in skill names" + else + echo "⛩️ スキル名の区切り文字を選択ください:" + echo " 1) ハイフン (/miko-setup) — どのプラットフォームでも動作" + echo " 2) ドット (/miko.setup) — ドット区切りに対応したプラットフォーム向け" + fi + read -r -p " [1/2] (default: 1): " ans + case "$ans" in + 2|.|dot) SEP="." ;; + *) SEP="-" ;; + esac +fi + +# to_local — 正規スキル名（. 区切り）を選択された区切り文字の名前に変換する +to_local() { echo "${1//./$SEP}"; } + +# rewrite_skill_refs ... — ファイル中のスキル名参照 (miko.foo) を選択された区切り文字に書き換える +rewrite_skill_refs() { + [ "$SEP" = "." ] && return 0 + local sed_script="" name esc + for name in "${canonical_skills[@]}"; do + esc="${name//./\\.}" + sed_script="${sed_script}s/${esc}/$(to_local "$name")/g;" + done + find "$@" -type f -name '*.md' | while IFS= read -r f; do + sed -i.mikobak "$sed_script" "$f" && rm -f "$f.mikobak" + done +} + if [ "$LANG_CHOICE" = "en" ]; then echo "⛩️ Installing miko skills..." else @@ -43,7 +81,7 @@ curl -fsSL "https://github.com/$REPO/archive/refs/heads/$BRANCH.tar.gz" | tar -x mkdir -p "$SKILLS_DIR" # 既存インストールの確認（VERSION ファイルまたは miko スキルが1つでもあれば既存とみなす） -if [ -f ".miko/VERSION" ] || ls -d "$SKILLS_DIR"/miko.* &> /dev/null; then +if [ -f ".miko/VERSION" ] || ls -d "$SKILLS_DIR"/miko.* &> /dev/null || ls -d "$SKILLS_DIR"/miko-* &> /dev/null; then if [ "$LANG_CHOICE" = "en" ]; then echo "⛩️ miko is already installed. Please use upgrade.sh to update:" else @@ -55,28 +93,45 @@ if [ -f ".miko/VERSION" ] || ls -d "$SKILLS_DIR"/miko.* &> /dev/null; then exit 0 fi -cp -r "$tmpdir"/miko/skills/miko.* "$SKILLS_DIR/" +# 正規スキル名（. 区切り）の一覧を収集し、選択された区切り文字の名前で配置する +canonical_skills=() +for d in "$tmpdir"/miko/skills/miko.*/; do + canonical_skills+=("$(basename "$d")") +done +for s in "${canonical_skills[@]}"; do + cp -r "$tmpdir/miko/skills/$s" "$SKILLS_DIR/$(to_local "$s")" +done cp -r "$tmpdir"/miko/ofuda .miko -# 言語設定の保存と tone_guide の解決 +# 言語・区切り文字設定の保存と tone_guide の解決 # リポジトリには tone_guide.md (ja) と tone_guide.en.md があり、 # 選択された言語のものを .miko/guides/tone_guide.md として配置する -echo "language=$LANG_CHOICE" > .miko/config +{ + echo "language=$LANG_CHOICE" + if [ "$SEP" = "." ]; then + echo "separator=dot" + else + echo "separator=hyphen" + fi +} > .miko/config if [ "$LANG_CHOICE" = "en" ]; then cp .miko/guides/tone_guide.en.md .miko/guides/tone_guide.md fi rm -f .miko/guides/tone_guide.en.md +# ハイフン区切りの場合、配置済みファイル内のスキル名参照を書き換える +rewrite_skill_refs .miko "$SKILLS_DIR"/miko"$SEP"* + if [ ! -f ".miko/protected_skills" ]; then -cat > .miko/protected_skills << 'EOF' +cat > .miko/protected_skills << EOF # miko アップグレード時に削除・上書きされないスキルを1行ずつ指定します。 -# miko.* という名前でご自身のカスタムスキルを作成している場合に使用してください。 +# miko${SEP}* という名前でご自身のカスタムスキルを作成している場合に使用してください。 # (Skills listed here, one per line, are preserved across miko upgrades. -# Use this if you have created custom skills named miko.*.) +# Use this if you have created custom skills named miko${SEP}*.) # # 例 / Example: -# miko.my-custom-skill -# miko.another-skill +# miko${SEP}my-custom-skill +# miko${SEP}another-skill EOF fi @@ -85,12 +140,12 @@ if [ "$LANG_CHOICE" = "en" ]; then else echo "✨ miko スキルをお納めいたしました: $SKILLS_DIR/" fi -ls -1d "$SKILLS_DIR"/miko.* .miko 2>/dev/null | while read -r d; do +ls -1d "$SKILLS_DIR"/miko"$SEP"* .miko 2>/dev/null | while read -r d; do echo " - $(basename "$d")" done echo "" if [ "$LANG_CHOICE" = "en" ]; then - echo "⛩️ Start with /miko.setup to set up your project. If in doubt, ask /miko.miko." + echo "⛩️ Start with /miko${SEP}setup to set up your project. If in doubt, ask /miko${SEP}miko." else - echo "⛩️ まずは /miko.setup でプロジェクトのセットアップを。迷ったら /miko.miko にお聞きくださいませ。" + echo "⛩️ まずは /miko${SEP}setup でプロジェクトのセットアップを。迷ったら /miko${SEP}miko にお聞きくださいませ。" fi diff --git a/ofuda/VERSION b/ofuda/VERSION index 9b99c29..3c7c92e 100644 --- a/ofuda/VERSION +++ b/ofuda/VERSION @@ -1,2 +1,2 @@ -1.3.2 -202606261418 +1.4.0 +202607170733 diff --git a/ofuda/examples/system_high_level_design.md b/ofuda/examples/system_high_level_design.md index bdf1beb..18f72ca 100644 --- a/ofuda/examples/system_high_level_design.md +++ b/ofuda/examples/system_high_level_design.md @@ -31,7 +31,7 @@ ## コード探索ガイド -> miko のスキル（catchup、new_cap、propose）がコードを探索・精読する際の手引き。 +> miko のスキル（catchup、new-cap、propose）がコードを探索・精読する際の手引き。 > プロジェクト固有のフレームワーク・構造・慣習をここに記述する。 ### フレームワーク・言語 diff --git a/ofuda/guides/business_rules_guide.md b/ofuda/guides/business_rules_guide.md index 20e0aab..226f2f4 100644 --- a/ofuda/guides/business_rules_guide.md +++ b/ofuda/guides/business_rules_guide.md @@ -46,10 +46,10 @@ ### 新規ケイパビリティの場合 ``` -/miko.new_cap +/miko.new-cap → 対話しながら business_rules.md + high_level_design.md を作成 -/miko.new_harae +/miko.new-harae → 初回の攻撃的検証。harae.md を生成（推奨） → 指摘を修正したら /miko.harae で再検証をお勧めする @@ -67,7 +67,7 @@ → proposal 適用後のルール体系を攻撃的に検証。指摘は proposal 内に記録される 3. 実装する - 基本: /miko.quick_impl + 基本: /miko.quick-impl → speckit を通さず直接実装（単一の意図・既存構造の範囲内の変更が対象） 重い変更（複数の意図が絡む、影響範囲の見極めに探索が要る、処理構造が大きく動く）は speckit フロー: @@ -81,14 +81,14 @@ → harae.md を更新（proposal の「祓え検証」セクションがあれば適用） ``` -**フェーズ分割:** 変更が大きい場合、`/miko.split_proposal` でプロポーザルを親（umbrella）+ サブにフェーズ分割できる。 +**フェーズ分割:** 変更が大きい場合、`/miko.split-proposal` でプロポーザルを親（umbrella）+ サブにフェーズ分割できる。 ### ドキュメントの流れ ``` proposal（人が元ネタを出し、AI と相談しながら書く） ↓ -実装（基本は quick_impl で直接実装。重い変更は speckit が使い捨て仕様を作って実装） +実装（基本は quick-impl で直接実装。重い変更は speckit が使い捨て仕様を作って実装） ↓ business_rules.md（AI が更新：ドメインの判断基準） high_level_design.md（AI が更新：構造の変化） diff --git a/ofuda/guides/tone_guide.en.md b/ofuda/guides/tone_guide.en.md index e79a44b..a1f4271 100644 --- a/ofuda/guides/tone_guide.en.md +++ b/ofuda/guides/tone_guide.en.md @@ -28,6 +28,19 @@ Keep the following as-is, regardless of language: --- +## Skill Name Notation + +Note: this section is not about tone — it lives here for convenience, because every skill is required to read this guide. + +The separator in miko skill names is decided at install time: dot (`/miko.xxx`) or hyphen (`/miko-xxx`). The original SKILL.md files and guides are written with dots and converted to the chosen separator at install time. Whenever you mention a skill name in your output, follow the `separator` value in `.miko/config`, not the notation in the source text: + +- `separator=dot` → write skill names with dots +- `separator=hyphen` → write skill names with hyphens + +If the config cannot be read or has no `separator` entry, default to dots. + +--- + ## Emoji Use in section headings and status displays. Never inside body text. diff --git a/ofuda/guides/tone_guide.md b/ofuda/guides/tone_guide.md index 7ca0801..9e4c304 100644 --- a/ofuda/guides/tone_guide.md +++ b/ofuda/guides/tone_guide.md @@ -23,6 +23,19 @@ miko のすべての出力は **日本語** で行う。対話テキストだけ --- +## スキル名の表記 + +※ このセクションはトーン（口調）のルールではないが、全スキルが必ず読む指示書であるため、便宜上ここに置いている。 + +miko のスキル名の区切り文字は、インストール時の選択によりドット（`/miko.xxx`）またはハイフン（`/miko-xxx`）になる。SKILL.md やガイドの原文はドット区切りで書かれており、インストール時に選択した区切り文字へ変換される。出力でスキル名に言及するときは、原文の表記ではなく `.miko/config` の `separator` の値に従うこと: + +- `separator=dot` → ドット区切りで表記する +- `separator=hyphen` → ハイフン区切りで表記する + +config が読めない場合や `separator` の設定がない場合は、デフォルトのドット区切りで表記する。 + +--- + ## 絵文字 セクション見出しと状態表示に使う。本文中には使わない。 diff --git a/skills/miko.catchup_system_hld/SKILL.md b/skills/miko.catchup-system-hld/SKILL.md similarity index 100% rename from skills/miko.catchup_system_hld/SKILL.md rename to skills/miko.catchup-system-hld/SKILL.md diff --git a/skills/miko.catchup/SKILL.md b/skills/miko.catchup/SKILL.md index ab0f369..a11ef73 100644 --- a/skills/miko.catchup/SKILL.md +++ b/skills/miko.catchup/SKILL.md @@ -22,18 +22,18 @@ $ARGUMENTS ユーザーに確認する: -> ⛩️ キャッチアップの前に確認でございます。`/miko.catchup_system_hld` は実施済みでしょうか？ +> ⛩️ キャッチアップの前に確認でございます。`/miko.catchup-system-hld` は実施済みでしょうか？ > `system_high_level_design.md` が古いままですと、コード探索のスコープがずれる恐れがございます。 - ユーザーが「実施済み」「不要」等と回答した場合 → 次に進む -- ユーザーが「まだ」「やってほしい」等と回答した場合 → `/miko.catchup_system_hld` の実行を案内し、完了後に `/miko.catchup` を再実行するよう伝えて中止する +- ユーザーが「まだ」「やってほしい」等と回答した場合 → `/miko.catchup-system-hld` の実行を案内し、完了後に `/miko.catchup` を再実行するよう伝えて中止する ### 3. 既存ファイル確認 - `miko//business_rules.md` が存在するか確認する - **存在しない場合はエラーとして中止する:** > ⛩️ `miko//business_rules.md` が見つかりません。 - > - 新規作成は `/miko.new_cap ` をお使いください + > - 新規作成は `/miko.new-cap ` をお使いください - 存在する場合: - 「🌿 既存の business_rules.md を読み込み、コードとの差分をキャッチアップいたします。」 diff --git a/skills/miko.harae/SKILL.md b/skills/miko.harae/SKILL.md index 7b521c3..d5b815c 100644 --- a/skills/miko.harae/SKILL.md +++ b/skills/miko.harae/SKILL.md @@ -17,7 +17,7 @@ $ARGUMENTS **`miko//harae.md` が存在しない場合はエラー:** > ⛩️ `miko//harae.md` が見つかりません。 -> まず `/miko.new_harae ` で初回検証を行ってください。 +> まず `/miko.new-harae ` で初回検証を行ってください。 **proposal が指定されていない場合:** @@ -38,7 +38,7 @@ $ARGUMENTS **成果物:** - proposal なしの場合: `miko//harae.md` を更新する -- proposal 付きの場合: **proposal ファイル内に「祓え検証」セクションを追記する。harae.md は更新しない。** proposal はまだ確定していないため、harae.md への永続化は実装完了時（miko.speckit.implement / miko.quick_impl）に行う +- proposal 付きの場合: **proposal ファイル内に「祓え検証」セクションを追記する。harae.md は更新しない。** proposal はまだ確定していないため、harae.md への永続化は実装完了時（miko.speckit.implement / miko.quick-impl）に行う **検証の6軸:** `.miko/guides/harae_guide.md` に定義された6軸（内部矛盾・不完全性・境界の曖昧さ・時間軸の破綻・ビジネス毀損・悪用耐性）で検証する。proposal 付きの場合は6軸に加えて「既存への影響（proposal の変更で既存の本番エンティティが意図せず壊れないか）」も検証する。 @@ -117,7 +117,7 @@ proposal が指定されていない場合。メインセッションで棚卸 proposal が指定されている場合。proposal を仮想適用した BR を検証し、**指摘は proposal に追記する。harae.md は更新しない。** -proposal はまだ確定していないため、harae.md への永続化は実装完了時に行う（miko.speckit.implement / miko.quick_impl のデザインドキュメント更新ステップで harae.md に転記される）。 +proposal はまだ確定していないため、harae.md への永続化は実装完了時に行う（miko.speckit.implement / miko.quick-impl のデザインドキュメント更新ステップで harae.md に転記される）。 ### 1. 資料の読み込み @@ -179,7 +179,7 @@ proposal の変更が既存の本番エンティティを意図せず壊さな ### 4. proposal に祓え検証セクションを追記 -対話の結果を反映し、proposal ファイルの末尾に「祓え検証」セクションとして追記する。このセクションは **harae.md に対する差分操作** を記述するもので、実装完了時（miko.speckit.implement / miko.quick_impl）に harae.md へ適用される。 +対話の結果を反映し、proposal ファイルの末尾に「祓え検証」セクションとして追記する。このセクションは **harae.md に対する差分操作** を記述するもので、実装完了時（miko.speckit.implement / miko.quick-impl）に harae.md へ適用される。 **フォーマット:** `.miko/examples/proposal.md` の「祓え検証」セクションに従う。注意点: - 「既存指摘のステータス変更」は該当がなければ省略する diff --git a/skills/miko.miko/SKILL.md b/skills/miko.miko/SKILL.md index ba95b14..e2d7c43 100644 --- a/skills/miko.miko/SKILL.md +++ b/skills/miko.miko/SKILL.md @@ -71,12 +71,12 @@ miko に関するあらゆるご質問にお答えする。 1. **プロジェクトに miko を初めて導入する** → `/miko.setup` をご案内 - - セットアップ後にコードベースが変わった場合は `/miko.catchup_system_hld` で追従 + - セットアップ後にコードベースが変わった場合は `/miko.catchup-system-hld` で追従 2. **新しいケイパビリティを定義したい** - → `/miko.new_cap ` をご案内 - - `new_cap` は BR/HLD を作成するまで。実装はしない - - 定義後は `/miko.new_harae ` で初回検証をお勧めする + → `/miko.new-cap ` をご案内 + - `new-cap` は BR/HLD を作成するまで。実装はしない + - 定義後は `/miko.new-harae ` で初回検証をお勧めする - 指摘を修正したら `/miko.harae ` で再検証をお勧めする - 実装に進むには、まず `/miko.propose` で proposal を作成してから @@ -86,28 +86,28 @@ miko に関するあらゆるご質問にお答えする。 - まず `/miko.propose` で proposal をお作りする（実装の前には必ず proposal が必要） - **検証フェーズ**（harae でルール体系を攻撃的に確かめる）: - proposal ができたら `/miko.harae ` でルール検証をお勧めする（指摘は proposal 内に記録される） - - 変更が大きい場合や他ケイパビリティへの横断影響がある場合は `/miko.split_proposal` で親（umbrella）+ サブにフェーズ分割できる（harae の後に実施。横断影響がある場合は影響先ケイパビリティにサブ proposal が作られる。DB マイグレーションや環境変更の分離にも有効） + - 変更が大きい場合や他ケイパビリティへの横断影響がある場合は `/miko.split-proposal` で親（umbrella）+ サブにフェーズ分割できる（harae の後に実施。横断影響がある場合は影響先ケイパビリティにサブ proposal が作られる。DB マイグレーションや環境変更の分離にも有効） - **実装フェーズ**（proposal に基づいて実装する。分割した場合は各サブ proposal に対して実行）: - - 基本は `/miko.quick_impl` をお勧め（speckit を通さず直接実装） + - 基本は `/miko.quick-impl` をお勧め（speckit を通さず直接実装） - 重い変更（複数の意図が絡む、影響範囲の見極めに探索が要る、処理構造が大きく動く）→ フルフロー（`/miko.speckit.specify` から）をお勧め - 判断がつかない → まず proposal で整理し、規模を見てからご案内 - 実装完了時に business_rules.md + high_level_design.md + harae.md が自動更新される 4. **コードは書いたがドキュメントが追いついていない** - - まず `/miko.catchup_system_hld` で system_high_level_design.md の追従を確認 - - 特定の変更（PR、ブランチ）だけ → `/miko.quick_catchup [diff]` + - まず `/miko.catchup-system-hld` で system_high_level_design.md の追従を確認 + - 特定の変更（PR、ブランチ）だけ → `/miko.quick-catchup [diff]` - 全体的に古くなっている → `/miko.catchup ` 4-2. **proposal を通さないリファクタリングをしたい（リネーム・移動・責務の再配置等）** - - `/miko.quick_impl <変更指示>` をご案内（proposal は不要） + - `/miko.quick-impl <変更指示>` をご案内（proposal は不要） - 実装後に影響する実装マッピングを全ケイパビリティ横断で自動更新 - BR 本文の変更が必要と判定された場合は `/miko.propose` に誘導される - スコープ（意図の単一性・影響範囲の明瞭さ・機械性 or 局所性）を超える場合はフルフローに誘導される 5. **propose は済んでいて、実装フェーズに進みたい** - harae が未実施で重要な変更 → `/miko.harae ` で検証してから実装フェーズへ - - 変更が大きい、または横断影響がある → `/miko.split_proposal` で分割してから各サブ proposal に対して実装 - - 基本 → `/miko.quick_impl` で直接 + - 変更が大きい、または横断影響がある → `/miko.split-proposal` で分割してから各サブ proposal に対して実装 + - 基本 → `/miko.quick-impl` で直接 - 重い変更 → フルフロー（`/miko.speckit.specify` から） - いずれも実装完了時に harae.md への転記を含むドキュメント更新が自動で行われる @@ -123,7 +123,7 @@ miko に関するあらゆるご質問にお答えする。 - BR の変更は直接編集ではなく、必ず `/miko.propose` でプロポーザルを作成してから行う - 対話の中で「このルールが足りない」「このルールは実態と違う」と判明した場合も同様 - 例: 「BR をチェックして → 不足を発見 → `/miko.propose` で変更提案を作りましょう」 - - 実装も必要なら、proposal 作成後にパターン3の実装フェーズ（基本は quick_impl、重い変更は speckit フロー）に進む + - 実装も必要なら、proposal 作成後にパターン3の実装フェーズ（基本は quick-impl、重い変更は speckit フロー）に進む --- @@ -202,7 +202,7 @@ miko の実装フローでは **constitution**（`.specify/memory/constitution.m **対話の中で BR の不足・誤り・変更の必要性が判明した場合、直接 BR を編集する提案をしてはいけない。** 必ず `/miko.propose` でプロポーザルを作成するフローに誘導する。 -これは BR チェックの依頼に限らない。どのような入力・対話であっても、結果として「BR を変えるべき」と判明したら `/miko.propose` → 必要に応じて実装フロー（基本は `/miko.quick_impl`、重い変更は `/miko.speckit.specify` → `/miko.speckit.plan` → ...）の順で進める。 +これは BR チェックの依頼に限らない。どのような入力・対話であっても、結果として「BR を変えるべき」と判明したら `/miko.propose` → 必要に応じて実装フロー（基本は `/miko.quick-impl`、重い変更は `/miko.speckit.specify` → `/miko.speckit.plan` → ...）の順で進める。 **悪い例:** > 「このルールが BR に不足しています。追加いたしましょうか？」 diff --git a/skills/miko.new_cap/SKILL.md b/skills/miko.new-cap/SKILL.md similarity index 98% rename from skills/miko.new_cap/SKILL.md rename to skills/miko.new-cap/SKILL.md index 313deb8..4e7888e 100644 --- a/skills/miko.new_cap/SKILL.md +++ b/skills/miko.new-cap/SKILL.md @@ -10,9 +10,9 @@ $ARGUMENTS 入力の形式: ` <概要（自由記述、省略可）>` -- 例: `/miko.new_cap order_management 注文の作成・決済・キャンセルを管理する` -- 例: `/miko.new_cap notification` -- 空の場合はエラー: 「⛩️ ケイパビリティ名をお願いいたします（例: `/miko.new_cap order_management 注文管理`）」 +- 例: `/miko.new-cap order_management 注文の作成・決済・キャンセルを管理する` +- 例: `/miko.new-cap notification` +- 空の場合はエラー: 「⛩️ ケイパビリティ名をお願いいたします（例: `/miko.new-cap order_management 注文管理`）」 --- @@ -28,7 +28,7 @@ $ARGUMENTS **catchup との違い:** -| 観点 | miko.new_cap | miko.catchup | +| 観点 | miko.new-cap | miko.catchup | |------|-----------|---------------| | 用途 | 新規作成 | 既存ドキュメントの更新 | | 前提 | ドキュメントがまだない | ドキュメントが既にある | @@ -249,4 +249,4 @@ HLD の骨子（`.miko/examples/high_level_design.md` と同等の構造）を ### 12. 完了報告 -生成したファイル、ルール総数（制約/導出の内訳、実装済み/未実装）、暗黙のルール数、未決事項数をサマリーテーブルで提示する。次のアクションとして `/miko.new_harae` によるルール検証をお勧めする。 +生成したファイル、ルール総数（制約/導出の内訳、実装済み/未実装）、暗黙のルール数、未決事項数をサマリーテーブルで提示する。次のアクションとして `/miko.new-harae` によるルール検証をお勧めする。 diff --git a/skills/miko.new_harae/SKILL.md b/skills/miko.new-harae/SKILL.md similarity index 92% rename from skills/miko.new_harae/SKILL.md rename to skills/miko.new-harae/SKILL.md index e5f9a0d..a75ca15 100644 --- a/skills/miko.new_harae/SKILL.md +++ b/skills/miko.new-harae/SKILL.md @@ -10,8 +10,8 @@ $ARGUMENTS 入力の形式: `` -- 例: `/miko.new_harae order_management` -- 空の場合はエラー: 「⛩️ ケイパビリティ名をお願いいたします（例: `/miko.new_harae order_management`）」 +- 例: `/miko.new-harae order_management` +- 空の場合はエラー: 「⛩️ ケイパビリティ名をお願いいたします（例: `/miko.new-harae order_management`）」 **`miko//harae.md` が既に存在する場合はエラー:** @@ -31,13 +31,13 @@ $ARGUMENTS **検証の6軸:** `.miko/guides/harae_guide.md` に定義された6軸（内部矛盾・不完全性・境界の曖昧さ・時間軸の破綻・ビジネス毀損・悪用耐性）で検証する。 **使用タイミング:** -- `/miko.new_cap` 後 — 定義したルールの初回検証 +- `/miko.new-cap` 後 — 定義したルールの初回検証 **フローでの位置づけ:** ``` -/miko.new_cap → ルール定義 -/miko.new_harae → ルールの弱点を探す（初回） +/miko.new-cap → ルール定義 +/miko.new-harae → ルールの弱点を探す（初回） /miko.harae → 既存の harae.md を棚卸し・差分探索（2回目以降） ``` @@ -55,7 +55,7 @@ $ARGUMENTS - `.miko/guides/harae_format_guide.md` — harae.md のフォーマットとステータス管理ルール - `miko//business_rules.md` — **存在しない場合はエラー:** > ⛩️ `miko//business_rules.md` が見つかりません。 - > まず `/miko.new_cap ` でケイパビリティを定義してください。 + > まず `/miko.new-cap ` でケイパビリティを定義してください。 - `miko//high_level_design.md` — あれば - `miko/glossary.md` — あれば diff --git a/skills/miko.propose/SKILL.md b/skills/miko.propose/SKILL.md index bfebbef..0ddc6f1 100644 --- a/skills/miko.propose/SKILL.md +++ b/skills/miko.propose/SKILL.md @@ -23,7 +23,7 @@ $ARGUMENTS **プロポーザルとは:** ケイパビリティに対する変更提案。ビジネスルールの変更だけでなく、機能仕様・影響範囲・代替案を含む。実装後に「ビジネスルールの変更」セクションだけが business_rules.md に反映される。 -**⚠️ 絶対禁止:** このスキルは `business_rules.md` を **読み取り専用** として扱う。propose が直接 business_rules.md を編集・上書きしてはならない。BR への変更はすべてプロポーザルファイルの「ビジネスルールの変更」セクションに記述し、実装スキル（implement / quick_impl）が反映する。 +**⚠️ 絶対禁止:** このスキルは `business_rules.md` を **読み取り専用** として扱う。propose が直接 business_rules.md を編集・上書きしてはならない。BR への変更はすべてプロポーザルファイルの「ビジネスルールの変更」セクションに記述し、実装スキル（implement / quick-impl）が反映する。 **対話のスタイル:** 機械的な質問リストではなく、自然な会話で進める。ただし確認ポイントは明確に設ける。 @@ -56,7 +56,7 @@ $ARGUMENTS > ⛩️ `miko//business_rules.md` が見つかりません。 > このスキルは既存の business_rules.md への変更提案を作成いたします。 > `- 既存コードがある場合: まず /miko.catchup で business_rules.md を生成してください` - > `- 新規ケイパビリティの場合: /miko.new_cap で初期ルールを定義してください` + > `- 新規ケイパビリティの場合: /miko.new-cap で初期ルールを定義してください` - `miko//high_level_design.md` — 現在の構造（なければスキップ） ### 3. 元ネタのヒアリング @@ -201,7 +201,7 @@ business_rules.md が存在するケイパビリティを対象に、サブエ ### 11. 完了報告 -ケイパビリティ名、proposal パス、ルール変更件数（新設/改訂/廃止）、代替案数をサマリーテーブルで提示する。次のアクションとして `/miko.harae` によるルール検証と、実装フロー（quick_impl or フルフロー）をご案内する。以下の場合は `/miko.split_proposal` によるフェーズ分割もご案内する: +ケイパビリティ名、proposal パス、ルール変更件数（新設/改訂/廃止）、代替案数をサマリーテーブルで提示する。次のアクションとして `/miko.harae` によるルール検証と、実装フロー（quick-impl or フルフロー）をご案内する。以下の場合は `/miko.split-proposal` によるフェーズ分割もご案内する: - プロポーザルの規模が大きい場合 - DB マイグレーションや環境変数の追加など、インフラ・環境の変更を含む場合 -- **`` マーカーを付与した場合（横断プロポーザル）** — `/miko.split_proposal` で影響先ケイパビリティへの影響先サブプロポーザルが作成される旨を案内する +- **`` マーカーを付与した場合（横断プロポーザル）** — `/miko.split-proposal` で影響先ケイパビリティへの影響先サブプロポーザルが作成される旨を案内する diff --git a/skills/miko.quick_catchup/SKILL.md b/skills/miko.quick-catchup/SKILL.md similarity index 92% rename from skills/miko.quick_catchup/SKILL.md rename to skills/miko.quick-catchup/SKILL.md index a6ade1b..afeea7a 100644 --- a/skills/miko.quick_catchup/SKILL.md +++ b/skills/miko.quick-catchup/SKILL.md @@ -10,10 +10,10 @@ $ARGUMENTS 入力の形式: ` [diff_source]` -- 例: `/miko.quick_catchup order_management` — カレントブランチのベースブランチからの diff を使用 -- 例: `/miko.quick_catchup order_management #8250` — PR の diff を使用 -- 例: `/miko.quick_catchup order_management HEAD~3..HEAD` — git range を使用 -- 空の場合はエラー: 「⛩️ ケイパビリティ名をお願いいたします（例: `/miko.quick_catchup order_management`）」 +- 例: `/miko.quick-catchup order_management` — カレントブランチのベースブランチからの diff を使用 +- 例: `/miko.quick-catchup order_management #8250` — PR の diff を使用 +- 例: `/miko.quick-catchup order_management HEAD~3..HEAD` — git range を使用 +- 空の場合はエラー: 「⛩️ ケイパビリティ名をお願いいたします（例: `/miko.quick-catchup order_management`）」 --- @@ -36,11 +36,11 @@ miko フローを通さずに入ったコード変更（緊急 FIX 等）を、 ユーザーに確認する: -> ⛩️ キャッチアップの前に確認でございます。`/miko.catchup_system_hld` は実施済みでしょうか？ +> ⛩️ キャッチアップの前に確認でございます。`/miko.catchup-system-hld` は実施済みでしょうか？ > `system_high_level_design.md` が古いままですと、コード探索のスコープがずれる恐れがございます。 - ユーザーが「実施済み」「不要」等と回答した場合 → 次に進む -- ユーザーが「まだ」「やってほしい」等と回答した場合 → `/miko.catchup_system_hld` の実行を案内し、完了後に `/miko.quick_catchup` を再実行するよう伝えて中止する +- ユーザーが「まだ」「やってほしい」等と回答した場合 → `/miko.catchup-system-hld` の実行を案内し、完了後に `/miko.quick-catchup` を再実行するよう伝えて中止する ### 2. 入力検証・資料読み込み @@ -57,7 +57,7 @@ miko フローを通さずに入ったコード変更（緊急 FIX 等）を、 - `miko/system_high_level_design.md` — コード探索ガイド（着目点の参照） - `miko//business_rules.md` — 現在のビジネスルール。**存在しない場合はエラー:** > ⛩️ `miko//business_rules.md` が見つかりません。 - > - 新規作成は `/miko.new_cap ` をお使いください + > - 新規作成は `/miko.new-cap ` をお使いください - `miko//high_level_design.md` — 現在の構造（あれば） **探索対象外:** `.miko/` ディレクトリは miko の内部リソースであり、プロジェクトのコードではない。探索・精読の対象にしないこと。 @@ -103,7 +103,7 @@ diff ソース、変更の要約、ビジネスルールへの影響（新設/ **ファイル名:** `miko//proposals/YYYY-MM-DD-.md` -**構造:** `.miko/examples/proposal.md` に準ずる。quick_catchup 固有の違い: +**構造:** `.miko/examples/proposal.md` に準ずる。quick-catchup 固有の違い: - 冒頭に「このプロポーザルはコード変更から事後的に作成されたものです。」と付記 - 影響範囲に diff ソースと変更ファイル一覧を記載する diff --git a/skills/miko.quick_impl/SKILL.md b/skills/miko.quick-impl/SKILL.md similarity index 98% rename from skills/miko.quick_impl/SKILL.md rename to skills/miko.quick-impl/SKILL.md index f010522..2738f83 100644 --- a/skills/miko.quick_impl/SKILL.md +++ b/skills/miko.quick-impl/SKILL.md @@ -10,9 +10,9 @@ $ARGUMENTS 入力の形式: 以下のいずれか -- proposal のパス（例: `/miko.quick_impl miko/order_management/proposals/2026-03-01-fix-trial-grace-period.md`） -- 変更指示の自由記述（例: `/miko.quick_impl OrderService を OrderFacade にリネーム`） -- 空の場合はエラー: 「⛩️ proposal のパスまたは変更指示をお願いいたします（例: `/miko.quick_impl miko/order_management/proposals/2026-03-01-fix-trial-grace-period.md`）」 +- proposal のパス（例: `/miko.quick-impl miko/order_management/proposals/2026-03-01-fix-trial-grace-period.md`） +- 変更指示の自由記述（例: `/miko.quick-impl OrderService を OrderFacade にリネーム`） +- 空の場合はエラー: 「⛩️ proposal のパスまたは変更指示をお願いいたします（例: `/miko.quick-impl miko/order_management/proposals/2026-03-01-fix-trial-grace-period.md`）」 --- @@ -47,7 +47,7 @@ miko の原則として BR ルール本文の変更には proposal が必要。p > ⛩️ 親プロポーザルは直接実装できません。サブプロポーザルを指定してください。 - 未分割プロポーザルの検出 — 先頭に `` マーカーがある場合、エラーとして中止する: > ⛩️ このプロポーザルは分割が必要です。 - > まず `/miko.split_proposal` でフェーズ分割してから、サブプロポーザルを指定してください。 + > まず `/miko.split-proposal` でフェーズ分割してから、サブプロポーザルを指定してください。 ### 2. 資料読み込み diff --git a/skills/miko.setup/SKILL.md b/skills/miko.setup/SKILL.md index 6fec48e..073115d 100644 --- a/skills/miko.setup/SKILL.md +++ b/skills/miko.setup/SKILL.md @@ -19,7 +19,7 @@ $ARGUMENTS miko を新しいプロジェクトに導入するための初期セットアップ。プロジェクトのコードベースを調査し、`miko/system_high_level_design.md` を生成する。 -このファイルは miko の全スキル（catchup、new_cap、propose 等）がコード探索・精読の際に参照する **コード探索ガイド** を含む。プロジェクト固有のフレームワーク・ディレクトリ構成・命名規約・ビジネスルール抽出パターンを記述することで、スキル側にフレームワーク依存の知識を持たせずに済む。 +このファイルは miko の全スキル（catchup、new-cap、propose 等）がコード探索・精読の際に参照する **コード探索ガイド** を含む。プロジェクト固有のフレームワーク・ディレクトリ構成・命名規約・ビジネスルール抽出パターンを記述することで、スキル側にフレームワーク依存の知識を持たせずに済む。 **出力:** `miko/system_high_level_design.md` @@ -106,7 +106,7 @@ miko を新しいプロジェクトに導入するための初期セットアッ - **システム概要** — プロジェクトの概要。1〜2文 - **テナント構造** — テナントの単位とデータの隔離方式（シングルテナントの場合はその旨） - **API 構造** — エンドポイントのパターンと認証方式 -- **ケイパビリティ一覧** — 既存のケイパビリティ候補（空テーブルでもよい。今後 new_cap で追加される） +- **ケイパビリティ一覧** — 既存のケイパビリティ候補（空テーブルでもよい。今後 new-cap で追加される） - **コード探索ガイド** - フレームワーク・言語 - ディレクトリ構成 @@ -117,7 +117,7 @@ miko を新しいプロジェクトに導入するための初期セットアッ **生成時の注意:** - コード探索ガイドはこのプロジェクトで miko を使う全スキルの基盤。正確さと網羅性を重視する - 着目点の「例」列には、実際のプロジェクトのコードから取ったサンプルを記載する -- ケイパビリティ一覧は暫定。ユーザーが今後 `/miko.new_cap` で正式に定義していく +- ケイパビリティ一覧は暫定。ユーザーが今後 `/miko.new-cap` で正式に定義していく **`miko/glossary.md` の生成:** @@ -131,4 +131,4 @@ miko を新しいプロジェクトに導入するための初期セットアッ ### 6. 完了報告 -生成したファイル、検出したフレームワーク・レイヤー数・着目点数・ケイパビリティ候補数・用語数をサマリーテーブルで提示する。次のアクションとして `/miko.new_cap` をご案内する。 +生成したファイル、検出したフレームワーク・レイヤー数・着目点数・ケイパビリティ候補数・用語数をサマリーテーブルで提示する。次のアクションとして `/miko.new-cap` をご案内する。 diff --git a/skills/miko.speckit.specify/SKILL.md b/skills/miko.speckit.specify/SKILL.md index 346ee3c..ab4922f 100644 --- a/skills/miko.speckit.specify/SKILL.md +++ b/skills/miko.speckit.specify/SKILL.md @@ -60,7 +60,7 @@ Miko プロポーザルの「機能仕様」セクションを speckit の speci **未分割プロポーザルの検出:** - 選択されたプロポーザルの先頭に `` マーカーがある場合、エラーとして中止する: > ⛩️ このプロポーザルは分割が必要です。 - > まず `/miko.split_proposal` でフェーズ分割してから、サブプロポーザルを指定してください。 + > まず `/miko.split-proposal` でフェーズ分割してから、サブプロポーザルを指定してください。 ### 2. プロポーザルと既存資料の読み込み diff --git a/skills/miko.split_proposal/SKILL.md b/skills/miko.split-proposal/SKILL.md similarity index 95% rename from skills/miko.split_proposal/SKILL.md rename to skills/miko.split-proposal/SKILL.md index fd410a0..59c70b5 100644 --- a/skills/miko.split_proposal/SKILL.md +++ b/skills/miko.split-proposal/SKILL.md @@ -10,8 +10,8 @@ $ARGUMENTS 入力の形式: `` -- 例: `/miko.split_proposal miko/order_management/proposals/2026-03-18-cancel-notify.md` -- 空の場合はエラー: 「⛩️ プロポーザルのパスをお願いいたします（例: `/miko.split_proposal miko/order_management/proposals/2026-03-18-cancel-notify.md`）」 +- 例: `/miko.split-proposal miko/order_management/proposals/2026-03-18-cancel-notify.md` +- 空の場合はエラー: 「⛩️ プロポーザルのパスをお願いいたします（例: `/miko.split-proposal miko/order_management/proposals/2026-03-18-cancel-notify.md`）」 --- @@ -26,7 +26,7 @@ $ARGUMENTS ``` /miko.propose → proposal 作成 /miko.harae → proposal 検証（推奨） -/miko.split_proposal → 親 + サブに分割 +/miko.split-proposal → 親 + サブに分割 → 各サブに対して /miko.speckit.specify → 実装フロー ``` @@ -50,8 +50,8 @@ $ARGUMENTS **読み込むファイル:** - `.miko/guides/tone_guide.md` — 対話スタイル。**このファイルの口調・絵文字・出力言語ルールに従うこと** -- `.claude/skills/miko.split_proposal/examples/umbrella_proposal.md` — 親プロポーザルのサンプル -- `.claude/skills/miko.split_proposal/examples/cross_capability_sub_proposal.md` — 横断サブプロポーザルのサンプル（横断分割の場合） +- `.claude/skills/miko.split-proposal/examples/umbrella_proposal.md` — 親プロポーザルのサンプル +- `.claude/skills/miko.split-proposal/examples/cross_capability_sub_proposal.md` — 横断サブプロポーザルのサンプル（横断分割の場合） - 指定されたプロポーザルファイル - `miko/system_high_level_design.md` — ケイパビリティ一覧の確認（cross-cap 分割時に使用） - 横断分割の場合: 影響先ケイパビリティの `business_rules.md` と `high_level_design.md` も読み込む @@ -128,14 +128,14 @@ $ARGUMENTS - 内容は「他ケイパビリティへの影響」セクションの該当部分から抽出する - **背景**（親プロポーザルへの `miko/` からの相対パスリンク）と**ビジネスルールの変更**（新設/改訂/廃止）のみ。機能仕様・影響範囲は不要 - 祓え検証（元のプロポーザルに影響先ケイパビリティごとの祓え検証サブセクションがあれば、該当ケイパビリティ・該当フェーズ分を振り分け） -- **サンプル:** `.claude/skills/miko.split_proposal/examples/cross_capability_sub_proposal.md` を参照 +- **サンプル:** `.claude/skills/miko.split-proposal/examples/cross_capability_sub_proposal.md` を参照 **ファイル命名:** - 親: `YYYY-MM-DD--umbrella.md`（メインケイパビリティの proposals/ ディレクトリ） - メインサブ: `YYYY-MM-DD--phase.md`（親と同ディレクトリ） - 影響先サブ: `YYYY-MM-DD--phase.md`（影響先ケイパビリティの proposals/ ディレクトリ。メインサブと同じフェーズ番号） -**サンプル:** `.claude/skills/miko.split_proposal/examples/umbrella_proposal.md` を参照。 +**サンプル:** `.claude/skills/miko.split-proposal/examples/umbrella_proposal.md` を参照。 ### 5. 元プロポーザルの削除提案 @@ -152,4 +152,4 @@ $ARGUMENTS - 親プロポーザルのパス - サブプロポーザル一覧（フェーズ番号、ケイパビリティ、概要、パス、BR 変更件数） - **クロスケイパビリティの場合:** 各フェーズの `/miko.speckit.specify` に渡すサブプロポーザルのパスをまとめて表示する（例: `/miko.speckit.specify path/to/cap_A/phase1.md path/to/cap_B/phase1.md`） -- 次のアクションとして、各サブプロポーザルに対する `/miko.harae`（必要に応じて）と実装フロー（`/miko.speckit.specify` or `/miko.quick_impl`）をご案内する +- 次のアクションとして、各サブプロポーザルに対する `/miko.harae`（必要に応じて）と実装フロー（`/miko.speckit.specify` or `/miko.quick-impl`）をご案内する diff --git a/skills/miko.split_proposal/examples/cross_capability_sub_proposal.md b/skills/miko.split-proposal/examples/cross_capability_sub_proposal.md similarity index 100% rename from skills/miko.split_proposal/examples/cross_capability_sub_proposal.md rename to skills/miko.split-proposal/examples/cross_capability_sub_proposal.md diff --git a/skills/miko.split_proposal/examples/umbrella_proposal.md b/skills/miko.split-proposal/examples/umbrella_proposal.md similarity index 100% rename from skills/miko.split_proposal/examples/umbrella_proposal.md rename to skills/miko.split-proposal/examples/umbrella_proposal.md diff --git a/upgrade.sh b/upgrade.sh index ae93ff2..9dafefc 100755 --- a/upgrade.sh +++ b/upgrade.sh @@ -14,6 +14,29 @@ if [ -f ".miko/config" ]; then [ "$LANG_CHOICE" = "en" ] || LANG_CHOICE="ja" fi +# スキル名の区切り文字設定: .miko/config の separator (dot/hyphen) を読む。なければ dot +SEP="." +if [ -f ".miko/config" ]; then + sep_val=$(grep -E '^separator=' .miko/config | head -n 1 | cut -d= -f2 | tr -d '[:space:]' || true) + [ "$sep_val" = "hyphen" ] && SEP="-" +fi + +# to_local — 正規スキル名（. 区切り）を設定された区切り文字の名前に変換する +to_local() { echo "${1//./$SEP}"; } + +# rewrite_skill_refs ... — ファイル中のスキル名参照 (miko.foo) を設定された区切り文字に書き換える +rewrite_skill_refs() { + [ "$SEP" = "." ] && return 0 + local sed_script="" name esc + for name in "${latest_skills[@]}"; do + esc="${name//./\\.}" + sed_script="${sed_script}s/${esc}/$(to_local "$name")/g;" + done + find "$@" -type f -name '*.md' | while IFS= read -r f; do + sed -i.mikobak "$sed_script" "$f" && rm -f "$f.mikobak" + done +} + # say — 言語設定に応じたメッセージを出力する say() { if [ "$LANG_CHOICE" = "en" ]; then echo "$2"; else echo "$1"; fi @@ -32,7 +55,7 @@ if ! command -v claude &> /dev/null; then fi # miko がインストールされているか確認（VERSION ファイルまたは miko スキルの存在） -if [ ! -f "$VERSION_FILE" ] && [ ! -f "$OLD_VERSION_FILE" ] && ! ls -d "$SKILLS_DIR"/miko.* &> /dev/null; then +if [ ! -f "$VERSION_FILE" ] && [ ! -f "$OLD_VERSION_FILE" ] && ! ls -d "$SKILLS_DIR"/miko.* &> /dev/null && ! ls -d "$SKILLS_DIR"/miko-* &> /dev/null; then say "⛩️ miko がインストールされていません。install.sh で初回インストールをお願いいたします。" \ "⛩️ miko is not installed. Please run install.sh for the initial installation." exit 1 @@ -121,7 +144,7 @@ if [ -d "$SKILLS_DIR/_miko" ]; then rm -rf "$SKILLS_DIR/_miko" fi -# 最新版に存在する miko.* スキル名を収集 +# 最新版に存在する miko.* スキル名（正規名、. 区切り）を収集 latest_skills=() for d in "$tmpdir"/miko/skills/miko.*/; do [ -d "$d" ] || continue @@ -149,23 +172,26 @@ if [ ${#protected_skills[@]} -gt 0 ]; then fi # is_protected — protected_skills に含まれるか判定するヘルパー +# 空配列の展開は bash 3.2 の set -u でエラーになるため、先に件数を確認する is_protected() { local name="$1" + [ ${#protected_skills[@]} -eq 0 ] && return 1 for p in "${protected_skills[@]}"; do [ "$p" = "$name" ] && return 0 done return 1 } -# 最新版にない miko.* スキルのうち、プロテクト済みでないものを削除候補として収集 +# 最新版にないローカルの miko スキルのうち、プロテクト済みでないものを削除候補として収集 +# ローカルのスキル名は設定された区切り文字なので、正規名を to_local で変換して比較する removed_skills=() -for d in "$SKILLS_DIR"/miko.*/; do +for d in "$SKILLS_DIR"/miko"$SEP"*/; do [ -d "$d" ] || continue name=$(basename "$d") is_protected "$name" && continue found=false for s in "${latest_skills[@]}"; do - [ "$s" = "$name" ] && found=true && break + [ "$(to_local "$s")" = "$name" ] && found=true && break done [ "$found" = false ] && removed_skills+=("$name") done @@ -205,14 +231,16 @@ if [ ${#removed_skills[@]} -gt 0 ]; then fi # miko 管理スキルを個別に更新（プロテクト済みはスキップ） +# 配置先はローカル名（設定された区切り文字） for s in "${latest_skills[@]}"; do - if is_protected "$s"; then - say " 🔒 $s はプロテクト済みのためスキップいたします" \ - " 🔒 $s is protected — skipping" + local_name=$(to_local "$s") + if is_protected "$local_name"; then + say " 🔒 $local_name はプロテクト済みのためスキップいたします" \ + " 🔒 $local_name is protected — skipping" continue fi - rm -rf "${SKILLS_DIR:?}/$s" - cp -r "$tmpdir/miko/skills/$s" "$SKILLS_DIR/" + rm -rf "${SKILLS_DIR:?}/$local_name" + cp -r "$tmpdir/miko/skills/$s" "$SKILLS_DIR/$local_name" done # .miko/ を更新: ユーザー作成ファイル（protected_skills, config 等）を保持したまま上書き @@ -223,11 +251,31 @@ cp -r "$tmpdir/miko/ofuda/." .miko/ if [ ! -f ".miko/config" ]; then echo "language=$LANG_CHOICE" > .miko/config fi +# v1.4.0 より前のインストールには separator 設定がないため補完する（既存はドット区切り） +if ! grep -qE '^separator=' .miko/config; then + if [ "$SEP" = "." ]; then + echo "separator=dot" >> .miko/config + else + echo "separator=hyphen" >> .miko/config + fi +fi if [ "$LANG_CHOICE" = "en" ] && [ -f ".miko/guides/tone_guide.en.md" ]; then cp .miko/guides/tone_guide.en.md .miko/guides/tone_guide.md fi rm -f .miko/guides/tone_guide.en.md +# ハイフン区切りの場合、更新したファイル内のスキル名参照を書き換える +# プロテクト済みスキルはユーザー管理のため書き換えない +if [ "$SEP" != "." ]; then + rewrite_paths=(.miko) + for s in "${latest_skills[@]}"; do + local_name=$(to_local "$s") + is_protected "$local_name" && continue + rewrite_paths+=("$SKILLS_DIR/$local_name") + done + rewrite_skill_refs "${rewrite_paths[@]}" +fi + echo "" say "✨ miko を $latest_semver ($latest_ts) に更新いたしました" \ "✨ miko has been updated to $latest_semver ($latest_ts)"