requirements

Files (1)

• SKILL.md

SKILL.md (first lines)

# PREPARE / Requirements

## 目的

実装前に「何を作るか」「何を守るか」「何を証明するか」を一度だけ決める。

所有するもの:

- Goal / In scope / Out of scope
- `ACxx` Acceptance Criteria
- `IVxx` Preserve / Invariant
- relevant requirement dimensions
- material assumptions
- Spec Confidence
- Risk / max observed Risk
- Required Controls
- compact Coverage Map
- `TCxx` Verification plan
- 必要十分な Impact summary

`C0` のままImplementationへ進まない。

## Instruction priority / autonomy

current explicit user instructionを、一般的なSkill guidanceより優先する。Safety invariantは別。

ユーザーがすでに許可したread-only discovery、reversible repository edit、review / fix、tests / verification、branch作成、requested / implied PR create/updateについて、このSkillだけを理由に追加permissionを要求しない。

質問やHuman Gateの前に、まず次を終える。

1. cheapな許可済みdiscovery
2. source priorityに沿った仕様復元
3. reversibleな準備
4. concrete alternativesとmaterial differenceの提示

その上でmaterial choiceが残る時だけC0としてHuman Gateへ進む。

## Context discipline

PREPARE後にsource本文を後工程へコピーしない。

- authoritative sourceはURL / path / Issue comment等の参照だけ残す
- AC / IV / TCはIDで引き継ぐ
- unchangedなGoal / scope / Risk / Controlsを各stageで再要約しない
- source再読はcontract conflict / requirements gap / unbounded impact時だけ

探索は狭く始める。

1. symbol / filename search
2. direct definition
3. direct caller
4. direct test
5. materialな未解決がある時だけ拡張

「漏れが怖いから最初から全repoを読む」はdefaultにしない。

## Mid-turn steering

作業中に追加ユーザー指示が来たら、current explicit user instructionとして取り込む。

- affected Goal / scope / AC / IV / TC / Risk / Controlsだけ更新
- unaffected contractとsame-content Evidenceは保持
- PREPAREを最初から無条件にやり直さない
- material choiceが新たに発生した時だけHuman Gateを検討

## Workspace Preflight

repository fileを変更するlocal taskでは `skills/workspace-preflight/SKILL.md` を使う。

GitHub connector等のAPI writeでは、専用task branch・base=`main`・task identity確認を同等Evidenceとする。

## Spec Confidence

- `C2 confirmed`: 目的・期待結果・主要ACが明確でmaterial conflictなし
- `C1 reconstructed`: docs / tests / current patternからmaterial choiceなしに復元可能
- `C0 unclear`: authorized discovery後も複数の妥当な成果物がありmaterial choiceが残る
- `C0 conflicted`: source reconciliation後もdesired stateについてauthoritative sourceが矛盾

Source priority:

1. current user instruction
2. latest explicitly approved spec / ADR
3. current Issue / comments
4. canonical docs
5. tests
6. current implementation / pattern

現在仕様が「BからAへ変更」と明示する場合、実装Bとの差はexpected deltaでありconflictではない。

## Material assumptions

実装結果を変えうる推測だけ記録する。

- cheapに確認できる → 実装前に確認
- sourceから一意に復元できる → C1 evidence
- authorized discovery後も複数のmaterial choiceが残る → C0

特にRe:Meでは次の意味を推測で決めない。

- sealed / unsealed visibility
- sent letter immutability
- delivery / notification state
- ownership / authorization
- exact scheduling privacy
- reply → future thread semantics

## Requirement completeness scan

runtime behavior変更では次を一度だけ `relevant` / `not_applicable` へ分類する。

- happy path
- boundary
- error / failure
- empty / loading
- auth / ownership
- persistence / state transition
- caller compatibility
- concurrency / idempotency
- navigation / accessibility

From hondasports/Re-Me, MIT.

More from hondasports/Re-Me