security-research
Team Mode security research skill. Orchestrates 3 vulnerability hunters and 2 PoC engineers to audit a codebase in parallel, prove exploitability, classify root causes, and calibrate severity by actual exploitability. Use for security review, vulnerability research, exploitability audit, pre-release security check, threat model validation, and /security-research. Triggers: 'security-research', 'security research', 'security review', 'vulnerability audit', 'exploitability audit', '보안 리뷰', '취약점 감사'.
- Installs
- 484
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/code-yeongyu/oh-my-openagent --skill security-research- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads security-research automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
Security Research - Team Mode Vulnerability Audit
Use this skill to run a parallel security audit that separates real exploitability from generic concern. The team has 3 vulnerability hunters and 2 PoC engineers.
Hard Preconditions
Before starting, verify:
team_*tools are available. If not, stop and tell the user:security-research requires team-mode. Set team_mode.enabled: true in your oh-my-openagent config, restart opencode, then retry.- You are in the main session, not a background subagent.
- You have a concrete target: repository, diff range, PR, release candidate, path list, or threat surface.
If the user provided no target, audit the current repository and current branch diff against its upstream or merge base. If there is no diff, audit the security-sensitive surfaces in the working tree.
Severity Standard
Use these references as the scoring frame:
- CWE for root-cause weakness classification: https://cwe.mitre.org/
- OWASP WSTG for test methodology: https://devguide.owasp.org/en/06-verification/01-guides/01-wstg/
- OWASP ASVS for control verification: https://owasp.org/www-project-application-security-verification-standard/
- CVSS v4.0 for exploitability and impact scoring: https://www.first.org/cvss/v4.0/specification-document
Rules:
- No severity without an attack path.
- No critical or high finding without concrete exploit preconditions and impact.
- Keep CWE category separate from severity.
- Prefer a small, reproducible PoC over theoretical language.
- Never run destructive exploits against real services or third-party systems.
- Use local fixtures, toy payloads, dry runs, or static proof when real execution would be unsafe.
Team Roster
Create one Team Mode run with these 5 members:
| Member | Kind | Category | Role |
|---|---|---|---|
surface-hunter | category | deep-low | Map entry points, trust boundaries, and reachable attack surfaces. |
auth-data-hunter | category | ultrabrain | Hunt auth, authorization, data isolation, injection, and secret handling flaws. |
runtime-supply-hunter | category | unspecified-high | Hunt filesystem, subprocess, archive, dependency, hook, MCP, and config risks. |
poc-engineer-a | category | unspecified-high | Build minimal PoCs for the strongest candidate findings. |
poc-engineer-b | category | deep-high | Independently reproduce, falsify, or downgrade candidate findings. |
Call team_create with an inline spec:
team_create({
inline_spec: {
name: "security-research",
description: "Parallel exploitability-driven security research team.",
members: [
{
name: "surface-hunter",
kind: "category",
category: "deep-low",
prompt: "You map attack surface. Enumerate entry points, trust boundaries, attacker-controlled inputs, data sinks, privilege transitions, and sensitive assets. Return evidence with file paths and exact functions. Do not assign severity unless you can name an attack path."
},
{
name: "auth-data-hunter",
kind: "category",
category: "ultrabrain",
prompt: "You hunt auth, authorization, tenant/data isolation, injection, SSRF, credential exposure, and confused-deputy flaws. Reason from attacker capability to impact. Return only findings with concrete exploit preconditions, CWE candidates, and verification steps."
},
{
name: "runtime-supply-hunter",
kind: "category",
category: "unspecified-high",
prompt: "You hunt filesystem, subprocess, archive extraction, dependency, hook execution, MCP, config, and environment-variable risks. Check path traversal, command injection, unsafe downloads, permission boundaries, and supply-chain assumptions. Cite file paths and commands used."
},
{
name: "poc-engineer-a",
kind: "category",
category: "unspecified-high",
prompt: "You build minimal safe PoCs for candidate findings. Use toy inputs and local-only execution. Your job is to prove or disprove exploitability, not to broaden scope. Report exact reproduction steps and expected output."
},
{
name: "poc-engineer-b",
kind: "category",
category: "deep-high",
prompt: "You independently reproduce candidate findings and try to falsify them. Downgrade anything without a working path. If a PoC is unsafe to run, design a safe static or dry-run proof and explain the limit."
}
]
}
})
If a category is unavailable, retry once by replacing only that category with unspecified-high. Do not reduce the team below 5 members.
Workflow
Phase 0: Scope and Baseline
Collect:
- Target scope and reason for audit.
- Branch, base ref, diff, and changed files if this is a change review.
- Security-sensitive directories and files if this is a full-repo audit.
- Existing tests and commands that exercise relevant surfaces.
- Any user-stated constraints, such as no network calls or no destructive tests.
Use rg, git diff, git log, LSP, and existing tests before assigning work.
Phase 1: Independent Hunter Pass
Send one prompt to the 3 hunters:
Audit target:
{target summary}
Context:
{diff, file list, security-sensitive paths, known constraints}
Task:
Find candidate vulnerabilities in your assigned role. For each candidate include:
- title
- affected file/function
- attacker capability
- attack path
- impact
- CWE candidate
- exact evidence
- safe verification idea
Reject generic hardening advice. Return only candidates with a plausible path.
Wait for all hunters.
Phase 2: PoC Pass
Deduplicate hunter candidates. Send the strongest candidates to both PoC engineers.
Each PoC engineer must return:
- Reproduced, falsified, or unsafe-to-run.
- Exact commands, fixtures, or static proof.
- Observed output or reason it fails.
- Severity recommendation using exploitability and impact.
- Downgrade rationale for anything not reproduced.
Phase 3: Cross-Check
Send the PoC results back to all 5 members.
Ask every member:
- Which findings survive?
- Which findings should be downgraded or removed?
- What remediation is smallest and specific?
- What regression test would prevent recurrence?
Phase 4: Final Report
Produce this report:
## Security Research Result
### Verdict
PASS | PASS WITH FINDINGS | BLOCK
### Scope
- Target:
- Base/diff:
- Commands run:
### Findings
| Severity | Title | CWE | Exploitability | Impact | PoC | Fix |
|----------|-------|-----|----------------|--------|-----|-----|
### Finding Details
For each finding:
- Evidence:
- Attack path:
- PoC:
- Severity rationale:
- Minimal fix:
- Regression check:
### Downgraded or Rejected Candidates
| Candidate | Reason |
|-----------|--------|
### Residual Risk
- What was not tested and why.
Output Rules
- Lead with the verdict.
- Do not bury blocking issues.
- Do not report speculative findings as vulnerabilities.
- Do not claim CVSS precision unless you actually scored the metrics.
- Include exact file paths and commands for every surviving finding.
- If no findings survive PoC, say that plainly and list residual risk.
FAQ
What does the security-research skill do?
Team Mode security research skill. Orchestrates 3 vulnerability hunters and 2 PoC engineers to audit a codebase in parallel, prove exploitability, classify root causes, and calibrate severity by actual exploitability. Use for security review, vulnerability research, exploitability audit, pre-release security check, threat model validation, and /security-research. Triggers: 'security-research', 'security research', 'security review', 'vulnerability audit', 'exploitability audit', '보안 리뷰', '취약점 감사'.
How do I install security-research?
Run npx skills add https://github.com/code-yeongyu/oh-my-openagent --skill security-research in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/security-research/ (personal) or .claude/skills/security-research/ (project).
Which AI agents can use security-research?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is security-research safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains security-research?
It is published by code-yeongyu in code-yeongyu/oh-my-openagent. It has 484 recorded installs.
More from code-yeongyu/oh-my-openagent
github-triage
code-yeongyu/oh-my-openagent
Read-only GitHub triage for issues AND PRs. 1 item = 1 background task (category: quick). Analyzes all open items and writes evidence-backed reports to /tmp/{datetime}/. Every claim requires a GitHub permalink as proof. NEVER takes any action on GitHub - no comments, no merges, no closes, no labels. Reports only. Triggers: 'triage', 'triage issues', 'triage PRs', 'github triage'.
github-issue-triage
code-yeongyu/oh-my-openagent
Open the skill to read its SKILL.md instructions.
work-with-pr
code-yeongyu/oh-my-openagent
Full PR lifecycle in a fresh task-owned git worktree: implement via the ulw-loop skill with mandatory evidence-bound manual QA → reviewer-readable English PR → verification loop (CI + Cubic, where Cubic is skipped only when its quota is exhausted) → merge by default → worktree cleanup. Decomposes one task into the smallest atomic, independently-mergeable PRs and builds the independent ones concurrently via one worktree per PR driven by parallel subagents or a team. Unbounded loop: any failing gate sends you back to fix-and-re-QA inside that PR's worktree. Use whenever implementation work needs to land as a PR. Triggers: 'create a PR', 'implement and PR', 'work on this and make a PR', 'implement issue', 'land this as a PR', 'split into atomic PRs', 'parallel PRs', 'work-with-pr', 'PR workflow', 'implement end to end', even when user just says 'implement X' if the context implies PR delivery.
pre-publish-review
code-yeongyu/oh-my-openagent
Nuclear-grade 12-agent pre-publish release gate. Runs /get-unpublished-changes to detect all changes since last npm release, spawns up to 10 ultrabrain agents for deep per-change analysis, invokes /review-work (orchestrator manual QA plus one gate reviewer) for holistic review, and 1 oracle for overall release synthesis. Runs ONLY when the user explicitly asks for a pre-publish review — a plain publish/release request MUST NOT trigger this; /publish ships directly. Triggers: 'pre-publish review', 'review before publish', 'release review', 'pre-release review', 'ready to publish?', 'can I publish?', 'pre-publish', 'safe to publish', 'publishing review', 'pre-publish check'.
hyperplan
code-yeongyu/oh-my-openagent
Adversarial multi-agent planning skill. Self-orchestrates 5 hostile category members (unspecified-low, unspecified-high, deep, ultrabrain, artistry) via team-mode for ruthless cross-critique debate, distills only the defensible insights, then MANDATORILY hands the distilled insight bundle to the plan agent for executable plan formalization. Use when planning needs maximum rigor and surfacing of weak assumptions, blind spots, and over-engineering. Triggers: 'hyperplan', 'hpp', '/hyperplan', 'adversarial plan', 'hostile planning', 'cross-critique plan', '하이퍼플랜', '적대적 계획', '교차 비평'.
remove-deadcode
code-yeongyu/oh-my-openagent
Remove unused code from this project with ultrawork mode, LSP-verified safety, atomic commits. Triggers: remove dead code, dead code, cleanup, remove unused.
Popular security skills
azure-compliance
microsoft/azure-skills
Run Azure compliance and security audits with azqr plus Key Vault expiration checks. Covers best-practice assessment, resource review, policy/compliance validation, and security posture checks. WHEN: compliance scan, security audit, BEFORE running azqr (compliance cli tool), Azure best practices, Key Vault expiration check, expired certificates, expiring secrets, orphaned resources, compliance assessment.
minimal-run-and-audit
lllllllama/rigorpilot-skills
Rigor Run skill for README-first deep learning repo reproduction. Use when the task is specifically to capture or normalize evidence from the selected smoke test or documented inference or evaluation command and write standardized reprooutputs/ files, including patch notes when repository files changed. Do not use for training execution, initial repo intake, generic environment setup, paper lookup, target selection, hidden scientific-meaning changes, or end-to-end orchestration by itself.
seo-audit
coreyhaines31/marketingskills
When the user wants to audit, review, or diagnose SEO issues on their site. Also use when the user mentions "SEO audit," "technical SEO," "why am I not ranking," "SEO issues," "on-page SEO," "meta tags review," "SEO health check," "my traffic dropped," "lost rankings," "not showing up in Google," "site isn't ranking," "Google update hit me," "page speed," "core web vitals," "crawl errors," "indexing issues," "stuck on page 2," "striking distance keywords," "title tag rewrite," "low CTR," "local SEO," "Google Business Profile," or "map pack." Use this even if the user just says something vague like "my SEO is bad" or "help with SEO" — start with an audit. For building pages at scale to target keywords, see programmatic-seo. For adding structured data, see schema. For AI search optimization, see ai-seo.
firebase-security-rules-auditor
firebase/agent-skills
Audits Firebase (Firestore, Cloud Storage) security rules for vulnerabilities, privilege escalation, role bypasses, create vs update inconsistencies, resource exhaustion, type safety, size limits, and hasOnly ownership checks. Use when auditing/reviewing rules, running red-team rule assessments, or scoring against auditor checklists. Don't use for Firebase CLI (login, deploy), Auth, Crashlytics, Remote Config, or database queries.
audit
pbakaus/impeccable
Run technical quality checks across accessibility, performance, theming, responsive design, and anti-patterns. Generates a scored report with P0-P3 severity ratings and actionable plan. Use when the user wants an accessibility check, performance audit, or technical quality review.
competitors
coreyhaines31/marketingskills
When the user wants to create competitor comparison or alternative pages for SEO and buyer-facing use. Also use when the user mentions 'alternative page,' 'vs page,' 'competitor comparison,' 'comparison page,' '[Product] vs [Product],' '[Product] alternative,' 'competitive landing pages,' 'how do we compare to X,' 'competitor teardown,' 'audit our competitor pages,' 'are our comparison pages out of date,' or 'competitive asset audit.' Use this for any content that positions your product against competitors. Covers four formats: singular alternative, plural alternatives, you vs competitor, and competitor vs competitor. For auditing existing claims (not researching competitors from scratch, which is competitor-profiling; not technical SEO on these pages, which is seo-audit), use the asset audit here. For internal battle cards and sales-specific competitor docs, see sales-enablement.