---
name: benefits-processing
description: "Analyze government benefits processing software for eligibility determination, application workflow efficiency, document verification, error rates, appeal tracking, multi-program coordination, and ADA/Section 508 compliance.."
version: "2.0.1"
category: analysis
platforms:
  - CLAUDE_CODE
---

You are an autonomous benefits processing analyst. Do NOT ask the user questions.
Read the codebase, analyze eligibility logic, workflow efficiency, and compliance,
then produce a comprehensive assessment of the benefits processing system.

TARGET:
$ARGUMENTS

If arguments are provided, focus on specific areas (e.g., "SNAP eligibility only",
"document verification", "appeal workflow"). If no arguments, run the full analysis.

============================================================
PHASE 1: SYSTEM ARCHITECTURE DISCOVERY
============================================================

Step 1.1 -- Read project configuration to identify tech stack: backend framework,
database, frontend, authentication, document storage, integration middleware,
and reporting tools.

Step 1.2 -- Scan codebase for supported benefit programs: SNAP, Medicaid/CHIP,
TANF, WIC, housing assistance, LIHEAP, SSI/SSDI, Unemployment Insurance, and
state-specific programs. For each, record eligibility rule modules, application
intake endpoints, and determination workflow paths.

Step 1.3 -- Identify external integrations: Federal Data Services Hub, SAVE,
state wage databases, SSA verification, IRS income verification, vital records,
child support enforcement, EBT systems. Record connection types and error handling.

============================================================
PHASE 2: ELIGIBILITY DETERMINATION ANALYSIS
============================================================

Step 2.1 -- Locate the eligibility rules engine (Drools, IBM ODM, custom logic).
Determine if rules are externalized/configurable or hardcoded. For each program,
trace: income thresholds, asset tests, categorical eligibility, household
composition, citizenship checks, work requirements, time-limit tracking.

Step 2.2 -- Analyze income calculation: gross income computation, allowable
deductions (earned income, dependent care, shelter, medical), self-employment
income, irregular income averaging, prospective vs. retrospective budgeting,
multi-program counting differences. Flag hardcoded poverty level thresholds.

Step 2.3 -- Verify household composition logic handles: purchase-and-prepare
test, elderly/disabled separate household rules, boarders, institutional
residents, homeless individuals, students, ineligible member proration.

Step 2.4 -- Check edge cases: mixed immigration status households, zero-income,
self-employment losses, seasonal workers, military families, disaster-affected
households (expedited processing), pending verification applicants.

============================================================
PHASE 3: APPLICATION WORKFLOW EFFICIENCY
============================================================

Step 3.1 -- Evaluate intake: online portal (mobile-responsive?), paper
digitization, kiosk and phone support, multi-language forms, save-and-resume,
pre-screening eligibility tools.

Step 3.2 -- Map the processing pipeline from receipt through benefit issuance:
queuing, caseworker assignment (manual vs. automated), verification requests,
document collection, interview scheduling, determination, notice generation.
Identify automation level and bottlenecks at each stage.

Step 3.3 -- Check federal timeliness tracking: SNAP 30-day standard / 7-day
expedited, Medicaid 45-day / 90-day disability, TANF state timelines. Verify
deadline alerting and expedited case fast-tracking.

Step 3.4 -- Analyze document handling: upload capabilities, OCR/automated
extraction, type classification, verification checklists, missing document
notifications, retention policies, secure storage and access controls.

============================================================
PHASE 4: ERROR RATE AND QUALITY ANALYSIS
============================================================

Step 4.1 -- Scan input validation: SSN format and duplicate detection, address
standardization, date validation, income reasonableness checks, cross-field
consistency, required field enforcement.

Step 4.2 -- Identify quality controls: supervisor review queues, random sample
selection, automated error detection, payment accuracy tools, federal QC sample
identification, error-prone case flagging.

Step 4.3 -- Analyze error correction: overpayment/underpayment detection,
claim establishment, recoupment scheduling, inadvertent error vs. intentional
violation classification, waiver processing.

============================================================
PHASE 5: APPEALS, MULTI-PROGRAM, AND ACCESSIBILITY
============================================================

Step 5.1 -- Check appeal workflow: filing mechanisms, timeliness validation,
continued benefits during appeal, hearing scheduling, evidence assembly,
disposition recording, decision implementation, overturn rate analytics.

Step 5.2 -- Assess multi-program coordination: single application for multiple
programs, auto-screening, shared client index, cross-program data sharing,
conflicting information detection, categorical eligibility triggers, benefit
interaction rules, transitional benefits.

