absolute

Absolute — 開発ワークフローエンジン

1 つのスキル、11 個のコマンドを /absolute <command> [target] として実行します。1 つは初期設定に使い、 残りは 2 つのグループに分かれます。

初期設定（リポジトリごとに 1 回実行）：init — ヒアリングとスタックの検出を行い、他のコマンドが読み込む JSON 設定を作成します。

ビルドループ（日常的なフロー）： 検討 → 計画 → 構築（work）→ 仕様のみ（spec）→ デザイン（ui）→ 仕上げ（simplify）→ ドキュメント作成（docs）

エンジニアリングの健全性（green な main で継続的に行うメンテナンス）： upgrade（依存関係） · audit（セキュリティ） · prune（不要なコード） · debt（lint／型） · deflake（不安定なテスト）

各コマンドの本文は references/<command>.md にあります。このファイルはルーターです。ユーザーが求めているコマンドを判断し、 対応するリファレンスを読み込んで、その指示に従います。コマンドのリファレンスは長く、明確な見解を示す内容です。実行中のコマンドのものだけを読み込んでください。 5 つの健全性コマンドは references/health-engine.md の共通ループを使用します（各コマンドが読み込みます）。

---

コマンド

コマンド	フェーズ	内容	リファレンス
init	セットアップ	初回のみのセットアップです。absolute の動作（出力スタイル、自律性／ゲーティング、TDD の厳格さ、仕様ディレクトリ、ファミリー）についてヒアリングし、スタックを一度だけ検出してから、.absolute.config.json（プロジェクト用、コミット対象）と、必要に応じて ~/.absolute/config.json（ユーザーのデフォルト設定とプロジェクトごとのオーバーライド）を書き込みます。それ以外のコマンドは再検出せず、この設定を読み込みます。非破壊的で、コミットは行いません。	references/init.md
work [target]	思考・計画・構築	エンドツーエンドで、フェーズごとにゲートを設けた SDLC です。徹底した設計ヒアリング → レビュー済み仕様 → 依存関係をグラフ化したタスクボード → 安全なウェーブ単位の TDD 実行 → 検証 → 収束まで対応します。機能、バグ、リファクタリング、新規開発、計画の細分化、移行を扱います。	references/work.md
spec [target]	計画	単独で使える軽量な設計仕様です。今すぐ構築するのではなく、議論や引き継ぎのための文書が必要な場合に適しています。コードベースをスキャンし、範囲を絞った確認（厳しい問い詰めではなく、いくつか質問します）を行い、docs/plans/ にレビュー済み仕様を書き込み、独立した採点レビューを行って終了します。work の仕様テンプレートと評価基準を再利用します。	references/spec.md
ui [target]	デザイン	具体的な CSS／Tailwind の値を使って、洗練された意図の明確な UI を構築します。タイポグラフィ、色、レイアウト、余白、ダークモード、アクセシビリティ、アニメーション、コンポーネントに対応します。曖昧なアドバイスではなく、最も包括的な UI ナレッジベースを提供します。	references/ui.md
simplify [target]	仕上げ	ステージング済み／未ステージの Git 変更、または対象パスを自律的に簡素化します。複雑さを減らし、ネストを平坦化し、冗長な箇所やデッドコードを削除してから、テストを実行して問題がないことを確認します。	references/simplify.md
docs [target]	ドキュメント化	Diátaxis に基づくドキュメント作成です。チュートリアル、ハウツー、リファレンス、解説、開発者向けドキュメント（README、CONTRIBUTING、ADR）を作成、改善、監査します。ドキュメントのスタックを検出し、すべての記述をコードと照合して検証します。	references/docs.md
upgrade [target]	ヘルス	依存関係をアップグレードします。古い依存関係や脆弱性のある依存関係を一覧表示し、セマンティックバージョニングに基づくウェーブ（パッチ／マイナーはまとめて適用し、メジャーはゲートを設けて変更履歴を確認）に計画し、段階的に適用してロックファイルを再生成し、各段階でテストを成功させます。	references/upgrade.md
audit [target]	ヘルス	脆弱性とセキュリティをスキャンします（防御目的、自分のリポジトリが対象）。依存関係の CVE とリスクのあるコードパターン（シークレット、インジェクション、脆弱な認可）を検出し、重大度 × 到達可能性に基づいてトリアージし、抑制せずに修正します。組み込みの /security-review を補完します。	references/audit.md
prune [target]	ヘルス	リポジトリ全体のデッドコードと依存関係を整理します。未使用の依存関係、参照されていないエクスポート、到達不能なコード、孤立したファイルを、ツールによる根拠がある場合にのみ、元に戻せるウェーブで削除します。（差分に限定した整理には simplify を使用します。）	references/prune.md
debt [target]	ヘルス	リントと型チェックの負債を解消します。既存のリポジトリ全体にわたるリント／型チェック違反や抑制（@ts-ignore、# type: ignore）を、原因を直して症状を取り繕うことなく、ウェーブごとにルールを一つずつ解消します。（差分に限定した品質改善には simplify を使用します。）	references/debt.md
deflake [target]	ヘルス	不安定なテストを修正します。繰り返し実行、順序のシャッフル、並列実行によって非決定的なテストを実証的に検出し、根本原因を診断して修正します。リトライ、スキップ、スリープは決して行わず、多数のランダム化実行を通じて検証します。	references/deflake.md

