skill-audit

ホスト：Codex CLI — このスキルは Claude Code 向けに設計され、Codex 用に適応されています。 相互参照コマンドでは、/octo:* スラッシュコマンドではなく、Codex にインストールされたスキル名を使用します。 現在の Codex シェルとサブエージェントツールを使用してください。現在のセッションで利用可能であることが確認されるまでは、プロバイダー、モデル、またはホストのサブエージェントが利用可能だと主張しないでください。 ホストツールに相当するものについては、skills/blocks/codex-host-adapter.md を参照してください。

体系的な監査プロセス

インストール済みプラグインから skills/blocks/engineering-method-selection.md を読み込み、 このタスクに関連する方法のみを適用してください。このエントリーポイントの 実行契約と出力形式を維持してください。参照先のスキルは指示として読み、 現在のコマンドを再帰的に呼び出したり、担当者からプロバイダー呼び出しを追加したりしないでください。

概要

コードベース全体の問題、不整合、機能の破損を見つけるための、包括的かつ体系的な監査です。

基本原則： 範囲を定義 → チェックリストを作成 → 体系的に実行 → 検出事項を報告 → 修正の優先順位を決定します。

アーキテクチャを簡素化する場合は、 skills/blocks/architecture-simplification.md を読み込んでください。リビジョンを固定し、最近の 変更と代表的な呼び出し元を調べてから、削除テストを適用してください。セキュリティ、クリーンアップ、優先順位、または 失敗に関する不変条件を一元化している小さなラッパーの削除を推奨しないでください。simplify の判定には、 ソースコードによる根拠、具体的な呼び出し元、移行手順およびロールバック手順が必要です。

使用する場合

ユーザーが次のことを求めている場合に、このスキルを使用してください：

• アプリケーション全体を監査して問題を見つける
• 問題のあるパターンのすべての箇所を見つける
• 機能の破損を体系的に確認する
• 包括的な品質検証を行う
• コードベース全体の不整合を特定する

次の場合には使用しないでください：

• セキュリティ脆弱性のスキャン（skill-security-audit を使用）
• コード品質のレビュー（skill-code-review を使用）
• 単一ファイルの検索（Grep/Glob を直接使用）
• パフォーマンスのプロファイリング

プロセス

フェーズ 1：範囲の定義

ステップ 1：監査の目的を理解する

**Audit Objectives:**

What to audit: [app features, code patterns, specific issues]
Why auditing: [what prompted this, what problem are we solving]
Scope: [entire app, specific module, particular feature set]
Depth: [surface-level or deep inspection]

ステップ 2：監査基準を定義する

必要に応じて AskUserQuestion を使用します：

**Audit Focus:**

Which aspects should I audit?
1. Functional - Do features work as expected?
2. Consistency - Are patterns applied uniformly?
3. Completeness - Are implementations finished?
4. Quality - Is code maintainable?
5. User-facing - Does UI/UX work correctly?
6. Integration - Do components work together?

ステップ 3：監査計画を作成する

**Audit Plan**

**Areas to Cover:**
1. [Area 1: e.g., All form submissions]
2. [Area 2: e.g., All API endpoints]
3. [Area 3: e.g., All button states]
4. [Area 4: e.g., All error handling]

**Methodology:**
- [ ] Identify all instances
- [ ] Test each systematically
- [ ] Document findings
- [ ] Categorize by severity
- [ ] Propose fixes

**Estimated Coverage:** [X components, Y files, Z features]

フェーズ 2：調査

ステップ 1：監査対象を特定する

Glob と Grep を使用して、関連するコードをすべて見つけます：

**Finding Audit Targets:**

Searching for: [pattern/feature]
Method: [glob pattern or grep query]

**Found:**
1. [File 1:line]
2. [File 2:line]
3. [File 3:line]
...
N. [File N:line]

Total instances: [N]

ステップ 2：監査チェックリストを作成する

**Audit Checklist:**

- [ ] Item 1: [component/feature to check]
  - Location: [file:line]
  - Expected: [what should happen]
  - Test: [how to verify]

- [ ] Item 2: [component/feature to check]
  - Location: [file:line]
  - Expected: [what should happen]
  - Test: [how to verify]

...

Total items to audit: [N]

タスク計画ツールを使って、監査の進捗を追跡します。

フェーズ 3：体系的な実行

ステップ 1：監査チェックリストを実行する

各項目について：

**Auditing Item [N]/[Total]: [Description]**

**Location:** [file:line]

