How to Use ChatGPT to Write Better Prompts for Windsurf

Why ChatGPT prompts matter before Windsurf

Windsurf is useful when I need to move from an idea to a working first version. It can create files, adjust UI, connect routes, and make a project feel alive quickly. But Windsurf is not a mind reader. If I give it a vague instruction, the first version usually reflects that vagueness.

A better prompt does not make the tool perfect. It makes the first build easier to inspect. It gives Windsurf the boundaries: what to change, what to preserve, what not to invent, what files matter, what validation commands should run, and how the final answer should be reported.

That is why I use ChatGPT before Windsurf. ChatGPT helps me slow down for a few minutes and turn a messy request into a practical implementation brief. In real projects, those few minutes often save more time than trying to fix a chaotic first draft later.

My practical AI coding prompt workflow

The flow I use is simple:

Idea -> ChatGPT prompt -> Windsurf first build -> test -> ChatGPT review -> Codex fix

For example, if I want to add a new article to this AI tool review site, I do not ask Windsurf to "write a blog post and fix SEO." That is too broad. I first ask ChatGPT to help define the article purpose, internal links, CTA, sitemap behavior, language requirements, and validation steps.

After Windsurf builds the first version, I test the page in the browser and through local scripts. If the output has broken links, strange Vietnamese labels, layout overlap, or a GitHub Pages route problem, I take screenshots or copy the error. Then ChatGPT helps me write a focused prompt for Codex. Codex is better when the problem is specific.

This is the same workflow I described in my main article, How I Use ChatGPT, Windsurf and Codex to Build Real AI Projects. This supporting guide zooms in on the prompt-writing part.

What I prepare before asking Windsurf

Before I write a Windsurf prompt, I try to collect four things. First, I write the user goal in plain language. Second, I list the files, folders, or pages that are likely involved. Third, I define the safety rules, such as no external API calls, no fake affiliate links, no auto-posting, and no manual edits inside generated docs unless the build pipeline handles it. Fourth, I specify the tests or validation scripts that should run afterward.

This makes the prompt more like a short engineering ticket than a wish. It also makes it easier to review the result. If the task says "update sitemap through the pipeline," then I know to check `sitemap.xml`. If the task says "do not break the language switcher," then I know to check English and Vietnamese versions.

For beginners, this matters because you do not need to know every line of code. You need to know how to describe the result and how to test whether the result actually works.

Prompt example 1 - Build a landing page

When I want Windsurf to create a first version of a landing page, I include the purpose, page structure, internal links, and constraints.

I want you to build a clean static landing page for my AI workflow checklist. Keep the current site style. Add a clear headline, short intro, 5 benefit bullets, an email setup-mode notice, and CTA buttons linking to /free-ai-coding-workflow-checklist/ and /blog/chatgpt-windsurf-codex-workflow/. Do not add external APIs, fake claims, or affiliate links. After editing, tell me which files changed and what command I should run to test.

This prompt works better than "build a landing page" because it tells Windsurf what page to support, what style to keep, which CTA links to use, and what not to do. It also protects the project from fake claims or accidental external integrations.

Prompt example 2 - Fix a mixed language issue

Mixed language is a real issue I have had to fix on this site. A page might have Vietnamese navigation but English table headings, or an English page might accidentally contain Vietnamese UI text. The prompt needs to mention both source and generated output.

Inspect the generated English and Vietnamese pages for mixed language UI. English pages should use English labels. Vietnamese pages should use natural Vietnamese labels. Fix the source generator, not only docs output. Preserve product names like ChatGPT, Windsurf, Codex, Cursor, and GitHub Copilot. Rebuild the site and confirm language integrity passes.

The important part is "fix the source generator, not only docs output." If a tool only edits the generated HTML, the problem comes back the next time I run the build. A good Windsurf prompt should push the fix upstream.

Prompt example 3 - Add SEO metadata

SEO tasks are easy to make messy because there are many small pieces: title, description, canonical, Open Graph, Twitter card, schema, sitemap, and internal links. I try to keep the prompt specific.

