name: japanese_workflow description: 日本語でのタスク管理と実装計画作成を強制するワークフロー

日本語ワークフロー

このスキルは、タスクの開始時に必ず実行し、全ての成果物とコミュニケーションを日本語で行うことを保証します。

ルール (Rules)

[!CAUTION]

🚨 【最優先・絶対遵守】バージョニングの独断更新は「即不合格」 🚨

AI（Antigravity等）は、ユーザーの明示的な「承認」なしにマイナーバージョン (0.X.0) を上げてはなりません。 このルールを無視した成果物は、内容の如何を問わず「失敗」とみなされます。

試行錯誤のログ = パッチ (Trial and Error = Patch): 開発中のあらゆる変更（バグ修正、機能追加、調整）は、統合されて実用できる状態になるまで すべてパッチ番号 (0.0.Z) としてインクリメント してください。

マイナーバージョンの厳格管理 (Strict Minor Versioning): マイナーバージョンを繰り上げるのは、ユーザーが「完全に使える状態になった」と判断し、承認した時のみです。

メジャーバージョンの基準 (Major Versioning): メジャーバージョン (X.0.0) は、ユーザーが全ファイルを精査し「本番稼働可能」と最終判断した時のみです。

提案と承認プロセス (Propose & Approve): AIはマイナーアップを提案できますが、承認なき独断更新は 「致命的な背信行為」 です。

CHANGELOGへの詳細集約 (Changelog Centralization): 全ての技術的知見を CHANGELOG.md に集約し、SSOT（唯一の真実）を維持してください。

全言語日本語: 成果物およびコミュニケーションはすべて日本語で行うこと。

アーティファクト管理: 一時的な作業用として標準アーティファクトを使用すること。

知識の永続化: 仕様は antigravity/ フォルダ内の _CONTEXT.md にも反映すること。

ダークモード対応: ライト/ダーク両モードでの視認性を必ず確認すること。

レスポンシブ (Mobile First): スマホ・タブレットでの表示崩れを絶対に起こさないこと。

既存資産の再利用: 新規CSSを書く前に、既存のデザインシステム（変数・クラス）を徹底的に利用すること。

軽微な修正の特例 (Fast Track)

以下の条件を満たす軽微な修正の場合、task.md および implementation_plan.md の作成・承認フローを省略し、直接実装に進むことができます。

誤字脱字の修正
軽微なデザイン修正（CSSの微調整など）
ロジック変更を伴わないコードの修正
ユーザーから明示的に「承認不要」「すぐにやって」と指示された場合
v0.1.0 移行チェックボックスの処理 (Fast Track 対象)

以下の場合は特例を適用できず、必ず通常フロー（実装計画の作成・承認）を経て実行してください:

大規模なロジック変更
Firebase 関連の変更（Rules, SDK, Cloud Functions 等）
複数ファイルにまたがる広範な変更
コンテンツの一斉更新などの大規模な変更

ただし、以下の手順は省略できません:

task_boundary ツールの使用（タスク区切りの明確化）
notify_user 等での日本語コミュニケーション
仕様や設計に影響がある場合の antigravity への知識同期 (Knowledge Sync)

手順

1. 前提知識の確認 (Context Loading)

タスクを開始する前に、まず antigravity フォルダ内の関連する _CONTEXT.md ファイルを読み込み、プロジェクトの文脈や既存の設計方針を確認してください。

2. タスクの定義 (Task Definition)

タスクを開始する前に、task_boundary ツールを使用してタスク境界を設定してください。初期状態の Mode は PLANNING に設定します。

3. タスクリストの作成 (Task List)

task.md ファイルを作成（または更新）し、タスクを以下の形式で定義してください。必ず日本語で記述してください。

# タスク: [タスク名]

- [ ] 現状の調査と分析
- [ ] 実装計画の作成
- [ ] [具体的な実装ステップ1]
- [ ] [具体的な実装ステップ2]
- [ ] ...
- [ ] 動作確認と修正

4. 実装計画の作成 (Implementation Plan)

implementation_plan.md を作成し、以下のセクションを日本語で記述してください。

# 実装計画: [タスク名]

## 目的

[この変更の目的と背景]

## 変更内容

[変更するファイルと具体的な内容の説明]
[NEW] / [MODIFY] / [DELETE] を明確にしてください。

### [コンポーネント名/ディレクトリ名]

