# Critical Component Selection

> Use this skill for freeze-grade hardware component decisions that need evidence reconciliation before a choice can be locked into schematic, BOM, pin assignment, layout, sourcing, or validation work. Trigger on critical component selection, BOM freeze review, EOL/PCN or supplier substitute decisions, candidate part-number decisions, shortlist review, vendor feedback against a requirement baseline, selection evidence map, procurement brief, supplier/FAE inquiry, leadership brief, 关键物料选型, BOM 冻结前评审, 选型证据地图, 选型报告, 沟通报告, or 候选料号决策. Common critical conditions include lifecycle/EOL/PCN/lead-time risk, toolchain verification such as EMIF/fitter/SI/PI/thermal, pinout/power/SI/thermal architecture impact, and vendor evidence that must be reconciled against requirements. Do NOT use for casual comparisons, learning questions, architecture sketches, or selections that do not require evidence reconciliation and freeze conditions.

- Skill: `joyhpc/critical-component-selection` (Agent Skill, multi-file: 13 files)
- Install (CLI): `npx skillmds@latest add joyhpc/critical-component-selection`
- Raw SKILL.md: https://api.skillmd.com/api/skills/joyhpc/critical-component-selection/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: joyhpc (https://skillmd.com/u/joyhpc)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/joyhpc/critical-component-selection

---


# Critical Component Selection

## Purpose

Drive hardware component choices that are serious enough to freeze into schematic, BOM, pin assignment, sourcing, validation, or layout constraints. Treat the skill as a practical freeze review workflow, not a project database or a part recommender.

Keep project facts outside the skill. Use `CONTEXT_INDEX.md` when present, project folders such as `hardware-projects/prj/<project>/`, vendor files, datasheets, PCNs, and current email/procurement evidence as the source of truth.

## Entry Phase

Identify the current entry phase before producing output:

1. New requirement: create the requirement baseline first.
2. Vendor substitute or feedback: update candidates, evidence gaps, and risk deltas.
3. Existing shortlist: compare candidates, classify them, and recommend next action.
4. Pre-freeze review: run the freeze checklist and list blockers.
5. Post-decision update: update the decision record, risks, and review date.

Trim output to the active phase. Do not repeat the full workflow when the user only needs an increment, but mention any missing prerequisite that blocks the phase.

For shortlist review, supplier substitute review, blocked decisions, or pre-freeze review, use `references/decision-playbook.md` before recommending a status.

## Evidence Rules

Never assert specific lifecycle, price, lead time, MOQ/MPQ, temperature grade, stock status, PCN/EOL status, tool support, or validation pass/fail from model memory.

For every concrete component fact, cite one of:

1. Datasheet section or table.
2. PCN/EOL number and date.
3. Vendor or distributor URL with access date.
4. Supplier email or message with date and sender.
5. Tool output file, report, or run date.
6. Project decision record or requirements file.

Mark unknown or unsupported fields exactly as `TBD-evidence`. Mark contradictions as `conflict`. Mark evidence that is too old for the decision owner's freshness window as `stale-evidence`. Do not soften these states in prose.

## Workflow Checklist

1. Requirement baseline: identify hard constraints, changeable constraints, target lifetime, and acceptance criteria.
2. Source inventory: list source IDs before making component claims.
3. Hard-gate screen: reject candidates that fail non-negotiable constraints and block candidates whose hard gates lack evidence.
4. Evidence authority check: separate `primary`, `supplier`, `project`, and `secondary` sources before relying on a claim.
5. Candidate evidence matrix: compare one field for one candidate per row using evidence status, not confidence language.
6. Candidate elimination and classification: assign each candidate to `Primary`, `Backup`, `Rejected`, `Watchlist`, or `Closed`, and cite what would reopen rejected routes.
7. Risk register: record supply, EOL, package/pinout, SI/PI/thermal, firmware/logic, cost, and substitute risks with mitigation owners.
8. Engineering verification gate: state this decision's required validation, owner, pass criteria, and output artifact; do not assume device-category-specific gates.
9. External validation interface: when the decision objective needs a domain-specific skill, tool, or project checklist, list it in `external_validation_skills_needed`.
10. Decision and freeze path: recommend one next decision, list freeze blockers, and propose where to save the record.

