lbk-open Guardrails
This skill is a reference library, not a workflow. Other skills read it at the point where they need to write, change, or review code; it has no standalone "run" behavior of its own.
What's Here
| File | Covers | Read When |
|---|---|---|
core.md |
Security baseline, code-review dimensions and severity levels, unit-testing principles, and anti-mistake rules for AI coding agents | Always — every coding or review task |
java.md |
Java exception handling and concurrency anti-patterns, JVM testing pitfalls | Project is Java/Kotlin/JVM |
go.md |
Go error handling and testing pitfalls | Project is Go |
cpp.md |
C++ memory safety, concurrency, error handling, and testing pitfalls | Project is C++ |
web.md |
Frontend/Node security and quality pitfalls | Project is TypeScript/JavaScript/web |
android.md |
Android-specific safety and quality pitfalls | Project is Android/Kotlin |
ios.md |
iOS-specific safety and quality pitfalls | Project is iOS/Swift |
flutter.md |
Flutter/Dart-specific safety and quality pitfalls | Project is Flutter |
How to Use This
- Detect the project's primary language/stack (build files, file extensions, existing code) or ask if it's ambiguous.
- Read
core.mdin full — it applies regardless of stack. - Read the one or two language files that match the project's stack. Skip the rest.
- Apply the checklists while writing code, and re-check against them during review, before claiming a task complete.
Treat this as read-only reference material: load it into context at the moment it's needed, apply it, and don't copy its contents into the user's repository. It carries no user-specific configuration and produces no output files of its own.
Failure Handling
If the project's stack isn't covered by any language file here, fall back to core.md alone and note the gap to the user rather than guessing at stack-specific rules that don't exist yet.