Cutout skills from flows

instructions/r3/core/skills/automation-test-execution-analysis/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: automation-test-execution-analysis
+description: "Rosetta phase pattern for obtaining test execution output, running Part-A style failure triage with debugging, and recording categorized root causes before correction work."
+license: Apache-2.0
+tags: ["workflow", "test-automation", "debugging"]
+baseSchema: docs/schemas/skill.md
+---
+
+<automation_test_execution_analysis>
+
+<role>
+
+Test failure analyst who turns raw logs into structured, actionable findings for a follow-up correction phase.
+
+</role>
+
+<when_to_use_skill>
+
+Use after automated tests were executed and the workflow needs execution evidence interpreted (logs, reports, CI artifacts), before proposing code changes.
+
+</when_to_use_skill>
+
+<core_concepts>
+
+- All Rosetta prep steps MUST be FULLY completed, load-context skill loaded and fully executed
+- Part A = analysis only; do not apply fixes in this skill unless the parent workflow explicitly merges phases
+- Parent workflow names the domain analysis skill (e.g. `*-test-debugging` Part A); this skill orchestrates around it
+
+</core_concepts>
+
+<process>
+
+1. Resolve report location: user message, workflow default path, or `agents/user-instructions/` per parent workflow.
+2. GATE: if no report is available, ask once with a concrete file path or paste format; **WAIT** for user input.
+3. USE SKILL `debugging` while interpreting failures.
+4. USE the parent-specified domain analysis skill; execute only **Part A** (report analysis) when that skill defines A/B parts.
+5. Categorize each failure: environment, data, product regression, test bug, flakiness, infra timeout, auth/session, selector/locator (UI flows), contract mismatch (API flows), unknown.
+6. For each category, tie to evidence: log lines, stack snippets, or request/response identifiers — distinguish verified facts from hypotheses.
+7. Produce or update the parent workflow's analysis artifact (path and template from phase file).
+8. Update workflow state with counts, root-cause summary list, report path, and phase completion timestamp.
+9. GATE: confirm recommendations are actionable for a correction phase (owner file, suspected fix type).
+
+</process>
+
+<validation_checklist>
+
+- Execution input was actually read, not summarized from memory
+- Every listed failure maps to evidence or is explicitly marked unknown with next data to collect
+- Part B / code changes were not started unless the parent workflow authorizes combined phases
+- State and analysis artifact both reflect the same run identifier or timestamp
+- User was informed how to proceed (e.g. correction phase) per parent workflow
+
+</validation_checklist>
+
+<best_practices>
+
+- Prefer stable identifiers (test case name, node id, request id) over page numbers in PDFs
+- When multiple failures share one root cause, collapse them to reduce noise
+
+</best_practices>
+
+<pitfalls>
+
+- Treating green CI from a different branch or stale run as current
+- Confusing application bugs with outdated tests without evidence
+
+</pitfalls>
+
+<resources>
+
+- skill `debugging` — systematic triage
+- skill `hitl` — when user must supply missing logs or approve scope
+- Parent workflow phase file — output path and domain skill name
+
+</resources>
+
+</automation_test_execution_analysis>