Add or verify SEO metadata for this page: unique title, meta description, canonical URL, Open Graph title/description/image, Twitter card, and one H1. Do not change the domain. Do not add fake analytics IDs. If the config is empty, the build should still work. Update sitemap through the normal pipeline.

This is useful for a static site because a page can look fine visually and still be weak for Google Search Console. I want Windsurf to update the right source path and keep the build safe when tracking IDs or verification fields are empty.

Prompt example 4 - Create internal links

Internal links should help the reader move through the topic, not just fill the page with anchors. For this article, the most useful supporting links are the main workflow article, the Windsurf review, the Cursor vs Windsurf comparison, and the AI coding workflow checklist.

Add natural internal links from this article to the main ChatGPT Windsurf Codex workflow article, Windsurf review, Cursor vs Windsurf comparison, and AI coding workflow checklist. Keep link density moderate. Use descriptive anchors. Do not create broken URLs. Do not add fake affiliate links.

I like prompts that say "keep link density moderate" because AI tools can overdo internal linking. A few useful links are better than a page that feels like a navigation dump.

Prompt example 5 - Fix a broken route or 404

Broken routes are common in static sites when the source generated the page locally but the committed `docs/` folder did not include the new output. This is exactly the kind of issue where a focused prompt helps.

The URL /blog/chatgpt-windsurf-codex-workflow/ returns 404 on GitHub Pages. Check whether the route exists in site_output and docs, whether sitemap includes it, and whether the source blog routing list includes the slug. Fix the source pipeline, rebuild, sync docs, and report the exact files that need to be committed.

This prompt tells Windsurf where to look: source routing, `site_output`, `docs`, sitemap, and the commit list. Without that detail, the tool might patch the wrong place or assume the problem is hosting when it is actually a missing generated folder.

How I test the Windsurf output

After Windsurf creates the first build, I do not assume it is ready. I open the page, click internal links, check the CTA, inspect the sitemap, and run the local validation scripts. I look for obvious human issues too: does the page read naturally, does the Vietnamese text make sense, does the heading match the search intent, and does the first screen explain why the article exists?

For AI coding content, I especially check whether the article links back to the main workflow. A supporting post should not live alone. It should help readers discover the bigger system: ChatGPT for planning, Windsurf for the first build, Codex for fixing.

If the page passes local validation but still feels robotic, I revise the prompt. Practical content needs examples from real work: broken routes, mixed language bugs, SEO metadata, internal linking, layout issues, and screenshots. Those details make the article useful.

When I hand the task to Codex

I usually hand the task to Codex when the issue is no longer about creating a first draft. If Windsurf generated the page but the route is missing in `docs`, or the FAQ schema is duplicated, or the language switcher needs source-level changes, Codex is a better fit.

The Codex prompt is more surgical. I include the exact failing URL, the expected behavior, the source files to inspect, the validation commands, and what not to change. This prevents broad refactors and keeps the project stable.

In practice, Windsurf gives me speed and Codex gives me repair quality. ChatGPT connects both by helping me write clearer prompts.

Prompt mistakes I try to avoid

The first mistake is asking for too much at once. "Improve the website" can mean SEO, design, content, routing, language, tracking, and social distribution. That is too broad for one pass.

The second mistake is leaving out constraints. If I do not say "do not call external APIs" or "do not create fake affiliate links," the tool might suggest something that does not fit the project. Constraints are not negative. They keep the work aligned with the real goal.

The third mistake is failing to define the test. A useful prompt should end with something like: run the build, sync docs, validate site, check language integrity, and report the files changed. That makes the result easier to trust.

My reusable Windsurf prompt checklist

• State the exact page, feature, or bug.
• Explain the reader or user goal.
• List required internal links and CTA destinations.
• Tell Windsurf what not to invent or change.
• Ask it to fix source generator files, not only generated output.
• Specify the build and validation commands.
• Ask for a short report with files changed and test results.

If you want a broader version of this process, use the free AI coding workflow checklist. It covers the full loop from idea to ChatGPT, Windsurf, Codex, GitHub Pages, SEO checks, and social drafts.

FAQ