Analyze Project

Goal

Build an accurate, read-only picture of an S32DS project: its target hardware, toolchain, attached SDKs, build health, dependencies, and debug capability. This gives you the context needed to make safe, correct changes later.

Tools Used

• search_actions - call FIRST to discover available actions; the returned catalog includes each action's input schema
• execute_action - invoke any discovered action via execute_action(action_name="X", params={...}); the static start_tool action brings the IDE up if it is not running
• The waitForJob action (via execute_action) - only needed if you trigger an async job (not required for pure analysis)

Before You Start

Call search_actions(query="...") first. The catalog is the source of truth for action names and their input schemas - use it instead of guessing (a parameterless search_actions() browses everything). Action names are case-sensitive

Prerequisites

• At least one project must exist in the workspace.
• The target project must be open. Closed projects cannot be queried - you can see them in listProjects but cannot read their info or problems.

Guardrails

Scope

• This skill is read-only. Inspect projects with list/getProjectInfo/SDK queries only; never build, modify, rename, or delete the analyzed project. If the user actually wants a change, hand off to the appropriate build/config skill.

Refuse-and-escalate

• If the named project is not in the workspace or the info calls fail, stop and ask the user to confirm the project rather than inferring its structure from a filename.

When to Use

• A user is new to a project and asks "what is this?" or "what does this target?"

• You need the MCU, core, and toolchain before making changes.

• A project behaves unexpectedly and you want a baseline before debugging.

• You want to know dependencies/referenced projects (they may need building first).

• It is the first step before any build, debug, or code-generation task on an unfamiliar project.

Steps

1. List workspace projects

• Call: execute_action(action_name="listProjects")
• Why: Discover the exact project name, open/closed state, and disk location. Every later step needs the precise name.
• Result: JSON list with name, open, location.
• If the target is closed, stop and tell the user - it cannot be analyzed until reopened.

2. Get project details

• Call: execute_action(action_name="getProjectInfo", params={"projectName": "<name>"})
• Why: This is the core of the analysis - it tells you what the project actually is.
• Result: JSON with project type info, build configs, MCU info, references.
• Extract and report, in plain language the user can act on:
  • MCU / Target: family, device, core, revision - this drives everything downstream.
  • Build configs: which configs exist (e.g. Debug/Release) and which one is active.
  • Project type: say what kind of project it is (e.g. "a C application built with the managed S32DS build system") rather than dumping raw Eclipse nature/builder IDs.
  • References: any projects this one depends on - these often need building first.

3. Find the SDKs for the target

• Call: execute_action(action_name="listAllSdks")
• Why: The SDK set determines which drivers/APIs (RTD, AMMCLIB, platform packages) are available to you when assisting with code.
• How: listAllSdks returns the global catalog of installed SDKs. Filter it by the MCU part you learned in step 2 to get the ones relevant to this target. For example, for an S32K344 project the relevant entries are names containing S32K344, such as PlatformSDK_S32K3_S32K344_M7 (the RTD platform package) and FreeMASTER_S32K344.
• Result: report the matching SDKs with name and version. Make clear these are the installed SDKs that match the target, drawn from the global catalog.
• Note: there is no per-project SDK attachment query available - the old getProjectSdks action has been removed from S32DS, so do not call it. Always use listAllSdks filtered by MCU part.
• If no SDK matches the target's part, note it - a missing platform SDK usually explains build errors later.

4. Check build health

• Call: execute_action(action_name="getProblems", params={"projectName": "<name>"})
• Why: Tells you whether the project is in a buildable state before you touch it.
• Note: projectName is optional. Omit it to get workspace-wide problems; pass it to scope to one project. For single-project analysis, scope it.
• Result: markers with severity, message, file, line.
• Summarize counts (errors / warnings / infos). If errors exist, list the top few with file and line - those are your first leads.

5. List debug / launch configurations

• Call: execute_action(action_name="listDebugLaunches", params={"nameFilter": "<name>"})
• Why: Shows how the application can be launched/debugged on hardware.
• Result: launch configs with name, type, associated project.
• Report each config's name and debugger type (e.g. GDB / PEMicro / S32 Debug Probe).

6. (Optional) Open a source file for inspection

• Call: execute_action(action_name="openFile", params={"filePath": "<absolute-or-workspace-path>"})
• Why: After spotting an interesting file (e.g. from a build problem), open it in the editor so the user can see it.
• Use the location from step 1 to build an absolute path when needed.

7. (Optional) Look up reference docs for the target MCU

• This skill does not search documentation itself. If the user needs hardware/peripheral context beyond the project config, hand off to the s32ds-find-documentation skill, scoping the query with the MCU/core you learned in step 2.

8. Present the summary

Give the user a single structured overview tying together everything above. Keep it scannable.

Example Summary Output

Use a clean, ASCII, structured layout like this (grounded in a real S32DS 3.6.5 project):

Project Analysis: FRDM_A_S32K344_UART

Target:        S32K344  (ARM Cortex-M7)
Family:        S32K3
Device core:   S32K344_M7
Project type:  C application, managed S32DS build

SDKs (installed packages matching this target):
  - PlatformSDK_S32K3_S32K344_M7 v7.0.1   (RTD platform package)
  - FreeMASTER_S32K344 v1.5.0

Build status: 0 errors, 0 warnings, 0 infos  (clean)

Debug configs (2):
  - FRDM_A_S32K344_UART Debug_FLASH       (S32 Debugger)
  - FRDM_A_S32K344_UART_Debug_FLASH_PNE   (GDB PEMicro)

Dependencies: none (standalone project)

Related Skills

• s32ds-build-and-debug - after analysis, to build and launch a debug session
• s32ds-fix-build-errors - if build health shows errors
• s32ds-check-sdk-compatibility - if SDK versions look problematic
• s32ds-find-documentation - to look up MCU/peripheral reference material
• s32ds-workspace-health-check - for full multi-project workspace analysis

Notes

• This skill is read-only - it never modifies the project. That is what makes it safe to run first on anything.
• MCU info comes from the project config; the matching SDKs reveal which APIs are available for coding assistance.
• Referenced projects may need to be built before the main project will compile.
• For a workspace-wide view across many projects, use s32ds-workspace-health-check instead of running this skill per project.

Anti-Patterns (Do NOT)

• Do NOT skip analysis and jump straight to building/debugging an unfamiliar project - you will miss missing SDKs and dependency ordering.
• Do NOT call the removed getProjectSdks action - use listAllSdks filtered by MCU part instead.
• Do NOT assume SDK availability - confirm it from listAllSdks, since it changes which APIs you can reference.
• Do NOT ignore referenced projects - they may need building first.
• Do NOT try to analyze a closed project - reopen it first or tell the user it is closed.
• Do NOT invent a documentation-search action here - delegate to s32ds-find-documentation.