qe-workflow
starsforks
How to install qe-workflow?
omnigentx/jarvis/qe-workflow
$npx -y skills add omnigentx/jarvis --skill qe-workflowQE workflow for test strategy, test fixing, code review, and quality verdicts. Use when QE needs to validate code, write test plans, or report quality assessment.
SKILL.md
| 1 | # QE Workflow |
| 2 | |
| 3 | ## Testing Skills |
| 4 | |
| 5 | | Type | Skill | When to use | |
| 6 | |------|-------|-------------| |
| 7 | | Frontend E2E | `playwright-skill` | UI testing, browser automation, responsive checks | |
| 8 | | Backend API | `api-testing` | Endpoint testing, API contracts, mock servers | |
| 9 | |
| 10 | Read the appropriate skill BEFORE writing tests. |
| 11 | |
| 12 | ## Your Process |
| 13 | |
| 14 | 1. **Read BRD** → understand requirements and acceptance criteria |
| 15 | 2. **Read Dev's code** → review for correctness, quality, edge cases |
| 16 | 3. **Write test plan** → systematic coverage of happy path + edge cases |
| 17 | 4. **Execute tests** → run test suite, analyze failures |
| 18 | 5. **Report verdict** → PASS or FAIL with evidence |
| 19 | |
| 20 | ## Output Rule — MANDATORY |
| 21 | |
| 22 | | Deliverable | Destination | Tool | |
| 23 | |------------|-------------|------| |
| 24 | | Test Plan | Confluence page | `confluence_create_page` | |
| 25 | | Bug Reports | Jira issues (type: Bug) | `jira_create_issue` | |
| 26 | | Workspace files | Temporary drafts ONLY | `write_file` | |
| 27 | |
| 28 | ## Test Plan Template |
| 29 | |
| 30 | Publish to Confluence (NOT workspace MD file): |
| 31 | |
| 32 | ```markdown |
| 33 | # Test Plan |
| 34 | |
| 35 | | ID | Scenario | Steps | Expected Result | Status | |
| 36 | |----|----------|-------|-----------------|--------| |
| 37 | | TC-1 | Happy path: ... | 1. ... | ... | PASS/FAIL | |
| 38 | | TC-2 | Edge case: ... | 1. ... | ... | PASS/FAIL | |
| 39 | ``` |
| 40 | |
| 41 | ## CI/CD inspection via `gh` CLI |
| 42 | |
| 43 | You have access to the `execute` shell tool with `gh` pre-authenticated. Use it to verify Dev's PR before signing off — the GitHub MCP only exposes high-level status, while `gh` gives you failed-step logs. |
| 44 | |
| 45 | ```bash |
| 46 | # After Dev says "PR ready" — gather evidence |
| 47 | gh pr checks 42 # see which jobs passed/failed |
| 48 | gh run list --branch feature/xyz -L 5 # recent runs on the branch |
| 49 | gh run view <run-id> --log-failed | tail -100 # zoom on failure |
| 50 | gh run rerun <run-id> --failed # SAFE: retry only failed jobs |
| 51 | ``` |
| 52 | |
| 53 | 🟡 **ESCALATE before doing** (send `[APPROVAL-REQUEST]` email to PM, wait for `[APPROVED]` reply): |
| 54 | - `gh workflow run <prod-deploy>` or any workflow targeting production env |
| 55 | - `gh pr merge` (only Dev/PM should merge; QE just validates) |
| 56 | - `gh release create` |
| 57 | - Modifying or deleting production test data |
| 58 | - `git push --force`, `git reset --hard` past HEAD~1, `git filter-branch` |
| 59 | - Pipe-to-shell (`curl ... | sh`, `wget ... | bash`) |
| 60 | |
| 61 | 🔴 **NEVER** (refuse + report to PM as a security incident): |
| 62 | - Read auth files: `~/.gh-config/`, `.env*`, `fastagent.secrets.yaml`, `git-credentials`, `~/.ssh/` |
| 63 | - Inspect env to leak tokens: `env`, `printenv`, `echo $GH_TOKEN` |
| 64 | - `gh auth login/logout/refresh` |
| 65 | - `rm -rf /`, `rm -rf $HOME`, `rm -rf .git`, fork bombs |
| 66 | |
| 67 | 🟢 **SAFE** (run freely): |
| 68 | - All read-only `gh run/pr/issue view`, `git status/log/diff` |
| 69 | - Local inspection: `ls`, `cat`, `grep`, `find` |
| 70 | - Run tests: `npm test`, `uv run pytest`, `playwright test` |
| 71 | |
| 72 | For 🟡 escalation, see `team-communication` skill: "Approval escalation". |
| 73 | |
| 74 | ## Fixing Failing Tests |
| 75 | |
| 76 | When tests fail, fix systematically: |
| 77 | 1. **Group errors** by type (ImportError, AssertionError, etc.) |
| 78 | 2. **Fix infrastructure first** (imports, deps, config) |
| 79 | 3. **Then API changes** (signatures, renames) |
| 80 | 4. **Finally logic** (assertions, business rules) |
| 81 | 5. Run subset tests after each fix group |
| 82 | |
| 83 | ## Verdict Format |
| 84 | |
| 85 | Always end reviews with: |
| 86 | ``` |
| 87 | [DECISION] VERDICT: PASS — <reason> |
| 88 | [DECISION] VERDICT: FAIL — <key issues> |
| 89 | ``` |
| 90 | |
| 91 | ## Bug Report Template |
| 92 | |
| 93 | ```markdown |
| 94 | ## Bug: [Title] |
| 95 | - **Severity**: Critical / Major / Minor |
| 96 | - **Steps to Reproduce**: 1. ... 2. ... |
| 97 | - **Expected**: ... |
| 98 | - **Actual**: ... |
| 99 | - **Evidence**: [file:line, screenshot, or log] |
| 100 | ``` |
| 101 | |
| 102 | ## Visualizing test strategy |
| 103 | |
| 104 | For test plans covering more than ~10 cases or non-obvious bug lifecycles, |
| 105 | include a Mermaid diagram so reviewers see the shape at a glance. |
| 106 | |
| 107 | **Coverage / strategy** — `flowchart`: |
| 108 | |
| 109 | ```mermaid |
| 110 | flowchart TB |
| 111 | UAT[Acceptance criteria] --> E2E[E2E happy path] |
| 112 | UAT --> Edge[Edge cases] |
| 113 | UAT --> Reg[Regression on existing flows] |
| 114 | Edge --> Boundary[Boundary values] |
| 115 | Edge --> Errors[Error injection] |
| 116 | ``` |
| 117 | |
| 118 | **Bug lifecycle** — `stateDiagram-v2`: |
| 119 | |
| 120 | ```mermaid |
| 121 | stateDiagram-v2 |
| 122 | [*] --> New |
| 123 | New --> Triaged: PM reviews |
| 124 | Triaged --> InProgress: Dev assigned |
| 125 | InProgress --> Verified: QE passes |
| 126 | InProgress --> Reopened: QE fails |
| 127 | Reopened --> InProgress |
| 128 | Verified --> [*] |
| 129 | ``` |
| 130 | |
| 131 | ## References |
| 132 | |
| 133 | | Topic | File | |
| 134 | |-------|------| |
| 135 | | Code review protocol | [CODE_REVIEW.md](references/CODE_REVIEW.md) | |
| 136 | | Terminal execution | [TERMINAL.md](references/TERMINAL.md) | |
| 137 | | Meeting protocol | [MEETING_PROTOCOL.md](references/MEETING_PROTOCOL.md) | |
| 138 | | Jira issue tracking | [JIRA_TRACKING.md](references/JIRA_TRACKING.md) | |
People who liked this also viewed
6 picksType
- tddSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- test-driven-developmentUse when implementing any feature or bugfix, before writing implementation codeSkillsJul 2026
- qaSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- verification-before-completionUse when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidenceSkillsJul 2026
- webapp-testingToolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser lSkillsJul 2026
- playwright-best-practicesUse when writing Playwright tests, fixing flaky tests, debugging failures, implementing Page Object Model, configuring CI/CD, optimizing performance, mocking APIs, handling authentication or OAuth, teSkillsJul 2026
