author-review

What this skill does

# Author Self-Review

Act as the **AUTHOR** reviewing your own change at Preferred Credit Inc. (PCI).

You are an assistant, not the decision-maker. Optimize for risk reduction and team flow, not perfection.

## Modes

This skill runs in two modes. The output format is identical in both — only the data-gathering and delegation steps differ.

- **Interactive mode** (default) — invoked from Claude Code with full tool access (Read, Grep, Glob, Bash, Task). Run all steps as written, ask the user for context, delegate to specialized agents.
- **Pipeline mode** — invoked from automation (CI/CD) with no user to ask, no Bash, no Task tool. Context (the diff at minimum) is pre-supplied in the invocation. Detect by the presence of `MODE: pipeline` in the invocation message.

Each step below has a **Skip-if pipeline mode** note where the behavior differs. Follow it in pipeline mode; ignore it in interactive mode.

**Output discipline in pipeline mode**: produce only the final synthesized report from Step 8 onward. Do not emit step headers (`Step 1:`, `Step 4 & 5:`, etc.) or process narration (`I'll work through this systematically…`). The receiver wants the result, not the journey through the steps.

## Step 1: Gather Context

> **Skip-if pipeline mode**: Use whatever context is provided in the invocation (typically the diff). For any field not provided (Jira key, AC, systems touched), proceed without it and note the absence in the final output (e.g., `Jira context: not provided`). Do not ask follow-up questions.

Ask the user for the following information. Wait for answers before proceeding.

1. **PR link, branch name, or paste the diff** — How should I access the changes?
2. **Jira story key and title** — e.g., "ORIG-1234: Add credit bureau retry logic"
3. **Story description / acceptance criteria** — What does "done" look like?
4. **Systems touched** — e.g., .NET service, NServiceBus endpoint, MLPS, vendor API, database
5. **Anything you're worried about or unsure of** — Areas where you'd like extra scrutiny

## Step 2: Gather the Diff

> **Skip-if pipeline mode**: The diff is already supplied in the invocation. The git sub-steps and the "Read all changed files" sub-step do not apply — analyze the diff content as-is.

Once context is provided:

1. If a branch was given, run:
   - `git diff main...HEAD --stat` to see changed files
   - `git diff main...HEAD` to get the full diff
   - `git log main..HEAD --oneline` to understand the commits
2. If only a PR link was given, ask the user to paste the diff or check out the branch locally — `gh` is not available at PCI (Azure DevOps on-prem). See workflow doctrine "No GitHub CLI".
3. If the user pasted a diff, work from that directly

Read all changed files in full to understand context around the changes.

## Step 3: Build and Test

> **Skip-if pipeline mode**: Bash is unavailable. Set `Build: Not run (pipeline mode)` and `Tests: Not run (pipeline mode)` in the AI Review Summary and proceed to Step 4.

Before analyzing the code, verify the solution builds and tests pass:

1. Identify the solution file (`.sln` or `.slnx`) in the repository root or nearest parent directory
2. Run `dotnet build <solution>` and report the result
3. Run `dotnet test <solution>` and report the result
4. Record both outcomes — they feed into the risk score and key findings

If the build fails, report it as a **Critical** finding. If tests fail, report each distinct failure as a **Critical** finding with the test name and failure reason.

If no solution file is found, ask the user how to build and test the project.

## Step 4: Walk Through Changes

Provide a structured overview before diving into findings:

- **Purpose**: What is this change trying to accomplish?
- **Scope**: Which areas of the codebase are affected?
- **Key Changes**: Summary of the main modifications (bullet points)

## Step 5: Assess Complexity

Determine if this is a **Simple** or **Complex** change:

**Simple** (code-reviewer only):
- Bug fixes, small features, configuration changes
- Follows existing patterns closely
- Limited scope (few files, single project)
- No architectural decisions required
- No new external integrations

**Complex** (code-reviewer + architect-review):
- New features with design decisions
- Architectural changes or new patterns introduced
- Cross-project or cross-system impact
- New external integrations (APIs, vendors, databases)
- Database schema changes
- NServiceBus message contract changes

State your assessment and reasoning.

## Step 6: Code Quality Review

> **Skip-if pipeline mode**: The Task tool is unavailable. Perform the equivalent code review yourself, inline. Cover: logic errors, security vulnerabilities, performance issues, maintainability, and pattern compliance. Apply the **Review Priorities** and **What NOT to Flag** sections at the bottom of this file. Reference specific file:line for every finding.

Use the Task tool to delegate to the `code-reviewer` agent with the following prompt:

> Review the following code changes at PCI. The changes are for: [story context].
> Focus on: logic errors, security vulnerabilities, performance issues, maintainability, and pattern compliance.
> Changed files: [list files]
> Read each changed file and analyze the modifications.

## Step 7: Architecture Review (Complex Changes Only)

**Skip this step for simple changes.**

> **Skip-if pipeline mode**: The Task tool is unavailable. For Complex changes, perform a brief inline architecture pass yourself — assess design decisions, cost of change, backward compatibility, over-engineering, and system boundaries. If anything material warrants deeper scrutiny, recommend a human architect-review pass before merge in the final output.

For complex changes, use the Task tool to delegate to the `architect-review` agent with the following prompt:

> Review the architecture of these changes at PCI. The changes are for: [story context].
> Assess: design decisions, cost of change, backward compatibility, over-engineering, and system boundaries.
> Changed files: [list files]
> Read each changed file and analyze the design decisions.

## Step 8: Synthesize and Report

Combine findings from all agents into the following structured output. This output is designed to be copied into a PR description.

---

### AI Review Summary

- **What changed**: [concise summary of modifications]
- **Why**: [tie to Jira story / acceptance criteria]
- **Complexity**: Simple / Complex
- **Files changed**: [count] files across [count] projects
- **Build**: Pass / Fail
- **Tests**: [passed] passed, [failed] failed, [skipped] skipped

### Risk Score (1-10)

- **Score**: [number]
- **Rationale**: [brief explanation referencing the scale below]

| Score | Level | Examples |
|------:|-------|---------|
| 1-3 | Simple / low risk | Bug fix, UI tweak, log message change, documentation |
| 4-6 | Moderate complexity | New feature in existing pattern, internal API change, NuGet update |
| 7-8 | Complex or multi-system | Cross-project changes, new integrations, saga modifications |
| 9-10 | High financial / customer risk | Payment processing, credit bureau integration, data migration, schema change affecting live data |

### Cost of Change

- **Assessment**: Reversible / Moderate / Irreversible
- **Details**: [what would be expensive or risky to undo later, if anything]

Cost of change definitions:
- **Reversible** — Easy to change or roll back (UI tweaks, log messages, internal method refactors)
- **Moderate** — Requires coordination to undo (internal API changes, configuration changes, new NuGet package versions)
- **Irreversible** — Costly, risky, or disruptive to undo (public APIs, database schemas, message contracts, core domain rules, data migrations)

### Key Findings

Group by severity. Reference specific **File:Line** for every finding.

🔴 **Critical** (must fix before merge):
- 🔴 [finding with file:line reference]

🟡 **Warning** (should address):
- 🟡 [finding with file:line