FN-6906: improve non-coding workflow artifact prompts
Non-coding built-in workflows now guide agents toward structured, reviewable artifacts. - Expand marketing and lead-generation prompts with explicit inputs, output structure, quality bars, and persisted task-document deliverables. - Require design execution to persist a reviewable preview document and update design review guidance to inspect it. - Document the new artifact-oriented behavior and cover prompt routing with regression tests while preserving coding workflow defaults. - Add a patch changeset for the published Fusion package. Files changed: .changeset/fn-6906-non-coding-workflow-prompts.md | 5 +++++ docs/workflow-steps.md | 11 +++++++---- .../builtin-lead-generation-workflow-ir.test.ts | 2 ++ .../core/src/__tests__/builtin-workflows.test.ts | 22 ++++++++++++++++++++++ .../src/builtin-lead-generation-workflow-ir.ts | 13 ++++++++----- packages/core/src/builtin-marketing-workflow-ir.ts | 9 ++++++--- packages/core/src/builtin-workflows.ts | 16 ++++++++++++++-- 7 files changed, 64 insertions(+), 14 deletions(-) Fusion-Task-Id: FN-6906 Fusion-Task-Lineage: 76f39350-e441-4dde-8571-35a6fbf6fcda
This commit is contained in:
gsxdsm
5
.changeset/fn-6906-non-coding-workflow-prompts.md
Normal file
5
.changeset/fn-6906-non-coding-workflow-prompts.md
Normal file
@@ -0,0 +1,5 @@
|
||||
---
|
||||
"@runfusion/fusion": patch
|
||||
---
|
||||
|
||||
Improve bundled non-coding workflow prompts so marketing, lead-generation, and design runs produce structured deliverables, with content and design preview artifacts persisted for review.
|
||||
@@ -15,6 +15,9 @@ The built-in catalog now includes a business lead-generation workflow with custo
|
||||
|
||||
FNXC:WorkflowRouting 2026-06-21-04:25:
|
||||
Triage and planning agents must preserve the project default workflow unless the user explicitly requests a different workflow. No-commit markers describe expected artifact behavior only; they no longer imply automatic Quick fix workflow selection.
|
||||
|
||||
FNXC:Docs 2026-06-21-12:00:
|
||||
FN-6906 makes non-coding built-in prompts artifact-oriented: marketing drafts, lead enrichment/outreach, and design previews are persisted with fn_task_document_write, while fn_artifact_register remains conditional until the artifact tool is available.
|
||||
-->
|
||||
|
||||
Fusion workflows define the task lifecycle policy that moves work from an idea to delivery. The default coding path is **Plan/Triage → Execute → Workflow steps → Review → Merge**, but that path is now represented as a workflow selection rather than only as fixed engine behavior. A task with no explicit workflow resolves to `builtin:coding`; an explicit missing/corrupt custom workflow fails closed instead of silently falling back.
|
||||
@@ -36,12 +39,12 @@ Decision-only or investigation tasks can also declare `noCommitsExpected` / `**N
|
||||
| Coding | `builtin:coding` | Default coding lifecycle and fallback for tasks without an explicit selection. |
|
||||
| Quick fix | `builtin:quick-fix` | Short path for trivial or no-commit/decision work; omits the standard review stage. |
|
||||
| Review-heavy | `builtin:review-heavy` | Standard execute/review/merge path with an additional gated security review. |
|
||||
| Marketing | `builtin:marketing` | Content pipeline with custom Ideation, Backlog, Drafting, Editorial review, Published, and Archived columns plus marketing brief/draft/editorial prompts; it reuses the standard lifecycle traits and merge-primitive region. |
|
||||
| Marketing | `builtin:marketing` | Content pipeline with custom Ideation, Backlog, Drafting, Editorial review, Published, and Archived columns plus structured marketing brief/draft/editorial prompts; drafts are persisted as task documents for review while the workflow reuses standard lifecycle traits and merge primitives. |
|
||||
| Compound engineering | `builtin:compound-engineering` | Plugin-gated workflow that invokes Compound Engineering skills for planning, work, review, PR/feedback, and learnings capture. |
|
||||
| Stepwise coding | `builtin:stepwise-coding` | Graph-executor workflow that models per-step parse/execute/review/rework explicitly. |
|
||||
| Design | `builtin:design` | UI-heavy work path that implements, runs a gated design/UX review, then performs the standard review and merge. |
|
||||
| Design | `builtin:design` | UI-heavy work path that implements, persists a user-facing design preview task document, runs a gated design/UX review, then performs the standard review and merge. |
|
||||
| PR lifecycle | `builtin:pr-workflow` | Reusable PR lifecycle graph fragment (create PR → await review → respond → gate → merge); it is a fragment, not directly selectable as a task workflow. |
|
||||
| Lead generation | `builtin:lead-generation` | Selectable business workflow for sourcing, qualifying, enriching, and contacting leads with custom lead fields and stage columns; requires the workflow graph executor for custom board columns. |
|
||||
| Lead generation | `builtin:lead-generation` | Selectable business workflow for sourcing, qualifying, enriching, and contacting leads with custom lead fields, stage columns, and reviewable enrichment/outreach task documents; requires the workflow graph executor for custom board columns. |
|
||||
|
||||
### Custom workflow authoring
|
||||
|
||||
@@ -101,7 +104,7 @@ The default built-in catalog entry `builtin:coding` is backed by the canonical `
|
||||
|
||||
`builtin:stepwise-coding` is a separate graph variant backed by `BUILTIN_STEPWISE_CODING_WORKFLOW_IR`; it keeps the same lifecycle columns/traits while modeling per-step parse/execute/review/rework as authored graph structure.
|
||||
|
||||
`builtin:marketing` is a non-coding content workflow with marketing-specific columns (`ideation`, `backlog`, `drafting`, `editorial-review`, `published`, `archived`) and prompt seams for content brief, draft, and editorial review. It uses the same lifecycle traits (`intake`, `hold`, `wip`, `merge-blocker`, `human-review`, `complete`, `archived`) and the same merge-gate/branch-group/merge-attempt primitive region as coding workflows, so scheduler, capacity, review blocking, and merge orchestration behavior remain standard.
|
||||
`builtin:marketing` is a non-coding content workflow with marketing-specific columns (`ideation`, `backlog`, `drafting`, `editorial-review`, `published`, `archived`) and prompt seams for content brief, draft, and editorial review. Its draft stage saves the primary content deliverable as a task document for human review, while the workflow uses the same lifecycle traits (`intake`, `hold`, `wip`, `merge-blocker`, `human-review`, `complete`, `archived`) and the same merge-gate/branch-group/merge-attempt primitive region as coding workflows, so scheduler, capacity, review blocking, and merge orchestration behavior remain standard.
|
||||
|
||||
During triage/planning sessions, agents can call `fn_workflow_list` to discover available built-in and custom workflows and read their descriptions before routing work. They can call `fn_workflow_select` to select a workflow for the task being specified, or pass `workflow_id` when creating child tasks with `fn_task_create`; decision-only or investigation tasks can also set `noCommitsExpected` / `**No commits expected:** true` when no code changes are expected. The built-in triage thresholds, decision-only verb list, and default routing IDs are workflow-native typed settings resolved from the selected workflow.
|
||||
|
||||
|
||||
@@ -70,6 +70,8 @@ describe("built-in lead-generation workflow IR", () => {
|
||||
expect(config?.seam, node.id).toBeUndefined();
|
||||
expect(config?.prompt, node.id).toEqual(expect.stringMatching(/lead|prospect|outreach|customer|company/i));
|
||||
}
|
||||
expect(ir.nodes.find((node) => node.id === "enrich-lead")?.config?.prompt).toContain("fn_task_document_write");
|
||||
expect(ir.nodes.find((node) => node.id === "draft-outreach")?.config?.prompt).toContain("fn_task_document_write");
|
||||
|
||||
expect(compileWorkflowToSteps(ir).map((step) => step.name)).toEqual([
|
||||
"Source prospects",
|
||||
|
||||
@@ -9,6 +9,7 @@ import {
|
||||
isBuiltinWorkflowPluginGated,
|
||||
} from "../builtin-workflows.js";
|
||||
import { BUILTIN_CODING_WORKFLOW_IR } from "../builtin-coding-workflow-ir.js";
|
||||
import { builtinPromptConfig, BUILTIN_SEAM_PROMPTS } from "../builtin-workflow-prompts.js";
|
||||
import { BUILTIN_WORKFLOW_SETTINGS } from "../builtin-workflow-settings.js";
|
||||
import { resolveColumnFlags } from "../trait-registry.js";
|
||||
import { compileWorkflowToSteps } from "../workflow-compiler.js";
|
||||
@@ -207,6 +208,7 @@ describe("built-in workflows", () => {
|
||||
expect(execute?.id).toBe("draft");
|
||||
expect(execute?.config?.name).toBe("Draft content");
|
||||
expect(String(execute?.config?.prompt ?? "")).toContain("marketing copywriter");
|
||||
expect(String(execute?.config?.prompt ?? "")).toContain("fn_task_document_write");
|
||||
expect(String(execute?.config?.prompt ?? "").length).toBeGreaterThan(100);
|
||||
expect(review?.id).toBe("editorial");
|
||||
expect(review?.config?.name).toBe("Editorial review");
|
||||
@@ -224,6 +226,13 @@ describe("built-in workflows", () => {
|
||||
const authoredNodeIds = design!.ir.nodes.filter((node) => node.id !== "start" && node.id !== "end").map((node) => node.id);
|
||||
expect(authoredNodeIds).toEqual(["execute", "design-review", "review", "merge"]);
|
||||
|
||||
const execute = design!.ir.nodes.find((node) => node.id === "execute");
|
||||
expect(execute?.config?.seam).toBe("execute");
|
||||
expect(execute?.config?.name).toBe("Execute");
|
||||
const executePrompt = String(execute?.config?.prompt ?? "");
|
||||
expect(executePrompt).toContain("fn_task_document_write");
|
||||
expect(executePrompt).toContain("preview");
|
||||
|
||||
const designReview = design!.ir.nodes.find((node) => node.id === "design-review");
|
||||
expect(designReview?.kind).toBe("gate");
|
||||
expect(designReview?.config?.name).toBe("Design review");
|
||||
@@ -235,6 +244,19 @@ describe("built-in workflows", () => {
|
||||
expect(prompt).toContain("responsive behavior");
|
||||
});
|
||||
|
||||
it("leaves coding-oriented built-in prompts and shared seam defaults on their existing paths", () => {
|
||||
const reviewHeavy = getBuiltinWorkflow("builtin:review-heavy")!;
|
||||
const security = reviewHeavy.ir.nodes.find((node) => node.id === "security");
|
||||
expect(security?.config?.prompt).toBe(
|
||||
"Review the diff for security issues: injection, auth/authorization gaps, secret handling, unsafe deserialization. Block on any exploitable finding.",
|
||||
);
|
||||
|
||||
expect(builtinPromptConfig("execute", "Execute").prompt).toBe(BUILTIN_SEAM_PROMPTS.execute);
|
||||
expect(
|
||||
getBuiltinWorkflow("builtin:quick-fix")!.ir.nodes.find((node) => node.id === "execute")?.config?.prompt,
|
||||
).toBe(BUILTIN_SEAM_PROMPTS.execute);
|
||||
});
|
||||
|
||||
it("repeated catalog reads and listings keep builtin:coding in the enabled order", () => {
|
||||
expect(getBuiltinWorkflow("builtin:coding")?.ir).toBe(BUILTIN_CODING_WORKFLOW_IR);
|
||||
expect(getBuiltinWorkflow("builtin:coding")?.ir).toBe(BUILTIN_CODING_WORKFLOW_IR);
|
||||
|
||||
@@ -6,6 +6,9 @@ import { BUILTIN_WORKFLOW_SETTINGS } from "./builtin-workflow-settings.js";
|
||||
* FNXC:Workflows 2026-06-20-00:25:
|
||||
* The lead-generation built-in must be a first-class v2 workflow with its own business pipeline columns, lead-specific task fields, and inline per-stage prompts instead of coding seams.
|
||||
* The custom non-default column ids make this workflow graph-executor-oriented at runtime while still compiling its linear prompt/gate spine for legacy step materialization.
|
||||
*
|
||||
* FNXC:Workflows 2026-06-21-12:00:
|
||||
* FN-6906 expands each lead-generation stage prompt with explicit inputs, output structure, and quality bars so non-coding agents produce reviewable business artifacts. Enrichment and outreach deliverables must be persisted with fn_task_document_write as the guaranteed path and can additionally use fn_artifact_register when that previewable-artifact tool is available.
|
||||
*/
|
||||
const RAW_BUILTIN_LEAD_GENERATION_WORKFLOW_IR: WorkflowIr = {
|
||||
version: "v2",
|
||||
@@ -76,7 +79,7 @@ const RAW_BUILTIN_LEAD_GENERATION_WORKFLOW_IR: WorkflowIr = {
|
||||
name: "Source prospects",
|
||||
executor: "model",
|
||||
prompt:
|
||||
"Research and identify promising prospects for this lead-generation task. Capture target companies, likely buyer personas, trigger events, and the evidence behind each prospect so downstream qualification can judge fit.",
|
||||
"Research and identify promising prospects for this lead-generation task. Use the task description, target market clues, existing lead fields (company, contactName, contactEmail, leadSource, leadScore, leadStatus), and any supplied ICP or territory constraints. Structure the output with: 1) sourcing assumptions and leadSource recommendation, 2) prioritized prospect/company list, 3) likely buyer persona or contact gaps, 4) trigger events or pain evidence, 5) source links or evidence notes, and 6) risks or missing data for qualification. Good sourcing is specific, traceable, and relevant to the ideal customer; avoid generic company lists, unsupported prospect claims, and invented contact details.",
|
||||
},
|
||||
},
|
||||
{
|
||||
@@ -87,7 +90,7 @@ const RAW_BUILTIN_LEAD_GENERATION_WORKFLOW_IR: WorkflowIr = {
|
||||
name: "Qualify lead",
|
||||
executor: "model",
|
||||
prompt:
|
||||
"Evaluate each sourced prospect against the ideal customer profile. Score company fit, pain urgency, budget or buying signals, and disqualifying risks; update lead score and recommend qualified or lost status with concise rationale.",
|
||||
"Evaluate each sourced prospect or lead against the ideal customer profile. Use the sourcing output, task description, and current lead fields (company, contactName, contactEmail, leadSource, leadScore, leadStatus) to score fit. Structure the output with: 1) company-fit rationale, 2) pain urgency and trigger strength, 3) budget, authority, and buying-signal evidence, 4) disqualifying risks, 5) recommended leadScore with scoring rationale, and 6) recommended leadStatus such as qualified or lost. Good qualification is evidence-based and conservative: continue plausible customer opportunities, but clearly mark weak-fit prospects, missing data, and assumptions rather than overstating certainty.",
|
||||
},
|
||||
},
|
||||
{
|
||||
@@ -98,7 +101,7 @@ const RAW_BUILTIN_LEAD_GENERATION_WORKFLOW_IR: WorkflowIr = {
|
||||
name: "Qualification go / no-go",
|
||||
gateMode: "advisory",
|
||||
prompt:
|
||||
"Advisory check: decide whether this lead should continue to enrichment. Continue for plausible fit, but record any concerns, missing data, or reasons the lead may be low priority.",
|
||||
"Advisory check: decide whether this lead or prospect should continue to enrichment. Use the qualification output, task description, and lead fields (company, contactName, contactEmail, leadSource, leadScore, leadStatus). Structure the advisory result with: 1) go/no-go recommendation, 2) evidence supporting continued enrichment, 3) concerns or missing customer data, 4) suggested leadStatus/leadScore adjustments, and 5) next-best action if the prospect is low priority. Good gate feedback is concise, fair, and useful for a human sales operator; continue plausible-fit companies while documenting risks instead of silently dropping uncertain leads.",
|
||||
},
|
||||
},
|
||||
{
|
||||
@@ -109,7 +112,7 @@ const RAW_BUILTIN_LEAD_GENERATION_WORKFLOW_IR: WorkflowIr = {
|
||||
name: "Enrich lead",
|
||||
executor: "model",
|
||||
prompt:
|
||||
"Enrich the qualified lead with company context and contact data. Add verified company details, relevant news or initiatives, likely stakeholders, contact name, contact email or profile URL, and personalization hooks for outreach.",
|
||||
"Enrich the qualified lead with company context and contact data. Use the task description, sourcing and qualification outputs, and declared lead fields (company, contactName, contactEmail, leadSource, leadScore, leadStatus) as the source of truth for what must be filled or corrected. Structure the enrichment with: 1) verified company summary, 2) relevant news, initiatives, hiring, funding, or technology signals, 3) likely stakeholders and selected contactName/contactEmail or profile URL with confidence notes, 4) personalization hooks for outreach, 5) updated lead field recommendations, and 6) source/evidence links. Good enrichment is verifiable, useful for outreach, and honest about confidence; do not invent emails or private data. Persist the enrichment deliverable as a task document using fn_task_document_write with key \"lead-enrichment\" so the human can review it. If an artifact-registry tool (fn_artifact_register) is available, also register the deliverable as a previewable artifact.",
|
||||
},
|
||||
},
|
||||
{
|
||||
@@ -120,7 +123,7 @@ const RAW_BUILTIN_LEAD_GENERATION_WORKFLOW_IR: WorkflowIr = {
|
||||
name: "Draft and send outreach",
|
||||
executor: "model",
|
||||
prompt:
|
||||
"Draft concise personalized outreach for the enriched lead. Reference the strongest trigger or pain evidence, state the proposed value clearly, choose a low-friction call to action, and record the sent or ready-to-send message plus follow-up timing.",
|
||||
"Draft concise personalized outreach for the enriched lead or prospect. Use the task description, the lead-enrichment task document when present, enrichment output, and declared lead fields (company, contactName, contactEmail, leadSource, leadScore, leadStatus). Structure the deliverable with: 1) outreach strategy and persona assumption, 2) ready-to-send initial message with subject line when appropriate, 3) personalization rationale tied to the strongest trigger or customer pain evidence, 4) low-friction call to action, 5) follow-up timing and alternate follow-up copy, and 6) any compliance or do-not-send caveats. Good outreach is brief, specific, respectful, value-led, and truthful; avoid spammy urgency, unsupported claims, and over-personalization from weak evidence. Persist the outreach draft as a task document using fn_task_document_write with key \"outreach-draft\" so the human can review it. If an artifact-registry tool (fn_artifact_register) is available, also register the deliverable as a previewable artifact.",
|
||||
},
|
||||
},
|
||||
{ id: "end", kind: "end", column: "converted" },
|
||||
|
||||
@@ -5,6 +5,9 @@ import { BUILTIN_WORKFLOW_SETTINGS } from "./builtin-workflow-settings.js";
|
||||
/**
|
||||
* FNXC:WorkflowMarketing 2026-06-20-00:00:
|
||||
* Fusion needs a non-coding built-in workflow for marketing and content work. Keep the engine pipeline unchanged by reusing the standard lifecycle trait vocabulary and the canonical merge-primitive region while exposing marketing-specific columns and prompts for brief, draft, and editorial review phases.
|
||||
*
|
||||
* FNXC:WorkflowMarketing 2026-06-21-12:00:
|
||||
* FN-6906 expands non-coding workflow prompts so marketing agents produce structured, high-quality artifacts instead of thin role-only responses. Deliverable-producing nodes must persist the reviewable content with fn_task_document_write as the guaranteed path and may register a previewable artifact with fn_artifact_register when that tool is available.
|
||||
*/
|
||||
const RAW_BUILTIN_MARKETING_WORKFLOW_IR: WorkflowIr = {
|
||||
version: "v2",
|
||||
@@ -43,7 +46,7 @@ const RAW_BUILTIN_MARKETING_WORKFLOW_IR: WorkflowIr = {
|
||||
seam: "planning",
|
||||
name: "Content brief",
|
||||
prompt:
|
||||
"You are a marketing content strategist. Turn this task into a concrete content brief: audience, channel, key message, format, success metric, required source material, and approval constraints.",
|
||||
"You are a marketing content strategist. Use the task description, any attached context, and prior stakeholder notes to turn the request into a concrete content brief. Structure the output with: 1) audience and customer problem, 2) channel, format, and distribution context, 3) key message and supporting proof points, 4) required source material or claims to verify, 5) success metric, CTA, and approval constraints, and 6) open questions or assumptions. A good brief is specific enough for a marketing copywriter to execute without guessing, avoids unsupported claims, calls out missing inputs, and keeps the scope aligned to the task rather than inventing a campaign.",
|
||||
},
|
||||
},
|
||||
{
|
||||
@@ -54,7 +57,7 @@ const RAW_BUILTIN_MARKETING_WORKFLOW_IR: WorkflowIr = {
|
||||
seam: "execute",
|
||||
name: "Draft content",
|
||||
prompt:
|
||||
"You are a marketing copywriter executing the approved brief. Produce the requested deliverable, following brand voice, audience intent, channel constraints, format requirements, and the brief's success metric.",
|
||||
"You are a marketing copywriter executing the approved brief. Use the task description, the content brief, prior-node output, source material, and any brand or channel constraints to produce the requested deliverable. Structure the response with: 1) a short execution summary, 2) the finished content in the required format, 3) channel-specific variants or subject lines when useful, 4) source/claim notes and assumptions, and 5) a publication-readiness checklist tied to audience intent, brand voice, CTA clarity, format requirements, and the brief's success metric. The copy should be clear, audience-specific, factual, and ready for editorial review; avoid generic filler, unverified claims, and off-brief tangents. Persist the finished content as a task document using fn_task_document_write with key \"marketing-draft\" so the human can review it. If an artifact-registry tool (fn_artifact_register) is available, also register the deliverable as a previewable artifact.",
|
||||
maxRetries: 2,
|
||||
},
|
||||
},
|
||||
@@ -66,7 +69,7 @@ const RAW_BUILTIN_MARKETING_WORKFLOW_IR: WorkflowIr = {
|
||||
seam: "review",
|
||||
name: "Editorial review",
|
||||
prompt:
|
||||
"You are an independent editorial reviewer. Check the draft for brand voice, factual accuracy, audience fit, channel fit, CTA clarity, compliance with the brief, and substantive quality issues; block on issues that would harm publication readiness.",
|
||||
"You are an independent editorial reviewer. Use the task description, the content brief, the marketing draft, and any persisted marketing-draft task document to assess publication readiness. Structure the review with: 1) verdict and publication recommendation, 2) brief-compliance findings, 3) brand voice, audience fit, channel fit, and CTA clarity notes, 4) factual accuracy and unsupported-claim checks, 5) required edits that block publication, and 6) non-blocking polish suggestions. Good editorial review is specific, evidence-backed, and focused on substantive quality issues; block only issues that would harm publication readiness, compliance with the brief, or customer trust, and avoid subjective nits without a clear publication impact.",
|
||||
},
|
||||
},
|
||||
{ id: "merge-gate", kind: "merge-gate", column: "editorial-review", config: { gate: "auto-merge" } },
|
||||
|
||||
@@ -306,13 +306,25 @@ export const BUILTIN_WORKFLOWS: WorkflowDefinition[] = [
|
||||
/**
|
||||
* FNXC:Workflows 2026-06-20-00:00:
|
||||
* Fusion needs a built-in design lane for UI-heavy work. Gate changes on the frontend-ux-design review criteria before the standard review and merge so visual hierarchy, spacing, typography, token consistency, component reuse, responsive behavior, and fit with the design language are checked without custom workflow assembly.
|
||||
*
|
||||
* FNXC:Workflows 2026-06-21-12:00:
|
||||
* FN-6906 requires non-coding design execution to produce a user-facing preview artifact, not just code changes. The execute prompt must keep the execute seam while requiring fn_task_document_write key design-preview as the guaranteed review path and optional fn_artifact_register registration when the previewable-artifact tool exists.
|
||||
*/
|
||||
linear({
|
||||
id: "builtin:design",
|
||||
name: "Design (built-in)",
|
||||
description: "Implement, then run a design/UX review gate before the standard review and merge — for UI-heavy work.",
|
||||
nodes: [
|
||||
{ id: "execute", kind: "prompt", config: builtinPromptConfig("execute", "Execute") },
|
||||
{
|
||||
id: "execute",
|
||||
kind: "prompt",
|
||||
config: {
|
||||
seam: "execute",
|
||||
name: "Execute",
|
||||
prompt:
|
||||
"You are a product-minded UI implementer for design-heavy work. Use the task description, existing UI patterns, relevant design tokens, component library conventions, and any prior planning output to implement the requested frontend/UI change while preserving the product design language. Structure your work output with: 1) implementation summary, 2) files or components changed, 3) design decisions and token/component reuse, 4) accessibility and responsive behavior considerations, and 5) verification notes. After implementation, produce a visual preview for the user: capture before/after states when possible via screenshots, a rendered HTML/markdown preview, or a Storybook story/reference that shows the changed state across relevant viewports. Persist the preview reference and notes as a task document using fn_task_document_write with key \"design-preview\" so the human can preview the UI change before review or merge. If an artifact-registry tool (fn_artifact_register) is available, also register the preview or deliverable as a previewable artifact. Good design execution is consistent, accessible, responsive, token-driven, and easy for the reviewer to inspect; avoid hardcoded visual one-offs, unreviewable screenshots with no context, and changes that cannot be previewed.",
|
||||
},
|
||||
},
|
||||
{
|
||||
id: "design-review",
|
||||
kind: "gate",
|
||||
@@ -320,7 +332,7 @@ export const BUILTIN_WORKFLOWS: WorkflowDefinition[] = [
|
||||
name: "Design review",
|
||||
gateMode: "gate",
|
||||
prompt:
|
||||
"You are a UX design reviewer. Review frontend/UI changes for visual polish and consistency with existing UI patterns and design tokens. Check visual hierarchy and information flow; spacing, typography, margins, padding, gaps, and type scale; color and token consistency, including CSS custom properties/design tokens and no hardcoded colors; reuse of existing components instead of one-off styling or duplication; responsive behavior across viewports; and fit with the product design language, including border radius, shadows, transitions, and icon style. Block merge on real visual-quality regressions such as layout breaks, broken responsive behavior, hardcoded color/token violations, inconsistent component patterns, or design-language mismatches. Do not block or nit when the diff has no frontend/UI impact or no real design issue exists.",
|
||||
"You are a UX design reviewer. Use the task description, implementation diff, existing UI patterns, design tokens, and the design-preview task document produced by the execute node to review frontend/UI changes for visual polish and consistency. Structure the review with: 1) verdict and whether the preview is sufficient for human inspection, 2) visual hierarchy and information-flow findings, 3) spacing, typography, margins, padding, gaps, and type-scale findings, 4) color and token consistency, including CSS custom properties/design tokens and no hardcoded colors, 5) component reuse versus one-off styling or duplication, 6) responsive behavior across relevant viewports, and 7) fit with the product design language, including border radius, shadows, transitions, and icon style. Good design review references the preview or explains why it is missing, focuses on user-visible regressions, and blocks merge on real visual-quality issues such as layout breaks, broken responsive behavior, hardcoded color/token violations, inconsistent component patterns, or design-language mismatches. Do not block or nit when the diff has no frontend/UI impact or no real design issue exists.",
|
||||
},
|
||||
},
|
||||
{ id: "review", kind: "prompt", config: builtinPromptConfig("review", "Review") },
|
||||
|
||||
Reference in New Issue
Block a user