---

ルーティングルール

呼び出しのたびにコマンドを解決し、対応するリファレンスに引き継ぎます。

1. 最初の単語がコマンドに一致する（init、work、spec、ui、simplify、docs、 upgrade、audit、prune、debt、deflake）→ references/<command>.md を読み、 その指示に正確に従います。コマンド名の後ろはすべて対象／引数です。

2. 最初の単語は一致しないが、意図が明確にいずれかのコマンドに対応する → そのコマンドのリファレンスを読み込み、 明示的に呼び出されたものとして進めます：

   • 「absolute をセットアップ／初期化／設定する」、「初回セットアップ」、「このリポジトリの 規約／設定を覚えておく」→ init
   • 「X を最初から最後まで構築する」、「計画して構築する」、「これをタスクに分解する」、 「この計画について質問して詰めて」、「このチケットに取りかかる」、「この移行を実行する」→ work
   • 「仕様を書く」、「この機能の仕様をまとめる」、「X の設計ドキュメントを作成する」、「引き継ぎ／レビュー用に仕様がほしい。まだ構築はしない」→ spec （work との違い：spec はレビュー済みの設計ドキュメントを作成して終了します。work は ドキュメントを作成し、さらに構築します。今すぐ構築するかどうか不明な場合は、まず spec を優先してください。 その後 work につなげられます。）
   • 「料金ページをデザインする」、「このコンポーネントのスタイルを整える」、「AI っぽい粗雑さをなくす」、 「余白／タイポグラフィ／色を修正する」、「ダークモード」→ ui
   • 「これを簡素化する」、「変更内容を整理する」、「これをリファクタリングする」、「複雑さを減らす」、 「不要なコードを削除する」、「これを整える」→ simplify
   • 「ドキュメント／チュートリアル／README を書く」、「これを文書化する」、「このドキュメントを改善する」、 「ドキュメントを監査する」、「ドキュメント構成を見直す」→ docs
   • 「依存関係をアップグレードする」、「依存関係のバージョンを上げる」、「パッケージを更新する」、 「非推奨の X から移行する」、「Dependabot の未対応項目を解消する」→ upgrade
   • 「セキュリティ監査」、「脆弱性があるか」、「CVE をスキャンする」、「シークレット／ インジェクションをチェックする」、「セキュリティを強化する」→ audit（防御目的でリポジトリ全体を対象にします。未確定の差分には組み込みの /security-review を併用してください。）
   • 「不要なコードを削除する」、「未使用の依存関係／エクスポートを見つける」、「削除できるものは何か」、 「孤立したファイルを整理する」（リポジトリ全体）→ prune
   • 「lint 警告を修正する」、「型エラーを解消する」、「strict モードにする」、「@ts-ignore／抑制を 一掃する」→ debt
   • 「不安定なテストを修正する」、「CI が不安定」、「このテストがランダム／断続的に失敗する」→ deflake

   判別のポイント：prune／debt は green な main をリポジトリ全体で対象にします。simplify は作業中の差分を対象にします。範囲に応じて振り分けてください。audit（コマンド）は リポジトリ全体のセキュリティをスキャンします。「ドキュメントを監査する」は引き続き docs です。

   2 つのコマンドが本当に当てはまる場合は、どちらを希望するか一度だけ尋ねます。それ以外は明確に当てはまるものを選び、 読み込んだコマンドを伝えます。

