devendra-skill-package 1.0.2

package/.github/skills/test-case-validator/examples/example-2-automated-frontend-suite/output-report.md

@@ -0,0 +1,274 @@
+# Test Case Validation Report — Beta Features Toggle
+
+Generated: 2026-07-08 · Project Profile: `frontend_automated` (auto-detected
+— `TEST_CASE_INPUT` matched a Jest source glob with React component
+imports) · BRD Mode: **Combined Spec Mode** (no `BRD_INPUT` provided;
+`input-spec.md` serves as both User Story and BRD source)
+
+## 1. Executive Summary
+
+This validates 9 in-scope automated tests (across 5 files) against 4
+functional requirements, 3 acceptance criteria, and 2 success criteria in
+`input-spec.md`. **Headline finding**: every individual piece of this
+feature is unit-tested and green — persistence, the toggle component, the
+entry-card component, and the deep-link guard all pass their own tests in
+isolation — but the Home screen's actual, real-preference-driven decision to
+show or hide the Beta Dashboard entry card (FR-003) is never exercised by
+any test. This is a textbook **Gated-Behavior Wiring Gap** (Rule 16): a user
+could toggle the feature on, the toggle would correctly persist `true`, and
+the entry card would still never appear, because nothing verifies the Home
+screen actually reads that persisted value — and every existing test would
+stay green.
+
+**Scope**
+
+| Category | Applicable? | Reason if N/A |
+|---|---|---|
+| Database Coverage | N/A | `frontend_automated` profile — preference persistence uses local storage, covered under Backend/Data-Layer Coverage instead |
+| Browser Compatibility, Localization | N/A | `frontend_automated` profile default exclusions; not in scope of this spec |
+| All other Rule 2-11 categories | Applicable | |
+
+**Configuration used**: Project Profile `frontend_automated` (auto-detected)
+· BRD Mode: Combined Spec Mode · Scoring weights: default.
+
+## 2. Requirement Traceability Matrix
+
+| Requirement ID | Requirement | Mapped Test Cases | Status | Observation |
+|---|---|---|---|---|
+| FR-001 | Toggle defaults off | `betaFeaturePreference.test.ts::...defaults to false...(FR-001)` (T1), `BetaFeatureToggle.test.tsx::...renders as off by default` (T2) | Full | — |
+| FR-002 | Toggling persists preference | `betaFeaturePreference.test.ts::...(FR-002)` ×2 (T1) | Full | — |
+| FR-003 | Entry card shown/hidden by real preference; tap navigates | `BetaDashboardEntryCard.test.tsx` ×2 (T2, logic-level only) | **Partial** | Component renders and its `onClick` fires correctly in isolation, but no test confirms `HomeScreen` actually reads the real preference and conditionally renders/hides this component — see §17 |
+| FR-004 | Deep-link redirect when preference is false | `betaDashboardGuard.test.ts::...(FR-004)` ×2 — both true/false states (T1) | Full | Genuine integration-level evidence — the guard test drives the real preference value, not a mock |
+| US-01-AC1 | Toggle on → persisted + entry card shown | betaFeaturePreference tests + BetaDashboardEntryCard tests | Partial | Persistence half is Full; entry-card-on-real-Home half is the FR-003 wiring gap |
+| US-01-AC2 | Toggle off → entry card hidden | Same as AC1 | Partial | Same wiring gap, inverse direction |
+| US-01-AC3 | Deep link while off → redirect to Home | `betaDashboardGuard.test.ts` | Full | — |
+| SC-001 | Never-toggled user sees no entry card | None directly | Partial | Depends on the same untested Home-screen wiring as FR-003 |
+| SC-002 | Toggle-on survives reload, entry card still shown | `betaFeaturePreference.test.ts` (persistence only) | Partial | Persistence confirmed; post-reload Home rendering not confirmed |
+
+**Excluded from this RTM (correctly, not as orphans)**: `HomeScreen.test.tsx`'s
+"shows the standard home content" and "shows the refresh button" — these
+test pre-existing Home screen behavior unrelated to beta features and are
+out of this spec's scope, not orphan test cases for *this* feature.
+
+## 3. User Story Validation
+
+| Story | Priority | ACs Covered | Status |
+|---|---|---|---|
+| US-01 — Enable Beta Features | P2 | 1 Full / 2 Partial of 3 | Partial |
+
+## 4. BRD Validation
+
+**N/A — Combined Spec Mode.** No separate BRD was provided; `input-spec.md`
+serves as the sole requirements source and is fully covered by Section 2.
+
+## 5. Acceptance Criteria Validation
+
+| AC | Positive | Negative | Status |
+|---|---|---|---|
+| AC1 (toggle on) | Partial — persistence yes, real-Home rendering no | n/a | Partial |
+| AC2 (toggle off) | Partial — same gap, inverse | n/a | Partial |
+| AC3 (deep link while off) | n/a | ✓ `betaDashboardGuard.test.ts` | Full |
+
+## 6. Frontend Coverage Report
+
+| Category | Status | Evidence |
+|---|---|---|
+| UI Rendering | Full | Toggle and entry-card components both render-tested |
+| Button Clicks | Full | Toggle `onToggle` and entry-card `onClick` both tested |
+| Navigation | Partial | Deep-link redirect (FR-004) fully tested; entry-card-triggered navigation to Beta Dashboard is asserted only as a called callback, not as an actual route change |
+| Loading / Empty / Error States | N/A | Not applicable to this feature — no async load in the toggle flow |
+| Accessibility, Keyboard Navigation | Missing | Not referenced in any test in the provided suite |
+
+## 7. Backend / Data-Layer Coverage Report
+
+*(Reinterpreted per `VALIDATION_RULES.md` Rule 3's no-real-backend note — no
+server-side component exists for this feature; persistence is local.)*
+
+| Category | Status | Evidence |
+|---|---|---|
+| Preference persistence (write) | Full | `betaFeaturePreference.test.ts` |
+| Preference persistence (read, at Home-mount time) | **Missing** | No test confirms `HomeScreen` reads the persisted value on mount — see §17 |
+| Route guard logic | Full | `betaDashboardGuard.test.ts` |
+
+## 8. Functional Coverage Report
+
+| Dimension | Status |
+|---|---|
+| Positive | Partial — see FR-003 gap |
+| Negative | Full — off-state and redirect-while-off both tested |
+| Boundary | N/A — no numeric/length limits in this feature |
+| Business Rule | N/A — see Section 12 |
+
+## 9. API Coverage
+
+N/A — this feature has no network API surface.
+
+## 10. Database Coverage
+
+N/A — see Scope table, Section 1.
+
+## 11. Security Coverage
+
+No security-sensitive behavior in this feature beyond the deep-link guard
+(FR-004), which is fully and correctly tested at the integration level.
+
+## 12. Business Rule Coverage
+
+No calculation, eligibility, or approval-flow business rules are documented
+in this spec — this feature is a preference toggle with a visibility gate,
+not a business-rule-bearing feature. Section marked complete by default
+(nothing to test) rather than silently omitted.
+
+## 13. Missing Scenario Report
+
+| Category | Applicable? | Present? | Affected Requirement(s) | Note |
+|---|---|---|---|---|
+| Refresh / Reload | Yes | No | SC-002 | No test confirms the entry card survives a simulated app reload with the preference already persisted true |
+| Race Condition | Yes | No | FR-002 | Rapid double-toggle (on-then-off before the first persist completes) is untested |
+
+## 14. Duplicate Test Case Report
+
+No duplicate test cases found across the 9 in-scope tests.
+
+## 15. Test Case Quality Report
+
+| Test Case | Issue | Impact |
+|---|---|---|
+| `BetaFeatureToggle.test.tsx`, `BetaDashboardEntryCard.test.tsx` (4 tests) | No inline `(FR-NNN)` tag, relying on Tier-2 structural mapping | Low — mapping is still `confirmed`-tier via unambiguous folder structure, but if this module ever splits into more files, structural mapping could become ambiguous; recommend adding explicit tags proactively |
+
+## 16. Risk Coverage Report
+
+| Requirement/Feature | Risk Tier (+ why) | Test Count | Meets Minimum? |
+|---|---|---|---|
+| FR-003 (entry card visibility) | Medium — a visible-feature bug, not security/financial, but affects every user of the feature | 2 (both logic-level only) | Meets numeric minimum (3) — no, 2 present; **and** neither is integration-level — see §17 |
+| FR-004 (deep-link guard) | Medium — prevents unauthorized early access to beta functionality | 2 | Yes, and both are integration-level |
+
+## 17. Gated-Behavior Wiring Report
+
+| Requirement ID | Gate Condition | Logic-Level Test | Integration-Level Test | Status | Severity |
+|---|---|---|---|---|---|
+| FR-003 | `betaFeaturesPreference === true` read by `HomeScreen` to decide whether to render `BetaDashboardEntryCard` | `BetaDashboardEntryCard.test.tsx` (component renders and fires `onClick` when directly mounted) | **None** — no `HomeScreen.test.tsx` test sets the real preference to `true`/`false` and asserts the card's presence/absence | **Wiring Gap** | Medium |
+| FR-004 | `betaFeaturesPreference === false` read by the Beta Dashboard route guard | `betaDashboardGuard.test.ts` (both states) | `betaDashboardGuard.test.ts` (both states) — this test *is* the integration point | Full | — |
+
+This is the report's central finding: FR-003 and FR-004 look identically
+"done" by ordinary traceability counting (each has 2 mapped tests), but only
+FR-004's tests actually exercise the real gate. FR-003's tests exercise a
+component that *could* be wired correctly or incorrectly with no observable
+difference in test results either way.
+
+## 18. Observation Report
+
+### Beta Dashboard entry card's visibility is never tested against the real preference (FR-003)
+**Severity**: Medium
+**Evidence**: `BetaDashboardEntryCard.test.tsx` renders the component
+directly and asserts its label and `onClick` behavior. No test in
+`HomeScreen.test.tsx` (or anywhere else in the suite) sets the real
+persisted `betaFeaturesPreference` value and asserts the card's presence at
+`true` and absence at `false`.
+**Affected Requirement(s)**: FR-003, US-01-AC1, US-01-AC2, SC-001, SC-002
+**Affected Test Case(s)**: `BetaDashboardEntryCard.test.tsx` (covers the
+component, not the wiring), `HomeScreen.test.tsx` (covers unrelated Home
+behavior, not this feature)
+**Impact**: A future refactor of `HomeScreen`'s mount logic (e.g. a typo in
+the preference-key string, a forgotten `useEffect` dependency, an
+accidentally-removed conditional) would break this feature for every user
+who enables it, and every existing test — including this feature's own
+"passing" ones — would remain green.
+**Recommendation**: Add a `HomeScreen.test.tsx` test that mocks the
+preference read to `true`, renders `HomeScreen`, and asserts the entry card
+is present; and a second test with the mock at `false` asserting it's
+absent. Model this directly on `betaDashboardGuard.test.ts`'s pattern, which
+already does this correctly for FR-004.
+**Suggested Test Case**: "Given the beta-features preference is `true`, when
+`HomeScreen` mounts, then the Beta Dashboard entry card is rendered; given
+the preference is `false`, when `HomeScreen` mounts, then it is absent."
+
+### Reload/persistence-survival scenario (SC-002) untested end to end
+**Severity**: Low
+**Evidence**: `betaFeaturePreference.test.ts` confirms the write; no test
+simulates a reload (fresh mount reading the already-persisted value) and
+confirms the Home screen reflects it — this is really the same root
+integration point as the Medium-severity finding above, so consider it
+resolved by the same fix rather than a separate one.
+**Affected Requirement(s)**: SC-002
+**Affected Test Case(s)**: None directly
+**Impact**: Low incremental risk beyond the finding above — same underlying
+gap.
+**Recommendation**: The `HomeScreen` test added for the finding above
+naturally covers this too, since it mounts fresh with a pre-set preference
+value (functionally equivalent to "after reload").
+**Suggested Test Case**: Covered by the suggested test above.
+
+## 19. Recommendations
+
+1. **Add the two `HomeScreen` integration tests** (real preference → entry
+   card presence/absence) — closes the report's central finding and both
+   observations above in one change.
+2. **Add explicit `(FR-NNN)` tags** to `BetaFeatureToggle.test.tsx` and
+   `BetaDashboardEntryCard.test.tsx` — low effort, removes reliance on
+   structural (Tier 2) mapping.
+3. **Add a rapid-double-toggle test** for FR-002 if this preference write is
+   not already debounced/sequenced at the state-management layer.
+
+## 20. Overall Quality Score
+
+| Category | Weight | Fraction | Points |
+|---|---|---|---|
+| Requirement Traceability | 25 | 0.72 | 18 |
+| Coverage | 20 | 0.78 | 16 |
+| Acceptance Criteria | 15 | 0.67 | 10 |
+| Frontend Coverage | 10 | 0.75 | 8 |
+| Backend/Data-Layer Coverage | 10 | 1.00 | 10 |
+| Business Rules | 10 | 1.00 | 10 |
+| Quality | 5 | 0.89 | 4 |
+| Duplicates | 5 | 1.00 | 5 |
+| **Total** | | | **81** |
+
+A genuinely well-tested small feature — no duplicates, no missing business
+rules, strong frontend/data-layer scores — held out of `PASS` almost
+entirely by one Rule 16 finding. This is the intended behavior of Rule 16:
+it should be possible for an otherwise-excellent suite to fall short of 95
+specifically because of an unverified wiring point, since that's exactly
+the kind of gap that erodes confidence in an all-green test run.
+
+## Final Summary
+
+TEST CASE VALIDATION SUMMARY
+
+Project Profile: frontend_automated
+BRD Mode: Combined Spec Mode
+
+Total Requirements: 4
+Covered Requirements: 4 (3 Full + 1 Partial)
+Missing Requirements: 0
+
+Total User Stories: 1
+Covered User Stories: 1 (Partial)
+
+Total Acceptance Criteria: 3
+Covered Acceptance Criteria: 3 (1 Full + 2 Partial)
+
+Total Test Cases: 9 (in scope; 2 additional pre-existing tests excluded as out of scope)
+
+Requirement Coverage: 72%
+Acceptance Criteria Coverage: 67%
+Frontend Coverage: 75%
+Backend/Data-Layer Coverage: 100%
+Functional Coverage: ~85%
+Negative Coverage: 100%
+Boundary Coverage: N/A — no boundary conditions in this feature
+Business Rule Coverage: N/A — no business rules documented
+API Coverage: N/A — no network API surface
+Database Coverage: N/A — local persistence only, see Backend/Data-Layer
+Security Coverage: Full (only security-relevant path is FR-004, fully tested)
+Automation Coverage: 100% (all 9 are automated source tests)
+
+Duplicate Test Cases: 0
+
+Missing Scenarios: 2 categories (see Section 13)
+
+Gated-Behavior Wiring Gaps: 1 (FR-003 — see Section 17)
+
+Overall Quality Score: 81/100
+
+Status: **NEEDS IMPROVEMENT**