instructions/r3/core/skills/automation-test-implementation-handoff/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: automation-test-implementation-handoff
+description: "Rosetta phase pattern for implementing approved automated tests, validating locally, handing off execution to the user, and updating workflow state without closing the overall workflow."
+license: Apache-2.0
+tags: ["workflow", "test-automation", "hitl"]
+baseSchema: docs/schemas/skill.md
+---
+
+<automation_test_implementation_handoff>
+
+<role>
+
+Test automation engineer who lands code in-repo, proves it is lint-clean, and stops at the right boundary for human-driven test runs.
+
+</role>
+
+<when_to_use_skill>
+
+Use in any phase whose job is to turn approved specs/plans into executable automated tests, then wait for the user to run the suite and report results.
+
+</when_to_use_skill>
+
+<core_concepts>
+
+- All Rosetta prep steps MUST be FULLY completed, load-context skill loaded and fully executed
+- Implementation ends at "ready to execute"; parsing failures belongs to a later analysis phase unless the workflow says otherwise
+- USE SKILL `hitl` for approval semantics; this skill defines the test-specific sequence
+
+</core_concepts>
+
+<process>
+
+1. USE SKILL `repository-implementation-standards` unless the parent workflow already did in this session.
+2. USE SKILL `coding` for implementation work.
+3. USE SKILL `testing` for test design constraints (isolation, idempotency, mocking policy) as applicable to this suite type.
+4. Apply the workflow-specific authoring skill or instructions the parent names (e.g. domain test implementation skill); do not substitute a different domain skill silently.
+5. Validate: project formatter/linter commands run clean; tests compile or parse; obvious import/path errors fixed.
+6. GATE: enumerate created or changed file paths and primary entry test files.
+7. Tell the user implementation is complete; provide the exact command to run tests for this repository.
+8. **STOP AND WAIT** for the user to execute tests and confirm completion before any execution-analysis phase begins.
+9. GATE: do not mark the overall parent workflow COMPLETE in state — only mark this implementation phase complete.
+10. Update the workflow state file with file paths, counts, utilities added, status `Ready for execution`, and timestamp.
+
+</process>
+
+<validation_checklist>
+
+- Approved upstream artifact (spec/plan) was referenced during implementation
+- Lint/format (or repo equivalent) ran with no unresolved errors on touched files
+- User received a concrete test command, not a generic framework name only
+- State shows implementation phase complete while parent workflow remains in progress
+- Execution was not assumed from partial user messages
+
+</validation_checklist>
+
+<best_practices>
+
+- Keep the first execution command copy-pasteable from repo docs or scripts
+- If flaky infrastructure is known, say so before the user runs tests
+
+</best_practices>
+
+<pitfalls>
+
+- Proceeding to failure triage without user-confirmed test run completion when the workflow requires it
+- Marking the whole workflow done because tests "should" pass
+
+</pitfalls>
+
+<resources>
+
+- skill `hitl` — wait/approve rules and assumption handling
+- skill `repository-implementation-standards` — doc-first alignment
+- skill `coding`, skill `testing` — shared implementation and test quality rules
+
+</resources>
+
+</automation_test_implementation_handoff>

instructions/r3/core/skills/confluence-source-harvesting/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: confluence-source-harvesting
+description: "Rosetta playbook for pulling Confluence content reliably: direct URLs vs search, child pages, truncation, URL shapes, and permission fallbacks — pair with TMS/Jira collection per workflow."
+license: Apache-2.0
+tags: ["workflow", "confluence", "mcp", "documentation"]
+baseSchema: docs/schemas/skill.md
+---
+
+<confluence_source_harvesting>
+
+<role>
+
+Documentation miner who respects Confluence hierarchy, size limits, and MCP boundaries.
+
+</role>
+
+<when_to_use_skill>
+
+Use whenever a workflow enriches tickets or tests with Confluence pages (alone or beside Jira/TestRail). Reduces missed child pages and silent truncation surprises.
+
+</when_to_use_skill>
+
+<core_concepts>
+
+- All Rosetta prep steps MUST be FULLY completed, load-context skill loaded and fully executed
+- Parent workflow selects MCP skills (e.g. `mcp-confluence-data-collection`); this skill defines cross-workflow harvesting discipline
+- Jira/TestRail ticket extraction stays in workflow-specific steps; combine outputs after both sides run
+
+</core_concepts>
+
+<process>
+
+1. If the user supplied Confluence URLs or page IDs, fetch those pages first with the configured Confluence MCP.
+2. After each parent page retrieved, fetch **child pages** when the API exposes them; repeat until leaves or depth cap the parent workflow defines.
+3. If no URLs were supplied, derive search terms from the ticket (labels, components, summary keywords) and run search; record terms used in the raw artifact.
+4. GATE: if search returns zero pages, ask once for explicit URLs or permission to proceed ticket-only; document the user choice.
+5. Apply truncation: if a page exceeds the parent workflow's word budget (default ~5000 words unless overridden), truncate with a clear banner and keep headings + first sections intact when possible.
+6. Normalize links: accept display URLs, direct `/wiki/` URLs, and short links; log the canonical URL stored.
+7. GATE: if a URL domain does not match the configured MCP site, warn and try once; on failure, ask for an accessible link or export.
+8. Deduplicate pages by canonical URL; merge content in stable order (parents before children unless workflow dictates otherwise).
+9. Summarize in the raw artifact: page count, children discovered, truncation flags, search terms, failures.
+
+</process>
+
+<validation_checklist>
+
+- Every stored page lists title, canonical URL, and parent/child relationship when applicable
+- Child pages were checked for each retrieved parent unless user waived with explicit approval
+- Truncated pages are labeled with what was omitted
+- Zero-result search paths end in user decision or documented waiver
+- Confluence section absent only when user approved ticket-only continuation
+
+</validation_checklist>
+
+<best_practices>
+
+- Prefer user-provided canonical links when search noise is high
+- Capture space key and last-updated metadata when available for traceability
+
+</best_practices>
+
+<pitfalls>
+
+- Assuming Confluence HTML renders identically to markdown — note rendering gaps
+- Stopping at the first parent when children hold acceptance criteria
+- Hiding MCP permission errors as empty content
+
+</pitfalls>
+
+<resources>
+
+- skill `questioning` — targeted follow-ups when discovery is ambiguous
+- skill `hitl` — explicit approval for proceeding without documentation
+- Parent workflow — which MCP Confluence skill name to invoke and output file path
+
+</resources>
+
+<templates>
+
+- Page entry (embed in parent artifact):
+
+```markdown
+### [Page title]
+- URL: [canonical]
+- Parent: [title or none]
+- Retrieved: [ISO-8601]
+- Children fetched: yes | no (reason)
+- Truncated: yes | no (word count / limit)
+#### Content
+[markdown body]
+```
+
+</templates>
+
+</confluence_source_harvesting>

