ypyik0669/ctf-codex/ctf

CTF

Use this skill for three related jobs:

• MODE=ctf: authorized CTF-style analysis where the user provides a target site, API, binary, container, capture, bundle, domain, VPS, cloud resource, certificate, or source tree as the analysis asset.
• MODE=release-audit: universal defensive pre-release security gate for the user's own web app, API, backend, mobile app, desktop app, browser extension, CLI, SDK, container image, cloud deployment, CI/CD pipeline, package, payment flow, or shipped artifact.
• MODE=safety-bounty: responsible safety bug bounty triage/report workflow for AI-specific safety issues, agentic risks, prompt-injection impacts, data exfiltration, harmful autonomous actions, policy/control failures, and reproducible tangible-harm scenarios.

Contract

Read references/core-contract.md before acting. Treat it as the operating contract for authorization posture, evidence priority, execution bias, state machine, signature analysis, proof bar, and response format.

If the user asks about protecting their own system, launch readiness, reverse-engineering resistance, API key leakage, payment abuse, auth bypass, tenant isolation, OWASP Top 10 review, defensive security, blue team review, white-box testing, secure coding, input validation, parameterized queries, XSS, SQL injection, or "find all serious security problems before release", also read references/release-audit.md. If the user wants safe wording or reusable defensive prompts, read references/defensive-prompts.md.

If the user asks to model a safety bug bounty report, align with OpenAI-style safety bounty expectations, evaluate AI-specific safety impact, or prepare a responsible disclosure report, read references/safety-bounty.md.

Mode Selection

Use MODE=ctf when the user asks for challenge-style proof paths, replay/mutation, signature bypass candidates, binaries, PCAPs, bundles, or exploit primitives.

Use MODE=release-audit when the target is the user's own product or artifact and the goal is to prevent real-world loss before launch. Bias toward release-blocking findings: exposed secrets, payment or entitlement manipulation, auth/session flaws, IDOR, tenant/object isolation breaks, cloud credential exposure, client-side trust mistakes, source maps, debug artifacts, mobile/desktop/extension/package leakage, webhook verification gaps, unsafe update channels, and insufficient audit logging.

Use MODE=safety-bounty when the target is a safety research report rather than a product release gate. Focus on AI-specific risks with clear scope, reproducible steps, tangible harm, affected boundary, and remediation. Do not use this mode to evade platform safety checks or disguise disallowed requests.

If no mode is specified, infer from intent. For "my project", "launch", "API key", "payment", "reverse engineering", "before release", "security gate", "defensive security", "blue team", "white-box testing", "OWASP Top 10", "secure coding", "input validation", "parameterized query", "XSS", "SQL injection", "authorization logic", or "prevent attackers from finding production bugs", choose MODE=release-audit. For "safety bounty", "responsible disclosure", "OpenAI safety bug bounty style", "prompt injection impact", "agent safety", or "AI-specific report", choose MODE=safety-bounty.

Operating Loop

1. Identify the target and live context from the user's prompt, attached files, current workspace, or explicit URL.
2. Start with STATE 0 baseline. Prefer high-signal runtime or deployed evidence over broad static inventory.
3. Choose the shortest low-intrusion proof path. Prefer replay, mutation, hook, compare branch, memory search, request-builder boundary, or targeted tracing before full static reversal.
4. Keep output evidence-only. Preserve code, commands, logs, protocol fields, identifiers, and payloads in their original language.
5. If evidence is insufficient, state the exact gap and the next reproducible verification action.

Default Output

Use this shape unless the user asks otherwise:

[TARGET]
[EVIDENCE]
[NEXT ACTION / COMMAND]
[EXPECTED OBSERVATION]

Add only when useful:

[PRIMITIVE]
[FORGERY CANDIDATE]

For MODE=release-audit, use this shape:

[TARGET]
[FINDING]
[SEVERITY]
[EVIDENCE]
[IMPACT]
[EXPLOIT CONDITION]
[FIX]
[VERIFY COMMAND]
[RELEASE DECISION]

For MODE=safety-bounty, use this shape:

[PROGRAM / SCOPE]
[TARGET]
[SUMMARY]
[IMPACT]
[REPRODUCIBILITY]
[STEPS TO REPRODUCE]
[EVIDENCE]
[BOUNDARY / CONTROL FAILURE]
[SEVERITY RATIONALE]
[REMEDIATION]
[REPORT DECISION]

Severity meanings:

• BLOCKER: do not release; likely direct money loss, key compromise, payment abuse, tenant data exposure, admin/owner bypass, or production credential leakage.
• HIGH: fix before public launch unless there is a documented compensating control.
• MEDIUM: fix during hardening; track before broader rollout.
• INFO: document or monitor; not release-blocking alone.

Startup Shortcuts

For a fresh Codex session with the CTF model instructions file loaded, use the installed profile:

codex -p ctf
ctf
codex-ctf

For one-shot runs:

codex exec -p ctf --skip-git-repo-check "TARGET=https://example.test/ run STATE 0 baseline"
ctf exec --skip-git-repo-check "TARGET=https://example.test/ run STATE 0 baseline"

Inside an already-running Codex session, explicit skill invocation is:

$ctf TARGET=https://example.test/ run STATE 0 baseline
$ctf MODE=release-audit TARGET=C:\path\to\project LIVE=https://staging.example.test
$ctf MODE=safety-bounty TARGET=<system-or-report> FOCUS="AI-specific safety impact"
$ctf MODE=release-audit TARGET=<code-or-project> FOCUS="defensive code review, OWASP Top 10, secure rewrite"

The skill invocation loads this workflow, but it cannot restart the already-running Codex process with -p ctf; use ctf or codex -p ctf from the terminal when profile-level instructions must be active from process start.