<< All versions

Skill v1.0.1

currentAutomated scan100/100
synaptiai/agent-capability-standard/critique

+4 new

──Details
PublishedOctober 30, 2026 at 08:06 AM
Content Hashsha256:a133f26af1b448a7...
Git SHA4ca65f8c08d8
Bump Typepatch
Compare with v1.0.0
──Files
Files (1 file, 12.8 KB)
SKILL.md12.8 KBactive
SKILL.md · 378 lines · 12.8 KB

name: critique description: Find failure modes, edge cases, ambiguities, and exploit paths in plans, code, or designs. Use when reviewing proposals, auditing security, stress-testing logic, or validating assumptions. argument-hint: "[target] [criteria] [severity_threshold]" disable-model-invocation: false user-invocable: true allowed-tools: Read, Grep context: fork agent: explore metadata: version: "1.0.1"


Intent

Systematically analyze a target (plan, code, design, document) to identify failure modes, edge cases, ambiguities, and potential exploits. Produce actionable findings with severity ratings and mitigation recommendations.

Success criteria:

  • All major failure modes identified
  • Edge cases documented with reproduction scenarios
  • Ambiguities flagged with clarification requests
  • Security/exploit risks rated appropriately
  • Each issue has an actionable suggestion

Compatible schemas:

  • schemas/output_schema.yaml

Inputs

ParameterRequiredTypeDescription
targetYesanyPlan, code, design, or document to critique
criteriaNoarrayEvaluation criteria
severity_thresholdNostringMinimum severity to report: low, medium, high, critical
contextNoanyAdditional context about the target

Inputs not listed here are outside the capability's contract: a workflow step that binds them gets W604 (STANDARD v1.1 §5.5).

Procedure

1) Understand the target: Analyze what is being critiqued

  • Read and comprehend the target fully
  • Identify the purpose and intended behavior
  • Note stated assumptions and constraints
  • Understand success criteria

2) Identify failure modes: Find ways the target could fail

  • What happens under unexpected inputs?
  • What if dependencies are unavailable?
  • What if timing assumptions are wrong?
  • What if scale exceeds expectations?

3) Enumerate edge cases: Find boundary conditions

  • Empty inputs, null values, missing fields
  • Maximum/minimum values
  • Concurrent access scenarios
  • Unicode, special characters, injection patterns

4) Detect ambiguities: Find unclear specifications

  • Terms with multiple interpretations
  • Missing definitions
  • Implicit assumptions
  • Contradictory requirements

5) Assess exploit paths: Identify security vulnerabilities

  • Input validation gaps
  • Authentication/authorization bypasses
  • Data exposure risks
  • Privilege escalation opportunities

6) Rate severity: Classify each issue (recorded per issue and in the severity map)

  • CRITICAL: System compromise or data loss
  • HIGH: Significant functionality or security impact
  • MEDIUM: Moderate impact, workarounds exist
  • LOW: Minor issues, cosmetic or edge-case
  • Report in issues only those at or above severity_threshold

7) Recommend mitigations: Provide actionable fixes as suggestions

  • Specific changes to address each finding
  • Priority ordering for fixes
  • Estimated effort for each mitigation

Output Contract

Return a structured object:

yaml
issues:
- id: string # Unique finding identifier
type: failure_mode | edge_case | ambiguity | exploit | gap
description: string # Clear description of the issue
severity: low | medium | high | critical
location: string # Where in target (file:line, section, etc.)
evidence: string # Supporting evidence
reproduction: string | null # How to reproduce
recommendation: string # Suggested fix
severity: # Issue severities, keyed by issue id
<issue_id>: low | medium | high | critical
risk_summary:
overall_risk: low | medium | high | critical
mitigations_possible: boolean
urgent_issues: array[string] # Issue IDs requiring immediate attention
risk_distribution:
critical: integer
high: integer
medium: integer
low: integer
suggestions:
- issue_ref: string # Issue ID
suggestion: string # Detailed fix suggestion
effort: low | medium | high
priority: integer # 1 = highest priority
patterns_identified:
- pattern: string # Recurring issue pattern
affected_issues: array[string]
systemic_fix: string # How to address pattern
confidence: number # 0.0-1.0
evidence_anchors: ["file:line", "section:name"]
assumptions: []

