adversarial build

Shipping production code requires more than just a quick prompt. Complex features and bug fixes often fail because tests aren't rigorous, edge cases are ignored, or security standards are bypassed. This skill enforces a multi-stage adversarial pipeline that treats your AI subagents like a professional engineering team. It not only writes code, it coordinates a spec writer, a test author, and multiple reviewers through a series of deterministic gates.

What it does

• Multi-agent orchestration coordinates subagents for spec writing, testing, coding, and review.
• Test-driven enforcement ensures new tests are written and fail correctly before any implementation code is touched.
• Automated quality gates runs your existing test suites, linters, and type checkers as ground truth after every pass.
• Adversarial reviews uses independent critic agents to find flaws in logic, security, and coding standards.
• Conflict arbitration resolves disputes between authors and critics using a final arbiter agent when limits are reached.

How it works

1. Initialize the run by specifying a work item and a rigor level (basic, reviewer, tests, adversarial, or full).
2. Authorize the spec by answering blocking questions or opting to bypass them and let the agent decide.
3. Monitor the automated loop as the agent switches between testing, coding, and review stages.
4. Review the final branch once all gates are green or step in if the pipeline hits a decision point.

Frameworks & tools

This skill works with any language that has CLI-based testing and linting tools. It specifically looks for pipeline.toml, pyproject.toml, or CLAUDE.md to configure commands like pytest, mypy, ruff, and semgrep.

Why this beats prompting it yourself

Manual prompting often leads to the agent "marking its own homework" and skipping tests to make code pass. This skill enforces a strict separation of concerns where the coder cannot modify the tests and critics have no access to the author's internal reasoning.

Use cases

• Implementing critical business logic where silent failures are not an option.
• Refactoring legacy code while ensuring zero regressions through strict test-first gates.
• Scanning for security vulnerabilities in new features before they hit human review.

Known limitations

Requires a clean working tree to start. The orchestrator cannot push, merge, or open PRs. Logic is restricted to the tools and gate commands defined in the repo configuration.