@dzhechkov/skills-idea2prd 0.1.3 → 0.1.5

package/templates/.claude/skills/idea2prd-manual/SKILL.md

@@ -422,12 +422,14 @@ idea2prd-manual/
 
 | ADR | Decision | Status | Load-bearing property | Falsifying test |
 |-----|----------|--------|-----------------------|-----------------|
-| ADR-001 | [Architecture]: [choice] | Accepted | [property] | FF-0NN / [feature].feature |
-| ADR-002 | [Database]: [choice] | Accepted | [property] | FF-0NN / [feature].feature |
+| ADR-001 | [Architecture]: [choice] | Accepted | [property] | FF-NNN / [feature].feature |
+| ADR-002 | [Database]: [choice] | Accepted | [property] | FF-NNN / [feature].feature |
 ...
 
-> **Confirmation check:** every row above MUST name a load-bearing property and a real falsifying test
-> (a `FF-NNN` fitness function or a Gherkin `.feature` scenario). A blank = an incomplete ADR — go back.
+> **Confirmation check:** every row above MUST name a load-bearing property and a real falsifying test —
+> a `FF-NNN` fitness function id (3-digit, matching `references/fitness-functions-catalog.md`) or a Gherkin
+> `.feature` scenario. A blank = an incomplete ADR — go back. **Phase 5 re-checks this table** (see the
+> Phase-5 "ADR Confirmation reconciliation" step): every id named here must EXIST in the Phase-5 output.
 
 ## C4 Diagrams
 
@@ -484,7 +486,7 @@ idea2prd-manual/
 
 **Reference:** `references/pseudocode-style.md`
 
-**Псевдокод фиксирует алгоритмическую логику ДО кодогенерации — меньше неоднозначности при реализации.** (Никаких неподтверждённых процентов: любые метрики качества эмитятся только с честным тегом — см. раздел «Claim Discipline».)
+**Псевдокод фиксирует алгоритмическую логику ДО кодогенерации — кодоген реализует уже принятый дизайн, а не изобретает его по ходу.** (Никаких неподтверждённых процентов: любые метрики качества эмитятся только с честным тегом — см. раздел «Claim Discipline».)
 
 **Действие Claude:**
 ```
@@ -563,10 +565,27 @@ END FUNCTION
 ### Phase 5: Validation, Tests & AI Context [ENHANCED]
 
 **Генерирует:**
-- 5+ Fitness Functions
+- 5+ Fitness Functions (ids in the canonical `FF-NNN` 3-digit form — see `references/fitness-functions-catalog.md`)
 - 5+ Gherkin Test Scenarios
 - 8 .ai-context/ files
 
+**ADR Confirmation reconciliation (REQUIRED — consumes the Phase-3 ADR table):**
+
+Phase 5 is where each ADR's Confirmation stops being a promise. Before the Phase-5 checkpoint, iterate the
+Checkpoint-3 **ADRs Summary** table and, for EVERY ADR, verify:
+
+1. Its `Falsifying test` names a concrete artifact — a `FF-NNN` id or a `<feature>.feature` scenario — not
+   a placeholder (`FF-NNN`, `[feature]`, `TBD`, blank).
+2. That artifact ACTUALLY EXISTS in this Phase-5 output: the `FF-NNN` id appears in the Fitness Functions
+   table (and `references/fitness-functions-catalog.md` / `scripts/fitness_validator.py`), or the `.feature`
+   file is in `docs/tests/`.
+3. The named test is tied to the ADR's **load-bearing property** — it would go RED if that property were
+   violated (not merely a generic happy-path scenario).
+
+A missing, placeholder, or property-mismatched test is an **incomplete ADR ⇒ Phase 5 is NOT signed off**:
+go back and add the fitness function / Gherkin scenario (or correct the ADR). Emit the result as the "ADR
+Confirmation Coverage" block below (every ADR row must read `✅ mapped`; any `🔴 unmapped` blocks sign-off).
+
 **Test Scenarios (Gherkin):**
 
 ```gherkin
@@ -589,10 +608,23 @@ Feature: Order Placement
 
 | ID | Rule | Target |
 |----|------|--------|
-| FF-01 | BC Independence | 100% |
-| FF-02 | Aggregate Size | ≤7 entities |
+| FF-001 | BC Independence | [target — tag MEASURED baseline or ESTIMATED from an NFR] |
+| FF-002 | Aggregate Size | [threshold — e.g. entity cap, tag ESTIMATED with its basis] |
 ...
 
