You design on the real site. Your agent writes the code.
Pixy is a set of instructions you hand your coding agent, an approval you grant in your own browser, and a sentence you say when you are done designing. Nothing between those three is a new place to work in.
No card. One script tag, and you design on the site you already have.
Nothing you do in Pixy changes your website. Every edit is a record, and your coding agent is what turns a record into code.
Name a project, press Copy instructions, and paste them into your coding agent. It asks where you want Pixy, adds the script tag to the head, takes a key of its own and files it with the project's other credentials, and learns what “Check Pixy” means. The invitation lasts ten minutes and works once, so no standing secret sits in a chat log.
Open your site with ?pixy-connect on the end of its address. A black Connect Pixy button sits at the bottom of the page. Click it, sign in, and the right to edit is stored in that browser for that one origin. The key in the tag grants nothing. This approval is the only credential in the chain that does, and it is the one thing the agent cannot do for you.
Press ⌘⇧E on any page of your site and it becomes your canvas. Move, resize, restyle, rewrite, draw new elements, leave comments. Esc leaves. Your site keeps running underneath the whole time.
Your coding agent pulls what you changed with its own key, builds it in the codebase, answers in each task's thread, and closes the record when it lands. You never copy anything across.
Step one is the only one with a choice in it. Install the Chrome extension and skip the tag, or paste the tag into the head yourself and invite an agent afterwards from the Pixy menu. Steps two to four are the same either way.
Design mode attaches to the document your browser already rendered. There is no copy of your site anywhere in Pixy, so there is nothing to sync and nothing to keep in step.
The element you select is the element on the page, with its own classes and its own place in the flow.
Sizes, colors and spacing are read from the stylesheets that shipped, as they were authored.
Signed in, mid-flow, with the menu open, on the record that actually broke the layout.
Change the artboard width and your site's own media queries answer. Nothing is simulated.
A record is your decision written down: what you touched, what it was, what it should be, and the width you set it at.
What the change is addressed to. The shape of the target is the scope, so the agent reads how far to go instead of guessing.
One entry per property changed, each with its before, its after, and the artboard width it was set at, so a base style is told apart from a media query.
Text, markup, a deletion, a new element. A structural change is an entry like any other, not a separate kind of task.
Press C and write. A comment travels in the same batch, addressed to the same thing, for what you cannot say by dragging.
Reload the page and your edits are gone from it. The records are not.
A color you changed on one button is usually a change to the button. Sometimes it is a change to the whole site. The record says which, so the work lands in one place instead of as an inline patch on the instance you happened to click.
An edit to a selector in your CSS. Site-wide, exactly as far as that selector reaches, implemented once at the component.
One of the site's colors, everywhere it appears. The record lists the lines of CSS that write it, custom properties and media blocks included.
One element on one page. A deliberate one-off, and marked as one.
Something born in Pixy, with no selector in your source yet. It arrives with the container it was laid into and the sibling it comes before.
A note about the page itself rather than about anything on it.
The website as a whole.
The agent connects to the project once, keeps its own key, and writes the workflow into the project's own notes. After that, “Check Pixy” is the whole interface. Nothing is installed on its side.
It asks for open records with its key. Pulling locks them to that agent, so two agents never build the same thing, and your panel shows who is holding what.
It implements the batch and nothing outside it, at the scope each record names, in the codebase you already have.
Questions and progress land in the task's thread, in your panel, and you reply there.
A record stays open until the agent closes it. An unacked batch simply arrives again on the next pull, so nothing is lost when a session dies mid-task.
Tasks are optional. Package edits into one yourself when you want a titled batch, or just edit and let the agent name one when it acks.
No card required · works on localhost, staging and production