# Engineering Portfolio Auditor > Analyze engineering portfolio environments for closed-work mix, SLA aging, and release-readiness tasks. Use when a prompt asks Codex to inspect work items, mix targets, SLA policy, releases, milestones, blockers, or dependencies and return an exact JSON answer following a supplied template. - Skill: `prism-shadow/engineering-portfolio-auditor` (Agent Skill) - Install (CLI): `npx skillmds@latest add prism-shadow/engineering-portfolio-auditor` - Raw SKILL.md: https://api.skillmd.com/api/skills/prism-shadow/engineering-portfolio-auditor/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: prism-shadow (https://skillmd.com/u/prism-shadow) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/prism-shadow/engineering-portfolio-auditor --- # Engineering Portfolio Auditor ## Core Workflow 1. Read the user prompt and answer template first. Treat the template as the output contract: exact keys, ordering notes, rounding precision, and no prose unless requested. 2. Read the runtime access notes supplied with the task and query the provided environment for the authoritative records needed by the prompt. 3. Build a small working table before calculating: include `id`, `status`, `duplicate_of`, `team`, `product_area`, `work_type`, `labels`, `title`, `owner`, `created_at`, `due_at`, `closed_at`, `severity`, `priority`, `release_id`, and `milestone_id` when present. 4. Use authoritative current fields. Do not use stale mirror/export fields or legacy category fields to decide inclusion, completion, or category. 5. Return only JSON matching the template. Sort and round exactly as the prompt says. ## Primary Records - Treat records with `duplicate_of` set, or current `status` of `Duplicate`, as non-primary. Report them only in duplicate or exclusion fields when the template asks. - Treat current `status` of `Cancelled` as non-primary unless the prompt explicitly asks for cancelled records. Report them as exclusions or distractors when requested. - Do not exclude a record just because its ID format looks different from nearby records. If it matches the authoritative scope and is primary, count it. - For completed work, prefer current `status` over mirror fields. Common complete statuses are `Done`, `Closed`, `Verified`, and `Deployed`. - For closed-window tasks, use `closed_at` for quarter/window membership and for closed-date ordering. ## Portfolio Mix Use item counts, not story points. 1. Filter by the prompt scope: quarter, teams, product areas, and any scope-specific target row. 2. Include primary records closed in the requested quarter/window. 3. Exclude duplicates and cancelled records, but list them in the requested exclusion or distractor fields. 4. Classify each included item into exactly one category: - `Security`: current security/compliance work, especially `work_type` of `Security` or `Compliance`, or non-stale title/label signals such as cve, security, encryption audit, auth security, or security exception. - `Reliability`: reliability or incident work, especially `work_type` of `Reliability` or `Incident`, or non-stale title/label signals such as outage, incident, latency, flaky reliability, postmortem, guardrail, or runbook. - `TechDebt`: refactor, chore, dependency, migration, cleanup, or maintenance work when stronger security/reliability signals do not define the item. - `NewFeature`: feature or enhancement work when stronger security/reliability signals do not define the item. 5. Resolve conflicts using current `work_type` plus the non-stale title. Labels help classify generic bugs, chores, compliance, and enhancements, but an isolated stale label or legacy category should not override clear current work intent. 6. Convert target fractions to percentage points. Round actual percentages and gaps to one decimal place. Compute `gap = actual_pct - target_pct`. 7. List under-invested categories as negative gaps ordered from most negative to least negative. For a rebalance recommendation, choose the largest deficit as the target category and the largest surplus as the source signal unless the prompt gives a different rule. ## SLA Aging 1. Filter primary work by the requested teams and portfolio categories. 2. Include work that is open as of the as-of date, plus primary work closed within the recent closed lookback window when the prompt includes one. 3. Keep duplicate clusters separate from the primary population. Group by canonical `duplicate_of`, sort cluster primary IDs and duplicate IDs lexicographically. 4. Use `due_at` as the breach boundary unless the prompt explicitly directs policy-derived due dates. An open item is overdue when `due_at` is before the as-of date. A closed item breached when `closed_at` is after `due_at`. 5. Treat items due exactly on the as-of date as due today, not overdue, unless the prompt states otherwise. 6. For aging buckets, count included primary records by age in days from `created_at` to `closed_at` for recently closed work, otherwise from `created_at` to the as-of date. Use the bucket boundaries exactly as named. 7. Count missing owners only among included primary records. Use `UNASSIGNED` for hotspot grouping when the owner is missing. 8. Compute breach rate as overdue primary count divided by included primary count, rounded to the requested precision. 9. For escalation queues, sort overdue primary work by severity (`S1` before `S2` before `S3` before `S4`), then priority number ascending, then due date ascending, then ID. If the prompt frames the queue as active follow-up, put still-open overdue work before recently closed breaches. ## Release Readiness 1. Use release membership from authoritative release/work item fields, not mirror fields. 2. Build milestone denominators from primary release work items. Exclude duplicate and cancelled release rows from primary totals. 3. Count complete work with current complete statuses such as `Done`, `Closed`, `Verified`, and `Deployed`. 4. Sort milestone rows by milestone ID. Round completion percentages to one decimal place. 5. Gating work item IDs are primary release work items that are not complete, sorted with no duplicates, unless the prompt narrows the definition. 6. Count unresolved high-impact blockers by exact cause text. Treat unresolved as not resolved; treat high impact as `High` and `Critical` unless the prompt defines another severity set. 7. Build dependency chains from release work toward dependencies whose authoritative status is not complete. Prefer readiness-blocking and validation relations when distinguishing critical chains. Sort paths lexicographically by the full ordered path. 8. Use `NO_SHIP` when unresolved high-impact blockers or non-complete readiness gates remain. Use `SHIP_WITH_WATCH` for only low-impact or monitoring concerns. Use `SHIP` only when primary work is complete and no unresolved readiness blockers remain. 9. Readiness score is completed primary release work divided by the primary denominator, rounded to three decimals unless the template says otherwise. ## Output Discipline - Follow template-specific ordering even when it differs from these defaults. - Sort ID lists lexicographically unless the prompt or template asks for closed-date ordering. - Do not add fields, comments, markdown, or explanatory prose to the JSON answer.