Menu
Find and safely ship one evidence-backed security improvement using an approved repository contract. Use when reviewing, hardening, or fixing a security issue in an unfamiliar codebase.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Design, build, review, or test command-line interfaces that work well for humans, scripts, agents, pipes, and CI. Use when defining command trees, arguments and flags, stdout/stderr contracts, human and structured output, exit codes, prompts, configuration precedence, destructive-action safeguards, TTY behavior, completion, or CLI compatibility. Also use when a TUI needs a stable non-interactive command surface. Language-agnostic core with optional TypeScript implementation references.
Design, audit, and evolve repository, source, module, and package structures so real ownership, runtime, dependency, and change boundaries are easy to see and enforce. Use when deciding where code belongs; reorganizing flat or layer-first trees; structuring by feature, route, screen, command, workflow, use case, bounded context, or capability; evaluating DDD or ports-and-adapters placement; planning safe folder migrations; or reviewing package and import direction. Do not activate for ordinary file moves whose destination is already established by the repository.
Design, build, review, or refine responsive Terminal User Interfaces (TUIs), especially Rust Ratatui and Ruby TTY/cli-ui applications. Use for TUI state and event architecture, terminal layout, navigation, keyboard and text-input behavior, async data loading, accessibility, rendering, resizing, empty/error/loading states, or visual polish. When the product also exposes scriptable commands, use cli-design alongside this skill for the CLI contract.
Choose and revise Codex model and reasoning effort for multi-stage engineering work. Use when deciding between Sol, Terra, and Luna; balancing judgment, cost, and latency; delegating bounded implementation or research to subagents; planning a model handoff; or escalating work after uncertainty, risk, or failed attempts increase. Apply at the start of substantial coding tasks that have independently executable work, not to trivial tasks where delegation overhead exceeds the work.
Prepare, verify, and publish a scoped GitHub pull request. Use when the user asks to commit local work, push a feature branch, or create or verify a GitHub PR. This workflow always uses main as the PR base branch.
Address actionable GitHub pull request review feedback. Use when the user wants to inspect unresolved review threads, requested changes, or inline review comments on a PR, implement selected fixes, reply on every addressed thread, and resolve those threads in GitHub.
| name | security-maintenance |
| description | Find and safely ship one evidence-backed security improvement using an approved repository contract. Use when reviewing, hardening, or fixing a security issue in an unfamiliar codebase. |
| argument-hint | [audit | fix-one | verify] |
Find and address at most one security issue or security improvement per run. Prioritize demonstrable risk and a narrow, well-tested change over broad hardening or checklist-driven work.
Read-only repository inspection and proportionate local verification are implicitly allowed. Do not add dependencies, change public contracts, alter authentication or authorization semantics, perform a broad refactor, publish external findings, or open a pull request unless the user has authorized that action.
Do not add or remove code comments unless the user explicitly asks. Express security intent through clear code, tests, and review communication instead.
Reference workflows do not grant additional authority; apply them only within these boundaries.
Before the first security scan in a repository, or whenever the existing contract is absent or stale, explicitly ask the user:
Before I start, may I set up or refresh this repository's security contract? I will inspect local instructions and configuration, identify the approved tooling and sensitive areas, and show the contract for your approval. Should this run be audit-only, fix one finding, or include a pull request?
Do not start the scan until the user approves discovery. After approval, gather the contract using only repository-local evidence:
Present the proposed contract to the user and wait for approval before changing repository files, recording durable memory, or creating a pull request. Use the template in repository-contract.md.
When the user approves it, preserve durable, non-sensitive repository-specific constraints and learnings in the host agent's approved memory system when one exists and the user has authorized persistence. Memory is routing context, not live evidence: revalidate commands, branches, policies, and security state in each run.
Start from evidence in the approved contract, a reported issue, a failing security check, or a changed sensitive path. Prefer investigating the highest impact reachable issue in this order:
Do not report a theoretical issue as exploitable without a supported path. Do not turn an unchanged baseline finding into a pull-request regression.
For an authorized fix, keep the change focused on the selected finding.
Stop and ask the user before adding a dependency, making a breaking change, changing an authentication or authorization contract, or expanding beyond one small finding. Never commit secrets, weaken controls to make tests pass, or publish exploit instructions or sensitive data.
Run the approved focused checks first, then the contract's required quality and security gates before publishing. Report blocked or unavailable checks exactly as they occurred; never claim an unrun check passed.
When a pull request is authorized:
If no small, evidence-backed improvement is available, report that conclusion and stop without creating a pull request.
