qa-flowkit 0.4.0-alpha.0

package/.qa-ai/adapters/cline/.clinerules

@@ -0,0 +1,9 @@
+You are working on a QA AI Starter repository.
+
+Read AGENTS.md first.
+Read qa-ai.config.yaml when present.
+Follow .qa-ai/rules/approval.rules.md before modifying files.
+Do not overwrite existing files unless explicitly approved.
+Keep all generated QA tests in English.
+Manual tests must also have .feature files.
+Unit tests are out of scope.

package/.qa-ai/adapters/codex/README.md

@@ -0,0 +1,44 @@
+# Codex Adapter
+
+This adapter gives Codex a compact onboarding path for QA FlowKit repositories.
+
+Related docs: [main README](../../../README.md) | [agent compatibility](../../../docs/qa-ai/agent-compatibility.md)
+
+## Primary Instructions
+
+| File | Purpose |
+|---|---|
+| `AGENTS.md` | Cross-agent rules and safety policy |
+| `qa-ai.config.yaml` | Target repository configuration |
+| `qa-ai-output/qa-knowledge-summary.md` | Team QA practice summary when `knowledge.enabled` is true |
+| `qa-ai-output/qa-init-decisions.md` | Approved context-based init decisions when `knowledge.enabled` is true |
+| `.qa-ai/rules/` | Mandatory QA workflow rules |
+| `.qa-ai/workflows/` | Phase playbooks |
+| `.qa-ai/agents/README.md` | Agent loading protocol |
+
+## Recommended Opening Prompt
+
+```text
+Read AGENTS.md, qa-ai.config.yaml, docs/qa-ai/implementation-guide-for-codex.md and .qa-ai/rules/. Then implement the next pending task from docs/qa-ai/backlog.md. Present a plan before editing files.
+```
+
+## Useful Commands
+
+| Command | Purpose |
+|---|---|
+| `node .qa-ai/scripts/config.mjs --help` | Import/export reusable QA AI config profiles |
+| `node .qa-ai/scripts/init.mjs --qa-context qa-ai-knowledge` | Enable a QA context folder for agent-assisted defaults |
+| `node .qa-ai/scripts/doctor.mjs` | Check setup health |
+| `node .qa-ai/scripts/doctor.mjs --strict` | CI-style checks for initialized target repositories |
+| `node .qa-ai/scripts/validate-target.mjs` | Run the full target repository validation pipeline |
+| `node .qa-ai/scripts/validate-features.mjs` | Validate `.feature` files |
+| `node .qa-ai/scripts/validate-traceability.mjs` | Validate traceability matrix coverage and shape |
+| `node .qa-ai/scripts/validate-sync-plan.mjs` | Validate proposal-first sync plans and mapping shape |
+| `node .qa-ai/scripts/validate-active-specialists.mjs` | Validate active specialist index |
+| `npm run validate:oss-extraction` | Run source-repo maintainer validation |
+| `node .qa-ai/scripts/smoke-test.mjs` | Run core maintainer smoke checks |
+| `node .qa-ai/scripts/clean.mjs` | Preview cleanup before deleting generated files |
+
+Claude Code and OpenCode support project slash commands through generated adapters. Use `/qa-init` for agent-first initialization instead of the native `/init` command, and `/qa-config` to import or export reusable configuration profiles.
+
+Gemini CLI uses the generated root `GEMINI.md` context file when the `gemini` adapter is selected.

package/.qa-ai/adapters/codex/prompts/implement-project.md

@@ -0,0 +1,15 @@
+Read `AGENTS.md`, `README.md`, `ROADMAP.md`, `docs/qa-ai/implementation-guide-for-codex.md`, `docs/qa-ai/backlog.md` and all files under `.qa-ai/rules/`.
+
+Then implement the QA FlowKit MVP from beginning to end.
+
+Before changing files, provide a concise plan. Do not remove or overwrite existing files unless necessary and clearly justified.
+
+Run the local validation scripts after changes:
+
+```bash
+node .qa-ai/scripts/doctor.mjs
+npm run validate:oss-extraction
+```
+
+For initialized target repositories after real QA artifacts exist, also use `node .qa-ai/scripts/doctor.mjs --strict` and run the feature, traceability, sync-plan and active-specialist validators without source-repo allowances.
+Shortcut: `node .qa-ai/scripts/validate-target.mjs`.

