check

Overview of check skill

What the check skill does

The check skill is a review-and-gate workflow for code diffs, PRs, issue triage, release readiness, pushes, and project audits. It is best for users who want a fast but disciplined answer to: “Is this safe to ship, what is broken, and what should I fix before merging?”

Best fit for this skill

Use the check skill when you need code review for a concrete change set, including before merge, before release, or when validating generated artifacts and follow-through actions. It is especially useful when you want the agent to inspect the worktree first, avoid hidden local changes, and separate fixable issues from items that need human confirmation.

What makes check different

The check skill is not a generic “look at this code” prompt. It has explicit safety gates for dirty or untracked worktrees, a clear review-first workflow, and routing for specialist review when architecture or security risks are present. That makes it stronger than a one-off prompt for check for Code Review because it reduces guesswork about when to inspect, what to inspect, and when to stop.

How to Use check skill

Install and trigger check

Install with:

npx skills add tw93/Waza --skill check

Then invoke it when you have a concrete review target: a diff, branch, PR, release candidate, commit range, or repo audit request. For check usage, give the agent a specific scope such as “review the last 3 commits,” “check this PR before merge,” or “audit release readiness after dependency updates.”

Give the skill the right input

The strongest input for check is not “is this good?” but a bounded task with context. Good examples:

• “Check this PR for security and architecture regressions before merge.”
• “Review the current worktree and tell me what blocks release.”
• “Audit the generated files and tell me whether they match source changes.”

Include the branch, commit range, intended release, and any constraints like “do not modify files” or “only inspect public repo context.” That helps the skill avoid broad, vague review behavior.

Read these files first

Start with SKILL.md, then inspect references/project-context.md and references/persona-catalog.md to understand review depth, specialist routing, and release expectations. Use agents/reviewer-security.md and agents/reviewer-architecture.md when the diff touches trust boundaries, APIs, imports, or module structure. references/public-reply.md matters when the workflow includes maintainer follow-up on issues or PRs.

Practical workflow tips

Before review, the skill expects a worktree safety check via git status --short --branch -uall. That matters because dirty or untracked changes can change the meaning of the review. If you want a better check guide result, tell the agent whether it should only report findings, whether it may fix safe issues, and what verification command should be used after changes.

check skill FAQ

Is check only for code review?

No. The check skill also covers release readiness, pushes, published artifacts, issue and PR triage, and project-wide audits. It is a better fit than a normal prompt when the task includes “before ship” judgment, not just code reading.

When should I not use check?

Do not use check for open-ended idea exploration, root-cause debugging, or prose editing. The skill is designed for concrete diffs and operational review, not for brainstorming or narrative feedback.

Is check beginner friendly?

Yes, if you can name the target and the outcome. Beginners get the best results when they say exactly what changed, what they want reviewed, and whether they want only findings or also safe fixes. Without that, check install may be easy but check usage becomes too broad to be reliable.

How is it different from a plain prompt?

A plain prompt usually asks for a subjective review. check adds a disciplined path: safety preflight, scope control, verification expectations, and specialist routing for security or architecture. That makes it more dependable for check for Code Review than an ad hoc review request.

How to Improve check skill

Provide a tighter review brief

The most useful inputs are: what changed, why it changed, what must not break, and what kind of review you want. For example, “review only the authentication path,” “focus on release artifacts,” or “check whether this refactor changes public APIs.” This narrows the search and improves signal.

Surface the hard constraints

Tell the skill about packaging rules, generated files, protected paths, and required verification commands. If the repo has a build or release source of truth, mention it up front. That reduces false confidence and helps the check skill spot drift, missing artifacts, or unsafe follow-through.

Iterate from findings, not from praise

After the first pass, respond with the exact findings you want rechecked or the patch you applied. The skill improves when you ask for a second pass on one risk area at a time, such as security, architecture, or release readiness. If the output feels too broad, narrow the scope rather than asking for “more detail.”