package/.github/skills/test-case-validator/prompts/00-applicability-resolution.md

@@ -0,0 +1,61 @@
+# Prompt 00 — Applicability Resolution
+
+**Input**: `TEST_CASE_INPUT` (for auto-detection signal), `PROJECT_PROFILE_INPUT`
+(if explicit), `config/default.config.yaml`.
+**Output**: `RESOLVED_PROFILE` (the active profile name) and
+`APPLICABILITY_MAP` (category → `Applicable` | `N/A` + reason), consumed by
+every later step per `VALIDATION_RULES.md` Rule 17.
+
+This is Rule 17's procedure. It has its own file — and runs first, before
+extraction even completes — because every other rule (2 through 11, and the
+Missing-Scenario categories in Rule 7) depends on knowing what's in scope
+*before* it can correctly classify anything as `Missing` rather than `N/A`.
+Rule 1 (Requirement Traceability) does not depend on this step — it
+operates on specific requirement IDs, not on the category checklist — but
+running this step before Rule 1 anyway is harmless and keeps the pipeline's
+step order simple to reason about.
+
+## Procedure
+
+1. **Resolve the profile.**
+   - If `PROJECT_PROFILE_INPUT` names a profile in
+     `config/default.config.yaml`'s `profiles` map, use it directly.
+   - Otherwise, evaluate `auto_detect.order` (see `CONFIGURATION.md` for the
+     exact structure) top to bottom against `TEST_CASE_INPUT`'s shape; use
+     the first matching rule's profile. If none match, use
+     `auto_detect.fallback_profile`.
+   - Record which path was taken (`explicit` vs. `auto-detected`, and if
+     auto-detected, which signal matched) — this must be stated in the
+     Executive Summary per `templates/executive-summary.md`.
+
+2. **Build `APPLICABILITY_MAP`.** For every category referenced anywhere in
+   `VALIDATION_RULES.md` Rules 2, 3, 7, and 9-11, look up its entry in
+   `CONFIGURATION.md`'s Applicability Matrix for `RESOLVED_PROFILE`:
+   - Present in the resolved profile's `disabled_categories` (config key,
+     snake_case) → `N/A`, with the matrix's stated reason.
+   - Not present → `Applicable`.
+   - **Not found in the Applicability Matrix at all** (a category newly
+     added to `VALIDATION_RULES.md` without a corresponding matrix row) →
+     default to `Applicable`, and separately record it as
+     `unclassified: true` — this must surface in the final report's
+     Recommendations section ("category X is not yet classified in the
+     Applicability Matrix — please confirm and add it"), per
+     `VALIDATION_RULES.md` Rule 17 step 4. Do not silently guess which
+     profiles should exclude it.
+
+3. **Category name mapping.** Config keys are snake_case
+   (`browser_compatibility`); prose/report category names are Title Case
+   ("Browser Compatibility"). Convert deterministically
+   (`snake_case → Title Case` by replacing underscores with spaces and
+   capitalizing each word) — do not introduce a second, inconsistent
+   naming scheme. If a category's natural prose name doesn't
+   round-trip cleanly through this conversion (e.g. an acronym like "API"),
+   the Applicability Matrix's prose column is authoritative for display;
+   the config key is authoritative for matching.
+
+## Output
+
+`APPLICABILITY_MAP`: one entry per category —
+`{ category: string, applicable: boolean, reason: string | null, unclassified: boolean }`.
+Feed this into every later rule; a category never gets a second, ad hoc
+applicability judgment call inside an individual rule's prompt file.

package/.github/skills/test-case-validator/prompts/01-extraction-user-story.md

@@ -0,0 +1,58 @@
+# Prompt 01 — User Story Extraction
+
+**Input**: `USER_STORY_INPUT` (raw document, any supported format).
+**Output**: `US_MODEL` conforming to `TRACEABILITY_ENGINE.md` §1's
+`UserStory`/`AcceptanceCriterion`/`Requirement` shapes.
+
+## Procedure
+
+1. **Detect structure first.** Is this a prose user-story document ("As a
+   ..., I want ..., so that ..."), a Spec-Kit-style `spec.md` (User Stories +
+   `FR-NNN` Functional Requirements + `SC-NNN` Success Criteria), or a
+   requirements table? The extraction target is the same regardless; the
+   parsing path differs.
+
+2. **Extract per user story**:
+   - ID (explicit, or synthesize `US-<n>` per `TRACEABILITY_ENGINE.md` §2.5)
+   - Title / one-line summary
+   - Priority (P1/P2/... or High/Medium/Low if stated; `null` if absent —
+     never invent one)
+   - Actor(s) / role(s)
+   - Business goal ("so that ...")
+   - Acceptance Criteria — extract every "Given/When/Then" or numbered
+     criterion as its own `AcceptanceCriterion`, synthesizing
+     `<story-id>-AC-<m>` IDs if the source doesn't number them
+   - Functional Requirements referenced or implied within the story (if the
+     document has a separate FR-NNN list, cross-link rather than duplicate)
+   - Non-Functional Requirements (performance, security, accessibility,
+     compliance) stated for this story specifically
+   - Business Rules embedded in the story's prose
+   - Validation Rules (input constraints, format rules)
+   - Workflow / state-transition steps described
+   - Calculations described (capture the exact formula text verbatim — do
+     not paraphrase a formula, paraphrasing risks silently changing it)
+   - APIs referenced (endpoint names/paths if given)
+   - UI elements referenced (screens, components, specific labels/copy)
+   - Navigation flow (what leads to this screen, what it leads to)
+   - Dependencies (on other stories, other systems, other teams)
+   - Error handling described
+   - Security requirements described (auth, authorization, data handling)
+
+3. **Also extract document-level items** not tied to one story: a shared
+   glossary, cross-cutting NFRs, an explicit Out-of-Scope section (capture
+   this — Rule 1's Document Integrity check needs to know what was
+   deliberately excluded vs. accidentally uncovered).
+
+4. **Flag extraction uncertainty inline.** If a sentence could be read as
+   either a requirement or a design note, extract it but mark
+   `category: "ambiguous"` rather than silently picking one classification —
+   surface this in the Executive Summary's Document Integrity note.
+
+## Do Not
+
+- Do not infer an acceptance criterion that "should" exist based on the
+  story's title if it isn't written in the document.
+- Do not merge two similarly-worded stories into one unless the document
+  itself presents them as one.
+- Do not resolve a `[NEEDS CLARIFICATION]`-style marker in the source
+  document — extract it as-is and flag it as an open item.

package/.github/skills/test-case-validator/prompts/02-extraction-brd.md

@@ -0,0 +1,64 @@
+# Prompt 02 — BRD Extraction
+
+**Input**: `BRD_INPUT`, if provided.
+**Output**: `BRD_MODEL` conforming to `TRACEABILITY_ENGINE.md` §1's
+`Requirement` shape (plus the BRD-specific fields below).
+
+## Step 0 — Combined Spec Mode Check
+
+If `BRD_INPUT` was not provided (per `SKILL.md` step 2, `COMBINED_SPEC_MODE =
+true`): **do not run this extraction**. Produce
+`BRD_MODEL = { combined_spec_mode: true, requirements: [] }` and move on.
+Report sections 4 and 10 (BRD Validation, Database Coverage if it was
+BRD-sourced) must read this flag and render
+`N/A — Combined Spec Mode` rather than iterating an empty list and reporting
+0% coverage.
+
+## Procedure (when a separate BRD exists)
+
+1. **Extract per requirement**:
+   - Requirement ID (explicit; never synthesize a BRD ID without flagging it
+     as synthesized — BRD IDs are usually load-bearing elsewhere, e.g. in a
+     compliance sign-off, so guessing one is riskier than guessing a user
+     story ID)
+   - Requirement text (verbatim for calculations/eligibility rules)
+   - Functional vs. Non-Functional classification
+   - Business Rules (eligibility, calculation, workflow, approval,
+     status-transition — capture each as its own `BusinessRule` entry per
+     `VALIDATION_RULES.md` Rule 9, with the exact source citation)
+   - Process Flow / Status Flow / Decision Trees — extract every branch of a
+     decision tree individually; a tree with 4 branches and only the "happy"
+     branch documented in prose is itself a Document Integrity finding
+   - Approval Flow (who approves, what triggers escalation)
+   - Eligibility Rules
+   - UI Rules (if the BRD specifies UI behavior distinct from the user
+     story — common when BRD is the compliance-owned document and user
+     story is the product-owned one; note any conflict between the two as
+     a Document Integrity finding, never silently prefer one)
+   - API Details (contract-level: endpoint, method, request/response shape,
+     status codes)
+   - Integration Points (external systems, third-party services)
+   - Database Requirements (entities, retention rules, migration
+     implications)
+   - Configuration Rules (feature flags, environment-specific behavior)
+   - Exception Handling
+   - Security requirements
+   - Compliance requirements (regulatory citations if given — extract the
+     citation verbatim, do not summarize a legal requirement in your own
+     words)
+   - Logging / Audit requirements
+   - Reporting requirements
+
+2. **Cross-reference against `US_MODEL`** (already extracted by Prompt 01):
+   for every requirement mentioned in both documents, confirm the two
+   descriptions agree. Any material disagreement is a Document Integrity
+   finding (Rule 1) — cite both locations, do not adjudicate which is
+   "correct" unless one document explicitly supersedes the other.
+
+## Do Not
+
+- Do not treat a BRD requirement's absence from the user story (or vice
+  versa) as an error by default — a BRD legitimately contains
+  requirements no single user story covers (e.g. cross-cutting compliance
+  rules). Only flag a genuine contradiction, not a difference in scope.
+- Do not paraphrase a compliance/legal citation.

