Forma Inspect

---
name: "forma-inspect"
description: "Inspect code, docs, issues, and evidence before deciding."
compatibility: opencode
metadata:
  forma.stage: "inspect"
  forma.target: "opencode"
---

# Forma Inspect

Inspect code, docs, issues, and evidence before deciding.

## Interaction Semantics

- Use this skill as a read-only grounding producer between plan intent and final plan files.
- Inspect only the repository context needed to produce known facts, options, gaps, and a handoff for finalization.
- Confirm facts and make non-authoritative recommendations, but do not accept user-owned product or engineering decisions.
- Do not write `plan.md`, do not write `tasks.md`, and do not start implementation.

## Workflow

- Use this skill after the plan stage has settled enough intent to provide bounded fact questions and before the finalize stage writes `plan.md` or `tasks.md`.
- Read the caller's `Settled Intent`, `Fact Questions`, `Decisions Waiting On Those Facts`, and requested `Return To` when present; do not broaden the inspection beyond the facts needed to unblock those decisions.
- Inspect repository context read-only and produce `Source Material`, `Confirmed Facts`, `Inferences`, `Options Considered`, `Validation Surfaces`, `Blocking Gaps`, `Recommended Handoff`, and `Return To`.
- For behavior, architecture, ownership, or integration grounding, load `references/engineering-quality-model.md` and gather the project rules, code reality, and proof surfaces that define the applicable quality bar.
- Keep facts, inferences, and recommendations separate. Every confirmed fact must name the exact source path or ref that supports it; every inference or recommendation is non-authoritative until the user accepts it.
- Use `Return To: plan` when grounding was requested before `proposal-ready`, or whenever an option, recommendation, or gap could change the proposal. Use `Return To: lock` only when the caller supplied an already-confirmed proposal and grounding found no plan-changing decision or gap.
- Leave unresolved choices in `Blocking Gaps`; the plan stage must present them to the user, and the finalize stage may copy only confirmed facts and user-approved recommendations.

## Load As Needed

- `references/engineering-quality-model.md`

## Requirements

- Use this skill only after the requirement intent is settled enough to know what repository facts need grounding.
- Keep the repository work read-only and do not create, edit, or stage files.
- Output relevant paths, viable options, unresolved gaps, validation surfaces, and a concise handoff that the finalize stage can cite.
- Each `Confirmed Facts` item must cite the source path or ref it came from and must not include inferred intent, preference, plan decisions, or implementation recommendations.
- Put repository observations that require interpretation under `Inferences` and label them non-authoritative.
- Put possible implementation choices under `Options Considered`; put the recommended option and rationale in `Recommended Handoff` without marking it accepted; put unresolved decisions in `Blocking Gaps`.
- Include `Source Material` with only the refs actually used, such as the current conversation, a GitHub issue URL, a reviewed solution package, or a prior grounding brief.
- Use the generic inspect stage only when no specialized grounding producer owns the domain. For activity solution work, direct activity requirement-to-solution replaces generic grounding; for Go refactor planning, direct Go refactor planning replaces generic grounding.
- Do not treat a plan draft as the authoritative requirement source. Cite the original source material and any reviewed grounding handoff separately.

## Output

- Return the grounding handoff with `Return To`, Source Material, Confirmed Facts, Inferences, Options Considered, Recommended Handoff, Validation Surfaces, and Blocking Gaps.