Manual QA

Generate a manual QA checklist from code changes. Use when the user wants to test a PR, commit, branch, or staged changes — or says "QA this", "test plan", "...

Security Scan

The skill's instructions expect the agent to run git/GitHub CLI commands and potentially use GitHub credentials, but the skill metadata declares no required binaries or environment variables — this mismatch is suspicious and should be resolved before use.

Purpose & Capability

The SKILL.md explicitly instructs the agent to run git and GitHub CLI commands (gh pr diff, git show, git diff, etc.) and to detect project test commands (package.json, Makefile). However, the skill metadata lists no required binaries or credentials. Either the metadata is incomplete (omitted needed tools/creds) or the instructions assume capabilities the environment may not provide.

Instruction Scope

The runtime instructions stay within the stated purpose (generate a QA checklist from code changes and offer to run agent-testable steps). They explicitly limit scope (only run steps relevant to the diff, prefer targeted tests). The instructions do require reading repository files and running commands locally or calling APIs, which is reasonable for this purpose.

Install Mechanism

There is no install spec (instruction-only), so nothing is written to disk by the skill itself. This is lower risk and consistent with an instruction-only QA helper.

Credentials

Although the skill declares no required environment variables, the instructions implicitly require authenticated access to GitHub (gh CLI) for PR diffs and may need network access for curl/API calls. The absence of declared credentials (e.g., GH_TOKEN or gh auth) is a proportionality mismatch that could hide implicit credential needs.

Persistence & Privilege

The skill is not marked always:true and does not request persistent presence or modify other skills' configs. Autonomous invocation is allowed (the platform default); that is expected for a tool that can run commands, but users should be aware the agent could execute terminal steps if permitted.

What to consider before installing

This skill's instructions are coherent for generating QA checklists, but the metadata omits practical requirements. Before installing or invoking it: 1) Verify the runtime environment has git and the GitHub CLI (gh) if you expect PR diff support; otherwise the agent will fail on PR URLs. 2) Understand that using gh pr diff or API calls typically requires GitHub authentication (gh auth or a token); the skill does not declare or request credentials — decide how you'll provide them and whether that's acceptable. 3) Be prepared for the agent to read repository files and run commands/tests if you accept its offer to "run 🤖 steps"; run such actions in a safe or CI-like environment if you have security concerns. 4) If you want to proceed, ask the skill author (or update the metadata) to declare required binaries and any environment variables (e.g., GITHUB_TOKEN) so you can evaluate permission needs accurately.

Generate a step-by-step QA checklist from code changes, separating what the agent can verify in the terminal from what needs a human.

Determine the change source

Use the first match:

1. Argument is a PR URL or number → gh pr diff
2. Argument is a commit SHA → git show
3. Staged changes exist → git diff --cached
4. Current branch differs from main → git diff main...HEAD
5. Unstaged changes exist → git diff

If nothing matches, tell the user there are no changes to QA.

Analyze the changes

Read the diff carefully. Understand what the change does — not just what files changed, but the intent. Look at:

• What behavior is being added, modified, or removed
• What inputs the changed code accepts
• What side effects it has (API calls, file writes, database changes, UI updates)
• What could go wrong

Output the QA checklist

Produce a numbered list of concrete test steps. Each step should be specific enough that someone unfamiliar with the code could follow it. Group by feature area if the change spans multiple concerns.

For each step, mark it:

• 🤖 Agent can test — The agent can run this in the terminal right now. CLI commands, scripts, API calls with curl, file assertions, running test suites, checking build output.
• 👤 Human must test — Requires a human. Interactive prompts (TTY-dependent), authenticated web sessions, visual/UI verification, multi-step flows across web + email + mobile, anything needing a browser the agent doesn't control, real-device testing.

Include both:

• Happy paths — the change works as intended with normal inputs
• Error paths — bad inputs, missing config, network failures, edge cases, permission errors

Offer to run agent-testable steps

After presenting the checklist, offer to run all 🤖 steps. If the user agrees, run them and report results inline — pass/fail for each, with output on failure.

Keep it practical

• Don't generate steps for things the diff clearly doesn't affect
• Don't suggest running the full test suite unless the change is broad — suggest targeted tests
• If the project has a test command (in package.json, Makefile, etc.), use it
• For bug fixes, include a step that reproduces the original bug and confirms it's fixed
• For new features, include a step that exercises the feature end-to-end