Frontend Shipping Guide

The person asking might be a designer, a product manager or a data analyst. The whole thing is built around that, and it is why this is a skill rather than a document nobody opens.

It answers one question, in eight steps, in the order the work actually happens. Ground yourself in the team's knowledge base. Open the real component. Prove the blast radius. Settle the open questions with the person rather than for them. Write the build guide. Make the ticket. Branch, review, merge. Then update the record.

1. 01Ground yourself in the team's knowledge base

2. 02Open the real component

3. 03Prove the blast radius

   Before a line is written, search for every consumer of the component about to change.

   • One consumer outside

     Stop and raise it

   • An edit to the shared design system

     Stop entirely

     That ships to every page on the site.

   • All inside this feature

     The change cannot reach the rest of the product

4. 04Settle the open questions with the person rather than for them

5. 05Write the build guide

6. 06Make the ticket

7. 07Branch, review, merge

8. 08Update the record

Its output is usually a prompt, not a patch. Most people on that team build in an AI editor, so the deliverable is the instruction they paste: the hard scope rules first, so the model cannot wander, then numbered edits in prop level detail, then the command that verifies it. Anything larger than one component is split into several prompts with a check between each, because a small prompt fails visibly and cheaply.

The scope lock is the step that earns its keep. Before a line is written, search for every consumer of the component about to change. All inside this feature means the change cannot reach the rest of the product, and you say so with line numbers so the person can trust it. One consumer outside means stop and raise it. An edit to the shared design system means stop entirely, because that ships to every page on the site. The conclusion goes into the prompt, the ticket and the review.

It even explains what a pull request is. One reference file does nothing else, in plain language, because a lot of the people using this do not know, which is completely reasonable. That file is the whole design in miniature: the hard part of getting a non engineer to ship is the forty small pieces of assumed knowledge between wanting a change and being allowed to make it.