package/.qa-ai/adapters/continue/README.md

@@ -0,0 +1,26 @@
+# Continue Adapter
+
+Continue is best used for review and checks in the folder-copy MVP.
+
+Related docs: [main README](../../../README.md) | [agent compatibility](../../../docs/qa-ai/agent-compatibility.md)
+
+When `knowledge.enabled` is true in `qa-ai.config.yaml`, review `knowledge.summaryPath` and `knowledge.decisionsPath` before applying QA checks or review guidance.
+
+## Read First
+
+| File | Purpose |
+|---|---|
+| `AGENTS.md` | Generic behavior and safety rules |
+| `.qa-ai/rules/` | Mandatory QA workflow rules |
+| `.qa-ai/adapters/continue/checks/qa-feature-conventions.md` | Feature-file review checklist |
+
+## Recommended Checks
+
+| Command | Purpose |
+|---|---|
+| `node .qa-ai/scripts/config.mjs --help` | Import/export reusable QA AI config profiles |
+| `node .qa-ai/scripts/doctor.mjs` | Check setup health |
+| `node .qa-ai/scripts/validate-features.mjs` | Validate `.feature` files |
+| `node .qa-ai/scripts/clean.mjs` | Dry-run cleanup before removal suggestions |
+
+Do not suggest external writes in the MVP. Keep TestRail, Jira, Confluence and GitHub write actions proposal-first.

package/.qa-ai/adapters/continue/checks/qa-feature-conventions.md

@@ -0,0 +1,15 @@
+# QA Feature Conventions Check
+
+Check that `.feature` files contain:
+
+- One configured scenario keyword per file.
+- Acceptance Criteria.
+- Required tags with values.
+- RF ID in file, Feature and Scenario titles.
+- `# language: es` when Spanish Gherkin is configured.
+
+Preferred command:
+
+```bash
+node .qa-ai/scripts/validate-features.mjs
+```

package/.qa-ai/adapters/gemini/GEMINI.md

@@ -0,0 +1,40 @@
+# QA FlowKit - Gemini CLI Context
+
+This repository uses QA FlowKit for repo-first QA workflows. Treat this file as the Gemini CLI entry point, then load the shared framework instructions before doing QA work.
+
+## Required Reading
+
+Before making changes:
+
+- Read `AGENTS.md` when present.
+- Read `qa-ai.config.yaml` when present.
+- When `knowledge.enabled` is true, read `knowledge.summaryPath` and `knowledge.decisionsPath` when present.
+- Read `.qa-ai/rules/` before changing workflow behavior.
+- Read `.qa-ai/agents/README.md` before QA workflow work.
+- Load the matching phase agent from `.qa-ai/agents/`.
+- Load `.qa-ai/agents/specialists/active.md` and the specialist files it lists when present.
+
+## Working Rules
+
+- Present a plan before modifying files.
+- Do not overwrite existing files unless the user explicitly approves it or asks for `--force` behavior.
+- Do not write to configured external tools in the MVP.
+- Never store secrets in repository files.
+- Keep all generated QA outputs open-source ready.
+
+## Useful Commands
+
+| Command | Purpose |
+|---|---|
+| `node .qa-ai/scripts/init.mjs` | Generate config, folders and selected adapters |
+| `node .qa-ai/scripts/init.mjs --qa-context qa-ai-knowledge` | Enable a QA context folder for agent-assisted defaults |
+| `node .qa-ai/scripts/config.mjs --help` | Import/export reusable QA AI config profiles |
+| `node .qa-ai/scripts/doctor.mjs` | Check setup health |
+| `node .qa-ai/scripts/validate-features.mjs` | Validate `.feature` files |
+| `node .qa-ai/scripts/clean.mjs` | Preview cleanup before deleting generated files |
+
+## QA Workflow Entry Prompt
+
+```text
+Read AGENTS.md, qa-ai.config.yaml, .qa-ai/rules/, .qa-ai/agents/README.md and .qa-ai/workflows/full-flow.md. If knowledge.enabled is true, read the configured QA knowledge artifacts first. Then follow the configured QA workflow, starting with a plan before editing files.
+```

