@aramassa/ai-rules 0.1.1-npmjs.20250910072942

package/README-npmjs.md

@@ -0,0 +1,37 @@
+# @aramassa/ai-rules
+
+A CLI tool for extracting and combining markdown instruction files based on frontmatter filters.
+
+## Installation
+
+```bash
+npm install -g @aramassa/ai-rules
+```
+
+## Usage
+
+```bash
+# Extract instructions by type
+ai-rules extract --type coding --out coding-rules.md
+
+# Extract instructions by language
+ai-rules extract --language typescript --out typescript-rules.md
+
+# Use presets
+ai-rules extract --recipe :typescript --out typescript-instructions.md
+```
+
+## Available Commands
+
+- `extract` - Extract and combine markdown files based on filters
+- `stats` - Show statistics about instruction files
+- `presets` - List available presets
+
+For detailed usage information, run:
+```bash
+ai-rules --help
+```
+
+## License
+
+ISC

package/README.md

@@ -0,0 +1,37 @@
+# @aramassa/ai-rules
+
+A CLI tool for extracting and combining markdown instruction files based on frontmatter filters.
+
+## Installation
+
+```bash
+npm install -g @aramassa/ai-rules
+```
+
+## Usage
+
+```bash
+# Extract instructions by type
+ai-rules extract --type coding --out coding-rules.md
+
+# Extract instructions by language
+ai-rules extract --language typescript --out typescript-rules.md
+
+# Use presets
+ai-rules extract --recipe :typescript --out typescript-instructions.md
+```
+
+## Available Commands
+
+- `extract` - Extract and combine markdown files based on filters
+- `stats` - Show statistics about instruction files
+- `presets` - List available presets
+
+For detailed usage information, run:
+```bash
+ai-rules --help
+```
+
+## License
+
+ISC

package/artifact/chatmodes/Instruction Improve.md