package/.github/skills/test-case-validator/prompts/03-extraction-test-cases.md

@@ -0,0 +1,92 @@
+# Prompt 03 — Test Case Extraction
+
+**Input**: `TEST_CASE_INPUT` — either manually-authored test cases or a
+path/glob to automated test source files.
+**Output**: `TEST_CASE_MODEL`, a list of `TestCase` per
+`TRACEABILITY_ENGINE.md` §1.
+
+## Step 0 — Determine Input Shape
+
+- Matches a source-code glob or is explicitly framed as "our test suite" /
+  "our test files" → **Automated Source path** (§B).
+- Is a spreadsheet, CSV, Markdown table, or Gherkin `.feature` file with
+  human-authored steps → **Manual path** (§A).
+- Ambiguous → ask, or default to Manual path and state the assumption in the
+  Executive Summary (per Auto Mode conventions of the calling context —
+  don't silently guess without saying so).
+
+## A. Manual Path
+
+Extract per row/case: Test Case ID, Title, Module, Requirement ID(s), User
+Story, BRD Reference, Preconditions, Test Data, Steps, Expected Result,
+Priority, Severity, Test Type, Automation Candidate, Owner, Tags, Status.
+Any column absent from the source is `null`/`not tracked` — never fabricate
+a plausible-looking value for a missing Priority or Owner.
+
+Infer `Test Type` (positive/negative/boundary/...) from the steps + expected
+result when not explicitly labeled, but mark it `inferred` (see
+`TRACEABILITY_ENGINE.md` confidence tiers — the same confidence-tiering
+concept applies to inferred test type, not just inferred requirement
+mapping).
+
+## B. Automated Source Path
+
+This is the extraction procedure v1 of this skill did not define — added in
+v2.0.0 after real use against a Jest/TypeScript suite; adapt the pattern
+names below to the actual framework/language found.
+
+1. **Locate test declarations.** Search recursively for the target
+   language's test-block syntax:
+   - JS/TS (Jest/Mocha/Vitest): `describe(...)`, `it(...)`, `test(...)`
+   - Python (pytest): `def test_*`, `class Test*`
+   - Java/Kotlin (JUnit): `@Test`-annotated methods, nested `@Nested` classes
+   - Go: `func Test*(t *testing.T)`
+   - Ruby (RSpec): `describe`, `context`, `it`
+   - Adapt for whatever else is present — the shape is always "a named,
+     nested grouping of individually-titled assertions."
+
+2. **Build the Test Case ID** as
+   `<relative-file-path>::<full nested block path>` (e.g.
+   `presentation/screens/HoldingsView/HoldingsViewScreen.test.tsx::HoldingsViewScreen > shows the movers carousel only when the feature flag is enabled (FR-013)`).
+   This must be stable across reruns — see `TRACEABILITY_ENGINE.md` §2.5 for
+   why line numbers are not used.
+
+3. **Title** = the innermost block's string argument, verbatim (including
+   any inline `(FR-NNN)`/`(USn ACn)` tag — this is the primary signal for
+   Tier-1 mapping in `TRACEABILITY_ENGINE.md` §2.1).
+
+4. **Steps / Expected Result** = summarize the test body: what is
+   arranged/mocked (Preconditions + Test Data), what action is taken
+   (Steps), and what is asserted (`expect(...)` or equivalent calls →
+   Expected Result). Do not just paste raw code as the "steps" — translate
+   it into the same human-readable shape a manual test case would have, so
+   Rule 5/6/11 can be applied uniformly regardless of source.
+
+5. **Requirement mapping**: run Tier 1 (explicit tag in title) → Tier 2
+   (folder/module structural match) → Tier 3 (fuzzy keyword match) per
+   `TRACEABILITY_ENGINE.md` §2. Record the tier used as `mapping_confidence`.
+
+6. **Fields not present in source code**: Priority, Severity, Owner, Tags,
+   Status, and (usually) BRD Reference have no natural home in a test file.
+   Report these as `"not tracked in this suite"` per
+   `VALIDATION_RULES.md` Rule 5 — this is a property of the team's process,
+   not a defect in any individual test, and `QUALITY_SCORING.md`'s Quality
+   fraction must not penalize a suite for a field class the language/
+   framework has no place to put, only for fields the *team's own
+   convention* implies should exist (e.g. if some tests do tag an FR and
+   others in the same file don't, that inconsistency is a legitimate Rule 11
+   finding).
+
+7. **Automation Candidate** = always `"Already Automated"` for this path —
+   don't ask whether an existing automated test "should" be automated.
+
+## Do Not
+
+- Do not run the actual test suite to determine pass/fail status as part of
+  extraction — this skill validates *coverage against requirements*, not
+  *current pass/fail health*. If the user also wants pass/fail health, that
+  is a distinct request (point them at their CI/test-runner output).
+- Do not silently drop a `.skip`/`.todo`/`@Disabled` test from the model —
+  extract it and mark `status: "disabled"`; a disabled test that would have
+  covered a requirement is a coverage gap in practice even though it exists
+  in source, and Rule 1 needs to know the difference.