package/.qa-ai/adapters/generic/AGENTS.md

@@ -0,0 +1,100 @@
+# AGENTS.md - QA FlowKit
+
+This file is the generic instruction layer for all AI coding agents working in this repository.
+
+## Project purpose
+
+Build an open-source, portable QA AI workflow starter. The first version is a folder-copy framework: users copy `.qa-ai` into a target QA/automation repository and run local Node scripts to initialize AI-assisted QA workflows. Claude Code and OpenCode can also start through `/qa-init` after running the bootstrap script from `.qa-ai`.
+
+## Primary goal
+
+Implement and maintain a reusable repo-first workflow that helps QA teams move from requirements to Gherkin tests, test-management planning, automation feasibility, configured-framework implementation plans and PR-ready outputs.
+
+## Mandatory behavior
+
+- Read this file before making changes.
+- Read `qa-ai.config.yaml` when present.
+- When `knowledge.enabled` is true, read the configured QA knowledge summary and init decisions artifacts before QA workflow work.
+- Read `.qa-ai/rules/` before changing workflow behavior.
+- Read `.qa-ai/agents/README.md` before QA workflow work; then load the matching phase agent and active specialists listed in `.qa-ai/agents/specialists/active.md`.
+- Present a plan before modifying files.
+- Do not overwrite existing files unless explicitly approved or `--force` behavior is requested by the user.
+- Do not create external writes to configured external tools in the MVP.
+- Never store secrets in repository files.
+- Keep the project open-source ready.
+
+## QA rules
+
+- Tests are written in the configured Gherkin language from `qa-ai.config.yaml` (`gherkin.language`): English (`en`) or Spanish (`es`).
+- Spanish `.feature` files must include `# language: es`.
+- One `.feature` file per test case.
+- Manual tests also have `.feature` files.
+- Every `.feature` must include the configured acceptance criteria label: `Acceptance Criteria:` for English or `Criterios de aceptación:` for Spanish.
+- Required tags: `@priority:`, `@type:`, `@manual:`.
+- Unit tests are out of scope for generated QA test cases.
+- The official RF ID is required before final test generation.
+
+## Preferred implementation stack
+
+- Node.js 20+.
+- Native Node APIs where possible.
+- No unnecessary dependencies in the folder-copy MVP.
+- YAML config can be generated as plain text in MVP.
+- Future npm CLI may introduce dependencies such as Commander, Inquirer and YAML.
+
+## Project structure
+
+```text
+.qa-ai/          portable framework folder
+AGENTS.md       generic agent instructions
+README.md       public project documentation
+docs/qa-ai/     implementation and architecture docs
+```
+
+## Target repository structure generated by default init
+
+```text
+qa-ai.config.yaml
+.opencode/
+.opencode/commands/qa-init.md
+qa-ai-output/
+qa-ai-output/qa-knowledge-summary.md
+qa-ai-output/qa-init-decisions.md
+features/
+tests/
+```
+
+Optional adapter outputs are generated only when requested with `--adapters` or bootstrap scripts:
+
+```text
+AGENTS.md
+.claude/
+.codex/
+.cline/
+.continue/
+.aider.conf.yml
+.goose/
+GEMINI.md
+.claude/commands/qa-init.md
+```
+
+## Completion criteria
+
+A target user must be able to:
+
+```bash
+cp -R qa-flowkit/.qa-ai ./target-repo/.qa-ai
+cd ./target-repo
+node .qa-ai/scripts/init.mjs
+node .qa-ai/scripts/doctor.mjs
+```
+
+After real QA artifacts exist in a target repository, validate with:
+
+```bash
+node .qa-ai/scripts/validate-target.mjs
+```
+
+The generated repository must be ready for use with Codex Desktop, Claude Code and other AI coding tools.
+Claude Code and OpenCode users may initialize through `/qa-init` after running the bootstrap script.
+The preferred agent-first setup is: copy `.qa-ai`, run `node .qa-ai/scripts/bootstrap-agent-adapters.mjs`, open Claude Code or OpenCode, then run `/qa-init`.

