[#313] refactor: skill naming taxonomy — analyze-* for report skills (task T8)

.claude/skills/pair-capability-assess-code-quality/SKILL.md → .claude/skills/pair-capability-analyze-code-quality/SKILL.md

@@ -1,40 +1,40 @@
 ---
-name: pair-capability-assess-code-quality
-description: "Assesses code quality using resolution cascade (Argument > Adoption > Assessment). Applies quality score formula from code-metrics guidelines. Produces quality report with complexity, size, coverage, and maintainability metrics (output-only, writes nothing). Idempotent: detects existing report, checks staleness. Invocable independently or composed by /pair-process-review."
+name: pair-capability-analyze-code-quality
+description: "Analyzes code quality using resolution cascade (Argument > Adoption > Assessment). Applies quality score formula from code-metrics guidelines. Produces quality report with complexity, size, coverage, and maintainability metrics (output-only, writes nothing). Idempotent: detects existing report, checks staleness. Invocable independently or composed by /pair-process-review."
 version: 0.5.0
 author: Foomakers
 ---
 
-# /pair-capability-assess-code-quality — Code Quality Assessment
+# /pair-capability-analyze-code-quality — Code Quality Analysis
 
 Evaluate code quality using objective metrics from [code-metrics.md](../../../.pair/knowledge/guidelines/code-design/quality-standards/code-metrics.md). Produces a quality report with complexity, size, coverage, duplication, and maintainability scores. Includes actionable recommendations for improvement. **Output-only**: this skill inspects code and runs coverage but writes no files — it never mutates adoption, code, or the PM tool.
 
 ## Arguments
 
 | Argument | Required | Description                                                                                       |
 | -------- | -------- | ------------------------------------------------------------------------------------------------- |
-| `$scope` | No       | Limit assessment to specific metric group: `complexity`, `size`, `coverage`, `duplication`, `maintainability`, `all` (default: `all`) |
-| `$path`  | No       | Limit assessment to a specific file, directory, or package. If omitted, assesses the full codebase. |
+| `$scope` | No       | Limit analysis to specific metric group: `complexity`, `size`, `coverage`, `duplication`, `maintainability`, `all` (default: `all`) |
+| `$path`  | No       | Limit analysis to a specific file, directory, or package. If omitted, analyzes the full codebase. |
 
 ## Algorithm
 
 ### Step 1: Resolution Cascade
 
 #### Path A — Existing Recent Report
 
-1. **Check**: Is there an existing quality report for this codebase? (Check conversation context, CI artifacts, or previous assessment output.)
+1. **Check**: Is there an existing quality report for this codebase? (Check conversation context, CI artifacts, or previous analysis output.)
 2. **Skip**: If no existing report, go to Path B.
 3. **Act**: Check staleness:
-   - Has the codebase changed since the last assessment? (Use `git diff --stat` since last assessment date or commit.)
+   - Has the codebase changed since the last analysis? (Use `git diff --stat` since last analysis date or commit.)
    - If no changes → confirm existing report is still valid. Exit.
    - If changes exist → report is stale. Present summary of changes and proceed to Path B.
 
-   > Existing quality report found ([date]). [N files changed since last assessment.]
-   > Re-assess? (Recommended — codebase has changed.)
+   > Existing quality report found ([date]). [N files changed since last analysis.]
+   > Re-analyze? (Recommended — codebase has changed.)
 
-4. **Verify**: If confirmed valid → exit. If stale or re-assessment requested → proceed to Path B.
+4. **Verify**: If confirmed valid → exit. If stale or re-analysis requested → proceed to Path B.
 
-#### Path B — Full Assessment
+#### Path B — Full Analysis
 
 1. **Act**: Proceed to Step 2.
 
@@ -134,14 +134,14 @@ RECOMMENDATIONS:
 1. [priority] [metric] — [current] → [target]: [action]
 2. ...
 
-RESULT: [Quality score: N/100 | Assessed | Confirmed existing]
+RESULT: [Quality score: N/100 | Analyzed | Confirmed existing]
 ```
 
 ## Composition Interface
 
 When composed by `/pair-process-review`:
 
-- **Input**: /pair-process-review may invoke `/pair-capability-assess-code-quality` during the technical review phase.
+- **Input**: /pair-process-review may invoke `/pair-capability-analyze-code-quality` during the technical review phase.
 - **Output**: Returns the quality report. /pair-process-review incorporates metrics and hotspots into review findings.
   - Poor maintainability or high complexity may inform review recommendations.
   - Metrics are informational — they do not HALT the review.
@@ -160,7 +160,7 @@ When invoked **independently**:
 ## Notes
 
 - This skill is **read-only / output-only** — it inspects code, runs coverage (via existing test commands), but never modifies files, adoption, or the PM tool. A finding worth tracking is promoted deliberately to the backlog via `/pair-capability-write-issue` (a manual, selective act) — never auto-created.
-- **Idempotent**: re-invocation checks staleness of existing report. If codebase unchanged → confirms existing report. If changed → re-assesses only.
+- **Idempotent**: re-invocation checks staleness of existing report. If codebase unchanged → confirms existing report. If changed → re-analyzes only.
 - Metrics are **health indicators, not absolute quality measures**. Context matters: business logic naturally has higher complexity, and metric targets should align with team capabilities.
-- Quality assessment is most valuable as a **trend** — individual snapshots matter less than improvement direction over time.
-- The maintainability index is a composite heuristic — it provides a single number for quick assessment but the component metrics offer more actionable insights.
+- Quality analysis is most valuable as a **trend** — individual snapshots matter less than improvement direction over time.
+- The maintainability index is a composite heuristic — it provides a single number for quick analysis but the component metrics offer more actionable insights.

.claude/skills/pair-capability-assess-debt/SKILL.md → .claude/skills/pair-capability-analyze-debt/SKILL.md

@@ -1,20 +1,20 @@
 ---
-name: pair-capability-assess-debt
-description: "Assesses technical debt using resolution cascade (Argument > Adoption > Assessment). Categorizes debt (code, design, test, documentation, infrastructure), applies prioritization formula (impact x effort), proposes remediation priority. Output-only: returns a report, writes no files, creates no backlog items, never blocks. Idempotent. Invocable independently or composed by /pair-process-review."
+name: pair-capability-analyze-debt
+description: "Analyzes technical debt using resolution cascade (Argument > Adoption > Assessment). Categorizes debt (code, design, test, documentation, infrastructure), applies prioritization formula (impact x effort), proposes remediation priority. Output-only: returns a report, writes no files, creates no backlog items, never blocks. Idempotent. Invocable independently or composed by /pair-process-review."
 version: 0.5.0
 author: Foomakers
 ---
 
-# /pair-capability-assess-debt — Technical Debt Assessment
+# /pair-capability-analyze-debt — Technical Debt Analysis
 
 Detect, categorize, and prioritize technical debt items. Applies the prioritization framework from [technical-debt.md](../../../.pair/knowledge/guidelines/code-design/quality-standards/technical-debt.md) guidelines. Produces a debt report with categorized items, severity, impact/effort scoring, and remediation recommendations. **Output-only**: this skill returns a report — it writes no files, creates no PM-tool items, and there is **no `$mode:scan`** and **no auto-conversion** of debt into backlog cards. Technical debt **never blocks a PR**.
 
 ## Arguments
 
 | Argument | Required | Description                                                                                                                                      |
 | -------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
-| `$scope` | No       | Limit assessment to specific categories: `code`, `design`, `test`, `documentation`, `infrastructure`, `all` (default: `all`)                    |
-| `$choice`| No       | Pre-identified debt item to assess (e.g., `"missing error handling in API layer"`). Skips detection, goes directly to categorization and scoring. |
+| `$scope` | No       | Limit analysis to specific categories: `code`, `design`, `test`, `documentation`, `infrastructure`, `all` (default: `all`)                    |
+| `$choice`| No       | Pre-identified debt item to analyze (e.g., `"missing error handling in API layer"`). Skips detection, goes directly to categorization and scoring. |
 
 ## Composed Skills
 
@@ -31,18 +31,18 @@ This skill is **output-only** — it composes no skill and writes no files. No a
 3. **Act**: Accept the pre-identified debt item. Skip detection (Step 2). Proceed directly to Step 3 (categorization) with the single item.
 4. **Verify**: Item accepted.
 
-#### Path B — Existing Assessment
+#### Path B — Existing Analysis
 
-1. **Check**: Is there an existing debt assessment for this codebase/PR? (Look for a recent debt report in the conversation context or PR comments.)
-2. **Skip**: If no existing assessment, go to Path C.
-3. **Act**: Present the existing assessment:
+1. **Check**: Is there an existing debt analysis for this codebase/PR? (Look for a recent debt report in the conversation context or PR comments.)
+2. **Skip**: If no existing analysis, go to Path C.
+3. **Act**: Present the existing analysis:
 
-   > Existing debt assessment found ([N items], [date]).
-   > Re-assess? (Only if explicitly requested by developer.)
+   > Existing debt analysis found ([N items], [date]).
+   > Re-analyze? (Only if explicitly requested by developer.)
 
-4. **Verify**: If developer confirms existing → exit. If re-assessment requested → proceed to Path C.
+4. **Verify**: If developer confirms existing → exit. If re-analysis requested → proceed to Path C.
 
-#### Path C — Full Assessment
+#### Path C — Full Analysis
 
 1. **Act**: Proceed to Step 2 (detection).
 
@@ -150,7 +150,7 @@ For each detected item, apply the prioritization formula:
 ## Output Format
 
 ```text
-TECH DEBT ASSESSMENT (output-only — no files or issues created):
+TECH DEBT ANALYSIS (output-only — no files or issues created):
 ├── Items Found:  [N total]
 ├── Categories:   Code: [N] | Design: [N] | Test: [N] | Docs: [N] | Infra: [N]
 ├── Severity:     High: [N] | Medium: [N] | Low: [N]
@@ -166,15 +166,15 @@ REMEDIATION PLAN (High severity):
 1. [item] — [strategy] (est. [effort])
 2. ...
 
-RESULT: [N items assessed, N high-priority — report only, nothing created/blocked]
+RESULT: [N items analyzed, N high-priority — report only, nothing created/blocked]
 ```
 
 ## Composition Interface
 
 When composed by `/pair-process-review`:
 
-- **Input**: /pair-process-review invokes `/pair-capability-assess-debt` during the completeness phase (Phase 4).
-- **Output**: Returns the debt assessment report. /pair-process-review incorporates findings into review output (the Tech Debt section).
+- **Input**: /pair-process-review invokes `/pair-capability-analyze-debt` during the completeness phase (Phase 4).
+- **Output**: Returns the debt report. /pair-process-review incorporates findings into review output (the Tech Debt section).
   - Debt items are **informational** — they do **not** HALT the review and **never** block the PR.
   - /pair-process-review does **not** auto-create tech-debt issues. Items worth tracking are promoted deliberately (after review) via `/pair-capability-write-issue` with the `tech-debt` label.
 
@@ -192,6 +192,6 @@ When invoked **independently**:
 
 ## Notes
 
-- **Idempotent**: re-invocation on an already-assessed codebase confirms the existing assessment. Re-assessment only on explicit developer request.
+- **Idempotent**: re-invocation on an already-analyzed codebase confirms the existing analysis. Re-analysis only on explicit developer request.
 - Prioritization formula `Impact × (6 - Effort)` favors quick wins: high-impact items with low effort get the highest scores.
 - Debt is contextual — the same pattern may be acceptable in a prototype but unacceptable in production code. Severity assessment considers the project's maturity and risk tolerance.