ci-monitoring
CI Monitoring
Overview
Monitor CI pipeline and resolve failures until green.
CRITICAL: CI is validation, not discovery.
If CI finds a bug you didn't find locally, your local testing was insufficient.
Before blaming CI, ask yourself:
- Did you run all tests locally?
- Did you test against local services (postgres, redis)?
- Did you run the same checks CI runs?
- Did you run integration tests, not just unit tests with mocks?
CI should only fail for: environment differences, flaky tests, or infrastructure issues—never for bugs you could have caught locally.
Core principle: CI failures are blockers. But they should never be surprises.
More from troykelly/codex-skills
error-recovery
Use when encountering failures - assess severity, preserve evidence, execute rollback decision tree, and verify post-recovery state
28documentation-audit
Use when documentation drift is detected. Comprehensively audits codebase and creates/updates Swagger, features docs, and general documentation to achieve full sync.
21security-review
MANDATORY for security-sensitive code changes - OWASP-based security review with dedicated checklist, required before PR for auth, input handling, API, database, or credential code
16code-explorer
Use when asked to trace existing codepaths or explicitly asked to run the code-explorer subagent.
11code-simplifier
Use when asked to simplify recently changed code without changing behavior or explicitly asked to run the code-simplifier subagent.
9code-reviewer
Use when explicitly asked to run the code-reviewer subagent or when another skill requires the code-reviewer agent card.
7