# Contributing to tree-sitter-analyzer

## 文書管理ガイドライン

### ディレクトリ構造と用途

#### `specs/` - 機能仕様書
- **目的**: プロジェクトの主要な機能仕様（Feature Specifications）を格納
- **対象**: プロジェクトの根幹をなす、永続的な設計文書
- **管理方針**: 
  - `specs/001-feature-name/` のようなサブディレクトリ構造で機能ごとにグループ化
  - `spec.md`, `plan.md` は恒久的に保持
  - `tasks.md` は完了後も履歴として保持（削除しない）

#### `docs/analysis/` - 分析結果
- **目的**: `speckit.analyze`やその他の分析ツールによる恒久的な分析結果を保存
- **対象**: 
  - プロジェクトのアーキテクチャ分析結果
  - 依存関係の分析レポート
  - コード品質メトリクス
  - パフォーマンス分析結果
  - セキュリティ監査結果
- **管理方針**: バージョン管理下で恒久的に管理

#### `.specify/` - 一時的な作業ファイル
- **目的**: `speckit`などのツールが生成する一時的な作業ファイルを格納
- **対象**: ブランチごとの短期的な仕様検討やタスク管理
- **管理方針**: 
  - `.gitignore`で追跡対象から除外
  - 対応するブランチがマージされれば削除可能

### 分析結果の文書化戦略

#### 恒久的な分析結果
- **保存場所**: `docs/analysis/`
- **命名規則**: 
  - `architecture_overview.md` - アーキテクチャの全体像
  - `dependency_analysis.md` - 依存関係の分析
  - `code_metrics_YYYY-MM-DD.md` - 日付付きのコードメトリクス
  - `performance_report_vX.X.X.md` - バージョン別パフォーマンスレポート

#### 一時的な分析結果
- **保存場所**: `.specify/` または `.temp/analysis/`
- **管理方針**: 作業完了後に削除

### speckit コマンドの使用ガイドライン

#### `speckit.analyze`
- **制約**: 読み取り専用（ファイル変更禁止）
- **目的**: spec.md, plan.md, tasks.md の一貫性と品質分析
- **実行タイミング**: `/tasks` 完了後
- **出力**: 構造化された分析レポート（ファイル書き込みなし）

#### 完了済みタスクファイルの取り扱い
- `tasks.md` は完了後も**削除しない**
- 履歴として保持し、将来の参考資料とする
- アーカイブディレクトリへの移動は行わない

### 文書間のナビゲーション

- [仕様書](../specs/) - プロジェクトの機能仕様
- [分析結果](analysis/) - 分析ツールによる結果
- [API文書](api/) - API仕様書
- [開発者ガイド](developer_guide.md) - 開発者向けガイド

## 開発ワークフロー

### 新機能開発
1. `specs/` に機能仕様を作成
2. `speckit.analyze` で一貫性チェック
3. 実装開始
4. 完了後、分析結果を `docs/analysis/` に保存

### バグ修正・リファクタリング
1. `.specify/` で一時的な作業ファイル管理
2. 修正完了後、`.specify/` ディレクトリを削除
3. 必要に応じて分析結果を `docs/analysis/` に保存

## コード品質

### テスト
- 新機能には必ずテストを追加
- 既存テストの回帰を確認

### ドキュメント
- 公開APIの変更時は必ずドキュメントを更新
- 重要な設計決定は `docs/analysis/` に記録

## リリース管理

### バージョニング
- セマンティックバージョニングに従う
- 破壊的変更は major バージョンアップ

### リリースノート
- `CHANGELOG.md` を更新
- 重要な変更は `docs/analysis/` にも記録