benefits-processing

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. USE THIS SKILL WHEN: user mentions benefits eligibility, SNAP, Medicaid, TANF, WIC, government assistance programs, social services software, eligibility rules engine, caseworker workflow, benefits application processing, or Section 508 accessibility. Trigger phrases: "analyze benefits system", "eligibility determination review", "benefits processing audit", "government program compliance", "caseworker workflow analysis", "appeal tracking review", "benefits application efficiency".
version	2.0.0
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.