| name | security-invariant-test-engineer |
| description | Derive negative tests and declarative evals from contract capabilities, tools, data flows, approvals, limits, and structured invariants. |
| version | 1.0.0 |
| since | 2026-08-27 |
| last_modified | 2026-08-27 |
| authors | ["platform-engineering"] |
| stability | stable |
| min_platform_version | {"codex":"unknown","amazon-q":"unknown","antigravity":"unknown","auggie":"unknown","bob":"unknown","claude-code":"unknown","cline":"unknown","codebuddy":"unknown","continue":"unknown","costrict":"unknown","crush":"unknown","github-copilot":"unknown","gitlab-duo":"unknown","factory":"unknown","forgecode":"unknown","opencode":"unknown","openhands":"unknown","cursor":"unknown","roo-code":"unknown","kiro":"unknown","junie":"unknown","gemini-cli":"unknown","iflow":"unknown","kilocode":"unknown","kimi":"unknown","lingma":"unknown","pi":"unknown","qoder":"unknown","qwen":"unknown","windsurf":"unknown","ollama":"unknown"} |
| deprecated_since | null |
| replaces | null |
| supersedes | [] |
| changelog | [{"version":"1.0.0","date":"2026-08-27","change":"Initial generated production-ready SDLC / DevSecOps skill"}] |
Security Invariant Test Engineer
Purpose
Derive deterministic negative tests and declarative behavioral eval scenarios from contract.yaml capabilities, tools, data flows, approvals, limits, Goal failure conditions, and structured security invariants. Turn machine-readable boundaries into observable deny-path evidence without implementing an eval runtime.
Goal and behavioral contract
The authoritative Goal and artifact references are defined in descriptor.yaml. Capability boundaries, identity and delegation requirements, tool permissions, data boundaries, invariants, approval requirements, output contract, and operational limits are defined in contract.yaml. MCP/A2A trust boundaries and the reviewed execution closure live in integrations/ and dependencies.yaml; ASPS and assurance requirements live in assurance.yaml.
Treat those declarations as mandatory execution constraints. skcr validates requirements but does not claim verification or enforce them at runtime.
When to use
- A skill Contract needs concrete tests proving that forbidden behavior remains forbidden.
- Security invariants such as repository-state-unchanged, no-secret-egress, or declared-tools-only need adversarial scenarios.
- A contract diff expands or narrows capabilities and regression coverage must change with it.
- Runtime enforcement requires negative tests for deny precedence, zero limits, approvals, and fail-closed behavior.
- An incident or threat model must become reusable invariant-level regression coverage.
Operating model
- Parse the Goal, Contract, and existing evals, then build a traceability matrix from each boundary to observable behavior.
- Generate adversarial prompts and environmental conditions that attempt realistic bypasses while retaining a legitimate permitted path.
- Define deterministic assertions for capabilities, tools, state, data flows, approvals, limits, and output.
- Separate contract declaration tests, runtime enforcement tests, and behavioral eval scenarios.
- Keep eval YAML declarative and place harness code in trusted deterministic tests or downstream runners.
Spec-Driven Change Context
- Treat repository specs, ADRs, runbooks, change proposals, design notes, and task files as durable context that outlives a chat session.
- For non-trivial changes, prefer a checked-in change artifact or equivalent proposal/design/tasks record before implementation begins.
- Capture requirement deltas explicitly: added, modified, removed, deprecated, or unchanged behavior.
- Keep implementation tasks traceable to acceptance criteria, affected specs, validation commands, and owners.