3. 引数なし（/absolute のみ）→ 何も自動実行しません。上記のコマンド一覧を提示し、 コンテキストに基づいて次に最も価値の高い 1～2 個のコマンドを推奨します （例：未コミットの変更がある → simplify、新しいチケットまたは曖昧な目標 → work、または引き継ぎ用の設計ドキュメントだけが必要なら spec、差分に UI ファイルがある → ui、ドキュメントが不足または古い → docs、マニフェスト内の依存関係が古い／脆弱 → upgrade／audit、CI が失敗または不安定 → deflake、設定がまだない → まず init を提案）。推奨はユーザーが確認してから実行する提案です。

4. 明確に一致するコマンドがない → 入力全体を開発タスクとして扱い、デフォルトのライフサイクルである work を読み込み、 入力を依頼内容として使用します。

設定の解決（init 以外のすべてのコマンドへの引き継ぎ前）

優先順位が高い順に設定を重ね合わせ、有効な設定を解決します：./.absolute.config.json（プロジェクト） → ~/.absolute/config.json の projects["<cwd>"] → ~/.absolute/config.json の defaults。 conventions と preferences は浅くマージします。解決した設定をコマンドに適用します（出力スタイル、自律性／ゲート、TDD の厳格さ、spec ディレクトリ）。

プロジェクトまたはグローバルの設定が存在しない場合は、1 行表示してから、その場で検出を続行します。処理をブロックしてはいけません：

Absolute の設定が見つかりません — /absolute init を実行すると、スタックと設定がキャッシュされ、コマンドで再検出する必要がなくなります。
その場での検出を続行します。

これはソフトな推奨事項であり、呼び出し 1 回につき最大 1 回だけ表示します。スキーマと優先順位については、references/init.md を参照してください。

コマンドのリファレンスを読み込んだら、そのリファレンス固有の開始バナー、ゲート、フローに従います。サブコマンドのリファレンスから、このルーターを再度呼び出すことはありません。

---

コマンド間で共有される原則

• 質問する前にコードベースを確認します。 質問する前に既存の内容を読み、コードから答えが得られない場合にのみ質問します。
• コストのかかる作業の前にゲートを設けます。 work ではフェーズ間にゲートを設け、docs ではアウトラインの段階でゲートを設け、simplify では対象範囲内の変更に限定します。spec はレビュー済みドキュメントの段階で停止し、実装を開始しません。ヘルスコマンド（upgrade／audit／prune／debt／deflake）では、リスクの高い順に検出結果を提示し、修正を適用する前にゲートを設けます。対象範囲を黙って広げてはいけません。
• 推測せず、検証します。 テスト、実際の出力、コードで確認した事実によって動作を証明します。実現を目指すだけの主張はしてはいけません。
• 自動コミットは決して行いません。 すべてのコマンドはファイルを書き込み、結果を報告します。コミットするのはユーザーです。