+> Targets are claims: fill each with a tagged value (MEASURED baseline / ESTIMATED target), never a naked
+> perfect score. See "Authoring Discipline → Claim Discipline".
+
+## ADR Confirmation Coverage
+
+| ADR | Load-bearing property | Named test | Exists in Phase 5? |
+|-----|-----------------------|------------|--------------------|
+| ADR-001 | [property] | FF-NNN / [feature].feature | ✅ mapped |
+| ADR-002 | [property] | FF-NNN / [feature].feature | ✅ mapped |
+...
+
+> Any `🔴 unmapped` row blocks Phase-5 sign-off (the ADR named a test that does not exist here).
+
 ## Test Scenarios
 
 | Feature | Scenarios | Coverage |
@@ -650,14 +682,14 @@ so nothing fragments.
 3. For each genuinely NEW lesson, via Bash run VERBATIM (one call per lesson):
 
 ```bash
-cd <BRAIN> && dz teach "<one-line reusable lesson>" --reward 0.7 --domain idea2prd --project <BRAIN>
+cd "<BRAIN>" && dz teach "<one-line reusable lesson>" --reward 0.7 --domain idea2prd --project "<BRAIN>"
 ```
 
 4. Log how many lessons were taught (0 is a valid, honest result on a run that surfaced nothing new).
 
-> **Pin discipline:** Step 0 recall and this teach MUST hit the SAME `<BRAIN>` (project root) via
-> `--project` — if recall reads one store and teach writes another, the two stores stay separate and
-> the loop does not accumulate in a single place. This mirrors the feature-adr `args.brain` rule.
+> **Pin discipline:** Step 0 recall and this teach MUST hit the SAME absolute `<BRAIN>` (project root) via
+> `--project`, shell-quoted — if recall reads one store and teach writes another, the two stores stay
+> separate and the loop does not accumulate in a single place. This mirrors the feature-adr `args.brain` rule.
 
 ---
 

package/templates/.claude/skills/idea2prd-manual/references/adr-catalog.md

@@ -60,8 +60,9 @@
 > Its `Required automated check` MUST name a REAL Phase-5 artifact — a `FF-NNN` fitness function
 > (`references/fitness-functions-catalog.md` / `scripts/fitness_validator.py`) or a Gherkin `.feature`
 > scenario — so the decision's load-bearing property is *falsifiable*, not prose. This wires Phase 3 (ADR)
-> to Phase 5 (fitness/tests): a property an ADR names is often the one that ships untested (a recurring
-> lesson in this repo), so the Confirmation stanza forces it to name its falsifying test.
+> to Phase 5 (fitness/tests): the property an ADR names is often the one left untested (CLAIMED — harness
+> feature-adr lesson, `.claude/rules/feature-adr-ultracode.md`), so the Confirmation stanza forces it to
+> name its falsifying test.
 > An ADR whose Confirmation names no falsifying check is **incomplete** — do not accept it at Checkpoint 3.
 
 ### Supersession discipline

package/templates/.claude/skills/idea2prd-manual/references/pseudocode-style.md

@@ -4,7 +4,7 @@
 
 Pseudocode в idea2prd используется для:
 1. Точного описания алгоритмов до написания кода
-2. Снижения неоднозначности при кодогенерации в Claude Code (алгоритм зафиксирован до кода)
+2. Фиксации алгоритмической логики до кодогенерации (логика описана независимо от синтаксиса реализации)
 3. Документирования business logic
 
 ## Syntax Conventions

package/templates/.claude/skills/problem-solver-enhanced/SKILL.md

@@ -3,7 +3,7 @@ name: problem-solver-enhanced
 description: Elite problem-solving system combining first principles thinking, game theory, root cause analysis, systematic frameworks AND TRIZ inventive principles for solving complex challenges. Use when facing complex challenges with unclear solutions, strategic decisions with multiple stakeholders, problems requiring breakthrough (not incremental) solutions, trade-offs that seem impossible to resolve, competitive scenarios requiring game-theoretic analysis, system design problems, or any situation requiring both analytical rigor and inventive thinking beyond surface-level solutions.
 trust_tier: 1
 trust_tier_label: "Structured"
-trust_tier_path: "Run /bto-test to promote to Tier 2"
+trust_tier_path: "Run a BTO evaluation (see the skills-bto package) to promote to Tier 2"
 ---
 
 # Elite Problem Solver (Enhanced with TRIZ)