Field Definitions

FieldTypeDescription
issuesarrayWeaknesses found at or above severity_threshold (empty when none; workflows gate on ${<step>.issues} == [])
severityobjectIssue severities, keyed by issue id
risk_summaryobjectOverall risk assessment
suggestionsarray<object>Prioritized improvement suggestions, each referencing an issue
patterns_identifiedarrayRecurring issues with systemic fixes
confidencenumber0.0-1.0 based on analysis completeness
evidence_anchorsarrayReferences to target locations
assumptionsarrayAssumptions made during analysis

Examples

Example 1: Plan Critique

Input:

yaml
target:
id: "deploy-plan-001"
goal: "Deploy new authentication service"
steps:
- id: "step-1"
action: "Stop old auth service"
- id: "step-2"
action: "Deploy new auth service"
- id: "step-3"
action: "Run smoke tests"
criteria: ["availability", "rollback", "security"]

Output:

yaml
issues:
- id: "CRT-001"
type: failure_mode
description: "Zero-downtime deployment not guaranteed. Stopping old service before new is verified creates outage window."
severity: high
location: "step-1 to step-2 transition"
evidence: "step-1 stops service, step-2 starts new - gap exists"
reproduction: "Execute plan; observe 503 errors between steps"
recommendation: "Use blue-green deployment: start new service, verify health, then route traffic"
- id: "CRT-002"
type: gap
description: "No rollback step defined. If step-3 smoke tests fail, no recovery procedure."
severity: critical
location: "plan.steps - missing rollback"
evidence: "No rollback_action in any step"
reproduction: "Smoke tests fail; manual intervention required"
recommendation: "Add rollback step: 'If step-3 fails, restart old auth service'"
- id: "CRT-003"
type: ambiguity
description: "'Smoke tests' not defined. Unclear what is being tested or pass criteria."
severity: medium
location: "step-3"
evidence: "No verification_criteria specified"
reproduction: null
recommendation: "Define specific test cases: auth flow, token validation, error handling"
- id: "CRT-004"
type: exploit
description: "No security verification step. New service could have misconfigured permissions."
severity: high
location: "plan - missing security check"
evidence: "No step validates auth service security posture"
reproduction: "Deploy service with open admin endpoint; not caught by smoke tests"
recommendation: "Add security scan step before traffic routing"
severity:
CRT-001: high
CRT-002: critical
CRT-003: medium
CRT-004: high
risk_summary:
overall_risk: critical
mitigations_possible: true
urgent_issues: ["CRT-002", "CRT-001"]
risk_distribution:
critical: 1
high: 2
medium: 1
low: 0
suggestions:
- issue_ref: "CRT-002"
suggestion: "Add rollback step with automatic trigger on smoke test failure"
effort: low
priority: 1
- issue_ref: "CRT-001"
suggestion: "Rewrite as blue-green deployment with health check before cutover"
effort: medium
priority: 2
- issue_ref: "CRT-004"
suggestion: "Add security scan after deployment, before enabling traffic"
effort: medium
priority: 3
- issue_ref: "CRT-003"
suggestion: "Define smoke test checklist with pass/fail criteria"
effort: low
priority: 4
patterns_identified:
- pattern: "Missing safety gates"
affected_issues: ["CRT-001", "CRT-002", "CRT-004"]
systemic_fix: "Adopt CAVR pattern: checkpoint before each mutation, verify after each step"
confidence: 0.9
evidence_anchors:
- "plan:step-1:stops-service"
- "plan:steps:no-rollback"
assumptions:
- "Auth service is critical for all user operations"
- "Downtime of auth service blocks all authenticated requests"

Evidence pattern: Each issue references specific plan location; suggestions are actionable.


Example 2: Code Critique (Security Focus)

Input:

yaml
target:
file: "src/api/auth.py"
code: |
def login(username, password):
user = db.query(f"SELECT * FROM users WHERE username='{username}'")
if user and user.password == password:
return create_token(user.id)
return None
criteria: ["security"]

