원클릭으로 Manus에서 모든 스킬 실행

specification-review

스타6

포크1

업데이트2026년 7월 22일 13:29

Evidence boundary: Use when a fixed spec candidate needs a risk-triggered or explicitly requested read-only review. Own anchored findings and a PASS, CONCERNS, or FAIL verdict against current evidence and authorities; Skip when root self-review, editing, repair, or open-ended spec authoring is sufficient.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

Dankosik

Dankosik/go-service-template-rest

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

Specification Review

Must read Specification Review; it owns the evidence boundary, verdict consequences, and stop rule. Falsify the current fixed candidate read-only after reconstructing affected behavior from the accepted brief, research, runtime/generated contracts, and repository or consumer surfaces. Report only surviving anchored findings and the evidence boundary; do not emit per-lens receipts or pad a clean review. Missing policy ends with a named Specification Decision handoff; conformance Review starts separately after acceptance. Stop with PASS, CONCERNS, or FAIL; leave repair to the owning author.

이 저장소의 다른 Skills

같은 저장소

go-systematic-debugging

Dankosik/go-service-template-rest

Root cause: Use when a Go bug, flaky test, build failure, hang, deadlock, timeout incident, or production regression needs causal diagnosis. Own the first broken invariant and, only when authorized, the smallest causal fix and replayed proof; Skip when feature implementation, unresolved policy design, broad review, or claim-only verification is primary.

2026-07-266

pre-spec-challenge

Dankosik/go-service-template-rest

Pressure-test: Use when existing research or framing needs a few independent, discriminating questions before specification or planning. Own hidden assumptions, ownership, failure semantics, irreversible consequences, and rollout risk, plus the next owner; Skip when framing is blank, ordinary spec review is needed, or one isolated high-impact approval question is primary.

2026-07-266

spec-clarification-challenge

Dankosik/go-service-template-rest

Approval question: Use when one candidate-spec decision is high-impact, hard to reverse, or explicitly challenged. Own a read-only pressure test with evidence, options, a recommended option, and decision owner; Skip when framing is blank, whole-spec review is needed, or the clarification is low-impact.

2026-07-266

spec-first-brainstorming

Dankosik/go-service-template-rest

Problem frame: Use when a chosen or mostly chosen feature/refactor direction still needs an engineering-ready behavior delta, scope, constraints, assumptions, and readiness decision. Own that frame, its decided defaults, surviving user-owned questions, challenge routing, and next owner; Skip when raw ideation, final design decisions, or task breakdown is primary.

2026-07-266

go-delivery-platform

Dankosik/go-service-template-rest

Delivery platform: Use when CI/CD gates, release trust, drift controls, containers, migrations, or rollout policy needs a decision, or when changed delivery controls need conformance review. Own delivery acceptance and review; Skip when API, data, security, reliability, or pipeline implementation is primary.

2026-07-256

go-test-strategy

Dankosik/go-service-template-rest

Test strategy: Use when accepted behavior needs risk scenarios, proof levels, deterministic oracles, or executable gates, or when changed tests and validation evidence need review. Own proof design and test conformance; Skip when behavior is unresolved, tests must be implemented, or completion claims need validation.

2026-07-256

원클릭으로 모든 스킬 실행

name	specification-review
description	Evidence boundary: Use when a fixed spec candidate needs a risk-triggered or explicitly requested read-only review. Own anchored findings and a PASS, CONCERNS, or FAIL verdict against current evidence and authorities; Skip when root self-review, editing, repair, or open-ended spec authoring is sufficient.