/does - Behavior Verification

Verify if a component, system, agent, or tool performs a specific behavior or action.

System Prompt

⚠️ EXECUTION DIRECTIVE: When the user invokes this command, you MUST:

1. IMMEDIATELY execute - no questions, no explanations first
2. Parse the query to identify subject and behavior
3. Verify behavior through documentation, code, or testing
4. Report definitively with YES/NO and evidence

DO NOT:

• Assume behavior without verification
• Conflate "can do" (capability) with "does do" (actual behavior)

The user invoking the command IS the confirmation.

---

Usage

/does <subject> <behavior>

Query Patterns

Query Pattern	Purpose	Verification Method
/does X support Y	Feature support	Documentation, code
/does X handle Y	Error/edge handling	Code analysis, tests
/does X call Y	Dependency check	Call graph, imports
/does X validate Y	Validation check	Code inspection
/does X log Y	Logging check	Code grep, log output
/does agent X do Y	Agent behavior	Agent definition

Execution Steps

Step 1: Parse Behavior Query

# Identify subject and behavior
SUBJECT=$(echo "$QUERY" | awk '{print $1}')
BEHAVIOR=$(echo "$QUERY" | cut -d' ' -f2-)

Step 2: Verify Behavior

# For code behavior
grep -r "$BEHAVIOR" "$SUBJECT_PATH"

# For agent behavior
cat "agents/$SUBJECT.md" | grep -i "$BEHAVIOR"

# For API behavior
grep -A 20 "def $METHOD" "$FILE" | grep "$BEHAVIOR"

# For call graph
python3 scripts/call-graph.py --function "$FUNCTION" --calls

Step 3: Provide Evidence

# Show code snippets, documentation, or test results
# that prove the behavior exists (or doesn't)

Response Format

┌─────────────────────────────────────────────────────────────────┐
│  /does: <query>                                                 │
├─────────────────────────────────────────────────────────────────┤
│  BEHAVIOR VERIFICATION                                          │
│  ─────────────────────                                          │
│                                                                 │
│  ✅ YES / ❌ NO                                                  │
│                                                                 │
│  Subject: <subject>                                             │
│  Behavior: <behavior being checked>                             │
│                                                                 │
│  EVIDENCE                                                       │
│  ────────                                                       │
│  <code snippet, documentation, or test showing behavior>        │
│                                                                 │
│  [If YES] Implementation:                                       │
│    File: <file path>                                            │
│    Line: <line number>                                          │
│    Code: <relevant snippet>                                     │
│                                                                 │
│  [If NO] Why Not:                                               │
│    <explanation of why behavior doesn't exist>                  │
│                                                                 │
│  [If NO] Alternative:                                           │
│    <how to achieve the behavior>                                │
│                                                                 │
├─────────────────────────────────────────────────────────────────┤
│  Verified by: <code inspection | docs | test>                   │
└─────────────────────────────────────────────────────────────────┘

Examples

Feature Support Check

/does the API support pagination

Output:

✅ YES

Subject: API
Behavior: pagination support

EVIDENCE:
File: api/views.py:45
Code:
  class ListAPIView(generics.ListAPIView):
      pagination_class = StandardPagination

Implementation:
  • Page size: 20 (default)
  • Parameters: ?page=N, ?page_size=N
  • Response includes: count, next, previous, results

Error Handling Check

/does the auth module handle expired tokens

Output:

✅ YES

Subject: auth module
Behavior: expired token handling

EVIDENCE:
File: auth/middleware.py:78
Code:
  except jwt.ExpiredSignatureError:
      return JsonResponse({'error': 'Token expired'}, status=401)

Implementation:
  • Catches ExpiredSignatureError
  • Returns 401 with clear message
  • Logs expiration event

Agent Behavior Check

/does agent devops-engineer handle terraform

Output:

✅ YES

Subject: devops-engineer agent
Behavior: terraform handling

EVIDENCE:
From agents/devops-engineer.md:
  skills:
    - terraform-patterns
    - infrastructure-as-code

  capabilities:
    - Execute terraform plan/apply
    - Manage state files
    - Handle modules

Logging Check

/does the payment module log transaction IDs

Output:

❌ NO

Subject: payment module
Behavior: transaction ID logging

EVIDENCE:
Searched: grep -r "transaction" payments/
Found: Transaction processing but no logging of IDs

Why Not:
  Logging was not implemented for transaction IDs.
  Only success/failure is logged.

Alternative:
  Add to payments/processor.py:
  logger.info(f"Transaction {transaction_id} processed")

Call Graph Check

/does process_order call send_notification

Output:

✅ YES

Subject: process_order
Behavior: calls send_notification

EVIDENCE:
Call chain:
  process_order()
    └── complete_order()
        └── send_notification()

File: orders/service.py:123
Code:
  def complete_order(order):
      # ... processing ...
      send_notification(order.user, 'order_complete')

Related Commands

Command	Purpose
/can <action>	Check capability (could do)
/is <state>	Check current state
/will <prediction>	Predict future behavior
/how <task>	Get implementation steps
/what <component>	Discover components

Success Output

✅ COMMAND COMPLETE: /does
Query: <query>
Behavior: YES/NO
Subject: <subject>
Verified by: <method>

Completion Checklist

Before marking complete:

• Subject identified
• Behavior clearly defined
• Evidence gathered
• Result clearly stated
• Alternative provided (if NO)

Failure Indicators

This command has FAILED if:

• ❌ No query provided
• ❌ Behavior assumed without verification
• ❌ No evidence provided
• ❌ Conflated with capability (/can)

When NOT to Use

Do NOT use when:

• Need capability check (use /can - "could it")
• Need state verification (use /is - "is it")
• Need prediction (use /will - "will it")

Differentiating /can vs /does

Command	Question	Example
/can	Is it capable?	/can claude read images → Yes, has capability
/does	Is it doing it?	/does claude read images by default → No, only when requested

Principles

This command embodies:

• #9 Based on Facts - Evidence-based verification
• #6 Clear, Understandable - Definitive YES/NO
• #3 Complete Execution - Always shows evidence

Full Standard: CODITECT-STANDARD-AUTOMATION.md

---

Version: 1.0.0 Created: 2026-02-04 Author: CODITECT Team Framework: 5W+H Question Framework