#### [MODIFY] [ファイル名](file:///path/to/file)

- 変更点の説明

## 検証計画

[どのように動作確認を行うか]

### 自動テスト

- 実行するコマンド等

### 手動検証

- 確認する手順

5. ユーザー確認

計画作成後、notify_user ツールを使用して、作成した計画 (implementation_plan.md 等) についてユーザーにレビューを依頼してください。メッセージも日本語で記述してください。

6. Antigravityへの同期 (Knowledge Sync)

タスク完了後、以下の手順で情報を永続化してください。

対象ファイルの選定: antigravity フォルダ内を検索し、今回の変更に関連するファイル（例: main/index_CONTEXT.md, pos/mobile-order_status_CONTEXT.md 等）を特定してください。適切なファイルがない場合は新規作成してください。
情報の追記・更新: 特定したファイルに対し、以下の内容を追記・更新してください。
- 実装した機能の仕様
- 重要な決定事項や理由
- 今後の保守に必要な注意点
- （必要であれば）ファイル構造や依存関係の更新
※ task.md や implementation_plan.md はタスク完了後に参照されなくなる可能性があるため、将来的に必要な情報は全て antigravity 配下に移動させてください。
完了報告: ユーザーへの完了報告時に、「どの情報をどのファイル(antigravity/xxx.md)に記録したか」を明記してください。
変更履歴の記録 (Changelog & Patching)

タスクの最後に、必ず CHANGELOG.md を更新し、パッチ番号（v0.x.X）をインクリメントしてください。

[!IMPORTANT] 更新前の絶対義務: AIは CHANGELOG.md を更新する前に、必ずファイルの冒頭80行を読み込み、以下の3点を例外なく確認しなければなりません。

現在の最新バージョン: 直近のパッチ番号を確認し、重複を避けてインクリメントすること。

挿入位置: 必ず「最新が一番上」になるよう、既存の最新エントリの直上に挿入すること。

日付の整合性: 日本標準時 (JST) に基づき、正しい日付を記載すること。

なお、antigravity/ 配下の _CONTEXT.md への同期も必要に応じて行いますが、デバッグ知見や「なぜそうしたか」の全履歴は CHANGELOG.md を正として集約させてください。

必須項目:

背景/原因 (Context/Reason): なぜこの作業が必要だったのか、あるいはバグの技術的な原因。
解決策/実装詳細 (Solution/Implementation): 具体的にどのように実装・修正したか。
得られた知見/注意点 (Learned/Caveats): 次回以降の作業に役立つ技術的ヒントや、再発防止のポイント。

フォーマット例:

## [0.x.X] タスク名 - YYYY-MM-DD

### メタ情報

- **AIモデル**: {Gemini | GPT | Claude} ※バージョンやモデルタイプ（Pro, Sonnet, 4o等）は含めず、主要名称のみを記述してください。
- **筆者**: [AI or User]

### 修正 (Fixed) / 追加 (Added) / 変更 (Changed)

- **具体的な変更内容の要約**
  - **背景/原因**: ...
  - **解決策**: ...
  - **得られた知見**: ... (ここを充実させることで知識を共有する)

AI（Antigravity等）は、ユーザーの明示的な「承認」なしにマイナーバージョン (0.X.0) を上げてはなりません。このルールを無視した成果物は、内容の如何を問わず「失敗」とみなされます。

試行錯誤のログ = パッチ (Trial and Error = Patch): 開発中のあらゆる変更（バグ修正、機能追加、調整）は、統合されて実用できる状態になるまですべてパッチ番号 (0.0.Z) としてインクリメントしてください。マイナーバージョンの厳格管理 (Strict Minor Versioning): マイナーバージョンを繰り上げるのは、ユーザーが「完全に使える状態になった」と判断し、承認した時のみです。メジャーバージョンの基準 (Major Versioning): メジャーバージョン (X.0.0) は、ユーザーが全ファイルを精査し「本番稼働可能」と最終判断した時のみです。提案と承認プロセス (Propose & Approve): AIはマイナーアップを提案できますが、承認なき独断更新は「致命的な背信行為」です。 CHANGELOGへの詳細集約 (Changelog Centralization): 全ての技術的知見を CHANGELOG.md に集約し、SSOT（唯一の真実）を維持してください。

Name	japanese-workflow
Description	日本語でのタスク管理と実装計画作成を強制するワークフロー

japanese-workflow

SKILL.md