package/.qa-ai/adapters/goose/recipes/qa-flowkit.yaml

@@ -0,0 +1,20 @@
+version: 1
+name: qa-flowkit
+description: Run the QA AI workflow for requirements-to-tests-to-automation.
+instructions: |
+  Read AGENTS.md, qa-ai.config.yaml and .qa-ai/rules/ before acting.
+  Produce a plan before modifying files.
+  Do not overwrite or externally write without approval.
+steps:
+  - name: health-check
+    prompt: Run node .qa-ai/scripts/doctor.mjs and summarize required failures or warnings.
+  - name: intake
+    prompt: Read the requirement source and produce qa-ai-output/requirement-analysis.md.
+  - name: design
+    prompt: Produce a test design proposal and generate approved Gherkin feature files. Run node .qa-ai/scripts/validate-features.mjs after feature changes.
+  - name: automation
+    prompt: Analyze automation feasibility and produce an implementation plan.
+  - name: pr
+    prompt: Prepare a PR summary with traceability and execution status.
+  - name: cleanup-preview
+    prompt: Run node .qa-ai/scripts/clean.mjs only as a dry-run when generated artifact cleanup is requested.

package/.qa-ai/adapters/opencode/README.md

@@ -0,0 +1,57 @@
+# OpenCode Adapter
+
+Use this folder as an instruction bridge for OpenCode or other terminal coding agents.
+
+Related docs: [main README](../../../README.md) | [agent compatibility](../../../docs/qa-ai/agent-compatibility.md)
+
+## Primary Files
+
+| File | Purpose |
+|---|---|
+| `AGENTS.md` | Generic behavior and safety rules |
+| `qa-ai.config.yaml` | Project configuration |
+| `qa-ai-output/qa-knowledge-summary.md` | Team QA practice summary when `knowledge.enabled` is true |
+| `qa-ai-output/qa-init-decisions.md` | Approved context-based init decisions when `knowledge.enabled` is true |
+| `.qa-ai/rules/` | Mandatory workflow rules |
+| `.qa-ai/agents/README.md` | Agent loading protocol |
+| `.qa-ai/workflows/` | Task playbooks |
+
+Agent files in `.qa-ai/agents/` are required role instructions for QA workflow phases. If OpenCode does not expose them as callable subagents, read the relevant Markdown files and follow them directly. Always load `.qa-ai/agents/specialists/active.md` when present, plus the specialist files it lists.
+
+## Slash Commands
+
+| Command | Purpose |
+|---|---|
+| `/qa-init` | Guided initialization |
+| `/qa-config` | Import or export reusable QA AI config profiles |
+| `/qa-full-flow` | End-to-end requirements-to-PR QA flow |
+| `/qa-add-tests` | Add tests for a new RF without disturbing existing tests |
+| `/qa-update-tests` | Review existing tests after RF changes and apply approved updates |
+| `/qa-automation-plan` | Classify existing `.feature` files and plan automation |
+| `/qa-coverage` | Analyze functional coverage across RFs, manual tests and automated tests |
+| `/qa-help` | Context-aware guidance for the next QA workflow step |
+| `/qa-gate` | Record enterprise release gate decision |
+| `/qa-status` | Summarize config, artifacts, feature health and recommended next steps |
+| `/qa-doctor` | Setup health checks |
+| `/qa-clean` | Manifest-based cleanup preview/execution |
+| `/qa-validate-features` | Gherkin convention validation |
+
+## Local Checks
+
+| Command | Purpose |
+|---|---|
+| `node .qa-ai/scripts/config.mjs --help` | Import/export reusable QA AI config profiles |
+| `node .qa-ai/scripts/doctor.mjs` | Check setup health |
+| `node .qa-ai/scripts/doctor.mjs --strict` | CI-style checks for initialized target repositories |
+| `node .qa-ai/scripts/qa-help.mjs` | Recommend the next QA phase based on artifacts and track |
+| `node .qa-ai/scripts/validate-target.mjs` | Run the full target repository validation pipeline |
+| `node .qa-ai/scripts/validate-features.mjs` | Validate `.feature` files |
+| `node .qa-ai/scripts/validate-traceability.mjs` | Validate traceability matrix coverage and shape |
+| `node .qa-ai/scripts/validate-sync-plan.mjs` | Validate proposal-first sync plans and mapping shape |
+| `node .qa-ai/scripts/validate-active-specialists.mjs` | Validate active specialist index |
+| `npm run validate:oss-extraction` | Run source-repo maintainer validation |
+| `node .qa-ai/scripts/clean.mjs` | Preview cleanup before deleting generated files |
+
+Use `.qa-ai/workflows/full-flow.md` for end-to-end QA delivery and keep all external writes proposal-first.
+
+When initializing with a QA context folder, use `/qa-init --qa-context <path>` so OpenCode reads `.qa-ai/workflows/context-intake.md` before choosing defaults.

