Ss guardrails
Agent Skills that take a requirement — or a production alert — to a reviewed pull request: multi-agent TDD coding, a parallel review panel with severity-graded verdicts, living OpenSpec-compatible specs, and per-language guardrails.
npx -y skills add lbk-open/super-spec --skill ss-guardrailsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
A library of safety, code-quality, and anti-mistake checklists that other ss-* skills consult on demand while writing or reviewing code. Not invoked directly by users — skills like ss-coding-workflow, ss-code-review, and ss-coding read core.md plus the relevant language file before generating or grading code.
SKILL.md
2.3 KB, as published. Nobody here has run it
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.