instructions/r3/core/skills/repository-implementation-standards/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: repository-implementation-standards
+description: "Rosetta contract for using repository standard docs as the authority before implementing or extending tests, helpers, page objects, or automation glue."
+license: Apache-2.0
+tags: ["workflow", "coding-standards", "repository"]
+baseSchema: docs/schemas/skill.md
+---
+
+<repository_implementation_standards>
+
+<role>
+
+Senior engineer aligning automation work with how this repository expects code and tests to be written.
+
+</role>
+
+<when_to_use_skill>
+
+Use before implementing or refactoring automated tests, shared test utilities, page objects, or thin automation adapters in any multi-phase test workflow.
+
+</when_to_use_skill>
+
+<core_concepts>
+
+- All Rosetta prep steps MUST be FULLY completed, load-context skill loaded and fully executed
+- Repository documentation beats model defaults when they conflict
+- Prefer extending existing patterns over introducing parallel conventions
+
+</core_concepts>
+
+<process>
+
+1. Locate and read, when present: `project_description.md`, `CONTEXT.md`, `ARCHITECTURE.md`, `IMPLEMENTATION.md` (repo root or paths given by the workflow or user).
+2. Extract explicit rules: test layout, naming, fixtures, auth/session handling, logging, lint/format commands, forbidden patterns.
+3. Search the codebase for the closest existing examples (same framework, same layer) before writing new files.
+4. GATE: if standard docs disagree with dominant code patterns, flag the conflict to the user and pick the documented rule unless the user directs otherwise.
+5. Record in the phase artifact which files were used as references (paths only, no large quotes).
+
+</process>
+
+<validation_checklist>
+
+- At least one of the standard doc files was read, or the user confirmed none exist and provided substitute standards
+- Implementation matches documented directory layout, naming, and tooling commands when documented
+- New code reuses or extends existing helpers/fixtures/page objects when applicable instead of duplicating
+- Conflicts between docs and code were surfaced to the user or documented as assumptions
+
+</validation_checklist>
+
+<best_practices>
+
+- Note the exact test runner command the repo uses before telling the user to execute tests
+- Prefer minimal surface area: smallest change that matches existing style
+
+</best_practices>
+
+<pitfalls>
+
+- Inventing folder or file names not seen elsewhere in the repo
+- Skipping `IMPLEMENTATION.md` when it exists — it often carries non-obvious constraints
+
+</pitfalls>
+
+<resources>
+
+- skill `coding` — implementation discipline shared with feature work
+- skill `testing` — test quality bar when authoring or updating tests
+
+</resources>
+
+</repository_implementation_standards>