## Decision Review Rules

Default to an evidence-first review:

1. Answer "can this freeze?" with `yes`, `no`, or `not yet` before long explanation when the user asks for a freeze decision.
2. Do not recommend `frozen` while any hard gate is `TBD-evidence`, `conflict`, `stale-evidence`, or `blocked`.
3. Do not promote a candidate to `Primary` only because it has better apparent specifications; promote the candidate with the clearest evidence path to freeze.
4. Treat supplier substitutes as deltas against the requirement baseline, not as a fresh marketing comparison.
5. Turn every blocker into an owner, needed evidence format, and due or review date.
6. If category-specific validation is required, route it through `external_validation_skills_needed`; do not invent domain pass/fail rules inside this skill.

## Selection Map Sidecar

Create a project-layer Selection Map when the selection has many datasheets, PCNs, overview files, supplier messages, or more candidate routes than can usefully fit in the decision record.

Use a Selection Map when any of these are true: candidate routes are >=5, source IDs are >=10, supplier/FAE/procurement message threads are >=3, or validation paths are >=3. The decision owner may also request one explicitly.

The map is not a catalog of every part number. It exists to help the next selection step by preserving:

1. Source navigation: where evidence lives and what conclusion it supports.
2. Candidate funnel: `Primary`, `Backup`, `Watchlist`, `Rejected`, and `Closed` routes at the useful family or route level.
3. Requirement coverage: which hard constraints are confirmed, conflicted, stale, or still `TBD-evidence`.
4. Rejection rationale: why a route was excluded and what evidence would reopen it.
5. Evidence acquisition plan: who should ask the original vendor, distributor, FAE, procurement, internal owner, or tool/lab path for missing evidence.
6. Tool validation map: what engineering validation must produce before freeze.

Treat "ask the vendor/distributor/procurement" as an evidence-acquisition reminder only. Do not present a question as answered until a dated source with sender, channel, exact subject, and answer is available and cited in the evidence matrix.

## Communication Reports

Create a report when the user needs to communicate the selection state to leadership, procurement, suppliers, FAEs, or a project meeting.

Reports are derived artifacts. They must point back to the decision record, selection map, or evidence matrix and must not introduce new facts. Always keep the current decision strength visible, such as `selected-not-frozen`, `frozen`, or `blocked`.

Choose the report audience before writing:

1. Leadership brief: emphasize decision ask, business impact, top options, top blockers, and deadline.
2. Procurement brief: emphasize exact evidence gaps, supplier questions, required answer format, owners, and dates.
3. Supplier / FAE inquiry: ask only the external-safe questions needed to close evidence gaps; avoid internal rankings, cost targets, competitor details, and unapproved architecture disclosure.
4. Project meeting brief: emphasize current status, decisions needed, blockers, owners, and next review.

Do not paste the full evidence matrix into a report unless explicitly requested. Use the smallest evidence summary that supports the communication goal.

Use hardware freeze semantics:

1. `draft`: still shaping requirements or candidates.
2. `shortlisted`: candidates are identified but no primary decision exists.
3. `selected-not-frozen`: primary candidate chosen for engineering/procurement work, but freeze blockers remain.
4. `frozen`: approved for schematic/BOM/pin/layout freeze with all non-N-A gates passed.
5. `blocked`: cannot proceed without named evidence or architecture change.
6. `superseded`: replaced by a later decision record.

If any hard constraint lacks evidence, the strongest allowed status is `selected-not-frozen`, never `frozen`.

If any hard constraint depends on `stale-evidence`, the strongest allowed status is also `selected-not-frozen` until the dated source is refreshed or explicitly accepted by the decision owner.

## Output Behavior

Default to phase-trimmed output. Include only the sections needed for the current entry phase, plus `Evidence Gaps`, `Recommendation`, and `Next Actions` when applicable.

