S32FlashTool - Identify User Board

Identify the most likely S32 Flash Tool board from whatever clues the user provides - exact or partial name, board image, silkscreen text, connector labels, processor markings, or installed S32 Flash Tool examples and PDFs - and hand off cleanly to the support-details workflow once identity is known.

When to use

Use this skill when the user wants to establish what board they have, before any support or operation question can be answered concretely.

Typical triggers:

• the user says "I have this board", "which board is this?", or "can you tell me what board this is?"
• the user provides a board photo, silkscreen text, or connector labels and asks to identify it
• the user gives a partial or approximate board name ("S32N EVB", "the S32G reference design") that needs to be resolved to a canonical name
• the user gives an exact board name and asks for confirmation or context
• a sibling skill (e.g. s32flashtool-supported-devices-per-platform) needs a board identity before it can produce a support-matrix answer
• the session has no established board yet and the next request would need one

When not to use

Do not use this skill for:

• support-matrix questions ("which processors / flashes / interfaces are supported on this board?") - use s32flashtool-supported-devices-per-platform
• hardware setup / connection details (interface, port, boot mode) - use s32flashtool-discover-hardware-setup
• live processor identification from the connected target - use s32flashtool-read-mcuid
• routing a general user request - use s32flashtool-workflow-index
• any operation on the target (read, program, erase, verify) - use the matching operation skill

This skill is read-only inference from clues. It never invokes tools that touch the target and never claims hardware verification.

Shared references

• Apply shared rules from s32flashtool-agent-rules-minimal/SKILL.md.
• Use s32flashtool-workflow-index/SKILL.md to select the correct workflow.
• Hand off support-matrix questions to s32flashtool-supported-devices-per-platform.
• For claim labeling and evidence discipline, apply s32flashtool-evidence-disciplined-technical-validation.

Quickstart

Follow this 5-step sequence. Skip forward when the user's clues already answer an earlier step.

Step 1 - Gather user clues

Extract any of:

• exact board name
• partial board name
• processor name or family
• platform (e.g. S32N5, S32G3)
• visible silkscreen text
• connector labels
• processor package marking
• whether the user provided an image or only text

If the user refers to "this board" and a board was identified earlier in the session, reuse that identity unless new evidence contradicts it.

Step 2 - Choose the identification path

Path A - exact or near-exact board name given. Use the name as the primary clue. Refine or confirm with nxp_knowledge_kb_search. If s32flashtool_folder is available, verify against installed examples/PDFs. Return an identification with confidence. Do not block on requesting the installation folder before giving a provisional answer.

Path B - image only. If board_image_* tools are available, use them to shortlist candidates. Otherwise, use visible clues from the image description together with nxp_knowledge_kb_search. With s32flashtool_folder available and user permission, inspect examples/ and matching PDFs.

Path C - no board name and no usable image. Do not guess. Ask for the smallest missing identifying detail (board name, processor family, or a photo).

Step 3 - Use installed S32FlashTool evidence when available

With s32flashtool_folder:

1. inspect s32flashtool_folder/examples
2. look for board/example names matching the user's clues
3. inspect matching board PDFs in examples (ask permission first for arbitrary local file reads)
4. treat an exact example or PDF hit as stronger evidence than inference
5. report installed-example evidence separately from knowledge-base evidence

Without s32flashtool_folder:

1. provide a provisional identification from user clues plus nxp_knowledge_kb_search
2. explicitly state that installed-example verification is still pending
3. ask for the folder only if the user wants authoritative verification

Step 4 - Handle ambiguity

If multiple boards remain plausible:

1. list the top candidates
2. assign a confidence level to each (see below)
3. explain the discriminator for each candidate
4. ask the smallest follow-up question that would eliminate the ambiguity

Confidence levels:

• high - exact board-name match from the user, or exact installed example/PDF match
• medium - strong family/platform and knowledge-base match, no exact installed verification yet
• low - partial name match, approximate image similarity, or otherwise incomplete clues

Step 5 - Hand off to support-details when needed

If the user asks "what is supported on this board?" after identification:

1. state the likely board/platform
2. hand off to s32flashtool-supported-devices-per-platform
3. keep identification evidence separate from support evidence

Evidence sources

Use these in decreasing order of authority. Every claim in the response labels which source it came from.

Source	Label	Justifies	Does NOT justify
Exact board name from the user	user-supplied	"Likely identified as X (user-supplied)"	hardware verification, support conclusions
Installed example folder / PDF match under s32flashtool_folder/examples	installed-example	"Matched against installed example X-EVB.pdf"	that the board is physically present or working
board_image_* tool result with clear confidence	image-match	"Board image analysis matched X with high confidence"	anything the image can't show (populated flash, boot-mode jumpers)
nxp_knowledge_kb_search result	kb-search	"Consistent with knowledge-base entry for X"	authoritative installed-package answers when the folder is available
Live tool output from a connected target	hardware-verified	"Verified by read_mcuid output"	any board-level fact the tool didn't return

