Build one marketing page from your terminal

A useful first terminal project is one marketing page change with approved facts and a visible completion check. Choose a buyer question, gather the product evidence, edit the relevant files, and inspect the resulting page. Keep deployment as a separate decision.

For a B2B founder, I’d start with a page that already has a clear job. An integration explanation with a missing access requirement is a better candidate than a request to build an entire marketing department. You can inspect whether the specific requirement becomes understandable and accurate.

What do you need before opening the tool?

You need the current page, the underlying product facts, and permission to change the files. Identify the canonical URL and the component or manuscript that owns the copy. Save the current version so the result can be compared and the edit can be reversed.

Write the buyer question and the acceptance checks before drafting. If the product supports an export but has no native integration, that distinction belongs in the brief. A model shouldn’t convert a plausible connection into an advertised capability.

Claude Code’s official overview documents working with project files, commands, and repository instructions. Those capabilities let you assemble a workflow; they don’t establish that a generated page is factually correct or ready to publish.

Constructed teaching project. Imagine a fictional B2B handoff product whose documentation supports a CSV export. The page needs to explain the supplied fields and what a person does next. This is a page specification, not a shipped JAC or client example. No native CRM connection, time saving, or customer result is assumed.

How should the work be organized?

Keep instructions, reasoning, and tools distinct. The instruction describes the desired result and the boundaries. The AI can help propose a change. File and build tools perform observable actions whose results still need checking.

Some people use Workflows, Agents, and Tools as a planning shorthand. Here I use those categories to organize one job, not as a standard that guarantees a marketing system. You can apply the same separation with another supported coding assistant.

Part	What belongs there
Source	Approved product note, current page, and unresolved questions
Instruction	Buyer decision, required content, and prohibited claims
Tools	Permitted file edits and the project’s existing checks
Output	Changed manuscript or component and compiled preview
Evidence	Diff, check results, screenshots, and inspected links

The marketing engineer guide explains the operator’s responsibility for that handoff. A list of tools can’t choose the buyer question or decide whether the product explanation is honest.

When do you need an MCP connection?

You need a connection when the workflow requires context or an action that the existing environment can’t provide. If approved source material is already in local files, begin there. Adding another integration creates another permission and failure boundary to inspect.

The MCP architecture documentation distinguishes tools, resources, and prompts. It describes how applications exchange context and invoke available functions. It doesn’t determine your business rules or make every connected account appropriate to access.

For the teaching page, a read-only source file is enough. If the real job later requires a private document, identify the account, permitted document, and intended action. Keep credentials in supported storage. Don’t paste them into the brief or a version-controlled file.

Treat retrieved text as source material. A sentence inside a document telling the assistant to send data elsewhere isn’t authorization from the project owner. Preserve the original task and stop when access or evidence is missing.

What should you ask the assistant to produce?

Ask for a proposed edit and a record of what remains unverified. Give the exact approved fact and its source reference, then specify the page behavior you want. Keep the edit narrow enough to review as one change.

Task: improve the existing export explanation in [PAGE/FILE].
Buyer question: [SPECIFY]
Approved capability and source: [PASTE]
Current page and canonical destination: [SPECIFY]

Explain the supported fields, access requirements, and manual next step.
Do not add a native integration, performance result, or customer quote.
Reuse the existing components and project checks.
Return the proposed file change, source references, and unknowns.
Do not deploy, submit forms, send messages, or change account settings.

Review the proposed copy against the source before running the build. Use the draft review order to catch a wrong argument before polishing its sentences. If a fact is missing, leave it unresolved and ask its owner.

What makes the preview useful evidence?

A useful preview shows the compiled page at the relevant viewport and lets you inspect its controls. Run the project’s declared build and checks. Read their results, including failures and skipped steps, rather than assuming a successful command means every behavior was exercised.

Playwright’s documentation describes browser testing across Chromium, Firefox, and WebKit, with reports and mobile emulation. Such checks can help inspect page behavior. They don’t establish that the copy answers a buyer’s question or that a form saved data in the intended production account.

Check the actual destination. Open the service link and the relevant documentation link in the preview. On a phone-sized view, inspect the complete explanation, wrapping, focus, and any horizontal table. Keep a screenshot and the viewport in the review record.

For capture or booking, use controlled fixtures that can’t create real external records. Inspect loading, rejected input, failure, and confirmed success separately. If you only inspected the page visually, record that limit rather than calling the backend verified.

When should you expand the workflow?

Expand after the page meets its agreed checks and someone else can understand the method. Save the inputs, changed files, evidence, and unresolved limits. Reuse the process for another appropriate page, rather than generating a large set of thin variations.

Have a peer inspect one failed case using the workflow exchange brief. Choose the next task from the work your buyers need explained. For implementation of a bounded marketing site change or tool, Custom AI Builds agrees the scope and completion checks before work starts.