Code and design goals

Last reviewed

Use a code goal for an implementation outcome and a design goal for iterative visual work. Both need a clear brief and a reviewable deliverable.

Code cockpit

Bind the correct project and workspace. Follow the stage trail and tasks. The cockpit provides file search, editing, changes and diff views, and a terminal for relevant commands. Check unsaved changes before closing or moving between files.

Use Start, Pause, Resume, and Stop according to the current state. Send a steer to change direction with clear scope. Where parallel tasks use worktrees, review their results before treating the combined work as complete. A workspace without Git can fall back to sequential execution.

Choose a starting stage

A new build can begin with ideation and requirements. A bug fix, review-comment task, refactor, or investigation may start later with a shorter plan. Check the proposed stages and exit criteria rather than assuming every task needs the same process.

Design cockpit

A design goal exposes the canvas and design tokens: semantic roles, color scales, typography, spacing, radius, elevation, gradients, motion, opacity, blur, and component breakpoints. Nudge the loop with a concrete change such as a warmer accent or tighter spacing.

Build with chat continues the design in a project-bound conversation. Inspect the resulting components and exports, including token JSON, CSS variables, and design documentation where offered.

Review the outcome

Open the actual files or rendered design and compare them with the brief. A supervisor’s verdict should accompany evidence; it is not a substitute for checking the user path that matters to you.

Ask Learn Gideon

Answers from the documentation.

What would you like to know?

Ask a question, find a guide, or get help with your next step.

Enter to send · Shift+Enter for a new line