# Fewshot Attempt 03 > Licensing Review Skill - Skill: `prism-shadow/fewshot-attempt-03-43` (Agent Skill) - Install (CLI): `npx skillmds@latest add prism-shadow/fewshot-attempt-03-43` - Raw SKILL.md: https://api.skillmd.com/api/skills/prism-shadow/fewshot-attempt-03-43/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: prism-shadow (https://skillmd.com/u/prism-shadow) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/prism-shadow/fewshot-attempt-03-43 --- # Licensing Review Skill Reusable instructions for processing structured licensing-review tasks in contractor, liquor, and alcohol-renewal domains. This skill covers environment setup, task-type recognition, data collection, domain analysis, and output formatting. --- ## 1. Environment Setup Every task references `` in the prompt. Resolve this by reading the file `environment_access.md` at the workspace root, which contains: - **`base_url`** — the actual HTTP origin to use in place of ``. - **`credentials`** — a mapping of HTTP method + path pattern to required headers. The most common credential is a header `X-Task-Token` required on `POST /api/sql` calls. - **`allowed_endpoints`** — the full list of endpoints available in this environment instance. Only endpoints listed here (and in the prompt) should be called. ### Making API calls - Use the `base_url` from `environment_access.md` to construct full URLs. - For `GET` endpoints, no special headers are typically required unless `environment_access.md` specifies one. - For `POST /api/sql`, include the required token header from `environment_access.md` credentials. The body should be a JSON object with a `"query"` key containing the SQL string. ### SQL access When `POST /api/sql` appears in the prompt or `environment_access.md`, you may run arbitrary `SELECT` queries against the environment's database. Use SQL to: - Join records across related tables when the REST endpoints return only flat lists. - Filter or aggregate data that would require multiple client-side passes over REST results. - Look up records by criteria not directly exposed as REST query parameters. Always inspect the REST endpoint responses first to understand the available table schemas and column names before writing SQL. --- ## 2. Task-Type Recognition Read the prompt to determine which of three task families the request belongs to. The family determines the endpoints to call, the analysis framework to apply, and the shape of the output. ### Type A — Contractor Batch Eligibility Review **Recognition signals:** - Mention of "State Contractors Licensing Board" or "Contractors Licensing Board". - A list of application IDs in the format `C-TRX-NNN`. - Phrases like "eligibility batch", "escalated for a structured application decision", or "specialty endorsement questions". - The prompt may specify a review date for financial-coverage checks. **Relevant endpoints:** - `GET /api/policies` - `GET /api/contractor/applications` - `GET /api/contractor/bonds` - `GET /api/contractor/insurance` - `GET /api/contractor/license-history` - `GET /api/contractor/violations` - `GET /api/contractor/correspondence` - `GET /api/contractor/inspections` - `POST /api/sql` ### Type B — Liquor License Staff Package **Recognition signals:** - Mention of "restricted liquor license", "liquor license transfer", "hotel-lounge", or "internal staff package". - A single target application ID in the format `L-TR*-*` plus a location ID in the format `LOC-TR*`. - Phrases like "issuance posture", "same-premises basis", "first-90-day monitoring plan", "escalation triggers". **Relevant endpoints:** - `GET /api/policies` - `GET /api/liquor/applications` - `GET /api/liquor/settlements` - `GET /api/liquor/privileges` - `GET /api/liquor/incidents` - `GET /api/liquor/site-evidence` - `POST /api/sql` (when listed in the prompt or `environment_access.md`) ### Type C — Alcohol Renewal Review Queue **Recognition signals:** - Mention of "Alcohol Renewal Unit", "pre-release renewal screen", or "renewal queue". - A range of license numbers in the format `AL-TR*-*`. - A "release boundary" or "boundary date" plus a "target queue size". - Phrases like "ranked manual-review queue", "violation matching", or "match confidence". **Relevant endpoints:** - `GET /api/alcohol/licensees` - `GET /api/alcohol/violations` - `GET /api/renewal/rules` - `POST /api/sql` (when listed in the prompt or `environment_access.md`) --- ## 3. Data Collection Strategy ### General pattern 1. Read `environment_access.md` to get `base_url` and any required token. 2. Read `input/payloads/answer_template.json` to understand the exact output schema — every field name, every allowed value, every ordering rule. 3. Call all relevant `GET` endpoints for the task type. Inspect the shape of each response to understand the available fields. 4. If the REST data is insufficient to resolve a decision (e.g., you need to join two datasets, or filter on a field not exposed as a query parameter), use `POST /api/sql` with a targeted `SELECT` query. 5. Cross-reference `GET /api/policies` against each application — policies describe current regulatory baselines that may create or remove deficiency flags compared to prior standards. ### Endpoint data shapes (general patterns) **`/api/policies`** — Returns policy records with fields for policy identifiers, effective dates, and policy text describing current regulatory requirements. Use these to determine whether a deficiency is created by a policy change (for the `policy_impacted` flag in Type A tasks). **Contractor endpoints** (Type A): - **`/api/contractor/applications`** — Each record has an `application_id`, applicant details, endorsement fields, and status flags. - **`/api/contractor/bonds`** — Each record links to an application or license and has bond amount, status (active/cancelled), and effective dates. - **`/api/contractor/insurance`** — Each record has coverage amounts, status (current/expired/pending), and effective dates. - **`/api/contractor/license-history`** — Each record has license status events including suspension start/end dates. - **`/api/contractor/violations`** — Each record has a violation ID, severity (minor/serious), and resolution status. - **`/api/contractor/correspondence`** — Each record has a correspondence ID, date, verification status, and linked application. - **`/api/contractor/inspections`** — Each record has inspection results, document gaps, and safety flags. **Liquor endpoints** (Type B): - **`/api/liquor/applications`** — The target application record with premise details, license class, and status. - **`/api/liquor/settlements`** — Past settlement agreements that may cover or exclude specific risks. - **`/api/liquor/privileges`** — Operating privilege grants and conditions attached to the license or location. - **`/api/liquor/incidents`** — Reported incidents at the location (assaults, noise complaints, minor sales, etc.). - **`/api/liquor/site-evidence`** — Site documentation: floor plans, photos, camera evidence, signage records, police memos. **Alcohol endpoints** (Type C): - **`/api/alcohol/licensees`** — Each record has a `license_no`, facility name, address, and status. - **`/api/alcohol/violations`** — Each record has a `violation_id`, `license_no` (or related identifier), violation date, and description. - **`/api/renewal/rules`** — Rule records describing renewal criteria, boundary-date handling, and risk-tier thresholds. --- ## 4. Domain Analysis Frameworks ### 4A. Contractor Batch Eligibility (Type A) For each application in the batch, evaluate across these dimensions and map findings to the deficiency codes and required actions defined in the answer template: **Bond evaluation:** - If no active bond exists → deficiency: `no_active_bond` / `bond_cancelled` → action: `file_active_bond` / `obtain_current_bond`. - If the bond amount is below the required minimum (check policies and application class) → deficiency: `bond_shortfall` → action: `increase_bond_amount` / `increase_bond`. **Insurance evaluation:** - If the insurance policy has expired based on the review date → deficiency: `insurance_expired` / `insurance_not_current` → action: `provide_current_insurance` / `renew_insurance`. - If coverage is below the required amount → deficiency: `insurance_shortfall` → action: `increase_insurance_amount` / `increase_insurance`. - If insurance status is pending and not yet bound → deficiency: `insurance_pending` → action: `verify_insurance_binding`. **Endorsement evaluation:** - If a required endorsement is completely absent → deficiency: `endorsement_missing` / `endorsement_not_verified` → action: `obtain_required_endorsement` / `verify_endorsement`. - If an endorsement application is in progress but not yet confirmed → deficiency: `endorsement_pending` → action: `verify_pending_endorsement`. **Experience evaluation:** - If documented experience falls below the required threshold for the license class → deficiency: `experience_shortfall` → action: `submit_experience_evidence` / `document_experience`. **License history evaluation:** - If the applicant has an active (unresolved) suspension → deficiency: `active_suspension` → action: `board_review_suspension` / `clear_suspension`. **Violation evaluation:** - If there are open/unresolved minor violations → deficiency: `open_minor_violation` → action: `resolve_minor_violation_review`. - If there are open/unresolved serious violations → deficiency: `open_serious_violation` / `unresolved_serious_complaint` → action: `resolve_serious_violation` / `resolve_complaint`. **Inspection evaluation:** - If an inspection found document gaps not yet cleared → deficiency: `inspection_doc_gap` → action: `clear_document_gap`. - If an inspection flagged safety issues requiring re-inspection → deficiency: `inspection_safety_recheck` → action: `complete_safety_recheck`. **Decision logic:** - **APPROVE**: No deficiencies found. All bonds, insurance, endorsements, experience, and background checks are satisfactory. - **HOLD**: One or more deficiencies exist that can be resolved by the applicant (missing documents, shortfalls, pending verifications). No active suspension or unresolved serious violation. - **DENY**: Active suspension, unresolved serious violations, or a combination of deficiencies that cannot be cured within the review period. **Risk tier assignment:** - **low**: No deficiencies (APPROVE cases). - **medium**: Holdable deficiencies that are administrative or financial in nature. - **high**: Active suspension, serious violations, safety recheck required, or a combination of 3+ deficiency categories. **Policy impact determination:** - Compare the application against the current policies from `GET /api/policies`. A `policy_impacted` flag is `true` when one or more deficiencies would not have existed under the prior policy baseline — i.e., the current policy *creates* the deficiency or material review flag. **Correspondence review:** - Identify correspondence records that are stale (beyond a reasonable response window) or unverified. Include their IDs in `stale_or_unverified_correspondence_ids` in the summary. **Summary construction:** - Count applications by determination (approve, hold, deny). - Collect application IDs for high-risk and policy-impacted cases. - Sort all ID lists in ascending lexical order. ### 4B. Liquor License Staff Package (Type B) For the single target application and location, build a structured staff review package: **Same-premises basis:** - Check the application and privilege records to determine whether the license is being reviewed on the same premises as a prior license. If the premises address matches a prior license record and the license class is transferable, `same_premises_basis_applies` is `true`. **Risk coverage assessment (`covered_risk_codes`):** - Review incidents, settlements, and site evidence to identify which risks are present and covered by current controls: - `AFTER_HOURS` — incidents or complaints about after-hours operation. - `ASSAULT` — reported assaults or violent incidents on premises. - `FOOD_SERVICE_GAP` — insufficient food service documentation or capacity. - `MINOR_SALE` / `SALE_TO_MINOR` — recorded or alleged sales to minors. - `NOISE` — noise complaints tied to the location. - `PUBLIC_SAFETY` — general public-safety incidents. - `SAME_PREMISES` — risks specifically tied to same-premises transfer rules. - `TAX_HOLD` — outstanding tax obligations blocking the license. - `PATIO_BOUNDARY` — risks related to patio or outdoor service boundaries. - `CAMERA_COVERAGE` — gaps in camera surveillance coverage. - `ID_CHECK` — risks from inadequate ID verification. **Verification gaps (`verification_gap_codes`):** - Identify what evidence or documentation is missing, conflicting, or stale: - Signage issues: `CONTROL_SIGNAGE_CONFLICTING`, `CONTROL_SIGNAGE_CURRENT_MISSING`, `control_signage_missing`. - Floor plan issues: `FLOOR_PLAN_CONFLICTING`, `FLOOR_PLAN_STALE`, `floor_plan_conflicting`. - Evidence gaps: `SITE_PHOTO_MISSING`, `site_photo_missing`, `camera_evidence_missing`, `food_service_evidence_missing`. - Notice gaps: `NEIGHBOR_NOTICE_MISSING`, `neighbor_notice_missing`. - Memo/legal conflicts: `POLICE_MEMO_CONFLICTING`, `police_memo_identity_note`. - Open issues: `OPEN_INCIDENT_FOLLOW_UP`, `TAX_CLEARANCE_MISSING`, `tax_hold_unresolved`, `late_night_monitoring_needed`. **Standard obligations vs. location-specific controls:** - **Standard obligations** are the ordinary license-class requirements — the obligations that apply to *any* license of this class regardless of location. Common codes: `CCTV`, `DELIVERY`, `FOOD_SERVICE`, `HOURS`, `ID_CHECK`, `NOISE`, `PATIO`, `SECURITY`. - **Location-specific controls** are additional controls imposed on *this specific location* due to its history, incidents, or conditions. Use the same code set but only include controls that are actively required at this location based on privilege conditions, settlement terms, or site-evidence documentation. **First-90-day monitoring plan:** - Build an ordered list of monitoring checkpoints, each with a `check_code` and `timing`: - `first_30_days` — checks that must happen immediately after issuance (signage review, ID check observation, initial walkthrough). - `days_31_60` — follow-ups that need a month of operational data (after-hours visits, police memo follow-up). - `days_61_90` — later-stage checks that verify sustained compliance (noise log review, patio boundary checks, tax clearance). - Each `check_code` addresses a specific verification gap or risk. The plan should be operationally sequenced — earlier checks verify setup, later checks verify sustained operation. **Escalation triggers:** - Define conditions that would cause field staff to escalate the license back for review: - Violation-based: `AFTER_HOURS_VIOLATION`, `REFERRED_MINOR_SALE_UNRESOLVED`, `minor_sale`, `after_hours_service`, `noise_or_patio_breach`, `patio_boundary_failure`, `id_check_failure`. - Control failures: `CONTROL_SIGNAGE_NOT_VERIFIED`, `SECURITY_CCTV_CONTROL_FAILURE`, `missing_camera_coverage`, `footage_not_produced`, `food_service_not_available`. - External events: `MAJOR_INCIDENT_REPORTED`, `BOARD_ORDER_CONFLICT`, `unreported_violent_incident`. - Administrative: `TAX_HOLD_REOPENED`, `open_tax_hold_uncleared`. **Recommended posture:** - `issue_restricted` — All major risks are covered, verification gaps are minor, and a monitoring plan is feasible. - `request_follow_up` — Significant verification gaps exist that need resolution before a final decision, but denial is premature. - `deny` — Unresolvable risks, missing same-premises basis when required, or active serious violations. ### 4C. Alcohol Renewal Review Queue (Type C) Build a ranked manual-review queue from a set of target licenses: **Violation matching:** - For each target license, find all violations that match. Matching should consider: - **Exact match**: The violation's `license_no` field equals the target license number exactly. - **Close address match**: The violation references the same facility/location through a related identifier (e.g., an old license number for the same premises, or an address-based match when the license number differs slightly). - **Uncertain match**: The violation may relate to the license but the connection is ambiguous (e.g., same address but different entity name). - Set `match_confidence` accordingly: `"exact"`, `"close_address"`, or `"uncertain"`. **Boundary date filtering:** - The prompt specifies a release boundary date. Violations with dates **on or after** the boundary date are *post-boundary* and must be **excluded** from the violation counts, `most_recent_violation_date`, and `matched_violation_ids` used for ranking. - Post-boundary violations should still be listed in `summary.post_boundary_violation_ids_excluded`. **Ranking logic:** - Rank licenses from highest review priority (rank 1) to lowest (rank 10) using these factors in descending priority: 1. **Number of pre-boundary matched violations** (more violations = higher priority). 2. **Recency** of the most recent pre-boundary violation (more recent = higher priority). 3. **Match confidence** (exact matches rank higher than close_address, which ranks higher than uncertain, all else equal). 4. **Violation severity** implied by the renewal rules or violation descriptions. - The queue must contain exactly the target size (e.g., 10 entries), with ranks 1 through N and no gaps. **Risk tier assignment:** - **high**: Multiple recent violations, serious violation types, or board-review triggers. - **medium**: Some violations but older or less severe. - **low**: Few or no violations, all minor and old. **Next-step label assignment:** - `board_review` — Licensees with the most severe or numerous violations requiring elevated review. - `manual_fine_check` — Licensees where fines may need manual verification. - `manual_ALERT_check` — Licensees flagged in an ALERT system or similar watchlist. - `additional_record_check` — Licensees needing further record pulls before a decision. **Summary construction:** - `queue_size`: The number of entries in the queue (should match the target). - `boundary_date`: The release boundary date from the prompt, in YYYY-MM-DD format. - `post_boundary_violation_ids_excluded`: All violation IDs with dates on or after the boundary date, sorted ascending. - `close_or_uncertain_match_license_numbers`: License numbers with non-exact match confidence, sorted ascending. - `board_review_license_numbers`: License numbers assigned `board_review` as their next step, sorted ascending. --- ## 5. Output Formatting Rules ### General rules for all task types 1. **Return only JSON** — no markdown fences, no prose, no narrative memo, no citations outside the JSON structure. 2. **Follow the answer template exactly** — use only the keys, value types, and allowed enum values defined in `input/payloads/answer_template.json`. 3. **Ordering** — respect all ordering rules stated in the template: - Application/queue entries ordered by their identifier (ascending lexical for IDs, ascending integer for ranks). - Deficiency codes, required actions, and other code arrays sorted in the order specified by the template (usually alphabetical/lexical ascending). - Violation IDs sorted by date ascending, then by ID ascending. 4. **Empty values** — use `[]` (empty array) when no codes, actions, or IDs apply. Never use `null` or omit a required key. 5. **Date format** — all dates must use `YYYY-MM-DD` format. 6. **No extra keys** — do not add keys not shown in the template, even if they would be informative. ### Type-specific formatting notes **Type A (Contractor Batch):** - `application_decisions` must contain exactly the number of target applications listed in the prompt, ordered by `application_id` ascending. - `summary.approve_count + summary.hold_count + summary.deny_count` must equal the total number of applications. - `policy_impacted` is a boolean per application. - `stale_or_unverified_correspondence_ids` collects correspondence IDs that are stale or unverified across the entire batch. **Type B (Liquor Staff Package):** - All code arrays (`covered_risk_codes`, `verification_gap_codes`, `standard_obligation_codes`, `location_specific_control_codes`, `escalation_trigger_codes`) must use only the allowed values from the template — the vocabulary varies between task instances. - `first_90_day_plan` is an array of objects, each with `check_code` and `timing`. The allowed check codes and timing values are specific to each template. - `same_premises_basis_applies` is a boolean. - `recommended_posture` is one of the three allowed enum values. **Type C (Alcohol Renewal Queue):** - `queue` must have exactly the target queue size with ranks 1 through N and no gaps. - `matched_violation_ids` within each queue entry must be sorted by violation date ascending, then violation_id ascending. - `summary.post_boundary_violation_ids_excluded` lists violation IDs that were filtered out by the boundary date. - `summary.close_or_uncertain_match_license_numbers` and `summary.board_review_license_numbers` must be sorted ascending. --- ## 6. Step-by-Step Execution Protocol When a licensing-review task is encountered, follow this protocol: 1. **Read environment**: Open `environment_access.md`, note `base_url` and any credentials. 2. **Read template**: Open `input/payloads/answer_template.json`, memorize the required output shape and all allowed enum values. 3. **Identify task type**: Match the prompt against the three families in Section 2. 4. **Fetch data**: Call all relevant `GET` endpoints. Inspect response shapes to learn field names. 5. **Apply analysis framework**: Use the appropriate framework from Section 4 to evaluate each application/license. 6. **Cross-reference policies**: Always check `GET /api/policies` against each application to determine policy impact. 7. **Fill gaps with SQL**: If REST data is insufficient to resolve a specific decision (e.g., joining across datasets, filtering by criteria not exposed as query parameters), use `POST /api/sql`. 8. **Construct output**: Build the JSON strictly according to the template, following all ordering and formatting rules from Section 5. 9. **Validate**: Verify counts are consistent, all required keys are present, all enum values are from the allowed set, and ordering rules are satisfied. 10. **Return only the JSON object** — no surrounding text.