Review adversarially: probe the code as an attacker would.

Output:

yaml
issues:
- id: "CRT-001"
type: exploit
description: "SQL injection vulnerability. Username is interpolated directly into query string."
severity: critical
location: "auth.py:2"
evidence: "f-string query with unescaped username input"
reproduction: "username=\"admin'--\", password=\"anything\" bypasses auth"
recommendation: "Use parameterized query: db.query('SELECT * FROM users WHERE username=?', (username,))"
- id: "CRT-002"
type: exploit
description: "Plain-text password comparison. Passwords stored in cleartext or compared unsafely."
severity: critical
location: "auth.py:3"
evidence: "Direct comparison: user.password == password"
reproduction: "Database compromise exposes all passwords"
recommendation: "Use bcrypt or argon2: bcrypt.checkpw(password, user.password_hash)"
- id: "CRT-003"
type: failure_mode
description: "No rate limiting. Brute force attacks possible."
severity: high
location: "auth.py:login function"
evidence: "No attempt tracking or delay mechanism"
reproduction: "Script 1000 login attempts per second"
recommendation: "Add rate limiting: max 5 attempts per minute per IP/username"
- id: "CRT-004"
type: edge_case
description: "Empty username/password not handled. Could cause unexpected behavior."
severity: low
location: "auth.py:1"
evidence: "No input validation at function entry"
reproduction: "login('', '') - behavior undefined"
recommendation: "Add input validation: if not username or not password: return None"
severity:
CRT-001: critical
CRT-002: critical
CRT-003: high
CRT-004: low
risk_summary:
overall_risk: critical
mitigations_possible: true
urgent_issues: ["CRT-001", "CRT-002"]
risk_distribution:
critical: 2
high: 1
medium: 0
low: 1
suggestions:
- issue_ref: "CRT-001"
suggestion: "IMMEDIATE: Replace f-string query with parameterized query"
effort: low
priority: 1
- issue_ref: "CRT-002"
suggestion: "IMMEDIATE: Migrate to bcrypt password hashing"
effort: medium
priority: 2
- issue_ref: "CRT-003"
suggestion: "Add rate limiting middleware before login endpoint"
effort: medium
priority: 3
- issue_ref: "CRT-004"
suggestion: "Add input validation decorator"
effort: low
priority: 4
patterns_identified:
- pattern: "OWASP Top 10 violations"
affected_issues: ["CRT-001", "CRT-002"]
systemic_fix: "Security code review and SAST integration in CI"
confidence: 0.95
evidence_anchors:
- "auth.py:2:sql-injection"
- "auth.py:3:plaintext-password"
assumptions:
- "This code handles real user authentication"
- "Database contains actual user credentials"

Verification

  • [ ] All criteria were examined
  • [ ] Severity ratings are justified
  • [ ] Each issue has a suggestion
  • [ ] Critical issues are highlighted
  • [ ] Patterns are identified for systemic fixes

Verification tools: Read (for code/doc analysis), Grep (for pattern search)

Safety Constraints

  • mutation: false
  • requires_checkpoint: false
  • requires_approval: false
  • risk: low

Capability-specific rules:

  • Never test exploits on production systems
  • Report all critical findings immediately
  • Do not disclose security findings to unauthorized parties
  • If finding reveals active exploit, escalate immediately
  • Be thorough but avoid false positives

Composition Patterns

Commonly follows:

  • plan - Critique plans before execution
  • inspect - Understand target before critique
  • retrieve - Gather context for critique

Commonly precedes:

  • plan - Revise plan based on critique issues and suggestions
  • mitigate - Address identified risks
  • verify - Validate fixes for findings
  • audit - Record critique and responses

Anti-patterns:

  • Never skip critique for high-risk plans
  • Never proceed with critical issues unaddressed
  • Avoid superficial critique of security-sensitive targets

Workflow references:

  • See reference/composition_patterns.md#debug-code-change for critique in debugging
  • See reference/composition_patterns.md#capability-gap-analysis for planning context
← v1.0.0All versions