Prefer higher-authority sources when they are available. Never merge sources in a single claim - split into labeled statements.

Preferred wording

Prefer "likely identified from the user-provided board name", "matched against installed S32FlashTool examples", "supported by knowledge-base evidence", "not yet verified against the local installation", "not hardware-verified".

Avoid "this is definitely the board" without exact evidence, "supported on the physical board" without verified support and applicability, or "confirmed" without documentation or live verification.

Output format

Respond in this structure. Omit sub-sections that have no content rather than leaving them empty.

Hardware setup assessment

• Likely board: ...
• Likely platform / family: ...
• Identification status: exact match / likely match / ambiguous / insufficient information
• Confidence: high / medium / low

Candidate boards

• Candidate 1: ... - reason
• Candidate 2: ... - reason
• Candidate 3: ... - reason
• If only one strong match exists: "No significant alternative candidates identified."

Evidence

List the exact evidence used, one line per item, labeled with a source from the Evidence sources table (user-supplied, installed-example, image-match, kb-search, hardware-verified). Include the pointer (example path, PDF filename, kb query, tool output reference).

Recommended next step

State the single safest next action. Typical patterns:

• Provisional answer, s32flashtool_folder missing -> ask for the folder to verify against installed examples/PDFs.
• Ambiguous -> ask for the smallest missing discriminator.
• Identified, user wants support details -> hand off to s32flashtool-supported-devices-per-platform.

Command or tool suggestion

Name the exact next tool/skill to use, e.g.:

• nxp_knowledge_kb_search with the identified board/platform clue
• inspect s32flashtool_folder/examples
• apply s32flashtool-supported-devices-per-platform

If more information is required

Ask only the minimal follow-up question(s). Examples:

• "What is the exact board name printed on the PCB or box?"
• "Can you share the processor family or device marking?"
• "Do you want me to verify this against your local S32FlashTool installation?"
• "What is your S32FlashTool installation folder?"

Worked examples

User gives only a picture. Try board_image_* first. Fall back to visible-clue reasoning plus nxp_knowledge_kb_search. Return the top candidates with confidence. Ask for the smallest discriminator if ambiguity remains.

User gives only a board name. Use the name as the primary clue. Refine with nxp_knowledge_kb_search. Do not block on requesting s32flashtool_folder. Ask for the folder only if the user wants installed-file verification.

User gives no hardware details. Do not guess. Ask for the smallest missing identifying detail. Do not jump to programming or support conclusions.

User says "I have this board <name>. Tell me what you know about it." Identify the board and platform first. Label the result as exact, likely, or provisional. If the user then asks about supported processors, flashes, interfaces, or limitations, hand off to s32flashtool-supported-devices-per-platform.

Guardrails

Scope

• Only identify the most likely S32 Flash Tool board from clues (name, image, silkscreen, connector labels, installed examples). Route support-matrix questions to s32flashtool-supported-devices-per-platform.
• Recovery on scope mismatch: name the correct sibling skill and stop.

Destructive actions

• Identification is read-only. Do not trigger writes, erases, or flash operations from this skill.

Refuse-and-escalate

• Do not force a single-board match when several remain plausible. Recovery: return all candidates with evidence labels and confidence.
• Do not claim installed-example evidence unless s32flashtool_folder was provided and inspected. Recovery: label the answer as provisional and ask for the folder if the user wants stronger evidence.
• Do not claim hardware verification unless a live tool call confirmed it. Recovery: label the answer as "not hardware-verified" and name the live tool that would verify it (usually s32flashtool-read-mcuid).
• Do not fabricate hardware-specific defaults. Recovery: ask for the missing detail.

Output contract

• The identification status is exactly one of exact | likely | ambiguous | unknown.
• Every claim carries an evidence label from the Evidence sources table and a pointer (filename, kb query, image field, silkscreen text).
• Board identification is reported separately from support-matrix conclusions.

Validation loop

1. The response classifies the match as one of exact | likely | ambiguous | unknown. Fail if the category is absent or invented.
2. Every claim (board name, platform, family, installed-example hit) carries an evidence label and pointer. Fail on any unsourced claim.
3. Support-matrix questions are deferred to s32flashtool-supported-devices-per-platform. Fail if this skill answers them directly.
4. No hardware-verification claim ("board confirmed", "connectivity verified") is made without a corresponding live tool call. Fail on any such claim.
5. No MCP tool that writes to a target is invoked. Fail on any destructive tool call.

Out of scope

• Answering support-matrix questions (which processors / flashes / interfaces are supported on the board). Route to s32flashtool-supported-devices-per-platform.
• Live hardware verification. Use the connectivity/operation skills (s32flashtool-read-mcuid, s32flashtool-get-flash-id, s32flashtool-list-available-serial-communication-interfaces).
• Forcing a single-board match when multiple candidates remain plausible.
• Making installed-example claims without inspecting s32flashtool_folder.