finding-easyconfig-parameters

name	finding-easyconfig-parameters
description	Extract and resolve software and toolchain parameters from user input.

Resolving User Input to EasyConfig parameters

IMPORTANT:

• Assumptions are FORBIDDEN.
• Interpret Workflow line by line and in order. Each line is important.
• If you failed to resolve these parameters, you MUST return an error.
• Perform a web search whenever you were confused (ONLY trust reliable websites).
• ./TOOLCHAINS.md is located inside this skill's directory.

Resolution Workflow (IN ORDER)

You MUST populate the following parameters in your context:

1. ACTION

   • Description: What does user want to do with the easyconfig?
   • RULES:
     • You MUST translate user request to one of GENERATE, TEST, or DEBUG actions.
     • To update an existing easyconfig, you MUST generate a new easyconfig with updated parameters.

2. SW_NAME

   • Description: The EXACT case-sensitive name of the software.
   • RULES:
     • MUST be provided by user.
     • MUST be a known software package, with correct capitalization (upper‑ and lower‑case letters).

3. TC_NAME

   • Description: The name of the toolchain.
   • RULES:
     • If two toolchain names are provided: set TC_NAME to the smaller toolchain name. (e.g. Pefer GCCcore over gompi or foss).
     • Else if one toolchain name is provided: set TC_NAME to that toolchain name.
     • Else if toolchain name is NOT provided: set TC_NAME to the minimal required toolchain of the SW_NAME within foss toolchain family.

4. TC_VERSION

   • Description: The version of the toolchian.
   • RULES:
     • If the user provides a toolchain version:
       • Read ./TOOLCHAINS.md and find the row where the provided toolchain version appears.
       • Set TC_VERSION to the EXACT version of TC_NAME in that row.
     • Else:
       • Read ./TOOLCHAINS.md to set TC_VERSION to the latest version of TC_NAME.

5. SW_VERSION

   • Description: The version of the software.
   • RULES:
     • You MUST NEVER use versions mentioned in filenames, examples, and commit messages since they are NON‑AUTHORITATIVE.
     • ONLY if the user asks for a specific software version in natural language AND that version is NOT derived from NON‑AUTHORITATIVE texts, set SW_VERSION to that version.
     • Otherwise, you MUST call mcp__web__agent tool to use web_search to set SW_VERSION to the latest stable release version and add (latest) tag to it.

6. SW_SUFFIX

   • Description: Any version suffixes (can contain one or more features name, optionally with their version).
   • RULES:
     • If the user provides a versionsuffix, it MUST contain feature names (e.g. CUDA). Keep these feature names for SW_SUFFIX.
     • You MUST NEVER use versions mentioned in filenames, examples, and commit messages since they are NON‑AUTHORITATIVE.
     • ONLY if the user asks for a specific feature version in natural language AND that version is NOT derived from NON‑AUTHORITATIVE texts, use that version for SW_SUFFIX.
     • Otherwise:
       1. If the feature has a toolchain-specific version in ./TOOLCHAINS.md, you MUST use it.
       2. Otherwise, you MUST call mcp__web__agent tool to use web_search to set the feature's version to the latest stable release version and add (latest) tag to it.