diff --git a/.agents/skills/impeccable/SKILL.md b/.agents/skills/impeccable/SKILL.md index 3ca040ef0..cf255c83a 100644 --- a/.agents/skills/impeccable/SKILL.md +++ b/.agents/skills/impeccable/SKILL.md @@ -12,12 +12,12 @@ Approach every design task as the design lead at a small studio known for giving You MUST do these steps before proceeding: -1. Run `node .agents/skills/impeccable/scripts/context.mjs` once per session; if the runtime shows this skill's loaded base directory, run `node /scripts/context.mjs` instead. Keep cwd/workdir at the user's project, not the skill directory. If the request names or implies a file, route, or app inside a monorepo, infer the concrete path and append `--target ` to the same command. If you've already seen its output in this conversation, do not re-run it. The script either prints the project's PRODUCT.md (and DESIGN.md when present) as a markdown block, or tells you it's missing. Follow whatever it prints. **If it reports `NO_PRODUCT_MD`:** divert into `reference/init.md` first when the user invoked `init`, `teach`, `craft`, or `shape`, or when their wording clearly maps to one of those from-scratch build flows (for example: "build/create/make a landing page", "design a new app", or "shape a feature"). Captured product context is the point of those flows. For any other command, a scoped evaluate / refine / enhance / fix / iterate request against existing code, do **not** divert into init. The existing code is the context: proceed with the requested command, infer the register from the surface in focus, and offer `$impeccable init` once as a suggestion the user can take later. A missing PRODUCT.md must never block a scoped request. If the output ends with an `UPDATE_AVAILABLE` directive, follow it (ask the user once about updating, then continue). It never blocks the current task. +1. Run `node .agents/skills/impeccable/scripts/context.mjs` once per session; if the runtime shows this skill's loaded base directory, run `node /scripts/context.mjs` instead. Keep cwd/workdir at the user's project, not the skill directory. If the request names or implies a file, route, or app inside a monorepo, infer the concrete path and append `--target ` to the same command. If you've already seen its output in this conversation, do not re-run it. The script either prints the project's PRODUCT.md (and DESIGN.md when present) as a markdown block, or tells you it's missing. Follow whatever it prints. **If it reports `NO_PRODUCT_MD`:** divert into `reference/init.md` first when the user invoked `init`, `teach`, `craft`, or `shape`, or when their wording clearly maps to one of those from-scratch build flows (for example: "build/create/make a landing page", "design a new app", or "shape a feature"). Captured product context is the point of those flows. **Exception: when no user can respond** (an unattended or one-shot run, or the user said not to ask questions), skip the init interview: write your own one-paragraph understanding of the product, audience, and the page's job from the brief, then proceed with the flow. For any other command, a scoped evaluate / refine / enhance / fix / iterate request against existing code, do **not** divert into init. The existing code is the context: proceed with the requested command, infer the register from the surface in focus, and offer `$impeccable init` once as a suggestion the user can take later. A missing PRODUCT.md must never block a scoped request. If the output ends with an `UPDATE_AVAILABLE` directive, follow it (ask the user once about updating, then continue). It never blocks the current task. 2. If the user invoked a sub-command (`craft`, `shape`, `audit`, `polish`, ...), you MUST read the command's reference next: **`reference/.md`, or the native variant from the Commands table** (e.g. `reference/audit.native.md`) **when the project platform is native** (`ios` / `android` / `adaptive`, per the `context.mjs` directive). One file, not both. Non-optional. The reference defines the command's flow; without it you will skip steps the user expects. 3. Familiarize yourself with any existing design system, conventions, and components in the code. Read at least one project file (CSS / tokens / theme / a representative component or page). **Required even when you've loaded a sub-command reference in step 2.** Don't reinvent the wheel; use what's there when it works, branch out when the UX wins. 4. Identify the register. If the surface is marketing, a landing page, a campaign, long-form content, or a portfolio, design IS the product: the **brand register** applies (see Registers below). If it is app UI, admin, a dashboard, or a tool, design SERVES the product: the **product register** applies. Pick by first match: (1) task cue ("landing page" vs "dashboard"); (2) surface in focus; (3) `register` field in PRODUCT.md. For substantial brand or product work, `reference/brand.md` / `reference/product.md` carry extended depth worth reading; the essentials are inlined below either way. 5. **If PRODUCT.md's `## Platform` is `ios` or `android`**, also read `reference/.md` (HIG / Material 3 conventions). `adaptive` (cross-platform, ships both) reads both files. `web`, absent, or unrecognized: nothing extra to read. `context.mjs` prints the directive when one applies. -6. **If the project is brand-new (no existing CSS tokens / theme / committed brand colors found in step 3)**, run `node .agents/skills/impeccable/scripts/palette.mjs` to receive a brand seed color and composition guidance. This is the anchor for your primary brand color. Compose the rest of the palette (bg, surface, ink, accent, muted) around it per the script's instructions. Use OKLCH throughout. **Skip this step only if step 3 found committed brand colors in existing tokens; in that case identity-preservation wins.** +6. **If the project is brand-new (no existing CSS tokens / theme / committed brand colors found in step 3)**, run `node .agents/skills/impeccable/scripts/palette.mjs` to receive a brand seed color. The seed exists to break your reflex palette, not to override the subject: when the subject's own world clearly dictates color (an era, a place, a material, a medium), derive the palette from that world and use the seed only as a check on whether your choice was a reflex. When the subject leaves color open, adopt the seed as the anchor and compose the rest of the palette (bg, surface, ink, accent, muted) around it per the script's instructions. Use OKLCH throughout. **Skip this step only if step 3 found committed brand colors in existing tokens; in that case identity-preservation wins.** ## How to design @@ -41,7 +41,7 @@ If the brief doesn't pin down what the product or subject is, pin it yourself be Work in two passes, doing the thinking in your reasoning rather than narrating it. -First, plan a compact token system: **palette** (named values, composed around the seed from Setup step 6 when one was issued), **type** (faces and roles), **layout** (the structural concept in one sentence), and **signature**: the one element this page will be remembered by, drawn from the subject's world. Structure is part of the concept: the standard page skeleton is a default, not a given. Derive the page's frame, viewport treatment, and section rhythm from what the subject needs; when the concept calls for a different structure, take it. +First, plan a compact token system: **palette** (named values; Setup step 6's seed rule decides whether the seed or the subject's world anchors it), **type** (faces and roles), **layout** (the structural concept in one sentence), and **signature**: the one element this page will be remembered by, drawn from the subject's world. Structure is part of the concept: the standard page skeleton is a default, not a given. Derive the page's frame, viewport treatment, and section rhythm from what the subject needs; when the concept calls for a different structure, take it. Then audit the plan before building: work through what you would produce for a *similar* brief from another client. Wherever the two plans converge (same palette family, same face, same skeleton), that part is your generic default, not a choice made for this brief. Revise it. Only then write code, following the revised plan exactly and deriving every color and type decision from it. diff --git a/.agents/skills/impeccable/reference/craft.md b/.agents/skills/impeccable/reference/craft.md index 4adbc2b1f..86fdefca4 100644 --- a/.agents/skills/impeccable/reference/craft.md +++ b/.agents/skills/impeccable/reference/craft.md @@ -19,6 +19,8 @@ You must stop at every gate. **Shape confirmation alone is NOT a green light to When the harness lacks native image generation, gates 2-4 collapse into the brief itself, and shape confirmation does advance straight to code. +**Unattended runs.** When no user can respond (a one-shot task, an automated run, or an explicit instruction not to ask questions), every gate collapses into a decision you make yourself. Hold the same bar the gate would have held: state the shape brief, the visual direction, and the palette as decided (one line each, in your reasoning or the final summary), then proceed straight through to build and the visual iteration pass. Do not stop to wait, do not ask, and do not skip the direction thinking just because nobody will read the questions. + ## Step 0: Project Foundation Before shape, before code: figure out what kind of project you're working in. @@ -44,7 +46,7 @@ Default: Astro for brand briefs, the project's existing framework for product br Run $impeccable shape, passing along whatever feature description the user provided. Shape is **required** for craft; it is what produces a confirmed direction. -Present the shape output and stop. Wait for the user to confirm, override, or course-correct before writing code. +Present the shape output and stop. Wait for the user to confirm, override, or course-correct before writing code. On an unattended run, produce the compact shape output for yourself and continue without pausing. If the user already supplied a confirmed brief or ran shape separately, use it and skip this step. diff --git a/.agents/skills/impeccable/reference/shape.md b/.agents/skills/impeccable/reference/shape.md index 6252c5166..be8838b80 100644 --- a/.agents/skills/impeccable/reference/shape.md +++ b/.agents/skills/impeccable/reference/shape.md @@ -12,6 +12,8 @@ Most AI-generated UIs fail not because of bad code, but because of skipped think **Do NOT write any code or make any design decisions during this phase.** Your only job is to understand the feature deeply enough to make excellent design decisions later. +**Unattended runs:** when no user can respond (a one-shot task, an automated run, or an explicit instruction not to ask questions), answer the interview questions yourself from the brief, record the answers as the design brief, and continue without pausing at any confirmation gate in this file. The thinking is still required; only the waiting is waived. + This is a required interaction, not optional guidance. Ask these questions in conversation, adapting based on answers. Don't dump them all at once; have a natural dialogue. STOP and use Codex's structured user-input/question tool when available; if unavailable, ask directly in chat to clarify what you cannot infer. ### Interview cadence diff --git a/.claude/skills/impeccable/SKILL.md b/.claude/skills/impeccable/SKILL.md index 47aaa062b..21471521a 100644 --- a/.claude/skills/impeccable/SKILL.md +++ b/.claude/skills/impeccable/SKILL.md @@ -18,12 +18,12 @@ Approach every design task as the design lead at a small studio known for giving You MUST do these steps before proceeding: -1. Run `node .claude/skills/impeccable/scripts/context.mjs` once per session; if the runtime shows this skill's loaded base directory, run `node /scripts/context.mjs` instead. Keep cwd/workdir at the user's project, not the skill directory. If the request names or implies a file, route, or app inside a monorepo, infer the concrete path and append `--target ` to the same command. If you've already seen its output in this conversation, do not re-run it. The script either prints the project's PRODUCT.md (and DESIGN.md when present) as a markdown block, or tells you it's missing. Follow whatever it prints. **If it reports `NO_PRODUCT_MD`:** divert into `reference/init.md` first when the user invoked `init`, `teach`, `craft`, or `shape`, or when their wording clearly maps to one of those from-scratch build flows (for example: "build/create/make a landing page", "design a new app", or "shape a feature"). Captured product context is the point of those flows. For any other command, a scoped evaluate / refine / enhance / fix / iterate request against existing code, do **not** divert into init. The existing code is the context: proceed with the requested command, infer the register from the surface in focus, and offer `/impeccable init` once as a suggestion the user can take later. A missing PRODUCT.md must never block a scoped request. If the output ends with an `UPDATE_AVAILABLE` directive, follow it (ask the user once about updating, then continue). It never blocks the current task. +1. Run `node .claude/skills/impeccable/scripts/context.mjs` once per session; if the runtime shows this skill's loaded base directory, run `node /scripts/context.mjs` instead. Keep cwd/workdir at the user's project, not the skill directory. If the request names or implies a file, route, or app inside a monorepo, infer the concrete path and append `--target ` to the same command. If you've already seen its output in this conversation, do not re-run it. The script either prints the project's PRODUCT.md (and DESIGN.md when present) as a markdown block, or tells you it's missing. Follow whatever it prints. **If it reports `NO_PRODUCT_MD`:** divert into `reference/init.md` first when the user invoked `init`, `teach`, `craft`, or `shape`, or when their wording clearly maps to one of those from-scratch build flows (for example: "build/create/make a landing page", "design a new app", or "shape a feature"). Captured product context is the point of those flows. **Exception: when no user can respond** (an unattended or one-shot run, or the user said not to ask questions), skip the init interview: write your own one-paragraph understanding of the product, audience, and the page's job from the brief, then proceed with the flow. For any other command, a scoped evaluate / refine / enhance / fix / iterate request against existing code, do **not** divert into init. The existing code is the context: proceed with the requested command, infer the register from the surface in focus, and offer `/impeccable init` once as a suggestion the user can take later. A missing PRODUCT.md must never block a scoped request. If the output ends with an `UPDATE_AVAILABLE` directive, follow it (ask the user once about updating, then continue). It never blocks the current task. 2. If the user invoked a sub-command (`craft`, `shape`, `audit`, `polish`, ...), you MUST read the command's reference next: **`reference/.md`, or the native variant from the Commands table** (e.g. `reference/audit.native.md`) **when the project platform is native** (`ios` / `android` / `adaptive`, per the `context.mjs` directive). One file, not both. Non-optional. The reference defines the command's flow; without it you will skip steps the user expects. 3. Familiarize yourself with any existing design system, conventions, and components in the code. Read at least one project file (CSS / tokens / theme / a representative component or page). **Required even when you've loaded a sub-command reference in step 2.** Don't reinvent the wheel; use what's there when it works, branch out when the UX wins. 4. Identify the register. If the surface is marketing, a landing page, a campaign, long-form content, or a portfolio, design IS the product: the **brand register** applies (see Registers below). If it is app UI, admin, a dashboard, or a tool, design SERVES the product: the **product register** applies. Pick by first match: (1) task cue ("landing page" vs "dashboard"); (2) surface in focus; (3) `register` field in PRODUCT.md. For substantial brand or product work, `reference/brand.md` / `reference/product.md` carry extended depth worth reading; the essentials are inlined below either way. 5. **If PRODUCT.md's `## Platform` is `ios` or `android`**, also read `reference/.md` (HIG / Material 3 conventions). `adaptive` (cross-platform, ships both) reads both files. `web`, absent, or unrecognized: nothing extra to read. `context.mjs` prints the directive when one applies. -6. **If the project is brand-new (no existing CSS tokens / theme / committed brand colors found in step 3)**, run `node .claude/skills/impeccable/scripts/palette.mjs` to receive a brand seed color and composition guidance. This is the anchor for your primary brand color. Compose the rest of the palette (bg, surface, ink, accent, muted) around it per the script's instructions. Use OKLCH throughout. **Skip this step only if step 3 found committed brand colors in existing tokens; in that case identity-preservation wins.** +6. **If the project is brand-new (no existing CSS tokens / theme / committed brand colors found in step 3)**, run `node .claude/skills/impeccable/scripts/palette.mjs` to receive a brand seed color. The seed exists to break your reflex palette, not to override the subject: when the subject's own world clearly dictates color (an era, a place, a material, a medium), derive the palette from that world and use the seed only as a check on whether your choice was a reflex. When the subject leaves color open, adopt the seed as the anchor and compose the rest of the palette (bg, surface, ink, accent, muted) around it per the script's instructions. Use OKLCH throughout. **Skip this step only if step 3 found committed brand colors in existing tokens; in that case identity-preservation wins.** ## How to design @@ -47,7 +47,7 @@ If the brief doesn't pin down what the product or subject is, pin it yourself be Work in two passes, doing the thinking in your reasoning rather than narrating it. -First, plan a compact token system: **palette** (named values, composed around the seed from Setup step 6 when one was issued), **type** (faces and roles), **layout** (the structural concept in one sentence), and **signature**: the one element this page will be remembered by, drawn from the subject's world. Structure is part of the concept: the standard page skeleton is a default, not a given. Derive the page's frame, viewport treatment, and section rhythm from what the subject needs; when the concept calls for a different structure, take it. +First, plan a compact token system: **palette** (named values; Setup step 6's seed rule decides whether the seed or the subject's world anchors it), **type** (faces and roles), **layout** (the structural concept in one sentence), and **signature**: the one element this page will be remembered by, drawn from the subject's world. Structure is part of the concept: the standard page skeleton is a default, not a given. Derive the page's frame, viewport treatment, and section rhythm from what the subject needs; when the concept calls for a different structure, take it. Then audit the plan before building: work through what you would produce for a *similar* brief from another client. Wherever the two plans converge (same palette family, same face, same skeleton), that part is your generic default, not a choice made for this brief. Revise it. Only then write code, following the revised plan exactly and deriving every color and type decision from it. diff --git a/.claude/skills/impeccable/reference/craft.md b/.claude/skills/impeccable/reference/craft.md index 2c7bd99b1..d0aa05b78 100644 --- a/.claude/skills/impeccable/reference/craft.md +++ b/.claude/skills/impeccable/reference/craft.md @@ -19,6 +19,8 @@ You must stop at every gate. **Shape confirmation alone is NOT a green light to When the harness lacks native image generation, gates 2-4 collapse into the brief itself, and shape confirmation does advance straight to code. +**Unattended runs.** When no user can respond (a one-shot task, an automated run, or an explicit instruction not to ask questions), every gate collapses into a decision you make yourself. Hold the same bar the gate would have held: state the shape brief, the visual direction, and the palette as decided (one line each, in your reasoning or the final summary), then proceed straight through to build and the visual iteration pass. Do not stop to wait, do not ask, and do not skip the direction thinking just because nobody will read the questions. + ## Step 0: Project Foundation Before shape, before code: figure out what kind of project you're working in. @@ -44,7 +46,7 @@ Default: Astro for brand briefs, the project's existing framework for product br Run /impeccable shape, passing along whatever feature description the user provided. Shape is **required** for craft; it is what produces a confirmed direction. -Present the shape output and stop. Wait for the user to confirm, override, or course-correct before writing code. +Present the shape output and stop. Wait for the user to confirm, override, or course-correct before writing code. On an unattended run, produce the compact shape output for yourself and continue without pausing. If the user already supplied a confirmed brief or ran shape separately, use it and skip this step. diff --git a/.claude/skills/impeccable/reference/shape.md b/.claude/skills/impeccable/reference/shape.md index c76d25812..23e286df5 100644 --- a/.claude/skills/impeccable/reference/shape.md +++ b/.claude/skills/impeccable/reference/shape.md @@ -12,6 +12,8 @@ Most AI-generated UIs fail not because of bad code, but because of skipped think **Do NOT write any code or make any design decisions during this phase.** Your only job is to understand the feature deeply enough to make excellent design decisions later. +**Unattended runs:** when no user can respond (a one-shot task, an automated run, or an explicit instruction not to ask questions), answer the interview questions yourself from the brief, record the answers as the design brief, and continue without pausing at any confirmation gate in this file. The thinking is still required; only the waiting is waived. + This is a required interaction, not optional guidance. Ask these questions in conversation, adapting based on answers. Don't dump them all at once; have a natural dialogue. STOP and call the AskUserQuestion tool to clarify. ### Interview cadence diff --git a/.cursor/skills/impeccable/SKILL.md b/.cursor/skills/impeccable/SKILL.md index 3012cde35..3a5d9531f 100644 --- a/.cursor/skills/impeccable/SKILL.md +++ b/.cursor/skills/impeccable/SKILL.md @@ -13,12 +13,12 @@ Approach every design task as the design lead at a small studio known for giving You MUST do these steps before proceeding: -1. Run `node .cursor/skills/impeccable/scripts/context.mjs` once per session; if the runtime shows this skill's loaded base directory, run `node /scripts/context.mjs` instead. Keep cwd/workdir at the user's project, not the skill directory. If the request names or implies a file, route, or app inside a monorepo, infer the concrete path and append `--target ` to the same command. If you've already seen its output in this conversation, do not re-run it. The script either prints the project's PRODUCT.md (and DESIGN.md when present) as a markdown block, or tells you it's missing. Follow whatever it prints. **If it reports `NO_PRODUCT_MD`:** divert into `reference/init.md` first when the user invoked `init`, `teach`, `craft`, or `shape`, or when their wording clearly maps to one of those from-scratch build flows (for example: "build/create/make a landing page", "design a new app", or "shape a feature"). Captured product context is the point of those flows. For any other command, a scoped evaluate / refine / enhance / fix / iterate request against existing code, do **not** divert into init. The existing code is the context: proceed with the requested command, infer the register from the surface in focus, and offer `/impeccable init` once as a suggestion the user can take later. A missing PRODUCT.md must never block a scoped request. If the output ends with an `UPDATE_AVAILABLE` directive, follow it (ask the user once about updating, then continue). It never blocks the current task. +1. Run `node .cursor/skills/impeccable/scripts/context.mjs` once per session; if the runtime shows this skill's loaded base directory, run `node /scripts/context.mjs` instead. Keep cwd/workdir at the user's project, not the skill directory. If the request names or implies a file, route, or app inside a monorepo, infer the concrete path and append `--target ` to the same command. If you've already seen its output in this conversation, do not re-run it. The script either prints the project's PRODUCT.md (and DESIGN.md when present) as a markdown block, or tells you it's missing. Follow whatever it prints. **If it reports `NO_PRODUCT_MD`:** divert into `reference/init.md` first when the user invoked `init`, `teach`, `craft`, or `shape`, or when their wording clearly maps to one of those from-scratch build flows (for example: "build/create/make a landing page", "design a new app", or "shape a feature"). Captured product context is the point of those flows. **Exception: when no user can respond** (an unattended or one-shot run, or the user said not to ask questions), skip the init interview: write your own one-paragraph understanding of the product, audience, and the page's job from the brief, then proceed with the flow. For any other command, a scoped evaluate / refine / enhance / fix / iterate request against existing code, do **not** divert into init. The existing code is the context: proceed with the requested command, infer the register from the surface in focus, and offer `/impeccable init` once as a suggestion the user can take later. A missing PRODUCT.md must never block a scoped request. If the output ends with an `UPDATE_AVAILABLE` directive, follow it (ask the user once about updating, then continue). It never blocks the current task. 2. If the user invoked a sub-command (`craft`, `shape`, `audit`, `polish`, ...), you MUST read the command's reference next: **`reference/.md`, or the native variant from the Commands table** (e.g. `reference/audit.native.md`) **when the project platform is native** (`ios` / `android` / `adaptive`, per the `context.mjs` directive). One file, not both. Non-optional. The reference defines the command's flow; without it you will skip steps the user expects. 3. Familiarize yourself with any existing design system, conventions, and components in the code. Read at least one project file (CSS / tokens / theme / a representative component or page). **Required even when you've loaded a sub-command reference in step 2.** Don't reinvent the wheel; use what's there when it works, branch out when the UX wins. 4. Identify the register. If the surface is marketing, a landing page, a campaign, long-form content, or a portfolio, design IS the product: the **brand register** applies (see Registers below). If it is app UI, admin, a dashboard, or a tool, design SERVES the product: the **product register** applies. Pick by first match: (1) task cue ("landing page" vs "dashboard"); (2) surface in focus; (3) `register` field in PRODUCT.md. For substantial brand or product work, `reference/brand.md` / `reference/product.md` carry extended depth worth reading; the essentials are inlined below either way. 5. **If PRODUCT.md's `## Platform` is `ios` or `android`**, also read `reference/.md` (HIG / Material 3 conventions). `adaptive` (cross-platform, ships both) reads both files. `web`, absent, or unrecognized: nothing extra to read. `context.mjs` prints the directive when one applies. -6. **If the project is brand-new (no existing CSS tokens / theme / committed brand colors found in step 3)**, run `node .cursor/skills/impeccable/scripts/palette.mjs` to receive a brand seed color and composition guidance. This is the anchor for your primary brand color. Compose the rest of the palette (bg, surface, ink, accent, muted) around it per the script's instructions. Use OKLCH throughout. **Skip this step only if step 3 found committed brand colors in existing tokens; in that case identity-preservation wins.** +6. **If the project is brand-new (no existing CSS tokens / theme / committed brand colors found in step 3)**, run `node .cursor/skills/impeccable/scripts/palette.mjs` to receive a brand seed color. The seed exists to break your reflex palette, not to override the subject: when the subject's own world clearly dictates color (an era, a place, a material, a medium), derive the palette from that world and use the seed only as a check on whether your choice was a reflex. When the subject leaves color open, adopt the seed as the anchor and compose the rest of the palette (bg, surface, ink, accent, muted) around it per the script's instructions. Use OKLCH throughout. **Skip this step only if step 3 found committed brand colors in existing tokens; in that case identity-preservation wins.** ## How to design @@ -42,7 +42,7 @@ If the brief doesn't pin down what the product or subject is, pin it yourself be Work in two passes, doing the thinking in your reasoning rather than narrating it. -First, plan a compact token system: **palette** (named values, composed around the seed from Setup step 6 when one was issued), **type** (faces and roles), **layout** (the structural concept in one sentence), and **signature**: the one element this page will be remembered by, drawn from the subject's world. Structure is part of the concept: the standard page skeleton is a default, not a given. Derive the page's frame, viewport treatment, and section rhythm from what the subject needs; when the concept calls for a different structure, take it. +First, plan a compact token system: **palette** (named values; Setup step 6's seed rule decides whether the seed or the subject's world anchors it), **type** (faces and roles), **layout** (the structural concept in one sentence), and **signature**: the one element this page will be remembered by, drawn from the subject's world. Structure is part of the concept: the standard page skeleton is a default, not a given. Derive the page's frame, viewport treatment, and section rhythm from what the subject needs; when the concept calls for a different structure, take it. Then audit the plan before building: work through what you would produce for a *similar* brief from another client. Wherever the two plans converge (same palette family, same face, same skeleton), that part is your generic default, not a choice made for this brief. Revise it. Only then write code, following the revised plan exactly and deriving every color and type decision from it. diff --git a/.cursor/skills/impeccable/reference/craft.md b/.cursor/skills/impeccable/reference/craft.md index 2c7bd99b1..d0aa05b78 100644 --- a/.cursor/skills/impeccable/reference/craft.md +++ b/.cursor/skills/impeccable/reference/craft.md @@ -19,6 +19,8 @@ You must stop at every gate. **Shape confirmation alone is NOT a green light to When the harness lacks native image generation, gates 2-4 collapse into the brief itself, and shape confirmation does advance straight to code. +**Unattended runs.** When no user can respond (a one-shot task, an automated run, or an explicit instruction not to ask questions), every gate collapses into a decision you make yourself. Hold the same bar the gate would have held: state the shape brief, the visual direction, and the palette as decided (one line each, in your reasoning or the final summary), then proceed straight through to build and the visual iteration pass. Do not stop to wait, do not ask, and do not skip the direction thinking just because nobody will read the questions. + ## Step 0: Project Foundation Before shape, before code: figure out what kind of project you're working in. @@ -44,7 +46,7 @@ Default: Astro for brand briefs, the project's existing framework for product br Run /impeccable shape, passing along whatever feature description the user provided. Shape is **required** for craft; it is what produces a confirmed direction. -Present the shape output and stop. Wait for the user to confirm, override, or course-correct before writing code. +Present the shape output and stop. Wait for the user to confirm, override, or course-correct before writing code. On an unattended run, produce the compact shape output for yourself and continue without pausing. If the user already supplied a confirmed brief or ran shape separately, use it and skip this step. diff --git a/.cursor/skills/impeccable/reference/shape.md b/.cursor/skills/impeccable/reference/shape.md index 592def8a7..40804f6e4 100644 --- a/.cursor/skills/impeccable/reference/shape.md +++ b/.cursor/skills/impeccable/reference/shape.md @@ -12,6 +12,8 @@ Most AI-generated UIs fail not because of bad code, but because of skipped think **Do NOT write any code or make any design decisions during this phase.** Your only job is to understand the feature deeply enough to make excellent design decisions later. +**Unattended runs:** when no user can respond (a one-shot task, an automated run, or an explicit instruction not to ask questions), answer the interview questions yourself from the brief, record the answers as the design brief, and continue without pausing at any confirmation gate in this file. The thinking is still required; only the waiting is waived. + This is a required interaction, not optional guidance. Ask these questions in conversation, adapting based on answers. Don't dump them all at once; have a natural dialogue. ask the user directly to clarify what you cannot infer. ### Interview cadence diff --git a/.gemini/skills/impeccable/SKILL.md b/.gemini/skills/impeccable/SKILL.md index ab1c9c8fa..9ffa9cb86 100644 --- a/.gemini/skills/impeccable/SKILL.md +++ b/.gemini/skills/impeccable/SKILL.md @@ -12,12 +12,12 @@ Approach every design task as the design lead at a small studio known for giving You MUST do these steps before proceeding: -1. Run `node .gemini/skills/impeccable/scripts/context.mjs` once per session; if the runtime shows this skill's loaded base directory, run `node /scripts/context.mjs` instead. Keep cwd/workdir at the user's project, not the skill directory. If the request names or implies a file, route, or app inside a monorepo, infer the concrete path and append `--target ` to the same command. If you've already seen its output in this conversation, do not re-run it. The script either prints the project's PRODUCT.md (and DESIGN.md when present) as a markdown block, or tells you it's missing. Follow whatever it prints. **If it reports `NO_PRODUCT_MD`:** divert into `reference/init.md` first when the user invoked `init`, `teach`, `craft`, or `shape`, or when their wording clearly maps to one of those from-scratch build flows (for example: "build/create/make a landing page", "design a new app", or "shape a feature"). Captured product context is the point of those flows. For any other command, a scoped evaluate / refine / enhance / fix / iterate request against existing code, do **not** divert into init. The existing code is the context: proceed with the requested command, infer the register from the surface in focus, and offer `/impeccable init` once as a suggestion the user can take later. A missing PRODUCT.md must never block a scoped request. If the output ends with an `UPDATE_AVAILABLE` directive, follow it (ask the user once about updating, then continue). It never blocks the current task. +1. Run `node .gemini/skills/impeccable/scripts/context.mjs` once per session; if the runtime shows this skill's loaded base directory, run `node /scripts/context.mjs` instead. Keep cwd/workdir at the user's project, not the skill directory. If the request names or implies a file, route, or app inside a monorepo, infer the concrete path and append `--target ` to the same command. If you've already seen its output in this conversation, do not re-run it. The script either prints the project's PRODUCT.md (and DESIGN.md when present) as a markdown block, or tells you it's missing. Follow whatever it prints. **If it reports `NO_PRODUCT_MD`:** divert into `reference/init.md` first when the user invoked `init`, `teach`, `craft`, or `shape`, or when their wording clearly maps to one of those from-scratch build flows (for example: "build/create/make a landing page", "design a new app", or "shape a feature"). Captured product context is the point of those flows. **Exception: when no user can respond** (an unattended or one-shot run, or the user said not to ask questions), skip the init interview: write your own one-paragraph understanding of the product, audience, and the page's job from the brief, then proceed with the flow. For any other command, a scoped evaluate / refine / enhance / fix / iterate request against existing code, do **not** divert into init. The existing code is the context: proceed with the requested command, infer the register from the surface in focus, and offer `/impeccable init` once as a suggestion the user can take later. A missing PRODUCT.md must never block a scoped request. If the output ends with an `UPDATE_AVAILABLE` directive, follow it (ask the user once about updating, then continue). It never blocks the current task. 2. If the user invoked a sub-command (`craft`, `shape`, `audit`, `polish`, ...), you MUST read the command's reference next: **`reference/.md`, or the native variant from the Commands table** (e.g. `reference/audit.native.md`) **when the project platform is native** (`ios` / `android` / `adaptive`, per the `context.mjs` directive). One file, not both. Non-optional. The reference defines the command's flow; without it you will skip steps the user expects. 3. Familiarize yourself with any existing design system, conventions, and components in the code. Read at least one project file (CSS / tokens / theme / a representative component or page). **Required even when you've loaded a sub-command reference in step 2.** Don't reinvent the wheel; use what's there when it works, branch out when the UX wins. 4. Identify the register. If the surface is marketing, a landing page, a campaign, long-form content, or a portfolio, design IS the product: the **brand register** applies (see Registers below). If it is app UI, admin, a dashboard, or a tool, design SERVES the product: the **product register** applies. Pick by first match: (1) task cue ("landing page" vs "dashboard"); (2) surface in focus; (3) `register` field in PRODUCT.md. For substantial brand or product work, `reference/brand.md` / `reference/product.md` carry extended depth worth reading; the essentials are inlined below either way. 5. **If PRODUCT.md's `## Platform` is `ios` or `android`**, also read `reference/.md` (HIG / Material 3 conventions). `adaptive` (cross-platform, ships both) reads both files. `web`, absent, or unrecognized: nothing extra to read. `context.mjs` prints the directive when one applies. -6. **If the project is brand-new (no existing CSS tokens / theme / committed brand colors found in step 3)**, run `node .gemini/skills/impeccable/scripts/palette.mjs` to receive a brand seed color and composition guidance. This is the anchor for your primary brand color. Compose the rest of the palette (bg, surface, ink, accent, muted) around it per the script's instructions. Use OKLCH throughout. **Skip this step only if step 3 found committed brand colors in existing tokens; in that case identity-preservation wins.** +6. **If the project is brand-new (no existing CSS tokens / theme / committed brand colors found in step 3)**, run `node .gemini/skills/impeccable/scripts/palette.mjs` to receive a brand seed color. The seed exists to break your reflex palette, not to override the subject: when the subject's own world clearly dictates color (an era, a place, a material, a medium), derive the palette from that world and use the seed only as a check on whether your choice was a reflex. When the subject leaves color open, adopt the seed as the anchor and compose the rest of the palette (bg, surface, ink, accent, muted) around it per the script's instructions. Use OKLCH throughout. **Skip this step only if step 3 found committed brand colors in existing tokens; in that case identity-preservation wins.** ## How to design @@ -41,7 +41,7 @@ If the brief doesn't pin down what the product or subject is, pin it yourself be Work in two passes, doing the thinking in your reasoning rather than narrating it. -First, plan a compact token system: **palette** (named values, composed around the seed from Setup step 6 when one was issued), **type** (faces and roles), **layout** (the structural concept in one sentence), and **signature**: the one element this page will be remembered by, drawn from the subject's world. Structure is part of the concept: the standard page skeleton is a default, not a given. Derive the page's frame, viewport treatment, and section rhythm from what the subject needs; when the concept calls for a different structure, take it. +First, plan a compact token system: **palette** (named values; Setup step 6's seed rule decides whether the seed or the subject's world anchors it), **type** (faces and roles), **layout** (the structural concept in one sentence), and **signature**: the one element this page will be remembered by, drawn from the subject's world. Structure is part of the concept: the standard page skeleton is a default, not a given. Derive the page's frame, viewport treatment, and section rhythm from what the subject needs; when the concept calls for a different structure, take it. Then audit the plan before building: work through what you would produce for a *similar* brief from another client. Wherever the two plans converge (same palette family, same face, same skeleton), that part is your generic default, not a choice made for this brief. Revise it. Only then write code, following the revised plan exactly and deriving every color and type decision from it. diff --git a/.gemini/skills/impeccable/reference/craft.md b/.gemini/skills/impeccable/reference/craft.md index 2c7bd99b1..d0aa05b78 100644 --- a/.gemini/skills/impeccable/reference/craft.md +++ b/.gemini/skills/impeccable/reference/craft.md @@ -19,6 +19,8 @@ You must stop at every gate. **Shape confirmation alone is NOT a green light to When the harness lacks native image generation, gates 2-4 collapse into the brief itself, and shape confirmation does advance straight to code. +**Unattended runs.** When no user can respond (a one-shot task, an automated run, or an explicit instruction not to ask questions), every gate collapses into a decision you make yourself. Hold the same bar the gate would have held: state the shape brief, the visual direction, and the palette as decided (one line each, in your reasoning or the final summary), then proceed straight through to build and the visual iteration pass. Do not stop to wait, do not ask, and do not skip the direction thinking just because nobody will read the questions. + ## Step 0: Project Foundation Before shape, before code: figure out what kind of project you're working in. @@ -44,7 +46,7 @@ Default: Astro for brand briefs, the project's existing framework for product br Run /impeccable shape, passing along whatever feature description the user provided. Shape is **required** for craft; it is what produces a confirmed direction. -Present the shape output and stop. Wait for the user to confirm, override, or course-correct before writing code. +Present the shape output and stop. Wait for the user to confirm, override, or course-correct before writing code. On an unattended run, produce the compact shape output for yourself and continue without pausing. If the user already supplied a confirmed brief or ran shape separately, use it and skip this step. diff --git a/.gemini/skills/impeccable/reference/shape.md b/.gemini/skills/impeccable/reference/shape.md index 592def8a7..40804f6e4 100644 --- a/.gemini/skills/impeccable/reference/shape.md +++ b/.gemini/skills/impeccable/reference/shape.md @@ -12,6 +12,8 @@ Most AI-generated UIs fail not because of bad code, but because of skipped think **Do NOT write any code or make any design decisions during this phase.** Your only job is to understand the feature deeply enough to make excellent design decisions later. +**Unattended runs:** when no user can respond (a one-shot task, an automated run, or an explicit instruction not to ask questions), answer the interview questions yourself from the brief, record the answers as the design brief, and continue without pausing at any confirmation gate in this file. The thinking is still required; only the waiting is waived. + This is a required interaction, not optional guidance. Ask these questions in conversation, adapting based on answers. Don't dump them all at once; have a natural dialogue. ask the user directly to clarify what you cannot infer. ### Interview cadence diff --git a/.github/skills/impeccable/SKILL.md b/.github/skills/impeccable/SKILL.md index e394f385b..c61ad7716 100644 --- a/.github/skills/impeccable/SKILL.md +++ b/.github/skills/impeccable/SKILL.md @@ -15,12 +15,12 @@ Approach every design task as the design lead at a small studio known for giving You MUST do these steps before proceeding: -1. Run `node .github/skills/impeccable/scripts/context.mjs` once per session; if the runtime shows this skill's loaded base directory, run `node /scripts/context.mjs` instead. Keep cwd/workdir at the user's project, not the skill directory. If the request names or implies a file, route, or app inside a monorepo, infer the concrete path and append `--target ` to the same command. If you've already seen its output in this conversation, do not re-run it. The script either prints the project's PRODUCT.md (and DESIGN.md when present) as a markdown block, or tells you it's missing. Follow whatever it prints. **If it reports `NO_PRODUCT_MD`:** divert into `reference/init.md` first when the user invoked `init`, `teach`, `craft`, or `shape`, or when their wording clearly maps to one of those from-scratch build flows (for example: "build/create/make a landing page", "design a new app", or "shape a feature"). Captured product context is the point of those flows. For any other command, a scoped evaluate / refine / enhance / fix / iterate request against existing code, do **not** divert into init. The existing code is the context: proceed with the requested command, infer the register from the surface in focus, and offer `/impeccable init` once as a suggestion the user can take later. A missing PRODUCT.md must never block a scoped request. If the output ends with an `UPDATE_AVAILABLE` directive, follow it (ask the user once about updating, then continue). It never blocks the current task. +1. Run `node .github/skills/impeccable/scripts/context.mjs` once per session; if the runtime shows this skill's loaded base directory, run `node /scripts/context.mjs` instead. Keep cwd/workdir at the user's project, not the skill directory. If the request names or implies a file, route, or app inside a monorepo, infer the concrete path and append `--target ` to the same command. If you've already seen its output in this conversation, do not re-run it. The script either prints the project's PRODUCT.md (and DESIGN.md when present) as a markdown block, or tells you it's missing. Follow whatever it prints. **If it reports `NO_PRODUCT_MD`:** divert into `reference/init.md` first when the user invoked `init`, `teach`, `craft`, or `shape`, or when their wording clearly maps to one of those from-scratch build flows (for example: "build/create/make a landing page", "design a new app", or "shape a feature"). Captured product context is the point of those flows. **Exception: when no user can respond** (an unattended or one-shot run, or the user said not to ask questions), skip the init interview: write your own one-paragraph understanding of the product, audience, and the page's job from the brief, then proceed with the flow. For any other command, a scoped evaluate / refine / enhance / fix / iterate request against existing code, do **not** divert into init. The existing code is the context: proceed with the requested command, infer the register from the surface in focus, and offer `/impeccable init` once as a suggestion the user can take later. A missing PRODUCT.md must never block a scoped request. If the output ends with an `UPDATE_AVAILABLE` directive, follow it (ask the user once about updating, then continue). It never blocks the current task. 2. If the user invoked a sub-command (`craft`, `shape`, `audit`, `polish`, ...), you MUST read the command's reference next: **`reference/.md`, or the native variant from the Commands table** (e.g. `reference/audit.native.md`) **when the project platform is native** (`ios` / `android` / `adaptive`, per the `context.mjs` directive). One file, not both. Non-optional. The reference defines the command's flow; without it you will skip steps the user expects. 3. Familiarize yourself with any existing design system, conventions, and components in the code. Read at least one project file (CSS / tokens / theme / a representative component or page). **Required even when you've loaded a sub-command reference in step 2.** Don't reinvent the wheel; use what's there when it works, branch out when the UX wins. 4. Identify the register. If the surface is marketing, a landing page, a campaign, long-form content, or a portfolio, design IS the product: the **brand register** applies (see Registers below). If it is app UI, admin, a dashboard, or a tool, design SERVES the product: the **product register** applies. Pick by first match: (1) task cue ("landing page" vs "dashboard"); (2) surface in focus; (3) `register` field in PRODUCT.md. For substantial brand or product work, `reference/brand.md` / `reference/product.md` carry extended depth worth reading; the essentials are inlined below either way. 5. **If PRODUCT.md's `## Platform` is `ios` or `android`**, also read `reference/.md` (HIG / Material 3 conventions). `adaptive` (cross-platform, ships both) reads both files. `web`, absent, or unrecognized: nothing extra to read. `context.mjs` prints the directive when one applies. -6. **If the project is brand-new (no existing CSS tokens / theme / committed brand colors found in step 3)**, run `node .github/skills/impeccable/scripts/palette.mjs` to receive a brand seed color and composition guidance. This is the anchor for your primary brand color. Compose the rest of the palette (bg, surface, ink, accent, muted) around it per the script's instructions. Use OKLCH throughout. **Skip this step only if step 3 found committed brand colors in existing tokens; in that case identity-preservation wins.** +6. **If the project is brand-new (no existing CSS tokens / theme / committed brand colors found in step 3)**, run `node .github/skills/impeccable/scripts/palette.mjs` to receive a brand seed color. The seed exists to break your reflex palette, not to override the subject: when the subject's own world clearly dictates color (an era, a place, a material, a medium), derive the palette from that world and use the seed only as a check on whether your choice was a reflex. When the subject leaves color open, adopt the seed as the anchor and compose the rest of the palette (bg, surface, ink, accent, muted) around it per the script's instructions. Use OKLCH throughout. **Skip this step only if step 3 found committed brand colors in existing tokens; in that case identity-preservation wins.** ## How to design @@ -44,7 +44,7 @@ If the brief doesn't pin down what the product or subject is, pin it yourself be Work in two passes, doing the thinking in your reasoning rather than narrating it. -First, plan a compact token system: **palette** (named values, composed around the seed from Setup step 6 when one was issued), **type** (faces and roles), **layout** (the structural concept in one sentence), and **signature**: the one element this page will be remembered by, drawn from the subject's world. Structure is part of the concept: the standard page skeleton is a default, not a given. Derive the page's frame, viewport treatment, and section rhythm from what the subject needs; when the concept calls for a different structure, take it. +First, plan a compact token system: **palette** (named values; Setup step 6's seed rule decides whether the seed or the subject's world anchors it), **type** (faces and roles), **layout** (the structural concept in one sentence), and **signature**: the one element this page will be remembered by, drawn from the subject's world. Structure is part of the concept: the standard page skeleton is a default, not a given. Derive the page's frame, viewport treatment, and section rhythm from what the subject needs; when the concept calls for a different structure, take it. Then audit the plan before building: work through what you would produce for a *similar* brief from another client. Wherever the two plans converge (same palette family, same face, same skeleton), that part is your generic default, not a choice made for this brief. Revise it. Only then write code, following the revised plan exactly and deriving every color and type decision from it. diff --git a/.github/skills/impeccable/reference/craft.md b/.github/skills/impeccable/reference/craft.md index 2c7bd99b1..d0aa05b78 100644 --- a/.github/skills/impeccable/reference/craft.md +++ b/.github/skills/impeccable/reference/craft.md @@ -19,6 +19,8 @@ You must stop at every gate. **Shape confirmation alone is NOT a green light to When the harness lacks native image generation, gates 2-4 collapse into the brief itself, and shape confirmation does advance straight to code. +**Unattended runs.** When no user can respond (a one-shot task, an automated run, or an explicit instruction not to ask questions), every gate collapses into a decision you make yourself. Hold the same bar the gate would have held: state the shape brief, the visual direction, and the palette as decided (one line each, in your reasoning or the final summary), then proceed straight through to build and the visual iteration pass. Do not stop to wait, do not ask, and do not skip the direction thinking just because nobody will read the questions. + ## Step 0: Project Foundation Before shape, before code: figure out what kind of project you're working in. @@ -44,7 +46,7 @@ Default: Astro for brand briefs, the project's existing framework for product br Run /impeccable shape, passing along whatever feature description the user provided. Shape is **required** for craft; it is what produces a confirmed direction. -Present the shape output and stop. Wait for the user to confirm, override, or course-correct before writing code. +Present the shape output and stop. Wait for the user to confirm, override, or course-correct before writing code. On an unattended run, produce the compact shape output for yourself and continue without pausing. If the user already supplied a confirmed brief or ran shape separately, use it and skip this step. diff --git a/.github/skills/impeccable/reference/shape.md b/.github/skills/impeccable/reference/shape.md index 592def8a7..40804f6e4 100644 --- a/.github/skills/impeccable/reference/shape.md +++ b/.github/skills/impeccable/reference/shape.md @@ -12,6 +12,8 @@ Most AI-generated UIs fail not because of bad code, but because of skipped think **Do NOT write any code or make any design decisions during this phase.** Your only job is to understand the feature deeply enough to make excellent design decisions later. +**Unattended runs:** when no user can respond (a one-shot task, an automated run, or an explicit instruction not to ask questions), answer the interview questions yourself from the brief, record the answers as the design brief, and continue without pausing at any confirmation gate in this file. The thinking is still required; only the waiting is waived. + This is a required interaction, not optional guidance. Ask these questions in conversation, adapting based on answers. Don't dump them all at once; have a natural dialogue. ask the user directly to clarify what you cannot infer. ### Interview cadence diff --git a/.kiro/skills/impeccable/SKILL.md b/.kiro/skills/impeccable/SKILL.md index 7c13744c4..b5b663ab2 100644 --- a/.kiro/skills/impeccable/SKILL.md +++ b/.kiro/skills/impeccable/SKILL.md @@ -13,12 +13,12 @@ Approach every design task as the design lead at a small studio known for giving You MUST do these steps before proceeding: -1. Run `node .kiro/skills/impeccable/scripts/context.mjs` once per session; if the runtime shows this skill's loaded base directory, run `node /scripts/context.mjs` instead. Keep cwd/workdir at the user's project, not the skill directory. If the request names or implies a file, route, or app inside a monorepo, infer the concrete path and append `--target ` to the same command. If you've already seen its output in this conversation, do not re-run it. The script either prints the project's PRODUCT.md (and DESIGN.md when present) as a markdown block, or tells you it's missing. Follow whatever it prints. **If it reports `NO_PRODUCT_MD`:** divert into `reference/init.md` first when the user invoked `init`, `teach`, `craft`, or `shape`, or when their wording clearly maps to one of those from-scratch build flows (for example: "build/create/make a landing page", "design a new app", or "shape a feature"). Captured product context is the point of those flows. For any other command, a scoped evaluate / refine / enhance / fix / iterate request against existing code, do **not** divert into init. The existing code is the context: proceed with the requested command, infer the register from the surface in focus, and offer `/impeccable init` once as a suggestion the user can take later. A missing PRODUCT.md must never block a scoped request. If the output ends with an `UPDATE_AVAILABLE` directive, follow it (ask the user once about updating, then continue). It never blocks the current task. +1. Run `node .kiro/skills/impeccable/scripts/context.mjs` once per session; if the runtime shows this skill's loaded base directory, run `node /scripts/context.mjs` instead. Keep cwd/workdir at the user's project, not the skill directory. If the request names or implies a file, route, or app inside a monorepo, infer the concrete path and append `--target ` to the same command. If you've already seen its output in this conversation, do not re-run it. The script either prints the project's PRODUCT.md (and DESIGN.md when present) as a markdown block, or tells you it's missing. Follow whatever it prints. **If it reports `NO_PRODUCT_MD`:** divert into `reference/init.md` first when the user invoked `init`, `teach`, `craft`, or `shape`, or when their wording clearly maps to one of those from-scratch build flows (for example: "build/create/make a landing page", "design a new app", or "shape a feature"). Captured product context is the point of those flows. **Exception: when no user can respond** (an unattended or one-shot run, or the user said not to ask questions), skip the init interview: write your own one-paragraph understanding of the product, audience, and the page's job from the brief, then proceed with the flow. For any other command, a scoped evaluate / refine / enhance / fix / iterate request against existing code, do **not** divert into init. The existing code is the context: proceed with the requested command, infer the register from the surface in focus, and offer `/impeccable init` once as a suggestion the user can take later. A missing PRODUCT.md must never block a scoped request. If the output ends with an `UPDATE_AVAILABLE` directive, follow it (ask the user once about updating, then continue). It never blocks the current task. 2. If the user invoked a sub-command (`craft`, `shape`, `audit`, `polish`, ...), you MUST read the command's reference next: **`reference/.md`, or the native variant from the Commands table** (e.g. `reference/audit.native.md`) **when the project platform is native** (`ios` / `android` / `adaptive`, per the `context.mjs` directive). One file, not both. Non-optional. The reference defines the command's flow; without it you will skip steps the user expects. 3. Familiarize yourself with any existing design system, conventions, and components in the code. Read at least one project file (CSS / tokens / theme / a representative component or page). **Required even when you've loaded a sub-command reference in step 2.** Don't reinvent the wheel; use what's there when it works, branch out when the UX wins. 4. Identify the register. If the surface is marketing, a landing page, a campaign, long-form content, or a portfolio, design IS the product: the **brand register** applies (see Registers below). If it is app UI, admin, a dashboard, or a tool, design SERVES the product: the **product register** applies. Pick by first match: (1) task cue ("landing page" vs "dashboard"); (2) surface in focus; (3) `register` field in PRODUCT.md. For substantial brand or product work, `reference/brand.md` / `reference/product.md` carry extended depth worth reading; the essentials are inlined below either way. 5. **If PRODUCT.md's `## Platform` is `ios` or `android`**, also read `reference/.md` (HIG / Material 3 conventions). `adaptive` (cross-platform, ships both) reads both files. `web`, absent, or unrecognized: nothing extra to read. `context.mjs` prints the directive when one applies. -6. **If the project is brand-new (no existing CSS tokens / theme / committed brand colors found in step 3)**, run `node .kiro/skills/impeccable/scripts/palette.mjs` to receive a brand seed color and composition guidance. This is the anchor for your primary brand color. Compose the rest of the palette (bg, surface, ink, accent, muted) around it per the script's instructions. Use OKLCH throughout. **Skip this step only if step 3 found committed brand colors in existing tokens; in that case identity-preservation wins.** +6. **If the project is brand-new (no existing CSS tokens / theme / committed brand colors found in step 3)**, run `node .kiro/skills/impeccable/scripts/palette.mjs` to receive a brand seed color. The seed exists to break your reflex palette, not to override the subject: when the subject's own world clearly dictates color (an era, a place, a material, a medium), derive the palette from that world and use the seed only as a check on whether your choice was a reflex. When the subject leaves color open, adopt the seed as the anchor and compose the rest of the palette (bg, surface, ink, accent, muted) around it per the script's instructions. Use OKLCH throughout. **Skip this step only if step 3 found committed brand colors in existing tokens; in that case identity-preservation wins.** ## How to design @@ -42,7 +42,7 @@ If the brief doesn't pin down what the product or subject is, pin it yourself be Work in two passes, doing the thinking in your reasoning rather than narrating it. -First, plan a compact token system: **palette** (named values, composed around the seed from Setup step 6 when one was issued), **type** (faces and roles), **layout** (the structural concept in one sentence), and **signature**: the one element this page will be remembered by, drawn from the subject's world. Structure is part of the concept: the standard page skeleton is a default, not a given. Derive the page's frame, viewport treatment, and section rhythm from what the subject needs; when the concept calls for a different structure, take it. +First, plan a compact token system: **palette** (named values; Setup step 6's seed rule decides whether the seed or the subject's world anchors it), **type** (faces and roles), **layout** (the structural concept in one sentence), and **signature**: the one element this page will be remembered by, drawn from the subject's world. Structure is part of the concept: the standard page skeleton is a default, not a given. Derive the page's frame, viewport treatment, and section rhythm from what the subject needs; when the concept calls for a different structure, take it. Then audit the plan before building: work through what you would produce for a *similar* brief from another client. Wherever the two plans converge (same palette family, same face, same skeleton), that part is your generic default, not a choice made for this brief. Revise it. Only then write code, following the revised plan exactly and deriving every color and type decision from it. diff --git a/.kiro/skills/impeccable/reference/craft.md b/.kiro/skills/impeccable/reference/craft.md index 2c7bd99b1..d0aa05b78 100644 --- a/.kiro/skills/impeccable/reference/craft.md +++ b/.kiro/skills/impeccable/reference/craft.md @@ -19,6 +19,8 @@ You must stop at every gate. **Shape confirmation alone is NOT a green light to When the harness lacks native image generation, gates 2-4 collapse into the brief itself, and shape confirmation does advance straight to code. +**Unattended runs.** When no user can respond (a one-shot task, an automated run, or an explicit instruction not to ask questions), every gate collapses into a decision you make yourself. Hold the same bar the gate would have held: state the shape brief, the visual direction, and the palette as decided (one line each, in your reasoning or the final summary), then proceed straight through to build and the visual iteration pass. Do not stop to wait, do not ask, and do not skip the direction thinking just because nobody will read the questions. + ## Step 0: Project Foundation Before shape, before code: figure out what kind of project you're working in. @@ -44,7 +46,7 @@ Default: Astro for brand briefs, the project's existing framework for product br Run /impeccable shape, passing along whatever feature description the user provided. Shape is **required** for craft; it is what produces a confirmed direction. -Present the shape output and stop. Wait for the user to confirm, override, or course-correct before writing code. +Present the shape output and stop. Wait for the user to confirm, override, or course-correct before writing code. On an unattended run, produce the compact shape output for yourself and continue without pausing. If the user already supplied a confirmed brief or ran shape separately, use it and skip this step. diff --git a/.kiro/skills/impeccable/reference/shape.md b/.kiro/skills/impeccable/reference/shape.md index 592def8a7..40804f6e4 100644 --- a/.kiro/skills/impeccable/reference/shape.md +++ b/.kiro/skills/impeccable/reference/shape.md @@ -12,6 +12,8 @@ Most AI-generated UIs fail not because of bad code, but because of skipped think **Do NOT write any code or make any design decisions during this phase.** Your only job is to understand the feature deeply enough to make excellent design decisions later. +**Unattended runs:** when no user can respond (a one-shot task, an automated run, or an explicit instruction not to ask questions), answer the interview questions yourself from the brief, record the answers as the design brief, and continue without pausing at any confirmation gate in this file. The thinking is still required; only the waiting is waived. + This is a required interaction, not optional guidance. Ask these questions in conversation, adapting based on answers. Don't dump them all at once; have a natural dialogue. ask the user directly to clarify what you cannot infer. ### Interview cadence diff --git a/.opencode/skills/impeccable/SKILL.md b/.opencode/skills/impeccable/SKILL.md index 3ecf783fd..7230a1c33 100644 --- a/.opencode/skills/impeccable/SKILL.md +++ b/.opencode/skills/impeccable/SKILL.md @@ -18,12 +18,12 @@ Approach every design task as the design lead at a small studio known for giving You MUST do these steps before proceeding: -1. Run `node .opencode/skills/impeccable/scripts/context.mjs` once per session; if the runtime shows this skill's loaded base directory, run `node /scripts/context.mjs` instead. Keep cwd/workdir at the user's project, not the skill directory. If the request names or implies a file, route, or app inside a monorepo, infer the concrete path and append `--target ` to the same command. If you've already seen its output in this conversation, do not re-run it. The script either prints the project's PRODUCT.md (and DESIGN.md when present) as a markdown block, or tells you it's missing. Follow whatever it prints. **If it reports `NO_PRODUCT_MD`:** divert into `reference/init.md` first when the user invoked `init`, `teach`, `craft`, or `shape`, or when their wording clearly maps to one of those from-scratch build flows (for example: "build/create/make a landing page", "design a new app", or "shape a feature"). Captured product context is the point of those flows. For any other command, a scoped evaluate / refine / enhance / fix / iterate request against existing code, do **not** divert into init. The existing code is the context: proceed with the requested command, infer the register from the surface in focus, and offer `/impeccable init` once as a suggestion the user can take later. A missing PRODUCT.md must never block a scoped request. If the output ends with an `UPDATE_AVAILABLE` directive, follow it (ask the user once about updating, then continue). It never blocks the current task. +1. Run `node .opencode/skills/impeccable/scripts/context.mjs` once per session; if the runtime shows this skill's loaded base directory, run `node /scripts/context.mjs` instead. Keep cwd/workdir at the user's project, not the skill directory. If the request names or implies a file, route, or app inside a monorepo, infer the concrete path and append `--target ` to the same command. If you've already seen its output in this conversation, do not re-run it. The script either prints the project's PRODUCT.md (and DESIGN.md when present) as a markdown block, or tells you it's missing. Follow whatever it prints. **If it reports `NO_PRODUCT_MD`:** divert into `reference/init.md` first when the user invoked `init`, `teach`, `craft`, or `shape`, or when their wording clearly maps to one of those from-scratch build flows (for example: "build/create/make a landing page", "design a new app", or "shape a feature"). Captured product context is the point of those flows. **Exception: when no user can respond** (an unattended or one-shot run, or the user said not to ask questions), skip the init interview: write your own one-paragraph understanding of the product, audience, and the page's job from the brief, then proceed with the flow. For any other command, a scoped evaluate / refine / enhance / fix / iterate request against existing code, do **not** divert into init. The existing code is the context: proceed with the requested command, infer the register from the surface in focus, and offer `/impeccable init` once as a suggestion the user can take later. A missing PRODUCT.md must never block a scoped request. If the output ends with an `UPDATE_AVAILABLE` directive, follow it (ask the user once about updating, then continue). It never blocks the current task. 2. If the user invoked a sub-command (`craft`, `shape`, `audit`, `polish`, ...), you MUST read the command's reference next: **`reference/.md`, or the native variant from the Commands table** (e.g. `reference/audit.native.md`) **when the project platform is native** (`ios` / `android` / `adaptive`, per the `context.mjs` directive). One file, not both. Non-optional. The reference defines the command's flow; without it you will skip steps the user expects. 3. Familiarize yourself with any existing design system, conventions, and components in the code. Read at least one project file (CSS / tokens / theme / a representative component or page). **Required even when you've loaded a sub-command reference in step 2.** Don't reinvent the wheel; use what's there when it works, branch out when the UX wins. 4. Identify the register. If the surface is marketing, a landing page, a campaign, long-form content, or a portfolio, design IS the product: the **brand register** applies (see Registers below). If it is app UI, admin, a dashboard, or a tool, design SERVES the product: the **product register** applies. Pick by first match: (1) task cue ("landing page" vs "dashboard"); (2) surface in focus; (3) `register` field in PRODUCT.md. For substantial brand or product work, `reference/brand.md` / `reference/product.md` carry extended depth worth reading; the essentials are inlined below either way. 5. **If PRODUCT.md's `## Platform` is `ios` or `android`**, also read `reference/.md` (HIG / Material 3 conventions). `adaptive` (cross-platform, ships both) reads both files. `web`, absent, or unrecognized: nothing extra to read. `context.mjs` prints the directive when one applies. -6. **If the project is brand-new (no existing CSS tokens / theme / committed brand colors found in step 3)**, run `node .opencode/skills/impeccable/scripts/palette.mjs` to receive a brand seed color and composition guidance. This is the anchor for your primary brand color. Compose the rest of the palette (bg, surface, ink, accent, muted) around it per the script's instructions. Use OKLCH throughout. **Skip this step only if step 3 found committed brand colors in existing tokens; in that case identity-preservation wins.** +6. **If the project is brand-new (no existing CSS tokens / theme / committed brand colors found in step 3)**, run `node .opencode/skills/impeccable/scripts/palette.mjs` to receive a brand seed color. The seed exists to break your reflex palette, not to override the subject: when the subject's own world clearly dictates color (an era, a place, a material, a medium), derive the palette from that world and use the seed only as a check on whether your choice was a reflex. When the subject leaves color open, adopt the seed as the anchor and compose the rest of the palette (bg, surface, ink, accent, muted) around it per the script's instructions. Use OKLCH throughout. **Skip this step only if step 3 found committed brand colors in existing tokens; in that case identity-preservation wins.** ## How to design @@ -47,7 +47,7 @@ If the brief doesn't pin down what the product or subject is, pin it yourself be Work in two passes, doing the thinking in your reasoning rather than narrating it. -First, plan a compact token system: **palette** (named values, composed around the seed from Setup step 6 when one was issued), **type** (faces and roles), **layout** (the structural concept in one sentence), and **signature**: the one element this page will be remembered by, drawn from the subject's world. Structure is part of the concept: the standard page skeleton is a default, not a given. Derive the page's frame, viewport treatment, and section rhythm from what the subject needs; when the concept calls for a different structure, take it. +First, plan a compact token system: **palette** (named values; Setup step 6's seed rule decides whether the seed or the subject's world anchors it), **type** (faces and roles), **layout** (the structural concept in one sentence), and **signature**: the one element this page will be remembered by, drawn from the subject's world. Structure is part of the concept: the standard page skeleton is a default, not a given. Derive the page's frame, viewport treatment, and section rhythm from what the subject needs; when the concept calls for a different structure, take it. Then audit the plan before building: work through what you would produce for a *similar* brief from another client. Wherever the two plans converge (same palette family, same face, same skeleton), that part is your generic default, not a choice made for this brief. Revise it. Only then write code, following the revised plan exactly and deriving every color and type decision from it. diff --git a/.opencode/skills/impeccable/reference/craft.md b/.opencode/skills/impeccable/reference/craft.md index 2c7bd99b1..d0aa05b78 100644 --- a/.opencode/skills/impeccable/reference/craft.md +++ b/.opencode/skills/impeccable/reference/craft.md @@ -19,6 +19,8 @@ You must stop at every gate. **Shape confirmation alone is NOT a green light to When the harness lacks native image generation, gates 2-4 collapse into the brief itself, and shape confirmation does advance straight to code. +**Unattended runs.** When no user can respond (a one-shot task, an automated run, or an explicit instruction not to ask questions), every gate collapses into a decision you make yourself. Hold the same bar the gate would have held: state the shape brief, the visual direction, and the palette as decided (one line each, in your reasoning or the final summary), then proceed straight through to build and the visual iteration pass. Do not stop to wait, do not ask, and do not skip the direction thinking just because nobody will read the questions. + ## Step 0: Project Foundation Before shape, before code: figure out what kind of project you're working in. @@ -44,7 +46,7 @@ Default: Astro for brand briefs, the project's existing framework for product br Run /impeccable shape, passing along whatever feature description the user provided. Shape is **required** for craft; it is what produces a confirmed direction. -Present the shape output and stop. Wait for the user to confirm, override, or course-correct before writing code. +Present the shape output and stop. Wait for the user to confirm, override, or course-correct before writing code. On an unattended run, produce the compact shape output for yourself and continue without pausing. If the user already supplied a confirmed brief or ran shape separately, use it and skip this step. diff --git a/.opencode/skills/impeccable/reference/shape.md b/.opencode/skills/impeccable/reference/shape.md index 5c3519269..9990ca153 100644 --- a/.opencode/skills/impeccable/reference/shape.md +++ b/.opencode/skills/impeccable/reference/shape.md @@ -12,6 +12,8 @@ Most AI-generated UIs fail not because of bad code, but because of skipped think **Do NOT write any code or make any design decisions during this phase.** Your only job is to understand the feature deeply enough to make excellent design decisions later. +**Unattended runs:** when no user can respond (a one-shot task, an automated run, or an explicit instruction not to ask questions), answer the interview questions yourself from the brief, record the answers as the design brief, and continue without pausing at any confirmation gate in this file. The thinking is still required; only the waiting is waived. + This is a required interaction, not optional guidance. Ask these questions in conversation, adapting based on answers. Don't dump them all at once; have a natural dialogue. STOP and call the `question` tool to clarify. ### Interview cadence diff --git a/.pi/skills/impeccable/SKILL.md b/.pi/skills/impeccable/SKILL.md index dd7c59f66..e1879a0e5 100644 --- a/.pi/skills/impeccable/SKILL.md +++ b/.pi/skills/impeccable/SKILL.md @@ -16,12 +16,12 @@ Approach every design task as the design lead at a small studio known for giving You MUST do these steps before proceeding: -1. Run `node .pi/skills/impeccable/scripts/context.mjs` once per session; if the runtime shows this skill's loaded base directory, run `node /scripts/context.mjs` instead. Keep cwd/workdir at the user's project, not the skill directory. If the request names or implies a file, route, or app inside a monorepo, infer the concrete path and append `--target ` to the same command. If you've already seen its output in this conversation, do not re-run it. The script either prints the project's PRODUCT.md (and DESIGN.md when present) as a markdown block, or tells you it's missing. Follow whatever it prints. **If it reports `NO_PRODUCT_MD`:** divert into `reference/init.md` first when the user invoked `init`, `teach`, `craft`, or `shape`, or when their wording clearly maps to one of those from-scratch build flows (for example: "build/create/make a landing page", "design a new app", or "shape a feature"). Captured product context is the point of those flows. For any other command, a scoped evaluate / refine / enhance / fix / iterate request against existing code, do **not** divert into init. The existing code is the context: proceed with the requested command, infer the register from the surface in focus, and offer `/impeccable init` once as a suggestion the user can take later. A missing PRODUCT.md must never block a scoped request. If the output ends with an `UPDATE_AVAILABLE` directive, follow it (ask the user once about updating, then continue). It never blocks the current task. +1. Run `node .pi/skills/impeccable/scripts/context.mjs` once per session; if the runtime shows this skill's loaded base directory, run `node /scripts/context.mjs` instead. Keep cwd/workdir at the user's project, not the skill directory. If the request names or implies a file, route, or app inside a monorepo, infer the concrete path and append `--target ` to the same command. If you've already seen its output in this conversation, do not re-run it. The script either prints the project's PRODUCT.md (and DESIGN.md when present) as a markdown block, or tells you it's missing. Follow whatever it prints. **If it reports `NO_PRODUCT_MD`:** divert into `reference/init.md` first when the user invoked `init`, `teach`, `craft`, or `shape`, or when their wording clearly maps to one of those from-scratch build flows (for example: "build/create/make a landing page", "design a new app", or "shape a feature"). Captured product context is the point of those flows. **Exception: when no user can respond** (an unattended or one-shot run, or the user said not to ask questions), skip the init interview: write your own one-paragraph understanding of the product, audience, and the page's job from the brief, then proceed with the flow. For any other command, a scoped evaluate / refine / enhance / fix / iterate request against existing code, do **not** divert into init. The existing code is the context: proceed with the requested command, infer the register from the surface in focus, and offer `/impeccable init` once as a suggestion the user can take later. A missing PRODUCT.md must never block a scoped request. If the output ends with an `UPDATE_AVAILABLE` directive, follow it (ask the user once about updating, then continue). It never blocks the current task. 2. If the user invoked a sub-command (`craft`, `shape`, `audit`, `polish`, ...), you MUST read the command's reference next: **`reference/.md`, or the native variant from the Commands table** (e.g. `reference/audit.native.md`) **when the project platform is native** (`ios` / `android` / `adaptive`, per the `context.mjs` directive). One file, not both. Non-optional. The reference defines the command's flow; without it you will skip steps the user expects. 3. Familiarize yourself with any existing design system, conventions, and components in the code. Read at least one project file (CSS / tokens / theme / a representative component or page). **Required even when you've loaded a sub-command reference in step 2.** Don't reinvent the wheel; use what's there when it works, branch out when the UX wins. 4. Identify the register. If the surface is marketing, a landing page, a campaign, long-form content, or a portfolio, design IS the product: the **brand register** applies (see Registers below). If it is app UI, admin, a dashboard, or a tool, design SERVES the product: the **product register** applies. Pick by first match: (1) task cue ("landing page" vs "dashboard"); (2) surface in focus; (3) `register` field in PRODUCT.md. For substantial brand or product work, `reference/brand.md` / `reference/product.md` carry extended depth worth reading; the essentials are inlined below either way. 5. **If PRODUCT.md's `## Platform` is `ios` or `android`**, also read `reference/.md` (HIG / Material 3 conventions). `adaptive` (cross-platform, ships both) reads both files. `web`, absent, or unrecognized: nothing extra to read. `context.mjs` prints the directive when one applies. -6. **If the project is brand-new (no existing CSS tokens / theme / committed brand colors found in step 3)**, run `node .pi/skills/impeccable/scripts/palette.mjs` to receive a brand seed color and composition guidance. This is the anchor for your primary brand color. Compose the rest of the palette (bg, surface, ink, accent, muted) around it per the script's instructions. Use OKLCH throughout. **Skip this step only if step 3 found committed brand colors in existing tokens; in that case identity-preservation wins.** +6. **If the project is brand-new (no existing CSS tokens / theme / committed brand colors found in step 3)**, run `node .pi/skills/impeccable/scripts/palette.mjs` to receive a brand seed color. The seed exists to break your reflex palette, not to override the subject: when the subject's own world clearly dictates color (an era, a place, a material, a medium), derive the palette from that world and use the seed only as a check on whether your choice was a reflex. When the subject leaves color open, adopt the seed as the anchor and compose the rest of the palette (bg, surface, ink, accent, muted) around it per the script's instructions. Use OKLCH throughout. **Skip this step only if step 3 found committed brand colors in existing tokens; in that case identity-preservation wins.** ## How to design @@ -45,7 +45,7 @@ If the brief doesn't pin down what the product or subject is, pin it yourself be Work in two passes, doing the thinking in your reasoning rather than narrating it. -First, plan a compact token system: **palette** (named values, composed around the seed from Setup step 6 when one was issued), **type** (faces and roles), **layout** (the structural concept in one sentence), and **signature**: the one element this page will be remembered by, drawn from the subject's world. Structure is part of the concept: the standard page skeleton is a default, not a given. Derive the page's frame, viewport treatment, and section rhythm from what the subject needs; when the concept calls for a different structure, take it. +First, plan a compact token system: **palette** (named values; Setup step 6's seed rule decides whether the seed or the subject's world anchors it), **type** (faces and roles), **layout** (the structural concept in one sentence), and **signature**: the one element this page will be remembered by, drawn from the subject's world. Structure is part of the concept: the standard page skeleton is a default, not a given. Derive the page's frame, viewport treatment, and section rhythm from what the subject needs; when the concept calls for a different structure, take it. Then audit the plan before building: work through what you would produce for a *similar* brief from another client. Wherever the two plans converge (same palette family, same face, same skeleton), that part is your generic default, not a choice made for this brief. Revise it. Only then write code, following the revised plan exactly and deriving every color and type decision from it. diff --git a/.pi/skills/impeccable/reference/craft.md b/.pi/skills/impeccable/reference/craft.md index 2c7bd99b1..d0aa05b78 100644 --- a/.pi/skills/impeccable/reference/craft.md +++ b/.pi/skills/impeccable/reference/craft.md @@ -19,6 +19,8 @@ You must stop at every gate. **Shape confirmation alone is NOT a green light to When the harness lacks native image generation, gates 2-4 collapse into the brief itself, and shape confirmation does advance straight to code. +**Unattended runs.** When no user can respond (a one-shot task, an automated run, or an explicit instruction not to ask questions), every gate collapses into a decision you make yourself. Hold the same bar the gate would have held: state the shape brief, the visual direction, and the palette as decided (one line each, in your reasoning or the final summary), then proceed straight through to build and the visual iteration pass. Do not stop to wait, do not ask, and do not skip the direction thinking just because nobody will read the questions. + ## Step 0: Project Foundation Before shape, before code: figure out what kind of project you're working in. @@ -44,7 +46,7 @@ Default: Astro for brand briefs, the project's existing framework for product br Run /impeccable shape, passing along whatever feature description the user provided. Shape is **required** for craft; it is what produces a confirmed direction. -Present the shape output and stop. Wait for the user to confirm, override, or course-correct before writing code. +Present the shape output and stop. Wait for the user to confirm, override, or course-correct before writing code. On an unattended run, produce the compact shape output for yourself and continue without pausing. If the user already supplied a confirmed brief or ran shape separately, use it and skip this step. diff --git a/.pi/skills/impeccable/reference/shape.md b/.pi/skills/impeccable/reference/shape.md index 592def8a7..40804f6e4 100644 --- a/.pi/skills/impeccable/reference/shape.md +++ b/.pi/skills/impeccable/reference/shape.md @@ -12,6 +12,8 @@ Most AI-generated UIs fail not because of bad code, but because of skipped think **Do NOT write any code or make any design decisions during this phase.** Your only job is to understand the feature deeply enough to make excellent design decisions later. +**Unattended runs:** when no user can respond (a one-shot task, an automated run, or an explicit instruction not to ask questions), answer the interview questions yourself from the brief, record the answers as the design brief, and continue without pausing at any confirmation gate in this file. The thinking is still required; only the waiting is waived. + This is a required interaction, not optional guidance. Ask these questions in conversation, adapting based on answers. Don't dump them all at once; have a natural dialogue. ask the user directly to clarify what you cannot infer. ### Interview cadence diff --git a/.qoder/skills/impeccable/SKILL.md b/.qoder/skills/impeccable/SKILL.md index 025eec09b..7f4709e05 100644 --- a/.qoder/skills/impeccable/SKILL.md +++ b/.qoder/skills/impeccable/SKILL.md @@ -18,12 +18,12 @@ Approach every design task as the design lead at a small studio known for giving You MUST do these steps before proceeding: -1. Run `node .qoder/skills/impeccable/scripts/context.mjs` once per session; if the runtime shows this skill's loaded base directory, run `node /scripts/context.mjs` instead. Keep cwd/workdir at the user's project, not the skill directory. If the request names or implies a file, route, or app inside a monorepo, infer the concrete path and append `--target ` to the same command. If you've already seen its output in this conversation, do not re-run it. The script either prints the project's PRODUCT.md (and DESIGN.md when present) as a markdown block, or tells you it's missing. Follow whatever it prints. **If it reports `NO_PRODUCT_MD`:** divert into `reference/init.md` first when the user invoked `init`, `teach`, `craft`, or `shape`, or when their wording clearly maps to one of those from-scratch build flows (for example: "build/create/make a landing page", "design a new app", or "shape a feature"). Captured product context is the point of those flows. For any other command, a scoped evaluate / refine / enhance / fix / iterate request against existing code, do **not** divert into init. The existing code is the context: proceed with the requested command, infer the register from the surface in focus, and offer `/impeccable init` once as a suggestion the user can take later. A missing PRODUCT.md must never block a scoped request. If the output ends with an `UPDATE_AVAILABLE` directive, follow it (ask the user once about updating, then continue). It never blocks the current task. +1. Run `node .qoder/skills/impeccable/scripts/context.mjs` once per session; if the runtime shows this skill's loaded base directory, run `node /scripts/context.mjs` instead. Keep cwd/workdir at the user's project, not the skill directory. If the request names or implies a file, route, or app inside a monorepo, infer the concrete path and append `--target ` to the same command. If you've already seen its output in this conversation, do not re-run it. The script either prints the project's PRODUCT.md (and DESIGN.md when present) as a markdown block, or tells you it's missing. Follow whatever it prints. **If it reports `NO_PRODUCT_MD`:** divert into `reference/init.md` first when the user invoked `init`, `teach`, `craft`, or `shape`, or when their wording clearly maps to one of those from-scratch build flows (for example: "build/create/make a landing page", "design a new app", or "shape a feature"). Captured product context is the point of those flows. **Exception: when no user can respond** (an unattended or one-shot run, or the user said not to ask questions), skip the init interview: write your own one-paragraph understanding of the product, audience, and the page's job from the brief, then proceed with the flow. For any other command, a scoped evaluate / refine / enhance / fix / iterate request against existing code, do **not** divert into init. The existing code is the context: proceed with the requested command, infer the register from the surface in focus, and offer `/impeccable init` once as a suggestion the user can take later. A missing PRODUCT.md must never block a scoped request. If the output ends with an `UPDATE_AVAILABLE` directive, follow it (ask the user once about updating, then continue). It never blocks the current task. 2. If the user invoked a sub-command (`craft`, `shape`, `audit`, `polish`, ...), you MUST read the command's reference next: **`reference/.md`, or the native variant from the Commands table** (e.g. `reference/audit.native.md`) **when the project platform is native** (`ios` / `android` / `adaptive`, per the `context.mjs` directive). One file, not both. Non-optional. The reference defines the command's flow; without it you will skip steps the user expects. 3. Familiarize yourself with any existing design system, conventions, and components in the code. Read at least one project file (CSS / tokens / theme / a representative component or page). **Required even when you've loaded a sub-command reference in step 2.** Don't reinvent the wheel; use what's there when it works, branch out when the UX wins. 4. Identify the register. If the surface is marketing, a landing page, a campaign, long-form content, or a portfolio, design IS the product: the **brand register** applies (see Registers below). If it is app UI, admin, a dashboard, or a tool, design SERVES the product: the **product register** applies. Pick by first match: (1) task cue ("landing page" vs "dashboard"); (2) surface in focus; (3) `register` field in PRODUCT.md. For substantial brand or product work, `reference/brand.md` / `reference/product.md` carry extended depth worth reading; the essentials are inlined below either way. 5. **If PRODUCT.md's `## Platform` is `ios` or `android`**, also read `reference/.md` (HIG / Material 3 conventions). `adaptive` (cross-platform, ships both) reads both files. `web`, absent, or unrecognized: nothing extra to read. `context.mjs` prints the directive when one applies. -6. **If the project is brand-new (no existing CSS tokens / theme / committed brand colors found in step 3)**, run `node .qoder/skills/impeccable/scripts/palette.mjs` to receive a brand seed color and composition guidance. This is the anchor for your primary brand color. Compose the rest of the palette (bg, surface, ink, accent, muted) around it per the script's instructions. Use OKLCH throughout. **Skip this step only if step 3 found committed brand colors in existing tokens; in that case identity-preservation wins.** +6. **If the project is brand-new (no existing CSS tokens / theme / committed brand colors found in step 3)**, run `node .qoder/skills/impeccable/scripts/palette.mjs` to receive a brand seed color. The seed exists to break your reflex palette, not to override the subject: when the subject's own world clearly dictates color (an era, a place, a material, a medium), derive the palette from that world and use the seed only as a check on whether your choice was a reflex. When the subject leaves color open, adopt the seed as the anchor and compose the rest of the palette (bg, surface, ink, accent, muted) around it per the script's instructions. Use OKLCH throughout. **Skip this step only if step 3 found committed brand colors in existing tokens; in that case identity-preservation wins.** ## How to design @@ -47,7 +47,7 @@ If the brief doesn't pin down what the product or subject is, pin it yourself be Work in two passes, doing the thinking in your reasoning rather than narrating it. -First, plan a compact token system: **palette** (named values, composed around the seed from Setup step 6 when one was issued), **type** (faces and roles), **layout** (the structural concept in one sentence), and **signature**: the one element this page will be remembered by, drawn from the subject's world. Structure is part of the concept: the standard page skeleton is a default, not a given. Derive the page's frame, viewport treatment, and section rhythm from what the subject needs; when the concept calls for a different structure, take it. +First, plan a compact token system: **palette** (named values; Setup step 6's seed rule decides whether the seed or the subject's world anchors it), **type** (faces and roles), **layout** (the structural concept in one sentence), and **signature**: the one element this page will be remembered by, drawn from the subject's world. Structure is part of the concept: the standard page skeleton is a default, not a given. Derive the page's frame, viewport treatment, and section rhythm from what the subject needs; when the concept calls for a different structure, take it. Then audit the plan before building: work through what you would produce for a *similar* brief from another client. Wherever the two plans converge (same palette family, same face, same skeleton), that part is your generic default, not a choice made for this brief. Revise it. Only then write code, following the revised plan exactly and deriving every color and type decision from it. diff --git a/.qoder/skills/impeccable/reference/craft.md b/.qoder/skills/impeccable/reference/craft.md index 2c7bd99b1..d0aa05b78 100644 --- a/.qoder/skills/impeccable/reference/craft.md +++ b/.qoder/skills/impeccable/reference/craft.md @@ -19,6 +19,8 @@ You must stop at every gate. **Shape confirmation alone is NOT a green light to When the harness lacks native image generation, gates 2-4 collapse into the brief itself, and shape confirmation does advance straight to code. +**Unattended runs.** When no user can respond (a one-shot task, an automated run, or an explicit instruction not to ask questions), every gate collapses into a decision you make yourself. Hold the same bar the gate would have held: state the shape brief, the visual direction, and the palette as decided (one line each, in your reasoning or the final summary), then proceed straight through to build and the visual iteration pass. Do not stop to wait, do not ask, and do not skip the direction thinking just because nobody will read the questions. + ## Step 0: Project Foundation Before shape, before code: figure out what kind of project you're working in. @@ -44,7 +46,7 @@ Default: Astro for brand briefs, the project's existing framework for product br Run /impeccable shape, passing along whatever feature description the user provided. Shape is **required** for craft; it is what produces a confirmed direction. -Present the shape output and stop. Wait for the user to confirm, override, or course-correct before writing code. +Present the shape output and stop. Wait for the user to confirm, override, or course-correct before writing code. On an unattended run, produce the compact shape output for yourself and continue without pausing. If the user already supplied a confirmed brief or ran shape separately, use it and skip this step. diff --git a/.qoder/skills/impeccable/reference/shape.md b/.qoder/skills/impeccable/reference/shape.md index 592def8a7..40804f6e4 100644 --- a/.qoder/skills/impeccable/reference/shape.md +++ b/.qoder/skills/impeccable/reference/shape.md @@ -12,6 +12,8 @@ Most AI-generated UIs fail not because of bad code, but because of skipped think **Do NOT write any code or make any design decisions during this phase.** Your only job is to understand the feature deeply enough to make excellent design decisions later. +**Unattended runs:** when no user can respond (a one-shot task, an automated run, or an explicit instruction not to ask questions), answer the interview questions yourself from the brief, record the answers as the design brief, and continue without pausing at any confirmation gate in this file. The thinking is still required; only the waiting is waived. + This is a required interaction, not optional guidance. Ask these questions in conversation, adapting based on answers. Don't dump them all at once; have a natural dialogue. ask the user directly to clarify what you cannot infer. ### Interview cadence diff --git a/.rovodev/skills/impeccable/SKILL.md b/.rovodev/skills/impeccable/SKILL.md index 94cc53e4a..7ff8b863a 100644 --- a/.rovodev/skills/impeccable/SKILL.md +++ b/.rovodev/skills/impeccable/SKILL.md @@ -18,12 +18,12 @@ Approach every design task as the design lead at a small studio known for giving You MUST do these steps before proceeding: -1. Run `node .rovodev/skills/impeccable/scripts/context.mjs` once per session; if the runtime shows this skill's loaded base directory, run `node /scripts/context.mjs` instead. Keep cwd/workdir at the user's project, not the skill directory. If the request names or implies a file, route, or app inside a monorepo, infer the concrete path and append `--target ` to the same command. If you've already seen its output in this conversation, do not re-run it. The script either prints the project's PRODUCT.md (and DESIGN.md when present) as a markdown block, or tells you it's missing. Follow whatever it prints. **If it reports `NO_PRODUCT_MD`:** divert into `reference/init.md` first when the user invoked `init`, `teach`, `craft`, or `shape`, or when their wording clearly maps to one of those from-scratch build flows (for example: "build/create/make a landing page", "design a new app", or "shape a feature"). Captured product context is the point of those flows. For any other command, a scoped evaluate / refine / enhance / fix / iterate request against existing code, do **not** divert into init. The existing code is the context: proceed with the requested command, infer the register from the surface in focus, and offer `/impeccable init` once as a suggestion the user can take later. A missing PRODUCT.md must never block a scoped request. If the output ends with an `UPDATE_AVAILABLE` directive, follow it (ask the user once about updating, then continue). It never blocks the current task. +1. Run `node .rovodev/skills/impeccable/scripts/context.mjs` once per session; if the runtime shows this skill's loaded base directory, run `node /scripts/context.mjs` instead. Keep cwd/workdir at the user's project, not the skill directory. If the request names or implies a file, route, or app inside a monorepo, infer the concrete path and append `--target ` to the same command. If you've already seen its output in this conversation, do not re-run it. The script either prints the project's PRODUCT.md (and DESIGN.md when present) as a markdown block, or tells you it's missing. Follow whatever it prints. **If it reports `NO_PRODUCT_MD`:** divert into `reference/init.md` first when the user invoked `init`, `teach`, `craft`, or `shape`, or when their wording clearly maps to one of those from-scratch build flows (for example: "build/create/make a landing page", "design a new app", or "shape a feature"). Captured product context is the point of those flows. **Exception: when no user can respond** (an unattended or one-shot run, or the user said not to ask questions), skip the init interview: write your own one-paragraph understanding of the product, audience, and the page's job from the brief, then proceed with the flow. For any other command, a scoped evaluate / refine / enhance / fix / iterate request against existing code, do **not** divert into init. The existing code is the context: proceed with the requested command, infer the register from the surface in focus, and offer `/impeccable init` once as a suggestion the user can take later. A missing PRODUCT.md must never block a scoped request. If the output ends with an `UPDATE_AVAILABLE` directive, follow it (ask the user once about updating, then continue). It never blocks the current task. 2. If the user invoked a sub-command (`craft`, `shape`, `audit`, `polish`, ...), you MUST read the command's reference next: **`reference/.md`, or the native variant from the Commands table** (e.g. `reference/audit.native.md`) **when the project platform is native** (`ios` / `android` / `adaptive`, per the `context.mjs` directive). One file, not both. Non-optional. The reference defines the command's flow; without it you will skip steps the user expects. 3. Familiarize yourself with any existing design system, conventions, and components in the code. Read at least one project file (CSS / tokens / theme / a representative component or page). **Required even when you've loaded a sub-command reference in step 2.** Don't reinvent the wheel; use what's there when it works, branch out when the UX wins. 4. Identify the register. If the surface is marketing, a landing page, a campaign, long-form content, or a portfolio, design IS the product: the **brand register** applies (see Registers below). If it is app UI, admin, a dashboard, or a tool, design SERVES the product: the **product register** applies. Pick by first match: (1) task cue ("landing page" vs "dashboard"); (2) surface in focus; (3) `register` field in PRODUCT.md. For substantial brand or product work, `reference/brand.md` / `reference/product.md` carry extended depth worth reading; the essentials are inlined below either way. 5. **If PRODUCT.md's `## Platform` is `ios` or `android`**, also read `reference/.md` (HIG / Material 3 conventions). `adaptive` (cross-platform, ships both) reads both files. `web`, absent, or unrecognized: nothing extra to read. `context.mjs` prints the directive when one applies. -6. **If the project is brand-new (no existing CSS tokens / theme / committed brand colors found in step 3)**, run `node .rovodev/skills/impeccable/scripts/palette.mjs` to receive a brand seed color and composition guidance. This is the anchor for your primary brand color. Compose the rest of the palette (bg, surface, ink, accent, muted) around it per the script's instructions. Use OKLCH throughout. **Skip this step only if step 3 found committed brand colors in existing tokens; in that case identity-preservation wins.** +6. **If the project is brand-new (no existing CSS tokens / theme / committed brand colors found in step 3)**, run `node .rovodev/skills/impeccable/scripts/palette.mjs` to receive a brand seed color. The seed exists to break your reflex palette, not to override the subject: when the subject's own world clearly dictates color (an era, a place, a material, a medium), derive the palette from that world and use the seed only as a check on whether your choice was a reflex. When the subject leaves color open, adopt the seed as the anchor and compose the rest of the palette (bg, surface, ink, accent, muted) around it per the script's instructions. Use OKLCH throughout. **Skip this step only if step 3 found committed brand colors in existing tokens; in that case identity-preservation wins.** ## How to design @@ -47,7 +47,7 @@ If the brief doesn't pin down what the product or subject is, pin it yourself be Work in two passes, doing the thinking in your reasoning rather than narrating it. -First, plan a compact token system: **palette** (named values, composed around the seed from Setup step 6 when one was issued), **type** (faces and roles), **layout** (the structural concept in one sentence), and **signature**: the one element this page will be remembered by, drawn from the subject's world. Structure is part of the concept: the standard page skeleton is a default, not a given. Derive the page's frame, viewport treatment, and section rhythm from what the subject needs; when the concept calls for a different structure, take it. +First, plan a compact token system: **palette** (named values; Setup step 6's seed rule decides whether the seed or the subject's world anchors it), **type** (faces and roles), **layout** (the structural concept in one sentence), and **signature**: the one element this page will be remembered by, drawn from the subject's world. Structure is part of the concept: the standard page skeleton is a default, not a given. Derive the page's frame, viewport treatment, and section rhythm from what the subject needs; when the concept calls for a different structure, take it. Then audit the plan before building: work through what you would produce for a *similar* brief from another client. Wherever the two plans converge (same palette family, same face, same skeleton), that part is your generic default, not a choice made for this brief. Revise it. Only then write code, following the revised plan exactly and deriving every color and type decision from it. diff --git a/.rovodev/skills/impeccable/reference/craft.md b/.rovodev/skills/impeccable/reference/craft.md index 2c7bd99b1..d0aa05b78 100644 --- a/.rovodev/skills/impeccable/reference/craft.md +++ b/.rovodev/skills/impeccable/reference/craft.md @@ -19,6 +19,8 @@ You must stop at every gate. **Shape confirmation alone is NOT a green light to When the harness lacks native image generation, gates 2-4 collapse into the brief itself, and shape confirmation does advance straight to code. +**Unattended runs.** When no user can respond (a one-shot task, an automated run, or an explicit instruction not to ask questions), every gate collapses into a decision you make yourself. Hold the same bar the gate would have held: state the shape brief, the visual direction, and the palette as decided (one line each, in your reasoning or the final summary), then proceed straight through to build and the visual iteration pass. Do not stop to wait, do not ask, and do not skip the direction thinking just because nobody will read the questions. + ## Step 0: Project Foundation Before shape, before code: figure out what kind of project you're working in. @@ -44,7 +46,7 @@ Default: Astro for brand briefs, the project's existing framework for product br Run /impeccable shape, passing along whatever feature description the user provided. Shape is **required** for craft; it is what produces a confirmed direction. -Present the shape output and stop. Wait for the user to confirm, override, or course-correct before writing code. +Present the shape output and stop. Wait for the user to confirm, override, or course-correct before writing code. On an unattended run, produce the compact shape output for yourself and continue without pausing. If the user already supplied a confirmed brief or ran shape separately, use it and skip this step. diff --git a/.rovodev/skills/impeccable/reference/shape.md b/.rovodev/skills/impeccable/reference/shape.md index 592def8a7..40804f6e4 100644 --- a/.rovodev/skills/impeccable/reference/shape.md +++ b/.rovodev/skills/impeccable/reference/shape.md @@ -12,6 +12,8 @@ Most AI-generated UIs fail not because of bad code, but because of skipped think **Do NOT write any code or make any design decisions during this phase.** Your only job is to understand the feature deeply enough to make excellent design decisions later. +**Unattended runs:** when no user can respond (a one-shot task, an automated run, or an explicit instruction not to ask questions), answer the interview questions yourself from the brief, record the answers as the design brief, and continue without pausing at any confirmation gate in this file. The thinking is still required; only the waiting is waived. + This is a required interaction, not optional guidance. Ask these questions in conversation, adapting based on answers. Don't dump them all at once; have a natural dialogue. ask the user directly to clarify what you cannot infer. ### Interview cadence diff --git a/.trae-cn/skills/impeccable/SKILL.md b/.trae-cn/skills/impeccable/SKILL.md index 68263f692..c022a5666 100644 --- a/.trae-cn/skills/impeccable/SKILL.md +++ b/.trae-cn/skills/impeccable/SKILL.md @@ -15,12 +15,12 @@ Approach every design task as the design lead at a small studio known for giving You MUST do these steps before proceeding: -1. Run `node .trae-cn/skills/impeccable/scripts/context.mjs` once per session; if the runtime shows this skill's loaded base directory, run `node /scripts/context.mjs` instead. Keep cwd/workdir at the user's project, not the skill directory. If the request names or implies a file, route, or app inside a monorepo, infer the concrete path and append `--target ` to the same command. If you've already seen its output in this conversation, do not re-run it. The script either prints the project's PRODUCT.md (and DESIGN.md when present) as a markdown block, or tells you it's missing. Follow whatever it prints. **If it reports `NO_PRODUCT_MD`:** divert into `reference/init.md` first when the user invoked `init`, `teach`, `craft`, or `shape`, or when their wording clearly maps to one of those from-scratch build flows (for example: "build/create/make a landing page", "design a new app", or "shape a feature"). Captured product context is the point of those flows. For any other command, a scoped evaluate / refine / enhance / fix / iterate request against existing code, do **not** divert into init. The existing code is the context: proceed with the requested command, infer the register from the surface in focus, and offer `/impeccable init` once as a suggestion the user can take later. A missing PRODUCT.md must never block a scoped request. If the output ends with an `UPDATE_AVAILABLE` directive, follow it (ask the user once about updating, then continue). It never blocks the current task. +1. Run `node .trae-cn/skills/impeccable/scripts/context.mjs` once per session; if the runtime shows this skill's loaded base directory, run `node /scripts/context.mjs` instead. Keep cwd/workdir at the user's project, not the skill directory. If the request names or implies a file, route, or app inside a monorepo, infer the concrete path and append `--target ` to the same command. If you've already seen its output in this conversation, do not re-run it. The script either prints the project's PRODUCT.md (and DESIGN.md when present) as a markdown block, or tells you it's missing. Follow whatever it prints. **If it reports `NO_PRODUCT_MD`:** divert into `reference/init.md` first when the user invoked `init`, `teach`, `craft`, or `shape`, or when their wording clearly maps to one of those from-scratch build flows (for example: "build/create/make a landing page", "design a new app", or "shape a feature"). Captured product context is the point of those flows. **Exception: when no user can respond** (an unattended or one-shot run, or the user said not to ask questions), skip the init interview: write your own one-paragraph understanding of the product, audience, and the page's job from the brief, then proceed with the flow. For any other command, a scoped evaluate / refine / enhance / fix / iterate request against existing code, do **not** divert into init. The existing code is the context: proceed with the requested command, infer the register from the surface in focus, and offer `/impeccable init` once as a suggestion the user can take later. A missing PRODUCT.md must never block a scoped request. If the output ends with an `UPDATE_AVAILABLE` directive, follow it (ask the user once about updating, then continue). It never blocks the current task. 2. If the user invoked a sub-command (`craft`, `shape`, `audit`, `polish`, ...), you MUST read the command's reference next: **`reference/.md`, or the native variant from the Commands table** (e.g. `reference/audit.native.md`) **when the project platform is native** (`ios` / `android` / `adaptive`, per the `context.mjs` directive). One file, not both. Non-optional. The reference defines the command's flow; without it you will skip steps the user expects. 3. Familiarize yourself with any existing design system, conventions, and components in the code. Read at least one project file (CSS / tokens / theme / a representative component or page). **Required even when you've loaded a sub-command reference in step 2.** Don't reinvent the wheel; use what's there when it works, branch out when the UX wins. 4. Identify the register. If the surface is marketing, a landing page, a campaign, long-form content, or a portfolio, design IS the product: the **brand register** applies (see Registers below). If it is app UI, admin, a dashboard, or a tool, design SERVES the product: the **product register** applies. Pick by first match: (1) task cue ("landing page" vs "dashboard"); (2) surface in focus; (3) `register` field in PRODUCT.md. For substantial brand or product work, `reference/brand.md` / `reference/product.md` carry extended depth worth reading; the essentials are inlined below either way. 5. **If PRODUCT.md's `## Platform` is `ios` or `android`**, also read `reference/.md` (HIG / Material 3 conventions). `adaptive` (cross-platform, ships both) reads both files. `web`, absent, or unrecognized: nothing extra to read. `context.mjs` prints the directive when one applies. -6. **If the project is brand-new (no existing CSS tokens / theme / committed brand colors found in step 3)**, run `node .trae-cn/skills/impeccable/scripts/palette.mjs` to receive a brand seed color and composition guidance. This is the anchor for your primary brand color. Compose the rest of the palette (bg, surface, ink, accent, muted) around it per the script's instructions. Use OKLCH throughout. **Skip this step only if step 3 found committed brand colors in existing tokens; in that case identity-preservation wins.** +6. **If the project is brand-new (no existing CSS tokens / theme / committed brand colors found in step 3)**, run `node .trae-cn/skills/impeccable/scripts/palette.mjs` to receive a brand seed color. The seed exists to break your reflex palette, not to override the subject: when the subject's own world clearly dictates color (an era, a place, a material, a medium), derive the palette from that world and use the seed only as a check on whether your choice was a reflex. When the subject leaves color open, adopt the seed as the anchor and compose the rest of the palette (bg, surface, ink, accent, muted) around it per the script's instructions. Use OKLCH throughout. **Skip this step only if step 3 found committed brand colors in existing tokens; in that case identity-preservation wins.** ## How to design @@ -44,7 +44,7 @@ If the brief doesn't pin down what the product or subject is, pin it yourself be Work in two passes, doing the thinking in your reasoning rather than narrating it. -First, plan a compact token system: **palette** (named values, composed around the seed from Setup step 6 when one was issued), **type** (faces and roles), **layout** (the structural concept in one sentence), and **signature**: the one element this page will be remembered by, drawn from the subject's world. Structure is part of the concept: the standard page skeleton is a default, not a given. Derive the page's frame, viewport treatment, and section rhythm from what the subject needs; when the concept calls for a different structure, take it. +First, plan a compact token system: **palette** (named values; Setup step 6's seed rule decides whether the seed or the subject's world anchors it), **type** (faces and roles), **layout** (the structural concept in one sentence), and **signature**: the one element this page will be remembered by, drawn from the subject's world. Structure is part of the concept: the standard page skeleton is a default, not a given. Derive the page's frame, viewport treatment, and section rhythm from what the subject needs; when the concept calls for a different structure, take it. Then audit the plan before building: work through what you would produce for a *similar* brief from another client. Wherever the two plans converge (same palette family, same face, same skeleton), that part is your generic default, not a choice made for this brief. Revise it. Only then write code, following the revised plan exactly and deriving every color and type decision from it. diff --git a/.trae-cn/skills/impeccable/reference/craft.md b/.trae-cn/skills/impeccable/reference/craft.md index 2c7bd99b1..d0aa05b78 100644 --- a/.trae-cn/skills/impeccable/reference/craft.md +++ b/.trae-cn/skills/impeccable/reference/craft.md @@ -19,6 +19,8 @@ You must stop at every gate. **Shape confirmation alone is NOT a green light to When the harness lacks native image generation, gates 2-4 collapse into the brief itself, and shape confirmation does advance straight to code. +**Unattended runs.** When no user can respond (a one-shot task, an automated run, or an explicit instruction not to ask questions), every gate collapses into a decision you make yourself. Hold the same bar the gate would have held: state the shape brief, the visual direction, and the palette as decided (one line each, in your reasoning or the final summary), then proceed straight through to build and the visual iteration pass. Do not stop to wait, do not ask, and do not skip the direction thinking just because nobody will read the questions. + ## Step 0: Project Foundation Before shape, before code: figure out what kind of project you're working in. @@ -44,7 +46,7 @@ Default: Astro for brand briefs, the project's existing framework for product br Run /impeccable shape, passing along whatever feature description the user provided. Shape is **required** for craft; it is what produces a confirmed direction. -Present the shape output and stop. Wait for the user to confirm, override, or course-correct before writing code. +Present the shape output and stop. Wait for the user to confirm, override, or course-correct before writing code. On an unattended run, produce the compact shape output for yourself and continue without pausing. If the user already supplied a confirmed brief or ran shape separately, use it and skip this step. diff --git a/.trae-cn/skills/impeccable/reference/shape.md b/.trae-cn/skills/impeccable/reference/shape.md index 592def8a7..40804f6e4 100644 --- a/.trae-cn/skills/impeccable/reference/shape.md +++ b/.trae-cn/skills/impeccable/reference/shape.md @@ -12,6 +12,8 @@ Most AI-generated UIs fail not because of bad code, but because of skipped think **Do NOT write any code or make any design decisions during this phase.** Your only job is to understand the feature deeply enough to make excellent design decisions later. +**Unattended runs:** when no user can respond (a one-shot task, an automated run, or an explicit instruction not to ask questions), answer the interview questions yourself from the brief, record the answers as the design brief, and continue without pausing at any confirmation gate in this file. The thinking is still required; only the waiting is waived. + This is a required interaction, not optional guidance. Ask these questions in conversation, adapting based on answers. Don't dump them all at once; have a natural dialogue. ask the user directly to clarify what you cannot infer. ### Interview cadence diff --git a/.trae/skills/impeccable/SKILL.md b/.trae/skills/impeccable/SKILL.md index 8b3dbb477..b908b6e79 100644 --- a/.trae/skills/impeccable/SKILL.md +++ b/.trae/skills/impeccable/SKILL.md @@ -15,12 +15,12 @@ Approach every design task as the design lead at a small studio known for giving You MUST do these steps before proceeding: -1. Run `node .trae/skills/impeccable/scripts/context.mjs` once per session; if the runtime shows this skill's loaded base directory, run `node /scripts/context.mjs` instead. Keep cwd/workdir at the user's project, not the skill directory. If the request names or implies a file, route, or app inside a monorepo, infer the concrete path and append `--target ` to the same command. If you've already seen its output in this conversation, do not re-run it. The script either prints the project's PRODUCT.md (and DESIGN.md when present) as a markdown block, or tells you it's missing. Follow whatever it prints. **If it reports `NO_PRODUCT_MD`:** divert into `reference/init.md` first when the user invoked `init`, `teach`, `craft`, or `shape`, or when their wording clearly maps to one of those from-scratch build flows (for example: "build/create/make a landing page", "design a new app", or "shape a feature"). Captured product context is the point of those flows. For any other command, a scoped evaluate / refine / enhance / fix / iterate request against existing code, do **not** divert into init. The existing code is the context: proceed with the requested command, infer the register from the surface in focus, and offer `/impeccable init` once as a suggestion the user can take later. A missing PRODUCT.md must never block a scoped request. If the output ends with an `UPDATE_AVAILABLE` directive, follow it (ask the user once about updating, then continue). It never blocks the current task. +1. Run `node .trae/skills/impeccable/scripts/context.mjs` once per session; if the runtime shows this skill's loaded base directory, run `node /scripts/context.mjs` instead. Keep cwd/workdir at the user's project, not the skill directory. If the request names or implies a file, route, or app inside a monorepo, infer the concrete path and append `--target ` to the same command. If you've already seen its output in this conversation, do not re-run it. The script either prints the project's PRODUCT.md (and DESIGN.md when present) as a markdown block, or tells you it's missing. Follow whatever it prints. **If it reports `NO_PRODUCT_MD`:** divert into `reference/init.md` first when the user invoked `init`, `teach`, `craft`, or `shape`, or when their wording clearly maps to one of those from-scratch build flows (for example: "build/create/make a landing page", "design a new app", or "shape a feature"). Captured product context is the point of those flows. **Exception: when no user can respond** (an unattended or one-shot run, or the user said not to ask questions), skip the init interview: write your own one-paragraph understanding of the product, audience, and the page's job from the brief, then proceed with the flow. For any other command, a scoped evaluate / refine / enhance / fix / iterate request against existing code, do **not** divert into init. The existing code is the context: proceed with the requested command, infer the register from the surface in focus, and offer `/impeccable init` once as a suggestion the user can take later. A missing PRODUCT.md must never block a scoped request. If the output ends with an `UPDATE_AVAILABLE` directive, follow it (ask the user once about updating, then continue). It never blocks the current task. 2. If the user invoked a sub-command (`craft`, `shape`, `audit`, `polish`, ...), you MUST read the command's reference next: **`reference/.md`, or the native variant from the Commands table** (e.g. `reference/audit.native.md`) **when the project platform is native** (`ios` / `android` / `adaptive`, per the `context.mjs` directive). One file, not both. Non-optional. The reference defines the command's flow; without it you will skip steps the user expects. 3. Familiarize yourself with any existing design system, conventions, and components in the code. Read at least one project file (CSS / tokens / theme / a representative component or page). **Required even when you've loaded a sub-command reference in step 2.** Don't reinvent the wheel; use what's there when it works, branch out when the UX wins. 4. Identify the register. If the surface is marketing, a landing page, a campaign, long-form content, or a portfolio, design IS the product: the **brand register** applies (see Registers below). If it is app UI, admin, a dashboard, or a tool, design SERVES the product: the **product register** applies. Pick by first match: (1) task cue ("landing page" vs "dashboard"); (2) surface in focus; (3) `register` field in PRODUCT.md. For substantial brand or product work, `reference/brand.md` / `reference/product.md` carry extended depth worth reading; the essentials are inlined below either way. 5. **If PRODUCT.md's `## Platform` is `ios` or `android`**, also read `reference/.md` (HIG / Material 3 conventions). `adaptive` (cross-platform, ships both) reads both files. `web`, absent, or unrecognized: nothing extra to read. `context.mjs` prints the directive when one applies. -6. **If the project is brand-new (no existing CSS tokens / theme / committed brand colors found in step 3)**, run `node .trae/skills/impeccable/scripts/palette.mjs` to receive a brand seed color and composition guidance. This is the anchor for your primary brand color. Compose the rest of the palette (bg, surface, ink, accent, muted) around it per the script's instructions. Use OKLCH throughout. **Skip this step only if step 3 found committed brand colors in existing tokens; in that case identity-preservation wins.** +6. **If the project is brand-new (no existing CSS tokens / theme / committed brand colors found in step 3)**, run `node .trae/skills/impeccable/scripts/palette.mjs` to receive a brand seed color. The seed exists to break your reflex palette, not to override the subject: when the subject's own world clearly dictates color (an era, a place, a material, a medium), derive the palette from that world and use the seed only as a check on whether your choice was a reflex. When the subject leaves color open, adopt the seed as the anchor and compose the rest of the palette (bg, surface, ink, accent, muted) around it per the script's instructions. Use OKLCH throughout. **Skip this step only if step 3 found committed brand colors in existing tokens; in that case identity-preservation wins.** ## How to design @@ -44,7 +44,7 @@ If the brief doesn't pin down what the product or subject is, pin it yourself be Work in two passes, doing the thinking in your reasoning rather than narrating it. -First, plan a compact token system: **palette** (named values, composed around the seed from Setup step 6 when one was issued), **type** (faces and roles), **layout** (the structural concept in one sentence), and **signature**: the one element this page will be remembered by, drawn from the subject's world. Structure is part of the concept: the standard page skeleton is a default, not a given. Derive the page's frame, viewport treatment, and section rhythm from what the subject needs; when the concept calls for a different structure, take it. +First, plan a compact token system: **palette** (named values; Setup step 6's seed rule decides whether the seed or the subject's world anchors it), **type** (faces and roles), **layout** (the structural concept in one sentence), and **signature**: the one element this page will be remembered by, drawn from the subject's world. Structure is part of the concept: the standard page skeleton is a default, not a given. Derive the page's frame, viewport treatment, and section rhythm from what the subject needs; when the concept calls for a different structure, take it. Then audit the plan before building: work through what you would produce for a *similar* brief from another client. Wherever the two plans converge (same palette family, same face, same skeleton), that part is your generic default, not a choice made for this brief. Revise it. Only then write code, following the revised plan exactly and deriving every color and type decision from it. diff --git a/.trae/skills/impeccable/reference/craft.md b/.trae/skills/impeccable/reference/craft.md index 2c7bd99b1..d0aa05b78 100644 --- a/.trae/skills/impeccable/reference/craft.md +++ b/.trae/skills/impeccable/reference/craft.md @@ -19,6 +19,8 @@ You must stop at every gate. **Shape confirmation alone is NOT a green light to When the harness lacks native image generation, gates 2-4 collapse into the brief itself, and shape confirmation does advance straight to code. +**Unattended runs.** When no user can respond (a one-shot task, an automated run, or an explicit instruction not to ask questions), every gate collapses into a decision you make yourself. Hold the same bar the gate would have held: state the shape brief, the visual direction, and the palette as decided (one line each, in your reasoning or the final summary), then proceed straight through to build and the visual iteration pass. Do not stop to wait, do not ask, and do not skip the direction thinking just because nobody will read the questions. + ## Step 0: Project Foundation Before shape, before code: figure out what kind of project you're working in. @@ -44,7 +46,7 @@ Default: Astro for brand briefs, the project's existing framework for product br Run /impeccable shape, passing along whatever feature description the user provided. Shape is **required** for craft; it is what produces a confirmed direction. -Present the shape output and stop. Wait for the user to confirm, override, or course-correct before writing code. +Present the shape output and stop. Wait for the user to confirm, override, or course-correct before writing code. On an unattended run, produce the compact shape output for yourself and continue without pausing. If the user already supplied a confirmed brief or ran shape separately, use it and skip this step. diff --git a/.trae/skills/impeccable/reference/shape.md b/.trae/skills/impeccable/reference/shape.md index 592def8a7..40804f6e4 100644 --- a/.trae/skills/impeccable/reference/shape.md +++ b/.trae/skills/impeccable/reference/shape.md @@ -12,6 +12,8 @@ Most AI-generated UIs fail not because of bad code, but because of skipped think **Do NOT write any code or make any design decisions during this phase.** Your only job is to understand the feature deeply enough to make excellent design decisions later. +**Unattended runs:** when no user can respond (a one-shot task, an automated run, or an explicit instruction not to ask questions), answer the interview questions yourself from the brief, record the answers as the design brief, and continue without pausing at any confirmation gate in this file. The thinking is still required; only the waiting is waived. + This is a required interaction, not optional guidance. Ask these questions in conversation, adapting based on answers. Don't dump them all at once; have a natural dialogue. ask the user directly to clarify what you cannot infer. ### Interview cadence diff --git a/plugin/skills/impeccable/SKILL.md b/plugin/skills/impeccable/SKILL.md index 47aaa062b..21471521a 100644 --- a/plugin/skills/impeccable/SKILL.md +++ b/plugin/skills/impeccable/SKILL.md @@ -18,12 +18,12 @@ Approach every design task as the design lead at a small studio known for giving You MUST do these steps before proceeding: -1. Run `node .claude/skills/impeccable/scripts/context.mjs` once per session; if the runtime shows this skill's loaded base directory, run `node /scripts/context.mjs` instead. Keep cwd/workdir at the user's project, not the skill directory. If the request names or implies a file, route, or app inside a monorepo, infer the concrete path and append `--target ` to the same command. If you've already seen its output in this conversation, do not re-run it. The script either prints the project's PRODUCT.md (and DESIGN.md when present) as a markdown block, or tells you it's missing. Follow whatever it prints. **If it reports `NO_PRODUCT_MD`:** divert into `reference/init.md` first when the user invoked `init`, `teach`, `craft`, or `shape`, or when their wording clearly maps to one of those from-scratch build flows (for example: "build/create/make a landing page", "design a new app", or "shape a feature"). Captured product context is the point of those flows. For any other command, a scoped evaluate / refine / enhance / fix / iterate request against existing code, do **not** divert into init. The existing code is the context: proceed with the requested command, infer the register from the surface in focus, and offer `/impeccable init` once as a suggestion the user can take later. A missing PRODUCT.md must never block a scoped request. If the output ends with an `UPDATE_AVAILABLE` directive, follow it (ask the user once about updating, then continue). It never blocks the current task. +1. Run `node .claude/skills/impeccable/scripts/context.mjs` once per session; if the runtime shows this skill's loaded base directory, run `node /scripts/context.mjs` instead. Keep cwd/workdir at the user's project, not the skill directory. If the request names or implies a file, route, or app inside a monorepo, infer the concrete path and append `--target ` to the same command. If you've already seen its output in this conversation, do not re-run it. The script either prints the project's PRODUCT.md (and DESIGN.md when present) as a markdown block, or tells you it's missing. Follow whatever it prints. **If it reports `NO_PRODUCT_MD`:** divert into `reference/init.md` first when the user invoked `init`, `teach`, `craft`, or `shape`, or when their wording clearly maps to one of those from-scratch build flows (for example: "build/create/make a landing page", "design a new app", or "shape a feature"). Captured product context is the point of those flows. **Exception: when no user can respond** (an unattended or one-shot run, or the user said not to ask questions), skip the init interview: write your own one-paragraph understanding of the product, audience, and the page's job from the brief, then proceed with the flow. For any other command, a scoped evaluate / refine / enhance / fix / iterate request against existing code, do **not** divert into init. The existing code is the context: proceed with the requested command, infer the register from the surface in focus, and offer `/impeccable init` once as a suggestion the user can take later. A missing PRODUCT.md must never block a scoped request. If the output ends with an `UPDATE_AVAILABLE` directive, follow it (ask the user once about updating, then continue). It never blocks the current task. 2. If the user invoked a sub-command (`craft`, `shape`, `audit`, `polish`, ...), you MUST read the command's reference next: **`reference/.md`, or the native variant from the Commands table** (e.g. `reference/audit.native.md`) **when the project platform is native** (`ios` / `android` / `adaptive`, per the `context.mjs` directive). One file, not both. Non-optional. The reference defines the command's flow; without it you will skip steps the user expects. 3. Familiarize yourself with any existing design system, conventions, and components in the code. Read at least one project file (CSS / tokens / theme / a representative component or page). **Required even when you've loaded a sub-command reference in step 2.** Don't reinvent the wheel; use what's there when it works, branch out when the UX wins. 4. Identify the register. If the surface is marketing, a landing page, a campaign, long-form content, or a portfolio, design IS the product: the **brand register** applies (see Registers below). If it is app UI, admin, a dashboard, or a tool, design SERVES the product: the **product register** applies. Pick by first match: (1) task cue ("landing page" vs "dashboard"); (2) surface in focus; (3) `register` field in PRODUCT.md. For substantial brand or product work, `reference/brand.md` / `reference/product.md` carry extended depth worth reading; the essentials are inlined below either way. 5. **If PRODUCT.md's `## Platform` is `ios` or `android`**, also read `reference/.md` (HIG / Material 3 conventions). `adaptive` (cross-platform, ships both) reads both files. `web`, absent, or unrecognized: nothing extra to read. `context.mjs` prints the directive when one applies. -6. **If the project is brand-new (no existing CSS tokens / theme / committed brand colors found in step 3)**, run `node .claude/skills/impeccable/scripts/palette.mjs` to receive a brand seed color and composition guidance. This is the anchor for your primary brand color. Compose the rest of the palette (bg, surface, ink, accent, muted) around it per the script's instructions. Use OKLCH throughout. **Skip this step only if step 3 found committed brand colors in existing tokens; in that case identity-preservation wins.** +6. **If the project is brand-new (no existing CSS tokens / theme / committed brand colors found in step 3)**, run `node .claude/skills/impeccable/scripts/palette.mjs` to receive a brand seed color. The seed exists to break your reflex palette, not to override the subject: when the subject's own world clearly dictates color (an era, a place, a material, a medium), derive the palette from that world and use the seed only as a check on whether your choice was a reflex. When the subject leaves color open, adopt the seed as the anchor and compose the rest of the palette (bg, surface, ink, accent, muted) around it per the script's instructions. Use OKLCH throughout. **Skip this step only if step 3 found committed brand colors in existing tokens; in that case identity-preservation wins.** ## How to design @@ -47,7 +47,7 @@ If the brief doesn't pin down what the product or subject is, pin it yourself be Work in two passes, doing the thinking in your reasoning rather than narrating it. -First, plan a compact token system: **palette** (named values, composed around the seed from Setup step 6 when one was issued), **type** (faces and roles), **layout** (the structural concept in one sentence), and **signature**: the one element this page will be remembered by, drawn from the subject's world. Structure is part of the concept: the standard page skeleton is a default, not a given. Derive the page's frame, viewport treatment, and section rhythm from what the subject needs; when the concept calls for a different structure, take it. +First, plan a compact token system: **palette** (named values; Setup step 6's seed rule decides whether the seed or the subject's world anchors it), **type** (faces and roles), **layout** (the structural concept in one sentence), and **signature**: the one element this page will be remembered by, drawn from the subject's world. Structure is part of the concept: the standard page skeleton is a default, not a given. Derive the page's frame, viewport treatment, and section rhythm from what the subject needs; when the concept calls for a different structure, take it. Then audit the plan before building: work through what you would produce for a *similar* brief from another client. Wherever the two plans converge (same palette family, same face, same skeleton), that part is your generic default, not a choice made for this brief. Revise it. Only then write code, following the revised plan exactly and deriving every color and type decision from it. diff --git a/plugin/skills/impeccable/reference/craft.md b/plugin/skills/impeccable/reference/craft.md index 2c7bd99b1..d0aa05b78 100644 --- a/plugin/skills/impeccable/reference/craft.md +++ b/plugin/skills/impeccable/reference/craft.md @@ -19,6 +19,8 @@ You must stop at every gate. **Shape confirmation alone is NOT a green light to When the harness lacks native image generation, gates 2-4 collapse into the brief itself, and shape confirmation does advance straight to code. +**Unattended runs.** When no user can respond (a one-shot task, an automated run, or an explicit instruction not to ask questions), every gate collapses into a decision you make yourself. Hold the same bar the gate would have held: state the shape brief, the visual direction, and the palette as decided (one line each, in your reasoning or the final summary), then proceed straight through to build and the visual iteration pass. Do not stop to wait, do not ask, and do not skip the direction thinking just because nobody will read the questions. + ## Step 0: Project Foundation Before shape, before code: figure out what kind of project you're working in. @@ -44,7 +46,7 @@ Default: Astro for brand briefs, the project's existing framework for product br Run /impeccable shape, passing along whatever feature description the user provided. Shape is **required** for craft; it is what produces a confirmed direction. -Present the shape output and stop. Wait for the user to confirm, override, or course-correct before writing code. +Present the shape output and stop. Wait for the user to confirm, override, or course-correct before writing code. On an unattended run, produce the compact shape output for yourself and continue without pausing. If the user already supplied a confirmed brief or ran shape separately, use it and skip this step. diff --git a/plugin/skills/impeccable/reference/shape.md b/plugin/skills/impeccable/reference/shape.md index c76d25812..23e286df5 100644 --- a/plugin/skills/impeccable/reference/shape.md +++ b/plugin/skills/impeccable/reference/shape.md @@ -12,6 +12,8 @@ Most AI-generated UIs fail not because of bad code, but because of skipped think **Do NOT write any code or make any design decisions during this phase.** Your only job is to understand the feature deeply enough to make excellent design decisions later. +**Unattended runs:** when no user can respond (a one-shot task, an automated run, or an explicit instruction not to ask questions), answer the interview questions yourself from the brief, record the answers as the design brief, and continue without pausing at any confirmation gate in this file. The thinking is still required; only the waiting is waived. + This is a required interaction, not optional guidance. Ask these questions in conversation, adapting based on answers. Don't dump them all at once; have a natural dialogue. STOP and call the AskUserQuestion tool to clarify. ### Interview cadence diff --git a/skill/SKILL.src.md b/skill/SKILL.src.md index fa13d3a87..2a619ca73 100644 --- a/skill/SKILL.src.md +++ b/skill/SKILL.src.md @@ -17,12 +17,12 @@ Approach every design task as the design lead at a small studio known for giving You MUST do these steps before proceeding: -1. Run `node {{scripts_path}}/context.mjs` once per session; if the runtime shows this skill's loaded base directory, run `node /scripts/context.mjs` instead. Keep cwd/workdir at the user's project, not the skill directory. If the request names or implies a file, route, or app inside a monorepo, infer the concrete path and append `--target ` to the same command. If you've already seen its output in this conversation, do not re-run it. The script either prints the project's PRODUCT.md (and DESIGN.md when present) as a markdown block, or tells you it's missing. Follow whatever it prints. **If it reports `NO_PRODUCT_MD`:** divert into `reference/init.md` first when the user invoked `init`, `teach`, `craft`, or `shape`, or when their wording clearly maps to one of those from-scratch build flows (for example: "build/create/make a landing page", "design a new app", or "shape a feature"). Captured product context is the point of those flows. For any other command, a scoped evaluate / refine / enhance / fix / iterate request against existing code, do **not** divert into init. The existing code is the context: proceed with the requested command, infer the register from the surface in focus, and offer `/impeccable init` once as a suggestion the user can take later. A missing PRODUCT.md must never block a scoped request. If the output ends with an `UPDATE_AVAILABLE` directive, follow it (ask the user once about updating, then continue). It never blocks the current task. +1. Run `node {{scripts_path}}/context.mjs` once per session; if the runtime shows this skill's loaded base directory, run `node /scripts/context.mjs` instead. Keep cwd/workdir at the user's project, not the skill directory. If the request names or implies a file, route, or app inside a monorepo, infer the concrete path and append `--target ` to the same command. If you've already seen its output in this conversation, do not re-run it. The script either prints the project's PRODUCT.md (and DESIGN.md when present) as a markdown block, or tells you it's missing. Follow whatever it prints. **If it reports `NO_PRODUCT_MD`:** divert into `reference/init.md` first when the user invoked `init`, `teach`, `craft`, or `shape`, or when their wording clearly maps to one of those from-scratch build flows (for example: "build/create/make a landing page", "design a new app", or "shape a feature"). Captured product context is the point of those flows. **Exception: when no user can respond** (an unattended or one-shot run, or the user said not to ask questions), skip the init interview: write your own one-paragraph understanding of the product, audience, and the page's job from the brief, then proceed with the flow. For any other command, a scoped evaluate / refine / enhance / fix / iterate request against existing code, do **not** divert into init. The existing code is the context: proceed with the requested command, infer the register from the surface in focus, and offer `/impeccable init` once as a suggestion the user can take later. A missing PRODUCT.md must never block a scoped request. If the output ends with an `UPDATE_AVAILABLE` directive, follow it (ask the user once about updating, then continue). It never blocks the current task. 2. If the user invoked a sub-command (`craft`, `shape`, `audit`, `polish`, ...), you MUST read the command's reference next: **`reference/.md`, or the native variant from the Commands table** (e.g. `reference/audit.native.md`) **when the project platform is native** (`ios` / `android` / `adaptive`, per the `context.mjs` directive). One file, not both. Non-optional. The reference defines the command's flow; without it you will skip steps the user expects. 3. Familiarize yourself with any existing design system, conventions, and components in the code. Read at least one project file (CSS / tokens / theme / a representative component or page). **Required even when you've loaded a sub-command reference in step 2.** Don't reinvent the wheel; use what's there when it works, branch out when the UX wins. 4. Identify the register. If the surface is marketing, a landing page, a campaign, long-form content, or a portfolio, design IS the product: the **brand register** applies (see Registers below). If it is app UI, admin, a dashboard, or a tool, design SERVES the product: the **product register** applies. Pick by first match: (1) task cue ("landing page" vs "dashboard"); (2) surface in focus; (3) `register` field in PRODUCT.md. For substantial brand or product work, `reference/brand.md` / `reference/product.md` carry extended depth worth reading; the essentials are inlined below either way. 5. **If PRODUCT.md's `## Platform` is `ios` or `android`**, also read `reference/.md` (HIG / Material 3 conventions). `adaptive` (cross-platform, ships both) reads both files. `web`, absent, or unrecognized: nothing extra to read. `context.mjs` prints the directive when one applies. -6. **If the project is brand-new (no existing CSS tokens / theme / committed brand colors found in step 3)**, run `node {{scripts_path}}/palette.mjs` to receive a brand seed color and composition guidance. This is the anchor for your primary brand color. Compose the rest of the palette (bg, surface, ink, accent, muted) around it per the script's instructions. Use OKLCH throughout. **Skip this step only if step 3 found committed brand colors in existing tokens; in that case identity-preservation wins.** +6. **If the project is brand-new (no existing CSS tokens / theme / committed brand colors found in step 3)**, run `node {{scripts_path}}/palette.mjs` to receive a brand seed color. The seed exists to break your reflex palette, not to override the subject: when the subject's own world clearly dictates color (an era, a place, a material, a medium), derive the palette from that world and use the seed only as a check on whether your choice was a reflex. When the subject leaves color open, adopt the seed as the anchor and compose the rest of the palette (bg, surface, ink, accent, muted) around it per the script's instructions. Use OKLCH throughout. **Skip this step only if step 3 found committed brand colors in existing tokens; in that case identity-preservation wins.** ## How to design @@ -46,7 +46,7 @@ If the brief doesn't pin down what the product or subject is, pin it yourself be Work in two passes, doing the thinking in your reasoning rather than narrating it. -First, plan a compact token system: **palette** (named values, composed around the seed from Setup step 6 when one was issued), **type** (faces and roles), **layout** (the structural concept in one sentence), and **signature**: the one element this page will be remembered by, drawn from the subject's world. Structure is part of the concept: the standard page skeleton is a default, not a given. Derive the page's frame, viewport treatment, and section rhythm from what the subject needs; when the concept calls for a different structure, take it. +First, plan a compact token system: **palette** (named values; Setup step 6's seed rule decides whether the seed or the subject's world anchors it), **type** (faces and roles), **layout** (the structural concept in one sentence), and **signature**: the one element this page will be remembered by, drawn from the subject's world. Structure is part of the concept: the standard page skeleton is a default, not a given. Derive the page's frame, viewport treatment, and section rhythm from what the subject needs; when the concept calls for a different structure, take it. Then audit the plan before building: work through what you would produce for a *similar* brief from another client. Wherever the two plans converge (same palette family, same face, same skeleton), that part is your generic default, not a choice made for this brief. Revise it. Only then write code, following the revised plan exactly and deriving every color and type decision from it. diff --git a/skill/reference/craft.md b/skill/reference/craft.md index 0604d0e05..c3fe43be8 100644 --- a/skill/reference/craft.md +++ b/skill/reference/craft.md @@ -19,6 +19,8 @@ You must stop at every gate. **Shape confirmation alone is NOT a green light to When the harness lacks native image generation, gates 2-4 collapse into the brief itself, and shape confirmation does advance straight to code. +**Unattended runs.** When no user can respond (a one-shot task, an automated run, or an explicit instruction not to ask questions), every gate collapses into a decision you make yourself. Hold the same bar the gate would have held: state the shape brief, the visual direction, and the palette as decided (one line each, in your reasoning or the final summary), then proceed straight through to build and the visual iteration pass. Do not stop to wait, do not ask, and do not skip the direction thinking just because nobody will read the questions. + ## Step 0: Project Foundation Before shape, before code: figure out what kind of project you're working in. @@ -44,7 +46,7 @@ Default: Astro for brand briefs, the project's existing framework for product br Run {{command_prefix}}impeccable shape, passing along whatever feature description the user provided. Shape is **required** for craft; it is what produces a confirmed direction. -Present the shape output and stop. Wait for the user to confirm, override, or course-correct before writing code. +Present the shape output and stop. Wait for the user to confirm, override, or course-correct before writing code. On an unattended run, produce the compact shape output for yourself and continue without pausing. If the user already supplied a confirmed brief or ran shape separately, use it and skip this step. diff --git a/skill/reference/shape.md b/skill/reference/shape.md index 421ce68b6..615da27cb 100644 --- a/skill/reference/shape.md +++ b/skill/reference/shape.md @@ -12,6 +12,8 @@ Most AI-generated UIs fail not because of bad code, but because of skipped think **Do NOT write any code or make any design decisions during this phase.** Your only job is to understand the feature deeply enough to make excellent design decisions later. +**Unattended runs:** when no user can respond (a one-shot task, an automated run, or an explicit instruction not to ask questions), answer the interview questions yourself from the brief, record the answers as the design brief, and continue without pausing at any confirmation gate in this file. The thinking is still required; only the waiting is waived. + This is a required interaction, not optional guidance. Ask these questions in conversation, adapting based on answers. Don't dump them all at once; have a natural dialogue. {{ask_instruction}} ### Interview cadence