How to use the Pentest Verification Rules agent skill

What the skill makes the agent do

Agent skills are instruction packages that an AI agent loads when a task matches them. This one contains a short set of verification rules that apply to penetration testing records. Its core rule is that search results and public exploit hints are not vulnerabilities. The agent may not record a finding through record_vulnerability or mark it confirmed just because public intelligence or a proof-of-concept suggests it could work.

A finding can only be marked confirmed when the agent has saved real evidence in the record, such as command output, HTTP responses, file contents, or callback records. Unverified ideas must be labelled tentative or left out. Failed tests are written down as negative results so the same test is not repeated later.

• Search results and public exploit hints are treated as leads, not findings.
• A confirmed fact must carry evidence in its body or in the linked vulnerability's POC.
• Unproven ideas are labelled tentative or dropped; speculative wording such as 'possibly' or 'suspected' is not allowed.
• Failed verification is saved as a negative fact via upsert_project_fact so it is not retried.

Install the skill from a ZIP file

Download the ZIP for the skill from this page and unzip it. The package contains a single file, SKILL.md. To make it available to Claude Code for your user account, place the unzipped folder in ~/.claude/skills/. To limit it to one project, place it in that project's .claude/skills/ folder instead.

If you use the Claude apps rather than Claude Code, you can upload the skill instead. In the app, open Settings, go to Capabilities, and upload the skill there.

• Personal install: ~/.claude/skills/ (available across your projects).
• Project install: .claude/skills/ inside the project folder (available only there).
• Claude apps: Settings → Capabilities → Skills, then upload.

Check the requirements before you start

This skill is not standalone. It depends on the CyberStrikeAI platform, because it refers to that platform's record_vulnerability and upsert_project_fact tools. Without those tools the rules have nothing to write to.

It also refers to a companion skill, pentest-blackboard, which provides the shared blackboard tools. The verification skill points to it for alignment, so install it too if your workflow uses the shared record.

• CyberStrikeAI platform with record_vulnerability and upsert_project_fact tools.
• Companion skill pentest-blackboard for the shared blackboard tools.
• The skill runs no scripts and makes no network calls; it is a rules document.

Trigger the skill with natural requests

You do not need a special command. The skill's description says to use it when writing project facts, validating findings, or avoiding hallucination, so ask for those things in plain language and the agent should load it when the request matches.

Good requests name the record you want to keep accurate, for example asking the agent to check whether a finding has evidence before it is saved, or to log a failed test so it is not repeated.

• 'Before you save this finding, check whether we have evidence for it.'
• 'Record the failed SSH login test as a negative result so we do not retry it.'
• 'Mark the Jenkins lead as tentative until we confirm it.'
• 'Write the confirmed project fact for the admin panel and attach the HTTP response.'

Work through an example

Suppose a search turns up a public write-up for a known flaw in a web application. Under this skill the agent does not record it as a vulnerability. It notes the lead as tentative, then runs a check against the target. If the HTTP response confirms the behaviour, the agent saves that response as evidence and records the finding as confirmed. If the check fails, the agent saves a negative fact stating what was tested and that no exploitable issue was found.

The point of this flow is that every confirmed item in the record can be traced back to something the agent actually observed.

Safety notes before using it on real systems

The skill is designed to drive active exploitation work, but it does not check that you are allowed to test a target. It gives no authorization check of its own. Only use it against systems you have written authorization to test.

The skill runs no scripts and uses no network access. Any active testing is carried out through the platform and tools you run, so review those separately.

• Get written authorization for every target before testing.
• Keep the scope of the engagement in the shared record so the agent works within it.