package/.qa-ai/adapters/opencode/agents/qa-workflow.md

@@ -0,0 +1,18 @@
+# QA Workflow Orchestrator
+
+You coordinate the complete AI-assisted QA workflow.
+
+## Responsibilities
+
+- Read `AGENTS.md`, `qa-ai.config.yaml`, `.qa-ai/rules/` and `.qa-ai/agents/README.md` before acting.
+- Read `.qa-ai/agents/specialists/active.md` when present and load only the listed specialist instructions from `.qa-ai/agents/specialists/available/`.
+- Use the configured interface language from `qa-ai.config.yaml` (`project.interfaceLanguage` / `project.defaultLanguage`) for questions and descriptions. Use `gherkin.language` only for generated `.feature` files.
+- Delegate to specialized agents conceptually.
+- Maintain traceability from configured requirement sources/RF/CA to features, test management and automation.
+- Present a plan before every change.
+- Ask for approval before writes or modifications.
+- Stop and ask when official RF ID is missing.
+
+## Output expectation
+
+Every workflow must produce or update the expected docs under `qa-ai-output/`.

package/.qa-ai/adapters/opencode/commands/qa-add-tests.md

@@ -0,0 +1,42 @@
+---
+description: Add QA tests for a new RF / Anadir pruebas QA para un RF nuevo
+argument-hint: [requirement source or RF ID]
+---
+
+Add new QA tests to a repository that may already contain `.feature` files and automation tests.
+
+Read these files first:
+
+- `AGENTS.md`
+- `qa-ai.config.yaml` when present
+- `.qa-ai/rules/`
+- `.qa-ai/agents/README.md`
+- `.qa-ai/agents/qa-workflow-orchestrator.md`
+- `.qa-ai/agents/gherkin-test-design-agent.md`
+- `.qa-ai/agents/testrail-coverage-agent.md`
+- `.qa-ai/agents/specialists/active.md` when present
+- `.qa-ai/workflows/test-design.md`
+
+Use `project.interfaceLanguage` / `project.defaultLanguage` from `qa-ai.config.yaml` for user-facing questions and summaries. Use `gherkin.language` only for generated `.feature` files.
+
+If `$ARGUMENTS` is empty or ambiguous, ask the user:
+
+1. Where is the new requirement/RF source?
+2. What is the official RF ID?
+3. Should the first pass produce only proposal artifacts, or create new `.feature` files after approval?
+
+Stop before final `.feature` generation if the official RF ID is missing.
+
+Then present a concise plan before modifying files.
+
+Workflow:
+
+1. Inspect existing `.feature` files and configured automation paths to avoid duplicates.
+2. Analyze the new RF and acceptance criteria.
+3. Produce or update `qa-ai-output/requirement-analysis.md`.
+4. Produce or update `qa-ai-output/test-design-proposal.md` with only new tests to add and existing tests to reuse.
+5. After approval, create one `.feature` file per new test case under the configured `gherkin.featurePath`.
+6. Update `qa-ai-output/traceability-matrix.md` when useful.
+7. Run `node .qa-ai/scripts/validate-features.mjs`, `node .qa-ai/scripts/validate-traceability.mjs` and `node .qa-ai/scripts/validate-sync-plan.mjs` after feature/artifact changes.
+
+Do not modify existing tests unless the user explicitly approves that scope. Do not write to configured external tools.