@@ -0,0 +1,142 @@
+---
+description: "Chatmode for improving the project instructions through retrospective analysis.\nProvides structured approach to analyzing past tasks and converting insights into GitHub issues.\nIncludes comprehensive GitHub integration tools for issue and pull request management.\n"
+type: chatmode
+chatmode: instruction-improve
+tools: ["changes", "create_issue", "get_pull_request", "get_pull_request_comments", "get_pull_request_diff", "get_pull_request_files", "list_issues", "get_issue", "get_issue_comments", "search_issues", "update_issue", "add_issue_comment", "assign_copilot_to_issue"]
+---
+
+# Improve Instruction
+
+AIコーディングでより良い結果を得るために、以下の観点で instruction ファイル群を改善することを目的とします。
+今回行った内容をもう一度振り返り、Instruction の精度を向上させるための具体的な改善点を洗い出してください。
+
+## 実行ステップ
+
+1. 同様の内容の Issue が既に存在しないか確認する。OpenのものだけチェックすればOK。
+   - `list_issues` または `search_issues` ツールを使用して既存のIssueリストを確認・検索
+   - 既存の Issue がある場合は、重複を避けるために内容を調整または統合を検討
+2. 振り返りの結果をもとに、具体的な改善点をリストアップする。
+3. リストアップした改善点をもとに、修正計画を立てる（具体的な修正はIssue対応時に行うので、修正要件だけを書けばOK）。
+4. 修正計画を一度全部表示して、レビューを受ける。
+5. 修正計画を GitHub Issue として登録する。
+   - `create_issue` ツールを使用してIssueを作成
+   - 適切なラベルを設定（improvement, instruction, documentation等）
+
+## GitHub連携ワークフロー
+
+### 推奨フロー
+1. **Issue作成** → 2. **PR作成** → 3. **レビュー** → 4. **マージ**
+
+### AIエージェントによる自動化範囲
+
+#### 自動化可能な範囲
+- Issue リストの取得・作成・更新
+- Pull Request の詳細情報取得
+- コメントや差分、変更ファイルの取得・分析
+- 既存Issueリストとの重複チェック・検索
+- テンプレートに基づいたIssue本文の生成
+- Issue へのコメント追加やアサイン
+
+#### 人間の判断が必要な範囲
+- 最終的なIssue作成の承認
+- Pull Request のマージ判断
+- レビューの実施
+- 優先度や緊急度の最終判断
+- チーム方針との整合性確認
+
+### 運用ルール
+
+#### 命名規則
+- Issue タイトル: `[カテゴリ] 具体的な改善内容`
+- PR タイトル: `Fix #IssueNumber: 変更内容の要約`
+- ブランチ名: `improvement/issue-番号-簡潔な説明`
+
+#### ラベル付与ルール
+- `improvement`: 改善提案
+- `instruction`: instruction ファイルの修正
+- `documentation`: ドキュメント関連
+- `chatmode`: chatmode ファイルの修正
+- `high-priority`: 緊急度の高い改善
+- `breaking-change`: 既存の使用方法に影響する変更
+
+#### レビュー手順
+1. AIエージェントがIssue作成前に内容をレビュー依頼
+2. 人間がIssue内容を確認・承認
+3. PR作成時は変更内容の影響範囲を明記
+4. レビューでは既存のワークフローへの影響を重点確認
+
+## GitHub Issue への登録
+
+原則として、改善内容は GitHub Issue として登録してください。
+
+登録先リポジトリ: !{INSTRUCTION_GITHUB_REPO}
+
+### 利用可能なツール
+
+#### Issue関連
+- `list_issues`: Issueリストの取得
+- `search_issues`: 既存Issueの検索（重複チェック）
+- `get_issue`: 特定Issueの詳細情報取得
+- `get_issue_comments`: Issueコメントの取得
+- `create_issue`: 新規Issue作成
+- `update_issue`: 既存Issueの更新
+- `add_issue_comment`: Issueへのコメント追加
+- `assign_copilot_to_issue`: IssueへのCopilotアサイン
+
+#### Pull Request関連
+- `get_pull_request`: 特定PRの詳細情報取得
+- `get_pull_request_comments`: PRコメント取得
+- `get_pull_request_diff`: PRの差分取得
+- `get_pull_request_files`: PR内の変更ファイル取得
+
+#### その他
+- `changes`: 変更内容の取得
+
+### 記載例
+
+```
+# {タイトル}
+
+# {改善が必要な理由}
+
+## {現在の状況と問題点}
+
+## {改善案}
+
+# {改善内容の詳細}
+
+## {修正対象のファイル群とその内容}
+
+* {修正が必要な instruction ファイル名}
+  * {具体的な修正内容}
+* {修正が必要な instruction ファイル名}
+  * {具体的な修正内容}
+```
+
+### ツール使用例
+
+#### Issue作成前の重複チェック
+```
+list_issues(owner="{OWNER}", repo="{REPO}", state="open")
+```
+
+#### 既存Issue検索
+```
+search_issues("instruction improve OR chatmode improve", repo="{REPO}", owner="{OWNER}")
+```
+
+#### 既存Issue詳細の確認
+```
+get_issue(owner="{OWNER}", repo="{REPO}", issue_number={ISSUE_NUMBER})
+```
+
+#### 新規Issue作成
+```
+create_issue(
+  owner="{OWNER}", 
+  repo="{REPO}",
+  title="[Instruction] 改善内容のタイトル",
+  body="詳細な改善内容...",
+  labels=["improvement", "instruction"]
+)
+```

package/artifact/chatmodes/Planning.md

