停止。エンドポイントを呼び出す前に、この SKILL.MD 全体を読んでください。
assess は何をしますか？
一歩下がってプロジェクトの状態を批判的に再評価します。対話的なガイダンス（人間参加型）とプログラム的な分析（自動パイプライン）を提供します。ドキュメントの整理とドキュメント-コードの一貫性分析に特化しています。
CLI の使用法
# パイプライン用の構造化JSON評価
.pi/skills/assess/assess.py run . --output assessment.json
# 評価からすべての図を生成
create-figure from-assess --input assessment.json --output-dir ./figures/
評価の流れ
1. 評価の範囲を設定
明確な範囲（「認証モジュールを評価して」）→ 直接進む。 不明確な範囲（「一歩下がって」）→ 確認事項：懸念事項？ コード品質 vs ドキュメント？ 既知の問題のスキップ？ ドキュメント整理（「ドキュメントを整理して」）→ 確認事項：非推奨機能？ 不足しているドキュメント？ 一貫性？
2. プロジェクトルートを特定し、エコシステムを検出
markerファイル（pyproject.toml, package.json, Cargo.toml, go.mod）で検出します。 エコシステム固有のメタデータを読み取り、次に汎用ドキュメント（README.md, CONTEXT.md, AGENTS.md）を読みます。
3. スキルマニフェストを読み込む（ルートゲート制）
「Xを構築すべき」という推奨につながる可能性のある評価のために .pi/skills-manifest.json を読み込みます。ステータスチェックやドキュメントのみのレビューの場合はスキップします。
cat .pi/skills-manifest.json | python3 -c "
import json, sys
data = json.load(sys.stdin)
print(f'スキル数: {data[\"skill_count\"]} (生成日: {data[\"generated\"]})')
"
マニフェストが7日以上経過している場合は警告します。フォールバック: ls .pi/skills/ | wc -l
4. クイックスキャン → 確認 → 深堀り
- プロジェクトメタデータ、READMEを読み、グロブで構造を確認
- 2～3の初期所見を記載し、ユーザーに確認
- ユーザーのガイダンスに基づいて深堀り — 各所見について：ブロッカー？ 既知？ 修正の複雑さ？
5. 協力的なレポート
所見を提示し、どれを修正するか尋ねます。可視化のために /create-figure を提供します。
評価カテゴリ
1. ドキュメント-コードの一貫性
- READMEの主張と実装の比較
- 相互参照の検証（内部リンク、コード例）
- プレースホルダーと古い情報
- 非推奨：削除された機能に関するドキュメント
2. 野心的 vs 実装済み
- スタブ（
pass,raise NotImplementedError）、プレースホルダーノート - コード構造としては存在するがロジックがない機能、未使用の依存関係
3. 脆弱なコード
- ハードコードされた値、不足しているエラーハンドリング、脆弱な正規表現/パース
4. 動作しないコード
- デッドコードパス、暗黙の例外の飲み込み、壊れた統合
5. 過度に設計されたコード
- 単一の実装しかない抽象化、仮説的な柔軟性のための設定
6. テストカバレッジ（必須）
各機能/モジュールについて、テストファイル、合格するテスト、エッジケースを確認します。
理由のない pytest.mark.skip、「0 tests collected」、アサーションのないテストをフラグします。
タスクファイル監査: 各タスクに特定のテスト/アサーションを含む完了の定義があることを確認します。 実装タスクに完了の定義がない場合は実行をブロックします。
7. うまく機能しているもの
頑健なコードを認めて評価のバランスを取ります。
出力形式
# 評価: <プロジェクト名>
## 概要
<2～3文：全体的な健全性、主な所見>
## 所見
### ドキュメント-コードの一貫性
| 主張 | 現実 | アクション? |
### 見つかった問題
1. **file.py:123** - [問題] — 重大度: 高/中/低 — 提案された修正: [簡単な説明]
### テストカバレッジ
| 機能 | テストステータス | 必要なアクション |
### うまく機能しているもの
- [認めるべき頑健なコード]
## 推奨される次のステップ
優先順位付きの1～4のアクション。どれから始めるか尋ねます。
ポリシー
- デフォルトは読み取り専用 — 明示的な同意なしにファイルを書き込まない
- まず表示し、同意を得てから書き込む — 提案内容を表示し、その後書き込みを提案する
- 協力する — 評価は独白ではなく対話である
- 実行前に許可を得る — テスト、ビルド、有料サービスの前に許可を得る
- 賢くエスカレーションする — 複雑/重大な問題には
/review-codeを提案する - 具体的に — ファイルパスと行番号を記載する
- アクション可能にする — 各所見は次のステップを提案する
- テストカバレッジは必須 — 欠落しているテストをブロッカーとしてフラグする
外部リサーチ
必要に応じて利用可能（有料サービスは事前に確認）:
/context7— ライブラリドキュメント（無料）/brave-search— 一般的なウェブ検索（無料）/perplexity— 深層リサーチ（有料）
よくある間違い
# 間違い: すべての評価所見をブロッカーとして扱う
# → エージェントが12個のプライベートヘルパーに自動でdocstringを追加。不要な肥大化。
# 正しい: 所見をユーザーとレビューする。複雑な問題は /review-code にエスカレーションする。
# 間違い: 大きな変更後に /assess をスキップする
# → READMEの例が古い関数シグネチャを使っている。ユーザーがエラーに遭遇する。
# 正しい: コアAPIを編集した後に assess --focus "doc-code-alignment" を実行する。
# 間違い: /assess を実行し、古い結果に基づいて行動する
# → 評価は3日前のもの。コードベースはその後変更されている。
# 正しい: 常に評価を再実行する。セッション間で結果をキャッシュしてはいけない。