@contentful/experience-design-system-generation 2.30.1-dev-build-87c8cf1.0 → 2.30.1-dev-build-6f93a80.0

package/dist/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@contentful/experience-design-system-generation",
-  "version": "2.30.1-dev-build-87c8cf1.0",
+  "version": "2.30.1-dev-build-6f93a80.0",
   "description": "Agent-invocation and skill-prompt engine for the Contentful Experience Design System SDK",
   "license": "MIT",
   "type": "module",

package/dist/src/agent-names.d.ts

@@ -1,4 +1,4 @@
-export declare const AGENT_NAMES: readonly ["claude", "codex", "opencode", "cursor"];
+export declare const AGENT_NAMES: readonly ["claude", "codex", "opencode", "cursor", "copilot"];
 export type AgentName = (typeof AGENT_NAMES)[number];
 export declare const DEFAULT_AGENT_NAME: AgentName;
 export declare function isAgentName(value: string): value is AgentName;

package/dist/src/agent-names.js

@@ -1,4 +1,4 @@
-export const AGENT_NAMES = ['claude', 'codex', 'opencode', 'cursor'];
+export const AGENT_NAMES = ['claude', 'codex', 'opencode', 'cursor', 'copilot'];
 export const DEFAULT_AGENT_NAME = 'claude';
 export function isAgentName(value) {
     return AGENT_NAMES.includes(value);

package/dist/src/agent-runner.js

@@ -271,6 +271,7 @@ const AGENT_BINARIES = {
     codex: 'codex',
     opencode: 'opencode',
     cursor: 'cursor-agent',
+    copilot: 'copilot',
 };
 export function resolveBinary(agent) {
     const envKey = `EDS_AGENT_BINARY_${agent.toUpperCase()}`;
@@ -289,6 +290,7 @@ const DEFAULT_MODELS = {
     codex: 'gpt-5.4-mini', // requires OPENAI_API_KEY; ChatGPT account users must pass --model
     opencode: 'claude-haiku-4-5',
     cursor: 'gpt-mini', // cursor alias for gpt-5.4-mini-medium; haiku not in cursor's catalog
+    copilot: 'Auto', // the only model guaranteed on every Copilot plan (Free/Pro/Business/Enterprise); Pro+ users override via EDS_AGENT_MODEL_COPILOT
 };
 /**
  * Resolve the model for an agent. Explicit flag/creds value wins, then a
@@ -321,6 +323,25 @@ export function buildArgs(agent, prompt, model, promptViaStdin = false) {
         case 'cursor':
             // cursor-agent uses --print for non-interactive stdout output
             return ['--print', ...modelArg, ...promptArg];
+        case 'copilot': {
+            // copilot's -p takes the prompt as its value — it MUST come immediately
+            // after -p or the CLI rejects with "Invalid command format".
+            // --allow-all-tools mirrors codex's sandbox bypass for non-interactive
+            // use.
+            //
+            // Model handling is special: copilot's UI shows "Auto" as the default
+            // pick, but the CLI rejects --model Auto ("not available"). Auto is a
+            // UI-only label — internally, omitting --model IS Auto. So we only
+            // pass --model when the user set an explicit override (via flag or
+            // EDS_AGENT_MODEL_COPILOT); the sentinel string 'Auto' means "omit".
+            //
+            // Stdin fallback is unsupported: copilot -p requires an inline prompt
+            // value, so promptViaStdin will fail here — callers must pass the
+            // prompt inline for copilot.
+            const copilotModel = resolveAgentModel('copilot', model);
+            const copilotModelArg = copilotModel === 'Auto' ? [] : ['--model', copilotModel];
+            return ['-p', ...promptArg, ...copilotModelArg, '--allow-all-tools'];
+        }
     }
 }
 export async function runAgent(options) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@contentful/experience-design-system-generation",
-  "version": "2.30.1-dev-build-87c8cf1.0",
+  "version": "2.30.1-dev-build-6f93a80.0",
   "description": "Agent-invocation and skill-prompt engine for the Contentful Experience Design System SDK",
   "license": "MIT",
   "type": "module",
@@ -22,7 +22,7 @@
     "skills/"
   ],
   "dependencies": {
-    "@contentful/experience-design-system-types": "2.30.1-dev-build-87c8cf1.0"
+    "@contentful/experience-design-system-types": "2.30.1-dev-build-6f93a80.0"
   },
   "devDependencies": {
     "@tsconfig/node24": "^24.0.4",

package/skills/generate-components.md

@@ -91,7 +91,7 @@ Emit one JSON object per line. The CLI parses lines starting with `{`. Lines not
 - Every prop in the input must produce exactly one call: `classify_prop` OR `exclude_prop`.
 - Every slot must produce exactly one `classify_slot` call.
 - Emit `classify_component` once at the start (required). The `description` field is **required** — always provide a brief description of the component's purpose.
-- `values` is required for `cdf_type: "enum"` — must be a non-empty string array of the variant names the prop accepts. **There is no legal `enum` with a guessed list.** If the value set is shown to you anywhere in the material below — the type's own declaration, an `allowedValues` list on the raw prop, a variant/lookup map, a default, a sibling excerpt — copy it and emit `enum`. If it is shown nowhere, emit `cdf_type: "string"` and leave `values` off. `string` is an unrestricted enum: the author can still pass the real value. A guessed list silently rejects it.
+- `values` is required for `cdf_type: "enum"` — must be a non-empty string array of the variant names the prop accepts.
 - **Do NOT include `values` for `cdf_type: "token"`.** The two property types carry different kinds of list. An `enum` prop's list holds *variant names* the component accepts (`"primary"`, `"secondary"`). A `token` prop's list holds *design token paths* (`"color.brand.primary"`), produced by the separate token-mapping step (`$token.allowed`) — never by you. Emitting `values` on a token prop makes the definition invalid.
 - `token_kind` is required for `cdf_type: "token"` — must be a DTCG `$type` string, e.g. `"color"`.
 - `required` must be a JSON boolean (`true`/`false`), not a string.
@@ -208,14 +208,12 @@ the default "could be overridden" (every default can), or because the tie-break
 below exists. Nothing downstream re-derives, corrects, or second-guesses this —
 what you emit is what ships.
 
-**Ambiguity resolves to `enum` — but only when Q1–Q3 cannot be answered, and only
-when you can still cite its values.** The tie-break applies solely when the source
-shown does not let you answer the three questions: the property is interpolated
-in one place and looked up in another, the use sits in a file you cannot see, or
-the source is truncated at the point of use (the "uses not shown" line). In those
-cases emit `enum` if a value set is citable from the source shown, else `cdf_type:
-"string"` per "no legal `enum` with a guessed list" — either way, record the
-ambiguity in `reason`. When the three
+**Ambiguity resolves to `enum` — but only when Q1–Q3 cannot be answered.** The
+tie-break applies solely when the source shown does not let you answer the three
+questions: the property is interpolated in one place and looked up in another,
+the use sits in a file you cannot see, or the source is truncated at the point
+of use (the "uses not shown" line). In those cases emit `enum` (or `string` when
+it has no value set) and record the ambiguity in `reason`. When the three
 questions *can* be answered from the source shown, they are answered and the
 tie-break does not apply: a clear Q1-yes is `enum`, a clear Q2-yes + Q3-yes is
 `token`, and a type annotation does not create ambiguity. An `enum` is delivered
@@ -299,7 +297,7 @@ A prop with a complex TypeScript type is **not automatically excluded**. Many pr
 | Raw type pattern | How to resolve |
 |---|---|
 | `'primary' \| 'secondary' \| 'ghost'` (union of literals) | → `enum`, extract `values` |
-| `HeadingSize` / `ButtonVariant` / any named type that is clearly a finite set of visual options | → `enum` if you can cite its values from the source shown (the type's own declaration, a lookup table, a default) — copy them, never invent them. If the source shown does not enumerate the values, this is not the Q1–Q3 ambiguity tie-break — it is the "no legal `enum` with a guessed list" rule: emit `cdf_type: "string"` instead, with the missing evidence noted in `reason`. Do not default to a generic guess like `['sm', 'md', 'lg']` or `['primary', 'secondary']` — those are one design system's vocabulary, not a fallback for missing evidence. |
+| `HeadingSize` / `ButtonVariant` / any named type that is clearly a finite set of visual options | → `enum`. **Never invent a value list.** Use only values you can cite from the source shown (the type's own declaration, a lookup table, a default). If the source shown does not enumerate the values, this is the "cannot be answered" case — apply "Ambiguity resolves to `enum`": emit `enum` (or `string` if it has no discoverable value set) and record the missing evidence in `description` (not `reason` — `description` ships to the CDF, `reason` does not), e.g. `"WARNING: values not visible in source — enum values unconfirmed"`. Do not default to a generic guess like `['sm', 'md', 'lg']` or `['primary', 'secondary']` — those are one design system's vocabulary, not a fallback for missing evidence. |
 | `Variant` / `variant` prop | Usually a visual design variant. → `enum`, `cdf_category: "design"`. Same evidence rule as above — cite values from the source shown; do not invent them. |
 | `Section[]` / array of custom items where the structure is unclear | → `exclude_prop` only if the array elements are complex objects with no obvious flat representation. If items are simple (title, label, id), consider representing as `string` (a comma-separated IDs or keys) or note in `description` why. |
 | `ExperienceConfiguration<Variant>` / deep generic | Personalization config — → `exclude_prop`, reason: `"personalization configuration — framework internal"` |
@@ -464,30 +462,14 @@ footer is supplementary and optional
 {"tool":"classify_slot","slot":"footer","required":false,"description":"Optional footer area for actions or metadata","rationale":"Footer is a supplementary region typically used for actions or metadata. Optional because most cards do not need one and the card renders correctly without it."}
 ```
 
-### Named type (HeadingSize, ButtonVariant, etc.) — do NOT infer the values
+### Named type (HeadingSize, ButtonVariant, etc.)
 
-When a prop has a named TypeScript type that is not inlined as a union literal,
-the value set is whatever that type's declaration says. A type *name* is not
-evidence of its members: `HeadingSize` could be `h1`–`h6`, `sm|md|lg`, or
-`s|m|l|xl`. Guessing picks one design system's vocabulary and is wrong more
-often than it is right, and a wrong name matches no style rule — the author's
-setting silently does nothing.
+When a prop has a named TypeScript type that is not inlined as a union literal, reason from the prop name and type name to infer the finite value set.
 
-So: look for the declaration in the source shown. If it is there, copy it. If it
-is not, **emit `string`** — `string` is an unrestricted enum, so the author stays
-unrestricted but correct.
-
-Members visible in the source shown — copy them, do not paraphrase:
-```
-titleSize has type HeadingSize; HeadingSize is declared in the excerpt as 'sm' | 'md' | 'lg'
-{"tool":"classify_prop","prop":"titleSize","cdf_type":"enum","cdf_category":"design","required":false,"values":["sm","md","lg"],"description":"Heading size","reason":"Copied from the HeadingSize declaration shown in the excerpt."}
-```
-
-Members NOT visible in the source shown — degrade to `string`:
 ```
-titleSize has type HeadingSize; HeadingSize is not declared anywhere in the source shown
-no evidence for its members, so no values list — string, not a guess
-{"tool":"classify_prop","prop":"titleSize","cdf_type":"string","cdf_category":"design","required":false,"description":"Heading size","reason":"HeadingSize is not declared in the source shown, so its members cannot be cited. Emitted as string rather than inventing a value list."}
+titleSize has type HeadingSize — this is a named enum controlling heading size
+inferring likely values: ["h1", "h2", "h3", "h4", "h5", "h6"] — documenting inference
+{"tool":"classify_prop","prop":"titleSize","cdf_type":"enum","cdf_category":"design","required":false,"values":["h1","h2","h3","h4","h5","h6"],"description":"Heading level — inferred from HeadingSize type name; actual values may be h1–h6 or sm/md/lg"}
 ```
 
 ### href prop
@@ -513,7 +495,7 @@ Before emitting any tool calls, verify:
 1. Every prop in the input has exactly one `classify_prop` or `exclude_prop` call
 2. Every slot has exactly one `classify_slot` call
 3. `classify_component` is emitted exactly once
-4. Every `cdf_type: "enum"` has a non-empty `values` array taken from the material shown. A prop whose value set was shown nowhere is `cdf_type: "string"` with no `values` — never an `enum` with a plausible-looking list, and never an `exclude_prop`.
+4. Every `cdf_type: "enum"` has a non-empty `values` array
 5. Every `cdf_type: "token"` has `token_kind` (or a warning in `description` if lookup failed) and does **not** have `values` set
 6. No `cdf_type: "link"` — all href/url props use `string`
 7. `required` values are JSON booleans, not strings
@@ -525,7 +507,7 @@ Before emitting any tool calls, verify:
 13. `rationale.description` follows the same "Description content rules" as `description` — no internal initiative names (`INTEG-*`, `EDSI`, `DSI`, `M1`, `M2`, wave/phase references, etc.).
 14. Every `cdf_type: "token"` prop cites a line that interpolates its value into a style **and** a token reference at that use (Q2 yes, Q3 yes), and carries no `values`. If you cannot cite both, it is `enum` or `string`; if you can, it is `token` — its type annotation is not a reason to emit `string`.
 15. Every prop whose values are friendly names is `enum` with a non-empty `values` array, even when each name resolves to a design token internally; every prop for which Q1–Q3 could not be answered was emitted as `enum` (or `string`) with the ambiguity stated in `reason`, and no answerable prop was called ambiguous.
-16. Every `enum`'s `values` array is copied from evidence in the material shown — a type declaration, an `allowedValues` list on the raw prop, a variant or lookup map, a default, in the component's own file or in any sibling excerpt — and none of it was invented. Where the value set appears nowhere, the prop is `cdf_type: "string"`, with the reason recorded in `reason`. Do not drop a prop merely because you could not enumerate its values.
+16. Every `enum`'s `values` array is copied from evidence in the source shown (a type declaration, lookup table, or default) — none of it was invented. Where no evidence exists for the values, the `description` states so (e.g. `"WARNING: values not visible in source"`), not just `reason`.
 
 After the run completes, the developer can validate the pipeline output with:
 
@@ -546,6 +528,4 @@ properties — this is never acceptable.
 If you are genuinely uncertain about every prop, classify each as:
 {"tool":"classify_prop","prop":"<name>","cdf_type":"string","cdf_category":"content","required":false,"description":"Uncertain classification — review recommended"}
 
-An imperfect classification is infinitely better than no classification. That is
-about **classifying a prop rather than dropping it** — it is not a licence to
-invent a `values` list. The uncertain answer is `cdf_type: "string"`, every time.
+An imperfect classification is infinitely better than no classification.