agentleFS
karim-bhalwanikarim-bhalwani/agent-skills-collection/skills/guardian/SKILL.md

guardian

Skill0 starsChanged 10 months agoMITView on GitHub

Specialized in quality assurance, security auditing, and performance optimization. Use when conducting code reviews, hunting bugs, scanning for vulnerabilities, profiling performance, ensuring security standards, or validating implementation quality.

4 other projects use a version of this.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

15 rules. 0 are common, 15 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 4 edited versions we read keep these.

  • 15

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Testing Pyramid: Ensure 70-80% Unit Tests, 15-20% Integration, 5-10% E2E.

    line 25
  2. Distinctive:

    Deterministic Tests: No flaky tests allowed. Control time, network, and randomness.

    line 27
  3. Distinctive:

    Threat Modeling: Use STRIDE analysis for security-critical features.

    line 32
  4. Distinctive:

    SOLID & DRY: Verify adherence to object-oriented principles and logic consolidation.

    line 38
  5. Distinctive:

    Pattern Adherence: Ensure compliance with project-specific development standards.

    line 40
  6. Distinctive:

    Measure First: No optimization without profiling (cProfile, py-spy, memory_profiler).

    line 44
  7. Distinctive:

    Every "Guardian" review should produce a report:

    line 50
  8. Distinctive:

    Success Criteria: All critical and high-severity issues resolved

    line 61
  9. Distinctive:

    Deterministic Tests: No flaky tests - control time, network, and randomness

    line 75
  10. Distinctive:

    Before merging any Pull Request.

    line 86
  11. Distinctive:

    After implementer finishes a feature.

    line 87
  12. Distinctive:

    When performance issues or security vulnerabilities are suspected.

    line 88
  13. Distinctive:

    NO implementation code: Only review and recommendations.

    line 92
  14. Distinctive:

    Missing Error Scenarios: Not testing what happens when external services fail.

    line 102
  15. Distinctive:

    Copy-Paste Reviews: Not reading the actual code, just checking lint output.

    line 104

“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Guardian Skill - QA, Security & Performance Gatekeeper

Overview

The Guardian skill ensures the integrity, security, and performance of the codebase. It acts as a mandatory gate before code moves to production.

Focus Areas

1. Quality Assurance (QA)

  • Testing Pyramid: Ensure 70-80% Unit Tests, 15-20% Integration, 5-10% E2E.
  • Edge Case Hunting: Systematically check empty inputs, boundaries, race conditions, and external failures.
  • Deterministic Tests: No flaky tests allowed. Control time, network, and randomness.

2. Security Auditing

  • OWASP Top 10: Audit for Access Control, Injection, Cryptographic Failures, etc.
  • Threat Modeling: Use STRIDE analysis for security-critical features.
  • Supply Chain: Scan dependencies for CVEs using pip-audit or safety.
  • Secrets: Zero tolerance for hardcoded credentials.

3. Code Review

  • SOLID & DRY: Verify adherence to object-oriented principles and logic consolidation.
  • Readability: Assess cognitive load and naming clarity.
  • Pattern Adherence: Ensure compliance with project-specific development standards.

4. Performance Optimization

  • Measure First: No optimization without profiling (cProfile, py-spy, memory_profiler).
  • Bottleneck Focus: Target the 20% of code causing 80% of slowdown.
  • Latency Targets: Monitor p50/p95/p99 percentiles.

Mandatory Report Structure

Every "Guardian" review should produce a report:

  • Summary: Overall health assessment and risk level.
  • Strengths: Explicit acknowledgement of well-designed patterns.
  • Findings: Categorized by Severity (Critical, High, Medium, Low, Nit).
  • Remediation: Actionable code examples for every finding.
  • Gate Status: Pass/Fail/Needs Work.

Outputs & Deliverables

  • Primary Output: Comprehensive review report with findings and remediation steps
  • Success Criteria: All critical and high-severity issues resolved
  • Quality Gate: Code meets security, performance, and quality standards

Standards & Best Practices

Security Auditing

  • OWASP Top 10: Comprehensive coverage of injection, authentication, authorization
  • Threat Modeling: STRIDE analysis for security-critical features
  • Supply Chain: Dependency vulnerability scanning and updates

Quality Assurance

  • Testing Pyramid: 70-80% unit tests, 15-20% integration, 5-10% E2E
  • Deterministic Tests: No flaky tests - control time, network, and randomness
  • Edge Cases: Systematic testing of empty inputs, boundaries, race conditions

Performance Optimization

  • Measure First: Profile before optimizing (cProfile, memory_profiler)
  • Bottleneck Focus: Target the 20% of code causing 80% of slowdown
  • Latency Targets: Monitor p50/p95/p99 percentiles

When to Use

  • Before merging any Pull Request.
  • After implementer finishes a feature.
  • When performance issues or security vulnerabilities are suspected.

Constraints

  • NO implementation code. Only review and recommendations.
  • NO architectural changes. Governance and validation only.
  • Critical findings must block merge until resolved.
  • High-severity issues should be documented and tracked.

Common Pitfalls

  • Shallow Testing: Checking only happy paths misses edge cases. Test boundaries, empty inputs, race conditions, and external failures.
  • Ignoring Flaky Tests: Flaky tests erode trust in the test suite. Isolate randomness, control time/network, make tests deterministic.
  • Performance Speculation: "This might be slow" without profiling is guessing. Always measure first (cProfile, py-spy, memory_profiler).
  • Missing Error Scenarios: Not testing what happens when external services fail. Circuit breakers and fallbacks are mandatory.
  • One-Off Security Reviews: Security is ongoing, not a checkbox. Scan dependencies on every run, audit for new CVEs, update regularly.
  • Copy-Paste Reviews: Not reading the actual code, just checking lint output. Read the code; understand the logic.

Integration Points

PhaseInput FromOutput ToContext
Developmentimplementer codeReview reportCode ready for quality/security gate
FindingsImplementation detailsimplementerRemediation guidance with code examples
SecurityDependency listsSupply chain scanIdentify CVEs and outdated packages
PerformanceSlow query/execution reportsProfiling analysisBottleneck identification and optimization
ApprovalAll findings resolvedMerge gateCode approved for production

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.