Review Existing Solutions

---
name: review-existing-solutions
description: Review an existing solutions survey for search coverage, evaluation rigor, accuracy, due diligence, and a sound build-versus-adopt recommendation.
---

# Review Existing Solutions Survey

Audits an existing solutions survey and reports findings across five categories: coverage, evaluation rigor, accuracy, due diligence, and recommendation soundness.

## Prerequisites

- Apply the shared SDLC conventions in `skills/sdlc/references/shared.md`.
- If no argument is provided, locate the feature directory under `.sdlc/features/` whose frontmatter `issue` field references `$ISSUE_NUMBER`.
- `.sdlc/features/N-<slug>/existing-solutions.md`, or a survey document provided in context or as a file path
- `.sdlc/features/N-<slug>/requirements.md` (optional, improves coverage analysis)

## Steps

1. Read the survey from `.sdlc/features/N-<slug>/existing-solutions.md` if present, otherwise from context or as a file path.
2. Cross-reference against the requirements document if available.
3. Identify issues in each of the five categories below.
4. Report findings. Omit any category that has no findings.
5. Write the findings to `.sdlc/features/N-<slug>/review-existing-solutions.md` with frontmatter `artifact: existing-solutions`, `verdict` (`approved` if there are no blocking findings, `changes-requested` if the author must address findings, `rejected` for a fundamental flaw), and `reviewed_at: <ISO date>`, and the findings as the body, per `skills/sdlc/references/shared.md`. Record any unresolved open questions in the findings body. For any question that carries meaningful risk, also invoke `/create-assumption` to record it formally. For a chosen adopt-or-build direction with lasting consequences, invoke `/create-decision`.

## Review Checklist

### Coverage
- Was the internal codebase searched before looking at external options?
- Are the obvious open-source and commercial candidates present, or are well-known options missing?
- Does the survey map candidates back to the functional and non-functional requirements?

### Evaluation Rigor
- Is each strong candidate evaluated on strengths, weaknesses, integration effort, cost, and risk?
- Are gaps between a candidate and the requirements stated explicitly?
- Are claims backed by the candidate's docs or source rather than assumption?

### Accuracy
- Are licenses, maturity, and maintenance status current and correct?
- Are links valid and pointing at the right project?
- Are version-specific claims tied to a version?

### Due Diligence
- Are license compatibility and security posture considered for adopt candidates?
- Are maintenance health and lock-in risk assessed?
- For commercial options, is cost (and its scaling) accounted for?
- For adopt candidates, is forward compatibility assessed (upgrade stability, semver discipline, version range safety, tolerance to additive changes in the dependency's API)?

### Recommendation Soundness
- Does the recommended direction follow from the evaluation, or contradict it?
- If building, is the reason existing options fall short stated clearly?
- Are sources of information captured so the design can reuse proven patterns even when not adopting?

## Output Format

```markdown
## Coverage

<Findings or "No issues found.">

## Evaluation Rigor

<Findings or "No issues found.">

## Accuracy

<Findings or "No issues found.">

## Due Diligence

<Findings or "No issues found.">

## Recommendation Soundness

<Findings or "No issues found.">
```

## Outcome

If `$OUTCOME_YAML` is set, emit your verdict there per `skills/sdlc/references/shared.md`:

| Verdict | When |
|---|---|
| `approved` | No blocking findings; the subject passes review |
| `changes-requested` | Findings the author must address before it passes |
| `rejected` | Fundamental flaw requiring rework or stopping |

In the same emission, list the findings file under `artifacts:` (`.sdlc/features/N-<slug>/review-existing-solutions.md`).

## Example Usage

**Scenario 1: Missing an obvious option**
The survey for a JSON schema validator omits the de facto standard library.
Report under Coverage.

**Scenario 2: License overlooked**
The recommendation is to adopt a GPL library into a proprietary product without flagging the license conflict.
Report under Due Diligence.

**Scenario 3: Recommendation contradicts evaluation**
Every candidate is rated a poor fit, yet the recommendation is to adopt one anyway with no rationale.
Report under Recommendation Soundness.

## Next Step

Once the findings verdict is `approved`, continue with `/create-codebase-analysis` to analyze the internal code and architecture the feature will touch.

## Useful Commands Reference

| Command | Description |
|---|---|
| `WebFetch` | Re-check a candidate's license, version, or maintenance status |
| `WebSearch` | Verify that no well-known option was missed |