Updated
Agent rules
The lyrashield rules command writes and manages these rule files for you. Each file is wrapped in a checksummed LyraShield block so the CLI can detect edits and the LyraShield scanner treats a valid block as protective. Run the command in your project root:
lyrashield rules add <agent>Replace <agent> with an agent id from the integrations index. To remove a file, run lyrashield rules remove <agent>. To validate checksums, run lyrashield rules check.
Prerequisite: The LyraShield MCP server must be configured before agent rules can invoke it. See the integrations overview for setup instructions.
Claude Code — CLAUDE.md
<!-- lyrashield:begin v=1.0.0 sha=208df24552e2 -->
# LyraShield security checks
LyraShield is available as an MCP server and a Claude Code plugin/skill. Use it to verify security posture before creating a pull request and after applying a security fix.
You can surface these checks as:
- This `CLAUDE.md` section.
- A skill in `.claude/skills/lyrashield/SKILL.md` (if your project uses skills).
- A PreToolUse hook that runs `lyrashield check-diff --staged` before the `git commit` or `pr create` tool is used.
- A slash command `/lyra-diff` that runs `lyrashield check-diff --staged`.
## Pre-PR check
1. Run lyrashield_check_diff on the staged changes to identify security issues introduced by this work item.
2. Review any findings before committing.
3. If findings are reported, address them or document why each is acceptable.
## Post-fix verification
1. After applying a fix for a security finding, run lyrashield_verify_fix with the finding ID.
2. Poll the returned retest scan to a terminal state, then include its outcome and scan reference in the PR description.
3. Call the result independently verified only when a separate independent-verification receipt exists.
## Scope limits
- Only run security checks against targets that are owned by this workspace and explicitly listed as authorized targets in the LyraShield settings.
- Do not run checks on files or URLs you do not have permission to scan.
- Do not run scans against third-party URLs or repositories without explicit authorization.
## Honesty clause
A clean check result does not guarantee the absence of all vulnerabilities. A passing check is not a guarantee of zero vulnerabilities.
<!-- lyrashield:end -->
AGENTS.md — AGENTS.md
<!-- lyrashield:begin v=1.0.0 sha=842595c04ec1 -->
# LyraShield security workflow
The LyraShield MCP server is available as a registered tool.
## Pre-PR check
1. Run lyrashield_check_diff on the staged changes to identify security issues introduced by this work item.
2. Review any findings before committing.
3. If findings are reported, address them or document why each is acceptable.
## Post-fix verification
1. After applying a fix for a security finding, run lyrashield_verify_fix with the finding ID.
2. Poll the returned retest scan to a terminal state, then include its outcome and scan reference in the PR description.
3. Call the result independently verified only when a separate independent-verification receipt exists.
## Scope limits
- Only run security checks against targets that are owned by this workspace and explicitly listed as authorized targets in the LyraShield settings.
- Do not run checks on files or URLs you do not have permission to scan.
- Do not run scans against third-party URLs or repositories without explicit authorization.
## Honesty clause
A clean check result does not guarantee the absence of all vulnerabilities. A passing check is not a guarantee of zero vulnerabilities.
<!-- lyrashield:end -->
Cursor — .cursor/rules/lyrashield.mdc
<!-- lyrashield:begin v=1.0.0 sha=abb53c6e81b6 -->
---
description: LyraShield AI security policy for Cursor
globs: "*.{md,ts,tsx,js,jsx,py,go,rs,yml,yaml,json,jsonc,toml,prisma,sql}"
alwaysApply: false
---
# LyraShield security checks
## Pre-PR check
1. Run lyrashield_check_diff on the staged changes to identify security issues introduced by this work item.
2. Review any findings before committing.
3. If findings are reported, address them or document why each is acceptable.
## Post-fix verification
1. After applying a fix for a security finding, run lyrashield_verify_fix with the finding ID.
2. Poll the returned retest scan to a terminal state, then include its outcome and scan reference in the PR description.
3. Call the result independently verified only when a separate independent-verification receipt exists.
## Scope limits
- Only run security checks against targets that are owned by this workspace and explicitly listed as authorized targets in the LyraShield settings.
- Do not run checks on files or URLs you do not have permission to scan.
- Do not run scans against third-party URLs or repositories without explicit authorization.
## Honesty clause
A clean check result does not guarantee the absence of all vulnerabilities. A passing check is not a guarantee of zero vulnerabilities.
<!-- lyrashield:end -->
Cursor — .cursorrules
<!-- lyrashield:begin v=1.0.0 sha=6938b4349fc8 -->
# LyraShield security checks
## Pre-PR check
1. Run lyrashield_check_diff on the staged changes to identify security issues introduced by this work item.
2. Review any findings before committing.
3. If findings are reported, address them or document why each is acceptable.
## Post-fix verification
1. After applying a fix for a security finding, run lyrashield_verify_fix with the finding ID.
2. Poll the returned retest scan to a terminal state, then include its outcome and scan reference in the PR description.
3. Call the result independently verified only when a separate independent-verification receipt exists.
## Scope limits
- Only run security checks against targets that are owned by this workspace and explicitly listed as authorized targets in the LyraShield settings.
- Do not run checks on files or URLs you do not have permission to scan.
- Do not run scans against third-party URLs or repositories without explicit authorization.
## Honesty clause
A clean check result does not guarantee the absence of all vulnerabilities. A passing check is not a guarantee of zero vulnerabilities.
<!-- lyrashield:end -->
GitHub Copilot — .github/copilot-instructions.md
<!-- lyrashield:begin v=1.0.0 sha=42daddc4d592 -->
# LyraShield security instructions for GitHub Copilot
## Pre-PR check
1. Run lyrashield_check_diff on the staged changes to identify security issues introduced by this work item.
2. Review any findings before committing.
3. If findings are reported, address them or document why each is acceptable.
## Post-fix verification
1. After applying a fix for a security finding, run lyrashield_verify_fix with the finding ID.
2. Poll the returned retest scan to a terminal state, then include its outcome and scan reference in the PR description.
3. Call the result independently verified only when a separate independent-verification receipt exists.
## Scope limits
- Only run security checks against targets that are owned by this workspace and explicitly listed as authorized targets in the LyraShield settings.
- Do not run checks on files or URLs you do not have permission to scan.
- Do not run scans against third-party URLs or repositories without explicit authorization.
## Honesty clause
A clean check result does not guarantee the absence of all vulnerabilities. A passing check is not a guarantee of zero vulnerabilities.
<!-- lyrashield:end -->
Windsurf — .windsurf/rules/lyrashield.md
<!-- lyrashield:begin v=1.0.0 sha=3f7116ccc2e9 -->
# LyraShield security workflow for Windsurf
## Workflow
1. Before creating a PR: run `lyrashield check-diff --staged` on the changed files.
2. Review any findings and wait for resolution or explicit acceptance before proceeding.
3. After applying a security fix: run `lyrashield verify <finding-id>`, then poll the returned retest scan to a terminal state.
4. Include the retest outcome and scan reference in the PR description. Call it independently verified only when a separate independent-verification receipt exists.
5. Only scan authorized targets listed in the LyraShield workspace.
## Pre-PR check
1. Run lyrashield_check_diff on the staged changes to identify security issues introduced by this work item.
2. Review any findings before committing.
3. If findings are reported, address them or document why each is acceptable.
## Post-fix verification
1. After applying a fix for a security finding, run lyrashield_verify_fix with the finding ID.
2. Poll the returned retest scan to a terminal state, then include its outcome and scan reference in the PR description.
3. Call the result independently verified only when a separate independent-verification receipt exists.
## Scope limits
- Only run security checks against targets that are owned by this workspace and explicitly listed as authorized targets in the LyraShield settings.
- Do not run checks on files or URLs you do not have permission to scan.
- Do not run scans against third-party URLs or repositories without explicit authorization.
## Honesty clause
A clean check result does not guarantee the absence of all vulnerabilities. A passing check is not a guarantee of zero vulnerabilities.
<!-- lyrashield:end -->
Cline — .clinerules
<!-- lyrashield:begin v=1.0.0 sha=6938b4349fc8 -->
# LyraShield security checks
## Pre-PR check
1. Run lyrashield_check_diff on the staged changes to identify security issues introduced by this work item.
2. Review any findings before committing.
3. If findings are reported, address them or document why each is acceptable.
## Post-fix verification
1. After applying a fix for a security finding, run lyrashield_verify_fix with the finding ID.
2. Poll the returned retest scan to a terminal state, then include its outcome and scan reference in the PR description.
3. Call the result independently verified only when a separate independent-verification receipt exists.
## Scope limits
- Only run security checks against targets that are owned by this workspace and explicitly listed as authorized targets in the LyraShield settings.
- Do not run checks on files or URLs you do not have permission to scan.
- Do not run scans against third-party URLs or repositories without explicit authorization.
## Honesty clause
A clean check result does not guarantee the absence of all vulnerabilities. A passing check is not a guarantee of zero vulnerabilities.
<!-- lyrashield:end -->
OpenClaw — skills/lyrashield/skill.md
<!-- lyrashield:begin v=1.0.0 sha=b9393ce7bd5c -->
---
name: lyra-shield-security
description: Run LyraShield security checks before and after changes
---
# LyraShield security workflow
## Pre-PR check
1. Run lyrashield_check_diff on the staged changes to identify security issues introduced by this work item.
2. Review any findings before committing.
3. If findings are reported, address them or document why each is acceptable.
## Post-fix verification
1. After applying a fix for a security finding, run lyrashield_verify_fix with the finding ID.
2. Poll the returned retest scan to a terminal state, then include its outcome and scan reference in the PR description.
3. Call the result independently verified only when a separate independent-verification receipt exists.
## Scope limits
- Only run security checks against targets that are owned by this workspace and explicitly listed as authorized targets in the LyraShield settings.
- Do not run checks on files or URLs you do not have permission to scan.
- Do not run scans against third-party URLs or repositories without explicit authorization.
## Honesty clause
A clean check result does not guarantee the absence of all vulnerabilities. A passing check is not a guarantee of zero vulnerabilities.
<!-- lyrashield:end -->
Tips for effective agent rules
- Keep the rules focused on when to run checks — the agent will use the MCP tool descriptions to understand how.
- Add an explicit scope constraint to prevent the agent from scanning targets it does not own.
- Include a note that a passing check is not a guarantee — this keeps expectations accurate and prevents over-reliance on automated results.
- For teams, commit the rules file to the repository so all developers share the same behavior.