**Check 1: [Test name]**
- Expected: [what should happen]
- Method: [how to test - code review, runtime check, etc.]
- Result: ✓ Pass / ❌ Fail
- Evidence: [what you observed]

**Check 2: [Test name]**
- Expected: [what should happen]
- Method: [how to test]
- Result: ✓ Pass / ❌ Fail
- Evidence: [what you observed]

**Overall Status:** ✓ Pass / ⚠️ Issues Found / ❌ Broken

**Issues:**
[If any issues, list them here]

ステップ 2：進捗を追跡する

Audit Progress:
✓ [1/50] User login form
✓ [2/50] Password reset form
⚠️ [3/50] Registration form (issues found)
❌ [4/50] Contact form (broken)
⚙️ [5/50] Newsletter signup (in progress)
- [6/50] Survey form
...

フェーズ 4：分析と報告

ステップ 1：検出事項を分類する

**Audit Findings Summary**

**Critical Issues (Broken Functionality):**
1. [Issue 1]
   - Location: [file:line]
   - Impact: [what's broken]
   - Severity: Critical

2. [Issue 2]
   - Location: [file:line]
   - Impact: [what's broken]
   - Severity: Critical

**Major Issues (Degraded Functionality):**
1. [Issue 1]
   - Location: [file:line]
   - Impact: [what's wrong]
   - Severity: Major

**Minor Issues (Inconsistencies/Polish):**
1. [Issue 1]
   - Location: [file:line]
   - Impact: [what's inconsistent]
   - Severity: Minor

**Passed Checks:**
- [N] items fully functional
- [List if relevant]

ステップ 2：統計情報を提示する

**Audit Statistics**

Total Items Audited: [N]
✓ Passed: [N] ([X%])
⚠️ Issues Found: [N] ([X%])
❌ Broken: [N] ([X%])

**By Category:**
- Critical: [N]
- Major: [N]
- Minor: [N]

**Coverage:**
- Files reviewed: [N]
- Components tested: [N]
- Code paths verified: [N]

フェーズ 5：修正計画

ステップ 1：問題の優先順位を決める

**Recommended Fix Priority:**

**Phase 1: Critical Fixes (Do First)**
1. [Issue - file:line]
   - Why critical: [reason]
   - Estimated effort: [time]

2. [Issue - file:line]
   - Why critical: [reason]
   - Estimated effort: [time]

**Phase 2: Major Fixes (Do Next)**
1. [Issue - file:line]
   - Impact: [description]
   - Estimated effort: [time]

**Phase 3: Minor Fixes (Nice to Have)**
1. [Issue - file:line]
   - Impact: [description]
   - Estimated effort: [time]

**Total Estimated Effort:** [sum of all fixes]

ステップ 2：修正の実行を提案する

**Next Steps:**

I found [N] issues during the audit.

Would you like me to:
1. Fix all critical issues now (estimated [time])
2. Fix issues one category at a time (critical → major → minor)
3. Let you review findings first, then decide what to fix
4. Create detailed tickets/todos for each issue

What's your preference?

よくあるパターン

パターン 1：アプリ全体の機能破損を監査する

User: "Create a process to audit and check the entire app for things that might be broken"

Implementation:

**Phase 1: Scope**
- Audit all user-facing features
- Check for runtime errors
- Verify expected behavior

**Phase 2: Discovery**
- List all features (from routes, components, docs)
- Create comprehensive checklist

**Phase 3: Execute**
- Test each feature systematically
- Document working vs broken

**Phase 4: Report**
- Critical: Features that crash
- Major: Features that work incorrectly
- Minor: Features with UX issues

**Phase 5: Fix**
- Prioritized remediation plan

パターン 2：特定のパターンを監査する

User: "Find all instances of direct DOM manipulation and check if they should use React state"

Implementation:

**Phase 1: Scope**
- Audit: Direct DOM manipulation patterns
- Goal: Identify React anti-patterns

**Phase 2: Discovery**
- Grep for: document.querySelector, getElementById, etc.
- Found: [N] instances

**Phase 3: Execute**
- Check each instance:
  - Is there a good reason for direct DOM?
  - Should it use React state instead?
  - Is it causing bugs?

**Phase 4: Report**
- List instances that should migrate to React
- List instances that are fine as-is

**Phase 5: Fix**
- Refactor problematic instances

パターン 3：一貫性を監査する

User: "Audit the app for button style consistency"

Implementation:

**Phase 1: Scope**
- Audit: All button elements
- Goal: Ensure consistent styling

**Phase 2: Discovery**
- Find all buttons in codebase
- Identify button component(s)

**Phase 3: Execute**
- Check each button against style guide
- Document inconsistencies

**Phase 4: Report**
- Buttons using correct component: [N]
- Buttons with inconsistent styles: [N]
- Buttons using deprecated patterns: [N]

**Phase 5: Fix**
- Standardize all buttons to design system

他のスキルとの連携

skill-debug との連携

Audit found a broken feature?
→ Use skill-debug to investigate root cause
→ Use systematic debugging to fix

skill-visual-feedback との連携

Audit found UI inconsistencies?
→ Use skill-visual-feedback to fix visual issues
→ Ensure consistency across app

skill-iterative-loop との連携

Large audit with many items?
→ Use skill-iterative-loop to process in batches
→ Loop through sections of the app

skill-security-audit との連携

Audit includes security concerns?
→ Delegate security-specific checks to skill-security-audit
→ Use skill-audit for functional checks

ベストプラクティス

1. 場当たり的ではなく、体系的に進める

良い例：

Auditing all form submissions:
1. Login form
2. Registration form
3. Password reset form
4. Contact form
5. Newsletter signup
...
(Methodical, complete)

悪い例：

Checking some forms:
- Login form
- Maybe that contact thing
- Whatever else I find
(Random, incomplete)

2. すべてを記録する

監査項目ごとに、次の内容を記録します：

• 確認した内容
• 確認方法
• 結果（合格／不合格）
• 根拠（観察した内容）

3. カテゴリを使用する

検出事項を意味のあるカテゴリに分類します：

• 重大度別（クリティカル、重大、軽微）
• 種類別（機能、UI、一貫性、パフォーマンス）
• コンポーネント別（フォーム、ナビゲーション、データ表示）

4. 実行可能な検出事項にする

良い例：

Issue: Registration form submit button doesn't work
Location: src/components/RegisterForm.tsx:45
Root cause: onClick handler missing
Fix: Add onClick={handleSubmit}
Effort: 5 minutes

悪い例：

Issue: Some button broken somewhere
Fix: Fix it

危険な兆候 — これは避けてください

アクション	問題点
チェックリストを作成しない	確認漏れや作業の重複が発生します
体系的な方法を使わずにランダムにテストする	網羅性が不十分になります
調査結果を記録しない	後から優先順位を付けたり、修正したりできません
明確な基準なしに監査する	何をもって「合格」とするのか分かりません
監査中に修正する	監査と是正が混同されます
パターンを無視する	システム全体に関わる問題を見逃します

監査テンプレート

テンプレート 1：機能監査

**Feature:** [Name]
**Location:** [file:line]

**Tests:**
- [ ] Feature loads without errors
- [ ] Feature responds to user input
- [ ] Feature displays correct data
- [ ] Feature handles errors gracefully
- [ ] Feature works on mobile
- [ ] Feature is accessible

**Result:** ✓ Pass / ⚠️ Issues / ❌ Broken
**Issues:** [if any]

テンプレート 2：コードパターン監査

**Pattern:** [What to check]
**Instance:** [file:line]

**Checks:**
- [ ] Follows current best practices
- [ ] Consistent with codebase
- [ ] No deprecated APIs used
- [ ] Properly typed/documented
- [ ] No obvious bugs

**Result:** ✓ Good / ⚠️ Needs update / ❌ Problematic
**Notes:** [any observations]

テンプレート 3：UI 一貫性監査

**Component:** [Name]
**Location:** [file:line]

**Checks:**
- [ ] Uses design system components
- [ ] Follows spacing guidelines
- [ ] Uses correct colors
- [ ] Typography consistent
- [ ] Responsive design works
- [ ] States handled (hover, active, disabled)

**Result:** ✓ Consistent / ⚠️ Minor issues / ❌ Inconsistent
**Issues:** [if any]

クイックリファレンス

監査の種類	検出方法	確認方法	出力
機能	機能の一覧を作成	それぞれをテスト	合格／不合格のレポート
パターン	コードを grep で検索	各インスタンスをレビュー	準拠／非準拠
一貫性	すべてのインスタンスを確認	標準と比較	一貫／不一致
完全性	要件の一覧を作成	それぞれが存在することを確認	完全／不完全

要点

Systematic audit → Complete checklist + Methodical execution + Prioritized findings
Otherwise → Missed issues + Duplicate work + No clear action plan

範囲を定義します。チェックリストを作成します。体系的に実行します。調査結果を報告します。修正の優先順位を付けます。