Documentation

Community Guardrails

Browse ready-to-use guardrails from the community repository, or share your own enforced workspace rules with other developers.

New to guardrails?

See Guardrails for how rules intercept Claude Code tool calls, the Deny / Ask / Warn actions, match configuration, and versioning. This page covers discovering, importing, and sharing guardrails.

Community Repository

Don't want to start from scratch? Browse ready-to-use guardrails created by the community:

Community Repository

Visit github.com/superclawd-ai/superclawd/guardrails to discover guardrails for blocking force pushes, protecting secrets, locking down migrations, and more. Download JSON files and import them directly into your workspace.

Available Guardrails

The community repository includes guardrails such as:

  • block-force-push — Blocks destructive shell commands like force pushes and rm -rf
  • protect-secrets — Warns when a write looks like it contains an API key or secret
  • protect-migrations — Blocks direct edits to database migration files
  • protect-auth — Requires approval before editing auth or payments code

Using Community Guardrails

  1. Browse the guardrails directory
  2. Find a guardrail that matches your needs
  3. Click on the JSON file to view it
  4. Click "Raw" to get the raw JSON, or download the file
  5. In SuperClawd, go to GuardrailsImport
  6. Paste the JSON or drag and drop the file
  7. Click Import Guardrail
An imported guardrail arrives enabled, but as a draft

The imported guardrail lands enabled, and if its name is already taken it's auto-renamed (-2, -3, …). It's added as a draft, so it isn't enforced for the team until you publish and promote it to a stable release. See Versions & Releases.

Contributing Your Guardrails

Have guardrails that keep your team out of trouble? Share them with the community:

  1. Export your guardrail as JSON from the guardrail card menu
  2. Fork the community repository
  3. Add your guardrail JSON file to guardrails/examples/
  4. Update guardrails/README.md to list your guardrail
  5. Submit a pull request

Guardrail JSON Format

Community guardrails follow this structure — identity plus enforcement content only (no workspace ids, enabled state, or version pointers):

json
{
  "name": "block-force-push",
  "description": "Block force pushes and other destructive shell commands",
  "match": {
    "tools": ["Bash"],
    "commandPatterns": [
      "git\\s+push\\s+.*--force",
      "\\brm\\s+-rf\\b"
    ]
  },
  "action": "deny",
  "message": "Force pushes and recursive deletes are blocked by a workspace guardrail.",
  "presetId": null,
  "experimental": false
}

Contribution Guidelines

  • Use kebab-case for guardrail names (e.g., block-force-push)
  • Keep descriptions under 250 characters
  • Keep the message under 300 characters
  • Set action to one of deny, ask, or warn
  • Target at least one tool in match.tools; up to 20 patterns per matcher list
  • Test your guardrail before submitting

Instead of a JSON file, you can hand someone an unlisted, revocable share link straight from a guardrail's menu. The recipient can preview the rule and import their own copy into another workspace.

  • A stable release is required. You can only create a share link once the guardrail has been published and promoted to a stable release.
  • Pinned or live. A pinned link freezes a specific version; a live link always follows your current stable release.
  • Optional expiry & max-imports. Set an expiration date and an import limit; open and import counts are tracked (no importer identity).
  • Revocable. Delete the link at any time to cut off further imports.

Like a JSON import, importing from a share link creates an enabled draft (auto-renamed on name collision) that must be published and promoted before it enforces for your team.

See the Contributing Guide for detailed instructions.