agentleFS
blamechrisblamechris/chroxy/.claude/skills/qa-update/SKILL.md

qa-update

Skill8 starsChanged 9 days agoMITView on GitHub

Record manual QA test results and run gap analysis against the smoke test matrix.

The file

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 5 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read the current QA log:

    line 33
  2. Very specific:

    Default result is PASS unless the user says otherwise near a scope

    line 60
  3. Distinctive:

    If the input is ambiguous (can't determine which scopes were tested), ask the user to clarify before proceeding.

    line 64
  4. Very specific:

    Run git diff <scope-sha>..HEAD --name-only to find changed files

    line 71
  5. Very specific:

    If a scope's source files changed since its last-tested SHA → mark STALE

    line 87
  6. Distinctive:

    Add any notes from the user

    line 103
  7. Very specific:

    Leave -- scopes untouched.

    line 108
  8. Distinctive:

    Only include scopes that were actually tested in this entry — no rows for untested scopes.

    line 130
  9. Distinctive:

    If no scopes are stale and all scopes have been tested, report full coverage achieved.

    line 161

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

/qa-update

Record manual QA test results and run gap analysis against the smoke test matrix.

Arguments

  • $ARGUMENTS - Freeform description of what was tested, results, and device (e.g., "tested baseline and chat, both pass, iPhone")

Instructions

1. Gather Context

Auto-detect environment — no user input needed for these:

# Current commit
SHA=$(git rev-parse --short HEAD)

# Version from package.json
VERSION=$(node -p "require('./package.json').version")

# Tester name
TESTER=$(git config user.name)

# Timestamp
TIMESTAMP=$(date "+%Y-%m-%d %H:%M")

Read the current QA log:

cat docs/qa-log.md

2. Parse User Input

The user provides $ARGUMENTS as freeform text. Map keywords to the 12 smoke test scopes:

KeywordsScope
baseline, regressionRegression Baseline
connection, connect, qr, tunnelConnection
chat, streaming, messageChat
permission, hooks, approve, denyPermissions
model, switchingModel Switching
cost, usage, tokensCost/Usage Display
no-auth, noauthNo-Auth Mode
selection, copy, exportMessage Selection
input, keyboard, multilineInput Modes
terminal, pty, tmuxTerminal (PTY)
shutdown, cleanup, ctrl-cShutdown/Cleanup
edge, network, resilienceEdge Cases
allAll 12 scopes

Result keywords:

  • Default result is PASS unless the user says otherwise near a scope
  • "fail" / "failed" near a scope → FAIL
  • "partial" / "mostly" near a scope → PARTIAL

If the input is ambiguous (can't determine which scopes were tested), ask the user to clarify before proceeding. Do NOT guess.

3. Gap Analysis

This is the key step. For every scope in the coverage matrix that has been previously tested (status is not --):

  1. Get the scope's last-tested SHA from the matrix
  2. Run git diff <scope-sha>..HEAD --name-only to find changed files
  3. Map changed files to affected scopes using this table:
Changed File(s)Affected Scopes
ws-server.jsConnection, Chat, Permissions, No-Auth
cli-session.jsChat, Permissions, Model Switching
server-cli.js, cli.jsConnection, No-Auth, Shutdown
tunnel.js, tunnel-check.jsConnection
permission-hook.shPermissions
models.jsModel Switching
connection.tsConnection, Chat, Permissions, Model Switching, Cost/Usage
SessionScreen.tsxChat, Permissions, Model Switching, Cost/Usage, Selection
ConnectScreen.tsxConnection
server.js (src/), pty-manager.js, output-parser.jsTerminal
  1. If a scope's source files changed since its last-tested SHA → mark STALE
  2. Files NOT in the mapping (tests, docs, config, scripts) do not trigger staleness

Keep this mapping in sync with docs/smoke-test.md § File-to-Scope Mapping.

4. Update docs/qa-log.md

Make two updates to the file:

Update Coverage Matrix

For each scope that was just tested:

  • Set Status to the test result (PASS/FAIL/PARTIAL)
  • Set Last Tested to today's date
  • Set SHA to current HEAD
  • Set Tester name
  • Add any notes from the user

For scopes flagged as stale by gap analysis (not retested now):

  • Change Status from PASS/PARTIAL to STALE

Leave -- scopes untouched.

Insert Test History Entry

Insert a new entry immediately after the ## Test History heading (before older entries). Format:

### YYYY-MM-DD HH:MM -- Tester @ `SHA` (vX.Y.Z)

**Scopes Tested:**

| Scope | Result | Notes |
|---|---|---|
| Scope Name | PASS | Any notes |

**Device/Platform:** From user input
**Server Mode:** From user input (default: CLI headless)

**Notes:**
- Any additional context from user input

Only include scopes that were actually tested in this entry — no rows for untested scopes.

5. Report

Output a summary to the user:

## QA Update Recorded

**Commit:** `SHA` (vX.Y.Z)
**Tester:** Name
**Date:** YYYY-MM-DD HH:MM

### Results Recorded
- Scope 1: PASS
- Scope 2: FAIL — notes

### Stale Scopes (source files changed since last test)
- Scope: last tested at `abc1234`, files changed: foo.js, bar.ts

### Untested Scopes (never tested)
- Scope 1
- Scope 2

### Suggested Next Tests
Prioritized list based on:
1. FAIL scopes (retest after fix)
2. STALE scopes (source changed)
3. Never-tested scopes (`--`)

If no scopes are stale and all scopes have been tested, report full coverage achieved.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.