codex-review
Codex Review — Iterative Consensus Skill
Orchestrate an iterative debate between the local agent and Codex CLI until both reach consensus on code review findings, architecture decisions, or implementation plans.
Guiding principle: KISS (Keep It Simple, Stupid). Both sides should favor the simplest solution that works. Complexity must be justified.
Codex Independence
Codex is an independent reviewer, not a compliance checker. Do NOT instruct Codex to validate against AGENTS.md / CLAUDE.md conventions or treat them as rules to follow. Codex should form its own engineering opinions based on the code/plan it reads.
- The local agent follows the project's AGENTS.md / CLAUDE.md conventions (it already does naturally)
- Codex reviews with its own engineering judgment — it may agree with, be unaware of, or even challenge AGENTS.md / CLAUDE.md conventions
- When they disagree: the local agent may cite AGENTS.md / CLAUDE.md as one argument, but Codex is free to push back if it has a better reasoning. The debate resolves on merits, not authority.
- If truly unresolved: flag it for the user to decide
Give Codex only a brief project description (what it does, tech stack) for context — not a rulebook.
Codex CLI Configuration
More from mryll/skills
vertical-slice-architecture
Enforce Vertical Slice Architecture (VSA) when building applications in any language (Go, .NET/C#, Java, Kotlin, TypeScript, Python, etc.) and any type (web API, mobile backend, CLI, event-driven). Organize code by feature/use-case instead of technical layers. Each feature is a self-contained vertical slice with a single entry point that receives the router/framework handle and its dependencies. Use when the user says "vertical slice architecture", "VSA", "organizar por feature", "feature-based architecture", "slice architecture", or when building a new app or feature and the project already follows VSA conventions. Also use when reviewing or refactoring code to align with VSA principles.
166agentmd
Generate minimal, research-backed CLAUDE.md / AGENTS.md / COPILOT.md context files for coding agent CLIs. Based on "Evaluating AGENTS.md" (ETH Zurich, Feb 2026) which found that auto-generated context files DECREASE performance by ~3% and increase costs by 20-23%, while minimal human-written files improve performance by ~4%. Use when the user says "generate CLAUDE.md", "create AGENTS.md", "generate context file", "agentmd", "create recommended CLAUDE.md", "generate agent instructions", "init context file", or any request to create/improve a coding agent context file for a repository. Replaces the default /init command which generates bloated, counterproductive context files.
40low-complexity
Enforce low Cognitive Complexity (SonarSource) and low Cyclomatic Complexity in ALL code written or modified, in any programming language, framework, or platform. This skill MUST activate automatically whenever code is being written, generated, modified, or refactored — no explicit trigger needed. Triggers include writing any function, method, class, module, script, handler, endpoint, test, or code block. Also triggers on "low complexity", "cognitive complexity", "cyclomatic complexity", "reduce complexity", "simplify code", "too complex", "refactor for readability", "clean code", "implement", "fix bug", "add feature", "generate test", "optimize", "rewrite", "scaffold".
25test-namer
Guide for writing expressive, behavior-focused tests following Vladimir Khorikov's testing principles. Apply when writing, reviewing, or renaming any test (unit, integration, e2e) in any programming language. Triggers: writing tests, creating test files, adding test cases, reviewing test names, 'test naming', 'rename tests', 'Khorikov', or any test creation task. Covers: naming conventions (plain English over rigid policies), what to test (behavior not implementation), testing styles (output > state > communication), and pragmatic test investment.
18dual-testing
Go dual testing strategy: integration tests (testcontainers) verify full-chain wiring for happy paths, unit tests (testify/mock) verify error handling logic. Apply when designing test strategy for a Go project, creating a new handler or feature that needs tests, or deciding what type of test to write for a scenario. Triggers: 'dual testing', 'error path coverage', 'testcontainers vs mocks', 'what type of test', 'where should this test go', 'integration vs unit', creating Go handlers/features/workers that need tests. Does NOT trigger on: writing individual test assertions, renaming tests, test naming conventions (use test-namer for those).
4