القائمة
Use for security-sensitive changes or reviews. Focus on injection, auth, session handling, auditability, sensitive logging, and the repo’s required adversarial test posture.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | dr-security-review |
| version | 2026-03-26.1 |
| description | Use for security-sensitive changes or reviews. Focus on injection, auth, session handling, auditability, sensitive logging, and the repo’s required adversarial test posture. |
Load dr-repo-reference first for shared security defaults and component verification commands.
From AGENTS.md, treat these as first-class:
When the change touches handlers, commands, DB access, sessions, tokens, or admin flows, check:
For non-trivial security review, record:
Observed: exact risky patterns, boundaries, or verification outputInferred: security consequence supported by those factsProposed: mitigation or required testConfidence: 0.0-1.0 with one-line reasonFalsifier: what result would show the suspected issue is not realReflection: weakest assumption and the next security checkUse adversarial tests when relevant. The repo guidance includes:
Security fixes without a regression test are incomplete.
Use the relevant component verification entries from dr-repo-reference.
For large or mixed-surface changes, use security_reviewer as a dedicated read-only pass.
If the security issue is inside portal request handling, pair it with portal_explorer.
Use the model and reasoning defaults from docs/CODEX_AGENT_POLICY.md so security review remains on the strongest review path.
Use when asked to work in a continuous loop until done or truly blocked. Orchestrates pickup, planning, TDD execution, implementation waves when needed, debugging side-chains, verification, and resume behavior.
Use before planning when a feature or change request is underspecified. Resolve high-impact ambiguity around scope, consumers, security, failure handling, and acceptance criteria before writing the implementation plan.
Use for both preparing work for review and responding to review feedback. Keep review evidence local, concrete, and scoped to the real contract. Verify technically before agreeing or changing code.
Use before implementation. Merge design discovery and plan writing into one DR-specific flow: identify the consumer, inspect the repo, debate boundaries with partner and combatant, and produce an execution-ready plan that hands off cleanly into DR-native tasks, TDD, and implementation waves.
Use for the last mile: rerun verification, inspect diffs, commit or push if requested, and perform local docker-compose checks when needed. This is the DR local-tools replacement for MCP-style finish/deploy carryovers.
Use after planning and before implementation when you need a concrete, dependency-ordered task list. Turn the DR feature spec and plan into independently testable task slices with exact file paths and verification commands.