# Fewshot Attempt 02 > Licensing Board Review Decision Skill - Skill: `prism-shadow/fewshot-attempt-02-13` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add prism-shadow/fewshot-attempt-02-13` - Raw SKILL.md: https://api.skillmd.com/api/skills/prism-shadow/fewshot-attempt-02-13/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-02-13 --- # Licensing Board Review Decision Skill ## When to use Use this skill for any task that asks you to act as a licensing examiner / analyst for the State licensing environment and return a structured JSON decision package. The skill applies whenever the task points you at the shared licensing environment (the `` / `task-env` service) with a defined set of `GET /api/...` endpoints and (optionally) `POST /api/sql`, and asks for a JSON answer conforming to an `answer_template.json`. The skill is reusable across the review families the environment supports: - **Contractor batch eligibility review** (a set of `C-…` applications: bonds, insurance, license history, violations, correspondence, inspections, endorsements, experience). - **Restricted liquor-license staff package** (a single `L-…` application at a `LOC-…` location: settlements, privileges, incidents, site evidence, control obligations). - **Alcohol renewal manual-review queue** (a ranked queue over `AL-…` licenses with a release boundary date: licensees, violations, renewal rules). The shape of the answer differs per family and is fully described by that task's own `answer_template.json`. This skill never hard-codes per-task values — it tells you how to find, verify, and decide. ## Inputs you will be given For each task, the staged working tree contains: - a `prompt.txt` that names the role, the target identifiers (application/license/location ids or an id range), any review date or release boundary, and the endpoints to use; - an `input/payloads/answer_template.json` that is the **authoritative schema** — its required keys, allowed enum values, ordering rules, length constraints, and "additional output" restrictions define exactly what JSON you may return; - an `environment_access.md` describing how to reach the running environment over the network (base URL, any required request header, the allow-list of endpoints). Read the prompt, the template, and `environment_access.md` before touching the environment. ## Procedure 1. **Parse the prompt for the contract.** Extract: review family, target identifiers / id range, the review/boundary date (if any), the target queue/batch size (if any), and which endpoints the prompt calls out. The prompt's endpoint list is authoritative for that task; do not call endpoints it does not list. 2. **Read the answer template as the schema.** Before producing any output, internalize the template's: required top-level keys, per-field allowed enum values, list ordering rules (ascending lexical, by date, by rank, "operational sequence", etc.), required list lengths, and the explicit "do not include prose / markdown / extra keys" clause. When two families look similar (e.g. two liquor staff-package tasks) **do not assume the codes match** — the enum vocabularies differ between tasks; always re-read that task's template. 3. **Reach the environment the way `environment_access.md` says.** Use the documented base URL and the allow-listed endpoints exactly. If `environment_access.md` requires a header for an endpoint (e.g. `X-Task-Token` for `POST /api/sql`), send it. Do not invent paths, do not hit endpoints outside the allow-list, and do not attempt paths the prompt did not list for that task. Treat the base URL placeholder literally — substitute it from `environment_access.md`. 4. **Pull the policies first.** `GET /api/policies` (every family uses it) gives the current policy baseline. Several families carry a `policy_impacted` flag whose semantics — *"True when a current 2025 policy standard creates a deficiency/flag that would not have applied under the prior baseline"* — must be read from the policies endpoint, not guessed. Always fetch policies before deciding policy-impacted fields. 5. **Fetch the family's record endpoints.** Pull every endpoint the prompt lists for that family (one request per endpoint). For batch tasks, fetch the full collection once and index by id rather than re-fetching per item. 6. **Correlate records to targets.** For each target id in the prompt, gather its application/core record plus all related records (bonds, insurance, history, violations, correspondence, inspections / settlements, privileges, incidents, site-evidence / licensees, violations). Match on the id fields the data uses. For the alcohol queue, also handle **non-exact address matches** (old/alternate location records) — note them as `close_address`/`uncertain` confidence rather than forcing an exact match. 7. **Apply the family decision rubric.** See `references/decision_rubric.md` for the reusable per-family decision logic (deficiency detection, risk tiering, posture/next-step determination, policy-impact reasoning, boundary-date handling, and the optional `POST /api/sql` cross-check). The rubric is the procedure, not the answers — it maps *evidence in the records* to *codes in that task's template*, so the same rubric produces different output per task. 8. **Build the JSON exactly to the template.** Emit only the keys the template lists, each field drawn from the template's allowed enum values, every list in the template's required order, with the required list lengths (batch size / queue size), and `[]` where the template says to use empty arrays. For summary objects, derive counts and id lists *from the application-level decisions you just made* so they stay internally consistent (e.g. `approve_count` + `hold_count` + `deny_count` = batch size; `high_risk_application_ids` = every application you tiered `high`, sorted). 9. **Return only the JSON.** No prose, no markdown fences, no citations, no keys outside the template — the templates consistently forbid exactly these. Validate against your checklist before returning. ## Critical pitfalls to avoid - **Do not copy codes or ids from any train example into a live answer.** Each task's allowed values live in its own `answer_template.json`. A code that is valid in one contractor batch may not exist in another; the liquor vocabularies differ between the two liquor tasks. Always read the live template. - **Do not skip `GET /api/policies`.** `policy_impacted` is baseline-relative and unguessable without it. - **Honor list order and length precisely.** "ascending lexical order", "ascending by rank with no gaps", "sort by date ascending then id ascending", "operational sequence", and a fixed `required_length` / `length` are all scored constraints — re-sort every list before returning. - **Keep summary fields consistent with the per-item decisions.** They are derived, not independent. - **Use `POST /api/sql` only as an optional verification/cross-check** and only if `environment_access.md` documents the required token header — never as a way to bypass the public endpoints or to mutate data. ## Files in this skill - `SKILL.md` — this entry point. - `references/decision_rubric.md` — reusable per-family decision logic and environment protocol.