Use the full formal schema only when the user asks to create a decision record, run a freeze review, or save a project artifact.

Use a Selection Map sidecar when the user asks for a map, when the evidence set is too large for the decision record, or when future agents need a navigation artifact to continue the selection.

Use a Communication Report when the user asks for a report, meeting brief, leadership update, procurement action note, supplier inquiry, or FAE question list derived from the selection.

Full formal schema:

1. `Decision Objective`
2. `Entry Phase`
3. `Source Inventory`
4. `Requirement Baseline`
5. `Hard Gate Screen`
6. `Candidate Classification`
7. `Rejection Ledger`
8. `Evidence Matrix`
9. `Evidence Gaps`
10. `Risk Register`
11. `Engineering Verification Gates`
12. `External Validation Skills Needed`
13. `Recommendation`
14. `Freeze Checklist`
15. `Record Location`
16. `Next Actions`

## Workspace Interface

When working inside an existing workspace:

1. Read `CONTEXT_INDEX.md` first if it exists and the project/component is ambiguous.
2. Search project evidence before browsing the web. Browse only when current vendor, lifecycle, PCN, price, stock, standard, or tool support facts may have changed.
3. Suggest saving the final decision to `hardware-projects/prj/<project>/decisions/<YYYYMMDD>-<component>-selection.md` or the closest existing project decision folder.
4. Suggest adding a pointer to `CONTEXT_INDEX.md` after the decision record exists.
5. Do not store real project facts, vendor-specific cheatsheets, or concrete part numbers in this skill.
6. Follow `../SCHEMA.md` for saved `decision-record` and `selection-map` frontmatter so downstream agents can route on `schema_version`, `schema_kind`, `record_id`, `status`, `primary_candidate`, `backup_candidates`, `freeze_blockers`, `related_records`, `evidence_freshness_window_days`, and `external_validation_skills_needed` without reparsing prose.
7. Run `../tools/scripts/lint_record.py <record.md>` before treating a saved record as handoff-ready when a local Python runtime is available. The repo-level linter is canonical; `scripts/lint_decision_record.py` is only an old-path shim.

## References

Load only the schema or template needed for the active phase:

1. `../SCHEMA.md` for saved record frontmatter fields, lint rule codes, and downstream routing contract.
2. `references/decision-playbook.md` for shortlist reviews, supplier substitutes, hard-gate screening, pre-freeze review, blocker shaping, and domain-validation dispatch.
3. `references/source-inventory-template.md` for source IDs and source trust boundaries.
4. `references/evidence-matrix-template.md` for candidate evidence comparison.
5. `references/risk-register-template.md` for structured risk capture.
6. `references/decision-record-template.md` for the final selection record.
7. `references/freeze-checklist-template.md` for pre-freeze gate review.
8. `references/selection-map-template.md` for large evidence sets, candidate funnels, rejection ledgers, evidence acquisition reminders, and tool-validation navigation.
9. `references/communication-report-template.md` for leadership, procurement, supplier/FAE, and project-meeting reports derived from the selection artifacts.

## Bundled Tools

- `../tools/scripts/lint_record.py`: mechanically checks cross-skill record frontmatter, kind-specific fields, status/class table cells, evidence aging, JSON output, and `--stamp`. It does not parse datasheets, query suppliers, scrape PCNs, or make engineering judgments.
- `scripts/lint_decision_record.py`: old-path shim for callers that still reference the skill-local linter.

## Anti-Patterns

Do not include in this skill:

1. Real project data or real part-number examples.
2. Vendor-specific lifecycle claims.
3. Part-specific, tool-specific, or topology-specific facts such as DDR pinout rules, PMIC compensation recipes, connector SI tables, vendor command sequences, or concrete validation pass/fail thresholds. Generic freeze semantics, evidence trust levels, and risk categories are allowed because they define the decision process.
4. Scripts that parse datasheets, query suppliers, or scrape PCNs; those belong in project tooling after repeated use proves the schema is stable. Mechanical lint scripts for this skill's own output schema are allowed.