@@ -0,0 +1,173 @@
+---
+description: "Chatmode for supporting todo_plans creation with structured planning process.\nProvides phase-based guidance for requirement clarification, technical investigation, and implementation planning.\n"
+type: chatmode
+chatmode: planning
+tools: ["changes", "searchResults", "editFiles", "search", "add_issue_comment", "add_sub_issue", "create_issue", "get_code_scanning_alert", "get_discussion", "get_discussion_comments", "get_issue_comments", "get_pull_request", "get_pull_request_diff", "get_pull_request_files", "list_commits", "list_issues", "list_pull_requests", "search_code", "search_issues", "search_pull_requests", "search_repositories", "update_issue", "update_pull_request"]
+---
+
+# Planning Instructions
+
+todo_plans作成を段階的に支援し、一貫性のあるプランニングプロセスを実現します。
+
+## プランニングプロセス
+
+### Phase 1: 要件明確化
+
+まず、以下の項目を明確にしましょう：
+
+- **背景状況の整理**
+  - 現在直面している課題や問題点
+  - 改善したい機能や追加したい機能
+  - なぜこの改修が必要なのか
+
+- **解決したい課題の特定**
+  - 具体的に何を実現したいか
+  - どのような価値を提供するか
+  - 現状との違いを明確化
+
+- **成功条件の定義**
+  - 完成時にどのような状態になっているべきか
+  - 何をもって成功とするか
+  - 検証可能な基準の設定
+
+### Phase 2: 技術調査
+
+次に、技術面での調査を行います：
+
+- **既存コードベースの影響範囲分析**
+  - 関連するファイルやディレクトリの特定
+  - 既存機能への影響度評価
+  - 破壊的変更の可能性確認
+
+- **依存関係とパッケージ構造の確認**
+  - monorepoワークスペース内のパッケージ依存関係
+  - core/commonパッケージとの関係性
+  - ビルド・公開プロセスへの影響
+
+- **類似機能・パターンの調査**
+  - 既存のtodo_plans/change_plansから参考にできるパターン
+  - 同様の機能実装がある場合の参照
+  - ベストプラクティスの活用
+
+### Phase 3: 実装計画策定
+
+具体的な実装計画を立てます：
+
+- **改修対象ファイルの特定**
+  - 新規作成が必要なファイル
+  - 修正が必要な既存ファイル
+  - 影響を受ける可能性があるファイル
+
+- **実装順序の決定**
+  - 依存関係を考慮した実装順序
+  - 段階的リリースの可能性
+  - リスクを最小化する順序
+
+- **リスク評価と対策**
+  - 潜在的な問題点の洗い出し
+  - 対策・回避策の検討
+  - ロールバック計画の準備
+
+## プロジェクト固有ガイドライン
+
+### monorepoワークスペース考慮事項
+
+- **core/commonパッケージの依存ルール**
+  - coreパッケージに依存することは禁止
+  - commonパッケージに依存するのはOK
+  - パッケージ間の責務分離原則の遵守
+
+- **ビルド・公開プロセスへの影響評価**
+  - npm workspaceでの影響範囲確認
+  - rollupバンドル設定への影響
+  - dist/ディレクトリ生成への影響
+
+### 既存パターンの活用
+
+参考にできる既存のtodo_plansパターン：
+
+- **CLIオプション追加時**: `20250825_multiple_recipe_files_support.md`を参考
+- **リファクタリング時**: `20250714_refactor_improvements.md`を参考
+- **ビルドプロセス改善時**: `20250713_cli_rollup_publish.md`を参考
+
+## 品質確保チェックリスト
+
+todo_plans作成時に必ず確認する項目：
+
+- [ ] **skel/構造との整合性確認**
+  - スケルトンファイルの更新が必要か
+  - 構造変更がskel/と一致しているか
+
+- [ ] **skeleton-structure-validation.test.tsの実行**
+  - テスト実行で構造検証をパス
+  - 新しい構造変更のテスト追加
+
+- [ ] **関連ドキュメントの更新計画**
+  - docs/ディレクトリの更新が必要か
+  - READMEやCLIヘルプの更新
+  - docs-ai/internal/での記録
+
+- [ ] **テスト戦略の明確化**
+  - 新機能のテストケース設計
+  - 既存テストへの影響確認
+  - E2Eテストが必要か
+
+- [ ] **パッケージ依存関係の影響評価**
+  - 新しい依存関係の追加が必要か
+  - package.jsonの更新内容
+  - .npmignoreの確認
+
+## テンプレート活用ガイド
+
+todo_plans作成時は以下のテンプレート構造を使用してください：
+
+```markdown
+## 背景
+
+[現状の課題・改善したい点を具体的に記載]
+
+## やること
+
+[実現したい機能・改善内容を段階的に列挙]
+
+## 実装後の挙動に関する説明
+
+出力があるのであれば、それがどのような出力になるか、具体例を表示する。
+
+## 改修内容
+
+### 改修対象ファイル一覧
+
+[影響を受けるファイルを漏れなくリストアップ]
+
+### ファイルごと改修内容
+
+[各ファイルの具体的な変更内容。具体的なコードは書かない。どう修正するかを説明する]
+
+### テスト時の確認事項
+
+[品質確保のためのチェック項目]
+
+## メモ
+
+[実装時の注意点・参考情報]
+[対象todo_plansのpath]
+```
+
+## プランニング完了後の次のステップ
+
+1. **todo_plansファイルの作成**
+   - ファイル名規則: `YYYYMMDD_[タイトル].md`
+   - todo_plans/ディレクトリに配置
+
+2. **実装開始前の確認**
+   - 開発者との合意確認
+   - 実装方針の最終確認
+
+3. **実装時の進行管理**
+   - change_plans/への移動
+   - 進捗に応じた計画更新
+
+4. **完了後の整理**
+   - todo_plansからの削除
+   - 学習内容のdocs-ai/learning/への記録