package/.qa-ai/adapters/opencode/commands/qa-automation-plan.md

@@ -0,0 +1,43 @@
+---
+description: Plan automation from existing QA tests / Planificar automatizacion desde pruebas existentes
+argument-hint: [feature path, RF ID, or test filter]
+---
+
+Create an automation feasibility and implementation plan from existing `.feature` tests.
+
+Read these files first:
+
+- `AGENTS.md`
+- `qa-ai.config.yaml` when present
+- `.qa-ai/rules/`
+- `.qa-ai/agents/README.md`
+- `.qa-ai/agents/qa-workflow-orchestrator.md`
+- `.qa-ai/agents/automation-feasibility-agent.md`
+- `.qa-ai/agents/webdriverio-implementation-agent.md` when UI automation is configured
+- `.qa-ai/agents/api-testing-agent.md` when API automation is configured
+- `.qa-ai/agents/specialists/active.md` when present
+- `.qa-ai/workflows/automation-analysis.md`
+- `.qa-ai/workflows/implementation.md`
+
+Use `project.interfaceLanguage` / `project.defaultLanguage` from `qa-ai.config.yaml` for user-facing questions and summaries.
+
+If `$ARGUMENTS` is empty or ambiguous, ask the user:
+
+1. Which existing tests should be considered: all features, a folder, an RF ID, or specific files?
+2. Should this run only create the automation plan, or continue to implementation after approval?
+   - Recommend plan only first.
+3. Are there known environment, data, selector or credential constraints?
+
+Then present a concise plan before modifying files.
+
+Workflow:
+
+1. Inspect existing `.feature` files and configured automation paths.
+2. Inspect existing UI/API automation patterns before proposing code.
+3. Classify tests as automated, automatable, partial, manual, blocked or not automatable.
+4. Produce or update `qa-ai-output/automation-feasibility-report.md`.
+5. Produce or update `qa-ai-output/automation-implementation-plan.md`.
+6. If the user explicitly approves implementation, add automation code using the configured frameworks and local patterns.
+7. Run relevant project tests or explain why they cannot be run.
+
+Do not add dependencies, change global framework config or write to external tools without approval.

package/.qa-ai/adapters/opencode/commands/qa-clean.md

@@ -0,0 +1,42 @@
+---
+description: Guided manifest-based QA AI cleanup / Limpieza guiada de QA FlowKit
+argument-hint: [optional clean flags]
+---
+
+Preview or execute cleanup for generated QA FlowKit artifacts.
+
+Read `qa-ai.config.yaml` when present and use its configured interface language (`project.interfaceLanguage` / `project.defaultLanguage`, `en` or `es`) for questions, descriptions and summaries.
+
+If `$ARGUMENTS` is empty, run the safe dry-run first:
+
+```bash
+node .qa-ai/scripts/clean.mjs
+```
+
+Summarize the cleanup plan, then ask the user:
+
+1. Which scope should be cleaned?
+   - `generated`: generated config, QA output artifacts and empty generated folders.
+   - `adapters`: generated agent adapter files.
+   - `empty-dirs`: tracked empty directories.
+   - `all`: all tracked entries.
+2. Should cleanup be executed with `--force`?
+   - Recommend `no` until the dry-run is reviewed.
+3. Should modified tracked files be deleted?
+   - Recommend `no`; only use `--include-modified` if the user explicitly wants to discard edits.
+
+If the user approves execution, build and run:
+
+```bash
+node .qa-ai/scripts/clean.mjs --<scope> --force
+```
+
+Only add `--include-modified` when explicitly approved.
+
+If `$ARGUMENTS` is not empty, treat it as advanced mode and run:
+
+```bash
+node .qa-ai/scripts/clean.mjs $ARGUMENTS
+```
+
+Do not delete anything outside the manifest-based clean script.