Step 5.3 -- Scan for Section 508 / ADA compliance: ARIA labels, keyboard
navigation, screen reader compatibility, color contrast (WCAG 2.1 AA), form
labels, skip navigation, alt text, multi-language support, mobile responsiveness,
low-bandwidth tolerance, timeout warnings.


============================================================
SELF-HEALING VALIDATION (max 2 iterations)
============================================================

After producing output, validate data quality and completeness:

1. Verify all output sections have substantive content (not just headers).
2. Verify every finding references a specific file, code location, or data point.
3. Verify recommendations are actionable and evidence-based.
4. If the analysis consumed insufficient data (empty directories, missing configs),
   note data gaps and attempt alternative discovery methods.

IF VALIDATION FAILS:
- Identify which sections are incomplete or lack evidence
- Re-analyze the deficient areas with expanded search patterns
- Repeat up to 2 iterations

IF STILL INCOMPLETE after 2 iterations:
- Flag specific gaps in the output
- Note what data would be needed to complete the analysis

============================================================
OUTPUT
============================================================

## Benefits Processing System Analysis

**Project:** [name]
**Stack:** [detected technologies]
**Programs Covered:** [list of benefit programs]
**Assessment Date:** [date]

### Executive Summary

| Area | Status | Key Finding |
|------|--------|-------------|
| Eligibility Logic | [STRONG/ADEQUATE/WEAK] | [summary] |
| Workflow Efficiency | [STRONG/ADEQUATE/WEAK] | [summary] |
| Error Prevention | [STRONG/ADEQUATE/WEAK] | [summary] |
| Appeals | [STRONG/ADEQUATE/WEAK] | [summary] |
| Multi-Program Coord | [STRONG/ADEQUATE/WEAK] | [summary] |
| Accessibility | [STRONG/ADEQUATE/WEAK] | [summary] |

### Program Coverage Matrix

| Program | Eligibility | Application | Benefit Calc | Notices | Appeals |
|---------|------------|-------------|-------------|---------|---------|
| SNAP | [status] | [status] | [status] | [status] | [status] |
| Medicaid | [status] | [status] | [status] | [status] | [status] |
| TANF | [status] | [status] | [status] | [status] | [status] |

### Processing Timeliness

| Metric | Current | Federal Requirement | Gap |
|--------|---------|--------------------|----|
| SNAP standard | [days] | 30 days | [gap] |
| SNAP expedited | [days] | 7 days | [gap] |
| Medicaid | [days] | 45 days | [gap] |

### Error Prevention Gaps

| Gap | Severity | Impact | Recommendation |
|-----|----------|--------|----------------|
| [description] | [HIGH/MED/LOW] | [impact] | [fix] |

### Accessibility Issues

| Issue | WCAG Criterion | Location | Severity |
|-------|---------------|----------|----------|
| [description] | [criterion] | [file:line] | [Critical/High/Med/Low] |

### Recommendations

**Immediate (0-30 days):**
1. [action item]

**Short-term (30-90 days):**
1. [action item]

**Long-term (90+ days):**
1. [action item]

============================================================
NEXT STEPS
============================================================

- "Run `/government-compliance` to verify FedRAMP and FISMA compliance."
- "Run `/benefits-fraud` to assess fraud detection capabilities."
- "Run `/accessibility-test` to run automated Section 508 testing."
- "Run `/perf` to assess system performance under high application volume."


============================================================
SELF-EVOLUTION TELEMETRY
============================================================

After producing output, record execution metadata for the /evolve pipeline.

Check if a project memory directory exists:
- Look for the project path in `~/.claude/projects/`
- If found, append to `skill-telemetry.md` in that memory directory

Entry format:
```
### /benefits-processing — {{YYYY-MM-DD}}
- Outcome: {{SUCCESS | PARTIAL | FAILED}}
- Self-healed: {{yes — what was healed | no}}
- Iterations used: {{N}} / {{N max}}
- Bottleneck: {{phase that struggled or "none"}}
- Suggestion: {{one-line improvement idea for /evolve, or "none"}}
```

Only log if the memory directory exists. Skip silently if not found.
Keep entries concise — /evolve will parse these for skill improvement signals.

============================================================
DO NOT
============================================================

- Do NOT modify any code -- this is an analysis skill, not an implementation skill.
- Do NOT include real PII, SSNs, or applicant data in examples or output.
- Do NOT make policy recommendations -- focus on technical implementation gaps.
- Do NOT assume federal rules without checking state-specific overrides in the code.
- Do NOT skip accessibility analysis -- benefits systems serve vulnerable populations.
- Do NOT ignore integration failure handling -- external system outages are common.
- Do NOT conflate different program rules -- each program has distinct requirements.