Qa engineering requirements skills

docs/definitions/skills.md

@@ -18,7 +18,6 @@
 - security (not yet)
 - simulation (not yet)
 - backward-compatibility (not yet)
-- scenarios-generation (not yet)
 - data-generation (not yet)
 - documentation (not yet)
 - large-file-handling (not yet)

instructions/r3/core/skills/coding-agents-prompt-authoring/SKILL.md

@@ -51,9 +51,9 @@ Also for porting prompts between agents/IDEs, or migrating rules between formats
 
 Prompt classification:
 
-- **Skill** — reusable knowledge/instructions/action/activity loaded into agents on demand
+- **Skill** — reusable knowledge/instructions/action/activity dynamically loaded into agents on demand; skill is a folder with SKILL.md file plus references and assets loaded from SKILL.md
 - **Rule** — persistent constraints added to LLM context across all agents either globally (always apply) or by description (not reliable) or by path glob (ex: *.md, *.ts), do not duplicate skill, skill is preferred, rules are actually rarely needed
-- **Agent / Subagent** — delegated specialist with fresh context, own system prompt
+- **Agent / Subagent** — delegated specialist with fresh context, own system prompt, dynamically loaded on demand
 - **Workflow / Command** — user-triggered action or multi-phase pipeline coordinating multiple prompts/agents, large workflows come with phases in separate files
 - **Template** — parameterized template prompt with variables, instructions in placeholders, validated before rendering
 - **Ad-hoc** — one-off queries, no reuse expected, go simple and freeform
@@ -130,6 +130,16 @@ Example logical flow: discover → extract+intake → blueprint → for_each_pro
 
 </core_principles>
 
+<rosetta_canonical_lists>
+Read Rosetta's canonical lists when the target IS Rosetta (repos `rosetta`, `cto-ims-kb`, `RulesOfPower`, or the `instructions` folder); skip for any other system. Use them as if already existing — they define what should be what:
+
+- `docs/definitions/workflows.md`
+- `docs/definitions/templates.md`
+- `docs/definitions/agents.md`
+- `docs/definitions/skills.md`
+- `docs/definitions/rules.md`
+</rosetta_canonical_lists>
+
 <resources>
 
 - When needed READ SKILL FILE `references/pa-knowledge-base.md` (large file, grep headers to auto-TOC and load only needed sections)

instructions/r3/core/skills/coding-agents-prompt-authoring/references/pa-rosetta.md

@@ -19,20 +19,10 @@ Rosetta workflows and commands MUST declare `Rosetta Prep Steps` as a prerequisi
 
 Spawned subagents do NOT run this startup chain: they start with only `bootstrap-alwayson.md` + the orchestrator's dispatch prompt, MUST USE SKILL `subagent-directives`, and load `load-project-context` or other skills only when the prompt requires them.
 
-# Instructions Folder Structure and Canonical Lists
+# Instructions Folder Structure
 
 Instructions folder structure is defined in `docs/definitions/folder-structure.md`.
 
-Must check canonical lists of workflows, templates, subagents, skills, rules Rosetta has or to be implemented (you must use them as if those are already exist):
-
-- `docs/definitions/workflows.md`
-- `docs/definitions/templates.md`
-- `docs/definitions/agents.md`
-- `docs/definitions/skills.md`
-- `docs/definitions/rules.md`
-
-This list above defines what should be what, you must read it.
-
 Rosetta runs with AI coding agents on top of target repository. All rosetta prompts are coding-agent-agnostic.
 
 Rosetta uses the following folders on target repository:

instructions/r3/core/skills/data-collection/references/documentation-vendor-binding.md

@@ -1,6 +1,6 @@
 # Vendor binding: Documentation vendor
 