package/.qa-ai/adapters/opencode/commands/qa-config.md

@@ -0,0 +1,51 @@
+---
+description: Import or export QA FlowKit configuration / Importar o exportar configuracion de QA FlowKit
+argument-hint: [--export path | --import path]
+---
+
+Import or export a reusable QA FlowKit configuration profile.
+
+Read these files first:
+
+- `AGENTS.md`
+- `qa-ai.config.yaml` when present
+- `.qa-ai/rules/`
+- `.qa-ai/agents/README.md`
+
+Use `project.interfaceLanguage` / `project.defaultLanguage` from `qa-ai.config.yaml` when present for user-facing questions and summaries.
+
+If `$ARGUMENTS` is empty, ask the user:
+
+1. Do you want to export the current config or import an existing profile?
+2. What repo-local profile path should be used?
+   - Recommended export path: `.qa-ai/config-profiles/team.yaml`.
+3. If importing and `qa-ai.config.yaml` already exists, should it be overwritten?
+   - Recommend `no`; only use `--force` if the user explicitly approves.
+
+For export, run:
+
+```bash
+node .qa-ai/scripts/config.mjs --export <profile-path>
+```
+
+For import, run:
+
+```bash
+node .qa-ai/scripts/config.mjs --import <profile-path>
+```
+
+Only add `--force` when the user explicitly approves overwriting. Add `--no-structure` only when the user wants to import the YAML without creating configured folders or refreshing `.qa-ai/agents/specialists/active.md`.
+
+If `$ARGUMENTS` is not empty, treat it as advanced mode and run:
+
+```bash
+node .qa-ai/scripts/config.mjs $ARGUMENTS
+```
+
+After import, run or suggest:
+
+```bash
+node .qa-ai/scripts/doctor.mjs
+```
+
+Do not write to external tools.

package/.qa-ai/adapters/opencode/commands/qa-coverage.md

@@ -0,0 +1,46 @@
+---
+description: Analyze QA functional coverage / Analizar cobertura funcional QA
+argument-hint: [RF ID, requirement source, or scope]
+---
+
+Analyze functional QA coverage across requirements, `.feature` files, manual tests and automated tests.
+
+Read these files first:
+
+- `AGENTS.md`
+- `qa-ai.config.yaml` when present
+- `.qa-ai/rules/`
+- `.qa-ai/agents/README.md`
+- `.qa-ai/agents/qa-workflow-orchestrator.md`
+- `.qa-ai/agents/testrail-coverage-agent.md`
+- `.qa-ai/agents/automation-feasibility-agent.md`
+- `.qa-ai/agents/specialists/active.md` when present
+- `.qa-ai/workflows/automation-analysis.md`
+- `.qa-ai/workflows/testrail-sync.md`
+
+Use `project.interfaceLanguage` / `project.defaultLanguage` from `qa-ai.config.yaml` for user-facing questions and summaries.
+
+If `$ARGUMENTS` is empty or ambiguous, ask the user:
+
+1. What scope should be analyzed: one RF, a requirement source, a feature folder, or the whole repo?
+2. Where are the requirements or acceptance criteria for that scope?
+3. Should configured test management data be considered from local exports/mapping files?
+
+Then present a concise plan before modifying files.
+
+Coverage dimensions:
+
+- Requirement/RF coverage.
+- Acceptance criteria coverage.
+- Manual test coverage.
+- Automated test coverage.
+- Gaps, duplicates, overlaps and stale tests.
+- Automation candidates and blockers.
+
+Expected local artifacts:
+
+- `qa-ai-output/qa-coverage-report.md`
+- `qa-ai-output/testrail-coverage-analysis.md` when test management is configured or local mapping data exists
+- `qa-ai-output/traceability-matrix.md` when useful
+
+Do not modify tests or write to external tools unless the user explicitly asks and approves a follow-up change.

