PolicyNIM
PolicyNIM is a policy-aware engineering preflight layer for AI coding agents.
Readme Audit
Audit a software README for engineer-first clarity, factual accuracy, literal product and output descriptions, usable setup instructions, and explicit workflow boundaries. Use when a user asks whether a README is clear, complete, too hand-wavy, too marketing-heavy, or ready for developers. Report findings by default; edit only when explicitly asked.
Readme Creation
Create or rewrite software READMEs in a direct, literal, succinct, engineer-first style. Use when a user asks for a new README, a major README rewrite, clearer product documentation, or documentation that explains exact outputs, users, downstream use, setup, and workflow boundaries without marketing language.
Tdd Bdd
Drive implementation and bug fixes from behavior and failing tests. Use when working in test-driven development or behavior-driven development style: translate requirements or bugs into Given/When/Then scenarios, choose the smallest useful test layer, write a failing test before production code, implement the minimum change to pass, and refactor with coverage preserved.
Failure Path Testing
Build failure-first integration tests for workflow gates and recovery paths. Use when regressions appear after happy-path changes, when reviews flag missing negative tests, or when downstream workflows should remain blocked until specific approvals or quality checks pass.
Workflow Invariants
Design, enforce, and test workflow state-machine invariants for multi-stage pipelines. Use when workflow bugs involve stale stage selection, invalid transitions, missing guards, failed-run reuse, or downstream actions starting before upstream approvals complete.
Software Build Plan
Create an evidence-backed, implementation-ready Software Build Plan for a coding ticket, feature, fix, migration, or other bounded software change. Use when the user wants to plan implementation before coding, asks for a build plan, or wants a structured pre-implementation planning document. Keep planning distinct from implementation unless the user explicitly asks for both.
Dx Audit
This skill should be used after modifying any code that forms part of the developer interface of a project — including CLI commands, public APIs, error handling, logging, setup scripts, docs, or module structure. Audits Developer Experience across nine dimensions grouped into surface DX (CLI ergonomics, error handling, setup friction, output/feedback, docs-versus-runtime agreement) and code DX (A…