-**Canonical vendor example: Confluence** -- capabilities (page fetch / search / child pages) and harvesting discipline below use Confluence; for another backend (Notion, SharePoint, wiki) map by capability, same method. Base SKILL.md owns the general method -- not restated here. All specs/queries/MCP/URL here use Confluence as example, adapt target wiki system by example.
+**Canonical vendor example: Confluence** -- capabilities (page fetch / search / child pages) and harvesting discipline below use Confluence; for another backend (Notion, SharePoint, wiki) map by capability, same method. All specs/queries/MCP/URL here use Confluence as example, adapt target wiki system by example.
 
 **Operations below are named by capability, not by a fixed tool name.** Resolve each to the actual tool exposed by the configured documentation MCP binding: **get page**, **list child pages**, **search** (structured query or free text), and -- write, forbidden in this read-only binding -- **create / update page / add comment**.
 
@@ -34,7 +34,7 @@ Store each page under a **stable canonical reference** the backend guarantees (f
 3. **Deterministic ranking** -- fixed priority `title-match > label-match > body-match`; in-tier tiebreaker = MCP relevance score / recency. Record the query + top-N page IDs + ranking in the artifact's `Search Provenance` section for reproducibility.
 4. Retrieve top 3–5 pages via **get page** (same error branches as the direct path), then their child pages.
 
-**Cross-vendor:** when this binding runs beside Jira/TestRail, derive search terms from the upstream ticket (labels, components, summary keywords) the phase passes in; the phase owns merging the documentation section with the ticket section.
+**Cross-vendor:** when this binding runs beside Jira/TestRail, derive search terms from the upstream ticket (labels, components, summary keywords) already present in context.
 
 **Normalization discipline:**
 - **Truncate** pages over the phase's word budget (default ~5000 words); insert a banner naming the budget, the section where truncation happened, and the omitted section headings, e.g. `<!-- truncated: 5000-word budget reached at section 'Deployment Steps'; remaining 3 sections omitted: 'Monitoring', 'Rollback', 'Appendix' -->`. Keep headings + first sections intact.
@@ -73,7 +73,7 @@ Highest-risk: **page bodies** (runbooks/ops notes embed secrets; incident write-
 
 ## Output sections (within the phase-owned artifact)
 
-The phase owns the artifact path + heading; this binding emits, in order: per-page entries (per the per-page branch above); `Search Provenance` (search query + top-N IDs + ranking, or `N/A -- URL-driven retrieval`); `Gaps` (empty/restricted/cross-domain pages, or `None.`); redaction section (or `None.`). Every section present; empties use `None.`.
+This binding emits, in order: per-page entries (per the per-page branch above); `Search Provenance` (search query + top-N IDs + ranking, or `N/A -- URL-driven retrieval`); `Gaps` (empty/restricted/cross-domain pages, or `None.`); redaction section (or `None.`). Every section present; empties use `None.`.
 
 ## Validation items (binding-specific, added to SKILL `<validation_checklist>`)
 

instructions/r3/core/skills/data-collection/references/issue-vendor-binding.md

@@ -1,6 +1,6 @@
 # Vendor binding: Issue vendor
 
-**Canonical issue vendor example: Jira** -- the field map and examples below use Jira; for another tracker (Linear, GitHub Issues, Azure Boards) map by capability, same method. Base SKILL.md owns the general method (extract → normalize → redact → write) -- not restated here. All specs/queries/MCP/URL here use Jira as example, adapt target issue tracker system by example.
+**Canonical issue vendor example: Jira** -- the field map and examples below use Jira; for another tracker (Linear, GitHub Issues, Azure Boards) map by capability, same method. All specs/queries/MCP/URL here use Jira as example, adapt target issue tracker system by example.
 
 **Operations below are named by capability, not by a fixed tool name.** Resolve each to the actual tool exposed by the configured issue-tracker MCP/CLI/Fetch binding: **get issue** (with fields / expand / comment-limit), **search fields** (field-schema lookup), and -- write, forbidden in this read-only binding -- issue **create / update / transition / add comment**.
 

instructions/r3/core/skills/data-collection/references/tms-vendor-binding.md

@@ -1,6 +1,6 @@
 # Vendor binding: TMS / test-case vendor
 
-**Canonical test-case vendor example: TestRail** -- the field map and examples below use TestRail; for another test-case manager map by capability, same method. Base SKILL.md owns the general method -- not restated here.  All specs/queries/MCP/URL here use TestRail as example, adapt target test-case management system by example.
+**Canonical test-case vendor example: TestRail** -- the field map and examples below use TestRail; for another test-case manager map by capability, same method. All specs/queries/MCP/URL here use TestRail as example, adapt target test-case management system by example.
 
 **Operations below are named by capability, not by a fixed tool name.** Resolve each to the actual tool exposed by the configured TMS MCP/CLI/Fetch binding: **get case**, **get case fields** (case-field-schema lookup), and -- write, forbidden in this read-only binding -- case **update / add / delete**.
 

instructions/r3/core/skills/qa-knowledge/SKILL.md

@@ -1,36 +1,66 @@
 ---
 name: qa-knowledge
-description: "To supply the QA-domain conventions: failure taxonomies, authoring & correction discipline, and artifact skeletons."
+description: "To run QA engineering — requirements/gap analysis, scenario & spec design, test implementation, failure triage — over the QA knowledge base."
 license: Apache-2.0
-disable-model-invocation: true
-user-invocable: false
+disable-model-invocation: false
+user-invocable: true
 baseSchema: docs/schemas/skill.md
 ---
 
 <qa_knowledge>
 
+<role>
+
+QA-engineering skill. Runs the QA flow -- code analysis, requirements synthesis, gap analysis, scenario/spec design, QA test implementation, failure triage -- over the QA knowledge base (failure taxonomies, catalogs, artifact skeletons) it owns. Emits into the provided artifact contract; never invents its shape or path.
+
+</role>
+
 <when_to_use_skill>
 
-Use when authoring, analyzing, or correcting backend-API or UI/E2E tests and needing QA conventions: failure taxonomies, assertion & coverage discipline, selector & page-object rules, and the artifact skeletons these tasks emit. TestRail/Jira/Confluence are used as canonical examples, adapt to current case.
+Use for QA-engineering work on backend-API or UI/E2E tests: synthesizing collected sources into requirements, analyzing gaps/contradictions, designing test scenarios / specs / TMS cases, implementing QA tests (UI / API / selectors) from a plan or approved specs, triaging execution failures, or recovering test-automation architecture / API contracts. Also supplies the QA conventions and artifact skeletons these tasks emit. Plain unit/integration test writing is skill `testing`, not this flow. TestRail/Jira/Confluence are canonical examples, adapt to the current case.
 
 </when_to_use_skill>
 
+<dependencies>
+
+- **MUST USE SKILL `reverse-engineering`** for the `code_analysis` mode (test-automation architecture analysis, API-contract extraction).
+- USE SKILL `coding` for repo conventions; `debugging` for failing tests; `sensitive-data` for redaction (canonical authority).
+- USE SKILL `qa-structure` for QA paths / identifiers / state at point of use.
+
+</dependencies>
+
 <core_concepts>
 
-- Load only what the current task needs;
-- artifact skeletons are assets, READ SKILL FILE at point of use;
-- conventions are references -- see `<resources>`.
+- Load only what the current task needs; artifact skeletons are assets, conventions/catalogs are references -- READ SKILL FILE at point of use (see `<resources>`).
+- Per-value honesty: every concrete value traces to a loaded source, a user clarification, or an explicit `[ASSUMED: ...]` / `gap: ...` marker -- no confident fabrication.
+- Coverage is total: every input requirement / case / failure maps to ≥1 emitted item OR an explicit excluded/gap entry -- no silent drops.
+- Redaction: scan every emitted artifact and redact credentials/tokens/PII/credentialed-URLs before writing → USE SKILL `sensitive-data`.
+- Invocation: an owning phase supplies bindings (paths, IDs, workflow-state path) and deferred decisions. Standalone (no phase) -- ask the user for each and surface outputs to them; never write an assumed workflow-state path. "Ask the phase" in a reference = ask the user; never stall on a decision that cannot arrive.
 
 </core_concepts>
 
+<mode_selection>
+
+Pick exactly one mode by deliverable (multi-phase → run the earliest, stop; the next phase re-invokes); read its reference via `<resources>`. No clean match → name the closest mode and confirm, never silently pick. (Plain unit/integration tests are skill `testing`, not a mode here.)
+
+- code → test-arch map / API contract → **code_analysis** (analysis, no tests; via prereq skill `reverse-engineering`)
+- collected sources → one requirements doc → **synthesis** (redact before quoting)
+- find gaps/contradictions, no fixing → **gap_analysis** (analysis-only: surface each finding and STOP)
+- design test **cases/specs** incl. TMS, **not runnable** → **scenario_design**
+- write **runnable** QA tests (UI / API / selectors) from a plan/specs → **implementation_modes**
+- categorize run-report failures, no fixing → **test_execution_triage** (read-only)
+- propose fixes for failing QA tests + gain explicit approval to apply → **correction** (HITL-gated: present → approve → apply; via `coding` / `debugging`)
+
+</mode_selection>
+
 <resources>
 
 Router -- READ SKILL FILE for the one your current step needs (point-of-use, never all at once):
 
 | When you need to… | Command |
 |---|---|
-| present a correction for approval (API-QA **or** UI-QA) | READ SKILL FILE `assets/proposed-change-template.md` |
-| run the explicit-approval gate for a correction or spec/plan approval | READ SKILL FILE `assets/approval-gate.md` |
+| present a correction for approval (API-QA **or** UI-QA) (`<correction>` mode) | READ SKILL FILE `assets/proposed-change-template.md` |
+| run the explicit-approval gate for a correction or spec/plan approval (`<correction>` mode) | READ SKILL FILE `assets/approval-gate.md` |
 | emit the QA api-analysis artifact | READ SKILL FILE `assets/api-analysis-template.md` |
 | emit QA test specs (Given-When-Then `ATC-NNN`) | READ SKILL FILE `assets/test-spec-template.md` |
 | record the API-QA test-implementation | READ SKILL FILE `assets/api-qa-test-impl-record.md` |
@@ -44,9 +74,32 @@ Router -- READ SKILL FILE for the one your current step needs (point-of-use, nev
 | send the page-source capture message to the user | READ SKILL FILE `assets/page-source-capture-instructions.md` |
 | classify a QA backend-API failure | READ SKILL FILE `references/api-qa-failure-taxonomy.md` |
 | classify an UI-QA UI/E2E failure | READ SKILL FILE `references/ui-qa-failure-taxonomy.md` |
+| synthesize collected sources into a requirements document (`<synthesis>` mode) | READ SKILL FILE `references/synthesis-catalogs.md` |
+| run QA gap-analysis detection (`<gap_analysis>` mode) | READ SKILL FILE `references/gap-analysis-catalogs.md` |
+| design Given-When-Then API specs -- taxonomy + ATC template (`<scenario_design>` mode) | READ SKILL FILE `references/gwt-spec.md` |
+| format test cases for the configured TMS (scenario_design vendor binding) | READ SKILL FILE `references/<vendor>-format.md` (`<vendor>` from project config; TestRail shipped → `testrail-format.md`) |
+| export a case set to the configured TMS (vendor binding + destructive-write gate) | READ SKILL FILE `references/<vendor>-export.md` (`<vendor>` from project config; TestRail shipped → `testrail-export.md`) |
+| fork a TMS format/export binding to another vendor | READ SKILL FILE `references/vendor-fork-guide.md` |
+| implement UI / API / selector tests -- code + selector tables + templates (`<implementation_modes>` mode) | READ SKILL FILE `references/implementation-examples.md` |
+| analyze test-automation architecture or extract API contracts (`<code_analysis>` mode, via reverse-engineering) | READ SKILL FILE `references/analysis-modes.md` |
+| triage automated-test execution failures (`<test_execution_triage>` mode) | READ SKILL FILE `references/test-execution-triage.md` |
 
 </resources>
 
+<validation_checklist>
+
+Per active mode, before emitting:
+
+- code_analysis: (API-contract) every target endpoint has an entry OR a flagged gap, each with source citations + a Notes/Discrepancies field (`None.` if reconciled); (test-arch) every optional input marked `available` / `not available -- <impact>`; read-only.
+- synthesis: every requirement carries a Source; conflicts resolved via the source-priority ladder or flagged as an assumption; thresholdless NFRs flagged.
+- gap_analysis: each finding has a verbatim quote + citation + impact + exactly one risk tier; analysis-only (no fixes/questions); a clean analysis still emits the artifact.
+- scenario_design: total coverage (every case/requirement → ≥1 ATC/case or an excluded/gap entry); per-value honesty holds; auth-protected endpoints have ≥1 auth-failure scenario; vendor export passed the destructive-write gate.
+- implementation_modes: every plan assertion / ATC implemented OR recorded as uncovered/gap (no silent drop); page objects only (no raw selectors); lint/format clean on touched files.
+- test_execution_triage: every failure has exactly one taxonomy category and exactly one evidence label; `Unknown` states the missing capture; cross-failure Patterns present when ≥2 failures share a cause; read-only.
+- correction: each proposed change presented before any write; explicit approval obtained through the approval gate (no inferred approval); lint/format clean after each applied change; on reject or retry-cap, stop and report (no silent apply).
+
+</validation_checklist>
+
 <anti_patterns>
 
 Flag/refuse these before proceeding:

instructions/r3/core/skills/qa-knowledge/assets/code-analysis-report-template.md

@@ -49,7 +49,7 @@ UI-QA code-analysis report skeleton (9 sections) plus the test-location decision
 - Each optional input listed `available` or `not available -- <downstream impact>`. Silent omission forbidden -- downstream phases misread missing-data as no-issues.
 ```
 
-**Test-location decision rule** (the phase owns this; the skill applies it):
+**How to apply Test-location decision rule**:
 - **Add to existing file** if (a) the feature is a direct extension of an existing test class/describe, AND (b) the file stays under ~400 lines after addition.
 - **Create new file** if (a) it's a new area, OR (b) the file would exceed ~400 lines, OR (c) the existing setup/teardown shape doesn't fit.
 

instructions/r3/core/skills/qa-knowledge/assets/gap-finding-templates.md

@@ -4,7 +4,7 @@ QA gap-analysis finding-entry forms -- G[N] gaps, C[N] contradictions, A[N] ambi
 
 <gap-finding-templates>
 
-Finding-entry shapes for the gap-analysis artifact (one per finding). Quote source text verbatim; redact credentials/PII in any quoted line before writing (via the always-on `sensitive-data` skill, which the gap_analysis mode applies).
+Finding-entry shapes for the gap-analysis artifact (one per finding). Redact credentials/PII in any quoted line before writing (→ `sensitive-data`); for the full per-finding authoring discipline (verbatim quotes, citation, concrete impact) READ SKILL FILE `references/gap-analysis-catalogs.md`.
 
 **Classify each finding into exactly one type:** **G (Gap)** -- information is absent entirely · **C (Contradiction)** -- two sources state conflicting facts · **A (Ambiguity)** -- one source uses language with ≥2 valid interpretations. When a finding fits more than one type, file under the **most actionable** (C > A > G) and add a cross-reference in its `Impact` / `Needs Clarification` field.