package/.qa-ai/adapters/opencode/commands/qa-doctor.md

@@ -0,0 +1,13 @@
+---
+description: Run QA FlowKit setup health checks / Ejecutar comprobaciones de QA FlowKit
+---
+
+Run the QA FlowKit doctor script and explain the results.
+
+Read `qa-ai.config.yaml` when present and explain results in its configured interface language (`project.interfaceLanguage` / `project.defaultLanguage`, `en` or `es`).
+
+For target-repository CI or post-flow hardening, tell the user they can run `node .qa-ai/scripts/validate-target.mjs`, which includes `doctor --strict`, feature validation, traceability validation, sync-plan validation and active-specialist validation.
+
+Command output:
+
+!`node .qa-ai/scripts/doctor.mjs`

package/.qa-ai/adapters/opencode/commands/qa-full-flow.md

@@ -0,0 +1,59 @@
+---
+description: Guided full QA FlowKit workflow / Workflow completo guiado de QA FlowKit
+argument-hint: [optional requirement source]
+---
+
+Run the complete QA AI workflow for the configured requirement source, Markdown PRD/RF or pasted requirement.
+
+Read these files first:
+
+- `AGENTS.md`
+- `qa-ai.config.yaml`
+- `.qa-ai/rules/`
+- `.qa-ai/agents/README.md`
+- `.qa-ai/agents/qa-workflow-orchestrator.md`
+- `.qa-ai/agents/specialists/active.md` when present
+- `.qa-ai/workflows/full-flow.md`
+
+For each phase, load the matching phase agent from `.qa-ai/agents/README.md` and any active specialists before producing or changing artifacts. If the current tool cannot call subagents, treat those Markdown files as required role instructions.
+
+Use `project.interfaceLanguage` / `project.defaultLanguage` from `qa-ai.config.yaml` for user-facing questions and descriptions. Use `gherkin.language` only for generated `.feature` files. Supported values are `en` and `es`; default to `en` if the config is missing.
+
+If `$ARGUMENTS` is empty or the requirement source is ambiguous, ask the user:
+
+1. Where is the requirement source?
+   - Example: `docs/prd.md`, `docs/PRD/checkout.md`, pasted text, configured issue ID or documentation page reference.
+2. What is the official RF ID?
+   - If missing, say final `.feature` generation will pause until it is provided.
+3. What test management project/suite should be used for coverage/sync planning?
+   - If unknown, produce local placeholder analysis and mark the decision as pending.
+4. Should this run produce only proposal artifacts first, or continue to `.feature` generation after approval?
+   - Recommend proposal artifacts first.
+
+Then present a concise plan before modifying files.
+
+Expected local artifacts:
+
+- `qa-ai-output/requirement-analysis.md`
+- `qa-ai-output/testrail-coverage-analysis.md`
+- `qa-ai-output/test-design-proposal.md`
+- `.feature` files under the configured feature path after approval
+- `qa-ai-output/testrail-sync-plan.md`
+- `qa-ai-output/traceability-matrix.md`
+- `qa-ai-output/automation-feasibility-report.md`
+- `qa-ai-output/automation-implementation-plan.md`
+- `qa-ai-output/pr-summary.md`
+
+After feature and QA artifact changes, run the aggregated target-repository validator:
+
+```bash
+node .qa-ai/scripts/validate-target.mjs
+```
+
+For early/incomplete repositories, use `node .qa-ai/scripts/validate-target.mjs --allow-empty --allow-missing --no-strict-doctor`.
+
+Do not write to configured external tools. Ask for the official RF ID before final feature generation if it is missing.
+
+Respect `project.qaTrack` from `qa-ai.config.yaml` (see `.qa-ai/workflows/full-flow.md`).
+
+When this workflow step completes, run `/qa-help` or `node .qa-ai/scripts/qa-help.mjs` and share the recommended next phase.