package/.github/skills/test-case-validator/prompts/04-traceability-matrix.md

@@ -0,0 +1,41 @@
+# Prompt 04 — Requirement Traceability Matrix Assembly
+
+**Input**: `US_MODEL`, `BRD_MODEL`, `TEST_CASE_MODEL`.
+**Output**: `RTM` — the master list every later step reads from.
+
+## Procedure
+
+1. Build the unified requirement list: every `Requirement` from `BRD_MODEL`
+   (empty if Combined Spec Mode) plus every `UserStory`/`AcceptanceCriterion`
+   from `US_MODEL`, each retaining its `source_document` tag.
+
+2. For each item in the unified list, run the linking algorithm in
+   `TRACEABILITY_ENGINE.md` §2 against every `TestCase` in `TEST_CASE_MODEL`.
+   Record all matches found (not just the first), with their tier/confidence.
+
+3. Classify each item's `Status` per `TRACEABILITY_ENGINE.md` §4
+   (`Full`/`Partial`/`Missing`/`N/A`) — apply Rule 17's Applicability check
+   before classifying `Missing`; an inapplicable item is `N/A`, full stop.
+
+4. Populate the `Observation` field for every row that is not cleanly `Full`:
+   state *why* in one sentence (e.g. "only an `inferred_medium` match found,
+   no explicit ID reference" or "logic tested, no integration-level test —
+   see Rule 16").
+
+5. Identify orphan test cases: any `TestCase` in `TEST_CASE_MODEL` with zero
+   matches after all three tiers. List these separately — they don't get a
+   row in the main RTM (which is organized by requirement), but they must
+   appear in the report (Section 2, as a trailing "Orphan Test Cases" list,
+   or in Section 18 as their own Observation).
+
+6. Compute per-row coverage % is not applicable at the row level (a
+   requirement either has matches or doesn't) — row-level coverage nuance
+   belongs in the `Observation` field; the numeric coverage percentages
+   (Rule 13) are aggregate, computed once across the whole `RTM` in
+   `TRACEABILITY_ENGINE.md` §3, not per row.
+
+## Output Shape
+
+One `templates/rtm-row.md` row per unified requirement/AC item, grouped in
+the report by the source document's own organizing structure (by user story,
+then by BRD section if Combined Spec Mode is false).

package/.github/skills/test-case-validator/prompts/05-coverage-analysis.md

@@ -0,0 +1,46 @@
+# Prompt 05 — Coverage Analysis
+
+**Input**: `RTM`, `TEST_CASE_MODEL`, `RESOLVED_CONFIG`.
+**Output**: Filled tables for `VALIDATION_RULES.md` Rules 1-4 and 9, ready
+for Report Template sections 2-8 and 12.
+
+## Procedure
+
+1. **Run Rule 17 first** (if not already resolved earlier in the pipeline) —
+   produce the per-category Applicable/N/A determination for this project's
+   resolved profile. Every step below reads this determination before
+   reporting anything as a gap.
+
+2. **Rule 1 (Traceability)** — already substantially produced by Prompt 04;
+   this step adds the "No orphan test cases" check output and the Document
+   Integrity findings collected during Prompts 01-02.
+
+3. **Rule 2 (Frontend Coverage)** — for each Applicable category, scan
+   `TEST_CASE_MODEL` for evidence (an explicit test, or — for automated
+   source — a test whose body/assertions match the category's code-level
+   signature per `VALIDATION_RULES.md` Rule 2's automated-suite note).
+   Status per category: `Full` (multiple tests, including edge cases) /
+   `Partial` (some evidence, not exhaustive — say what's missing) /
+   `Missing` (Applicable, zero evidence) / `N/A`.
+
+4. **Rule 3 (Backend/Data-Layer Coverage)** — same procedure, reinterpreted
+   per `VALIDATION_RULES.md` Rule 3's no-real-backend note when applicable.
+
+5. **Rule 4 (Requirement Coverage breadth)** — for each requirement in
+   `RTM`, check which of the 18 test-type categories (Positive through
+   Sanity) have at least one matched test case exhibiting that type
+   (from the `test_type` field extracted in Prompt 03, or inferred from the
+   manual test case's steps/expected result).
+
+6. **Rule 9 (Business Rule Validation)** — for each `BusinessRule` extracted
+   in Prompts 01-02, locate test evidence and independently verify the
+   formula/logic match: recompute the rule's stated formula against the
+   test's own worked example/fixture values, and confirm they agree.
+   A test that merely asserts *a* value without the report-writer having
+   independently checked that value against the source formula is not
+   sufficient evidence of a "Yes" match — do the arithmetic.
+
+## Output
+
+Populates Report Template Sections 2 (partially — RTM itself comes from
+Prompt 04), 3, 4, 6, 7, 8, and 12.