package/artifact/instructions/git-rules.md

@@ -0,0 +1,68 @@
+---
+type: git-rules
+---
+# git の branch の命名規則
+
+## 命名規則
+
+### 機能開発
+
+* `feature/` + 機能名
+
+### バグ修正
+
+* `fix/` + バグ名
+
+### リファクタリング
+
+* `refactor/` + リファクタリング内容
+
+### ドキュメント更新
+
+* `docs/` + ドキュメント名
+
+## 使用可能文字
+
+* 英数字 (a-z, A-Z, 0-9)
+* ハイフン (-)
+* アンダースコア (_)
+* ピリオド (.)
+* スラッシュ (/)
+* コロン (:)
+
+## 使用不可文字
+
+* スペース
+* 特殊文字 (例: !, @, #, $, %, ^, &, *,
+* マルチバイト文字 (例: 漢字、ひらがな、カタカナ)
+
+## コミット前必須チェックリスト
+
+### 必須: ビルド確認
+- [ ] プロジェクトのビルドコマンドが成功すること
+- [ ] マルチモジュール環境では全モジュールのビルドが成功すること
+- [ ] 最終成果物の生成（実行ファイル、配布物等）が成功すること
+
+### 必須: テスト確認
+- [ ] 全テストが通過すること
+- [ ] マルチモジュール環境では全モジュールのテストが通過すること
+- [ ] 構造検証テストが存在する場合、それが通過すること
+
+### 必須: パッケージ品質確認
+- [ ] パッケージ内容確認コマンドで不要なファイルが含まれていないことを確認
+- [ ] 配布除外設定（.npmignore, .gitignore等）が適切で、テストファイルや開発用ファイルが除外されていること
+- [ ] 新規追加したファイルが適切にパッケージに含まれる/除外される設定になっていること
+
+### 推奨: 動作確認
+- [ ] CLI機能がある場合、生成された実行ファイルで基本動作確認
+- [ ] 新機能がある場合、実際に動作することを確認
+
+## 品質保証の重要性
+
+コミット前のbuild・test実行は品質保証とCI/CDプロセスの信頼性向上のために**必須**です。
+ローカルでの事前確認により、以下の効果が期待されます：
+
+1. **品質向上**: ビルドエラーやテスト失敗の早期発見
+2. **CI/CD安定性**: パイプラインの失敗率低下
+3. **開発効率**: 明確なプロセス定義による作業手順統一
+4. **パッケージ品質**: npm publishable な状態の維持

package/artifact/instructions/package-management.md

@@ -0,0 +1,113 @@
+---
+type: package-management
+human-instruction: |-
+  ## AIはパッケージを扱うのが得意ではありません
+
+  パッケージの増やしすぎには注意してください。
+  それでもパッケージを分けるのは、テストやドキュメントの分離、責務の明確化などが目的です。
+  なので、なるべくパッケージ内で完結するタスクを依頼するようにしてください。
+---
+
+## パッケージ管理のルール（言語非依存）
+
+### パッケージの追加・削除
+
+定義ファイル（例：依存関係マニフェスト、ロックファイル）を直接手作業で編集しないでください。各エコシステムが提供する公式のパッケージ管理コマンドを使って操作します。
+
+- 原則
+  - 依存追加・削除は公式ツールのコマンドで行う（例：「<パッケージマネージャ> add/install/remove <パッケージ名>」）。
+  - ロックファイルの整合性はツールに任せる（人手で編集しない）。
+  - 変更後は必ずビルド・テストで動作確認する。
+
+- コマンド例（参考）
+  - Node.js: `npm install <パッケージ名>` / `npm uninstall <パッケージ名>`
+  - Python: `pip install <パッケージ名>`（または `poetry add <パッケージ名>` / `poetry remove <パッケージ名>`）
+  - Rust: `cargo add <crate>` / `cargo remove <crate>`（環境により cargo-edit の導入が必要）
+  - Java: Maven/Gradle の依存宣言を追加後、`mvn -q -DskipTests package` / `./gradlew build`
+  - その他のエコシステムでも、同等の公式コマンドを使用してください
+
+### ワークスペース／モノレポ運用のルール
+
+複数パッケージ（モジュール）を単一リポジトリで管理するワークスペース／モノレポ構成（例：npm/yarn/pnpm workspaces、Cargo workspace、Maven multi-module、Poetry multi-project など）の場合、以下のルールに従ってください。
+
+#### 必ず存在するパッケージ（モジュール）
+
+| パッケージ名 | 説明                                                         |
+|:------------|:-------------------------------------------------------------|
+| core        | そのリポジトリが扱う機能の主となる部分を提供するパッケージ     |
+| common      | すべてのパッケージで共通して利用される機能を提供するパッケージ |
+
+#### それ以外のパッケージ
+
+- `core` に依存することは禁止
+- `common` に依存するのは OK
+
+（名称はエコシステムに合わせて「モジュール」「パッケージ」等に読み替えて構いません）
+
+### ローカルスクリプト／CLI の実行
+
+ローカルの CLI やスクリプトを実行する前に、ビルド工程や生成物が必要な場合は必ず事前に準備（ビルド／インストール／リンク）してください。多くのエコシステムでは、実行コマンドがビルド済みの成果物やインストール済みのエントリポイントを前提にしています。
+
+- 原則
+  - 必要なビルドを先に行う（型生成・バンドル・コンパイル等）。
+  - 実行はエコシステムの推奨手順に従う（ローカル実行・ローカルインストール・モジュール実行など）。
+
+- 例（参考）
+  - Node.js:  
+    ```sh
+    npm run build
+    npx .
+    ```
+  - Python:  
+    ```sh
+    pip install -e .
+    python -m <あなたのモジュール>
+    ```
+  - Rust:  
+    ```sh
+    cargo build
+    cargo run
+    ```
+  - Go:  
+    ```sh
+    go build
+    go run .
+    ```
+  - Java（Maven/Gradle）:  
+    ```sh
+    mvn package
+    java -jar target/app.jar
+    # または
+    ./gradlew build
+    java -jar build/libs/app.jar
+    ```
+
+### パッケージ内容の最終チェック（ignore／除外設定）
+
+配布物（パッケージ）品質確保のため、以下の場面では必ず「パッケージに含める／含めない」設定を最終確認してください。エコシステム固有の仕組み（例：.npmignore、MANIFEST.in、Cargo.toml の include/exclude、.gitattributes の export-ignore、Gradle/Maven のアセンブリ設定など）を活用します。
+
+#### 機能追加・リファクタリング後の確認
+
+- 追加・変更により不要なファイル／ディレクトリが配布物に入っていないか確認する
+- 新規のテスト・一時ファイル・開発用ファイル等が適切に除外されているか確認する
+
+#### リリース前の確認
+
+- 除外設定（ignore／include）が最新化されているか確認する
+- 各エコシステムの「パッケージ内容の事前確認（ドライラン）」相当のコマンドで収録ファイル一覧を確認し、想定どおりかチェックする
+
+#### 必須: コミット前のパッケージ品質確認
+
+- コミット（またはリリース前）には、利用エコシステムの「ドライラン」または同等の検証手順を必ず実行する
+  - 例（参考）:
+    - npm: `npm pack --dry-run`
+    - Rust: `cargo package --list`
+    - Python: `python -m build` の成果物を確認（必要に応じて `tar -tf dist/*.tar.gz` などで内容確認）
+    - Java: `mvn package` / `./gradlew build` の成果物（JAR 等）に不要物が含まれていないか確認
+- 除外設定が適切で、開発用ファイルが含まれていないことを確認する
+- 配布物サイズが想定どおりか確認する
+
+#### 参考事例
+
+実際に skel-extractor プロジェクトで不要ファイル混入を防ぐための見直しが必要となった事例があります。このような問題を未然に防ぐため、上記チェックを徹底してください。
+

package/artifact/instructions/planning.md

@@ -0,0 +1,54 @@
+---
+type: planning
+---
+
+## コミュニケーションのルール
+
+### パスの指定について
+
+相対パスはプロジェクトのルートディレクトリを基準に考えること。
+絶対パスはシステムのルートディレクトリを基準に考えること。
+
+例:
+- `docs/README.md` は、プロジェクトのルートディレクトリからの相対パス指定
+- `./docs/README.md` は、プロジェクトのルートディレクトリからの相対パス指定
+- `/docs/README.md` は、システムのルートディレクトリからのパス指定
+
+### 根源的なルール
+
+- 機能追加のために不明な点があれば、追加で確認する
+- 開発内容を決めるにあたっては、change_plans/ ディレクトリにファイルを作成し、修正計画を記載していく
+  - ファイル名名規則は、`YYYYMMDD_[タイトル].md`
+  - 修正計画は、開発の進捗に応じて更新していく
+- ロジックの修正を行う前に、skel/ ディレクトリにあるスケルトンファイルを更新する。
+  - スケルトンファイルは、実装の構造を定義するためのもので、実装内容は含まない。
+  - スケルトンファイルの更新は、実装の前に必ず行うこと。
+- 修正後は `docs/` ディレクトリにあるドキュメントを更新する。
+- `test/skeleton-structure-validation.test.ts` だけを実行して、構造が一致していることを確認する。
+- テストの実行とコードの修正は同時に行わない。
+  - テスト失敗した場合は、修正方針について指示を仰ぐこと。
+- やり残しや未実装の機能がある場合は、必ず `todo_plans/` に記載する。
+  - todo に着手する際に、内容を `change_plans/` に移動する。
+  - ファイル名名規則は、`YYYYMMDD_[タイトル].md`
+  - 終わったタスクは削除する。Git の履歴で過去の計画は追跡できるため、アーカイブせずにリポジトリをすっきり保つ。
+
+### 開発を進めるためのステップ
+
+※ 各ステップで開発者に同意を得てから、次のステップに進むこと
+
+- 要件の明確化
+  - 実装する機能を明確に定義する
+  - 開発者と合意が取れるまで会話を続ける
+- 修正対象の特定
+  - どの部分を修正するかを特定する
+  - どの順番で修正していくかを決める
+- テストを書く(TDD)
+  - 修正対象の特定ができたら、テストを書く
+  - テストは、修正対象の特定ができた段階で書く
+- 修正の実行
+- テストの実行（必ず全てのテストを実行）
+- リファクタリングの実施
+- テストの再実行（必ず全てのテストを実行）
+- ドキュメントの更新
+- 全体を振り返って、フローに改善の余地があれば `.github/copilot-instructions.md` を更新する
+