Use this skill only for pull requests, merge requests, branch diffs,
or commit ranges from repositories the user trusts. This skill is
optional and is not required for the core Spec Loop planning workflow.
If trust is unclear, stop and ask before fetching provider or Git
content.
Follow
for the full trust-boundary and
prompt-injection-handling rules.
Before work:
- read
../spec-loop-plan-task/SKILL.md
- read
../spec-loop-plan-task/task-file-constitution.md
- apply those shared conventions where they fit retrospective review
work, but do not apply the short planning path, task-file lifecycle
routing, or the normal approval gate to the
reviewed change itself;
- then read review-guidance.md.
Optional compact example:
examples/example-review-settings-loader.md.
Use it as a pattern collection for structure, area-wise outcome synthesis, and reconstructive
, not as a required review size.
= authoritative source for review purpose, evidence, file structure,
section semantics,
labels,
behavior, assessment style,
intent-vs-implementation analysis, tone, translation rules, diagram rules, sharing variant behavior.
= orchestration/entry-point only, not second guidance doc.
Reconstruct already-implemented work as the retrospective Spec Loop
review artifact that should have existed, then add AI assessment and
recommendations.
Do not treat the change as waiting at the normal PLAN -> IMPLEMENTATION
gate.
Use read-only provider commands for evidence when available:
- for GitHub
- for GitLab, including self-hosted GitLab when available
Detect provider from explicit review reference first. If unclear, inspect repo origin/remote host.
If provider, evidence source, or comparison range still unclear, stop and ask.
Write local review artifacts under
.
If the user wants a provider-specific sharing variant, follow
to decide whether a local sibling variant is needed or whether the canonical artifact can be reused directly.
Posting to the provider is outside this skill.