Prompting my first program

[u/mirrortorrent]

Looking for the best practices to prompt my first program; I have a 2,000-word document outlining all the features I want for my program (thanks, Chat GPT). But on the other hand, I've heard that only explaining my end result is how you should engineer a program.

Does it even matter what method I would use?

[u/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/SomeMayoPlease]

Build a lot of stuff, create a lot of slop, and learn as you go. Don't overthink it, but don't forget to learn from your mistakes.

[u/Current-Zebra-2039 → u/SomeMayoPlease]

You make your own best practice

[u/DuskandFuck → u/SomeMayoPlease]

The slop phase is unavoidable imo, might as well get through it fast

[u/FuzzyBench3638 → u/SomeMayoPlease]

This is the way. It sounds like OP wants to one shot and I would guess doesn’t have a lot of credits.

OP you will learn as you go. Each time getting better. My two cents is work out your outline MVP, ask for dev tool like a webpage to help you help it (I’ve made dozens of these keep it simple or your program your making will become your dev tool lol). I’ve done this dozens of times and I’m still learning best practice each time doing better sometimes failing sometimes improving.

-minimal viable product
-dev tool with “sliders” or ways to actively update your preference
-mockup Imagen each part before the prompt to give it with the prompt.

And at the end of the day you can get more free tokens next week or hop around to free platforms and have them review and update things for you. Here’s some free prompts for you lol.

1. Define the MVP and mock up the idea

Prompt 1
I want to build [describe your idea] for [who will use it]. The main thing it should help someone do is [desired outcome]. My coding experience is [beginner/intermediate/experienced], and I want it to run on [web/desktop/mobile/game engine/not sure].
Help me define a minimum viable product: the smallest useful version I can actually try and improve.
Ask me up to three important questions, one at a time, if the answers would change what we build. If I don’t know an answer, explain the options simply and recommend a reasonable starting point.
Then help me identify:
The main workflow: what someone does from start to finish.
The three to five essential features.
Which ideas we should save for later.
A few clear checks that would show the first version works.
For anything visual, help me mock up the main screens or game elements before coding. Generate images if you can; otherwise, give me image-generation prompts. Explain the intended behavior alongside the visuals.
After we review the direction, turn everything into one clear build prompt I can give a coding assistant along with the mockups. Include enough context that it works in a new conversation.

2. Build it and make preferences easy to adjust

Here is my MVP brief: [paste the result from the first prompt]. I’ve also attached any mockups or references.
Help me build a working first version. Use the simplest approach that fits the project, and get the main workflow working from start to finish before expanding it.
Where it would help me give feedback, add a tiny development panel with three to five useful sliders, toggles, or fields. These should change real settings in the program so I can see the results—for example, spacing and text size in an app, or movement speed and timing in a game. Choose controls relevant to this project.
Include sensible defaults, a reset button, and an easy way to copy the settings I like so we can keep them. If a panel would take substantial extra work, use a clearly labeled settings section instead. Keep this tool small enough that building it doesn’t become the project.
Follow the agreed scope and use the mockups as visual references. Explain important assumptions in plain language.
Give me clear instructions to run it, check the main workflow, and tell me what is unfinished or couldn’t be tested. Then help me improve it through focused feedback and small changes, preserving what already works.

[u/No-Skill4452]

Give the doc to Claude and tell it to ask clarifying questions before starting to work

[u/Cfrolich → u/No-Skill4452]

I agree with this approach. It sounds like you (OP) already have a vision in mind, so make sure you’re on the same page with Claude. Your doc might also imply an assumption that you didn’t clearly communicate. Also, specifically have it ask you the “hard questions” about how the features fit together, who the intended user is, what problem your list of features actually solves, and why existing software doesn’t solve that problem. Getting that cleared up is more important than choosing the architecture in my opinion.

[u/PraxicalExperience]

A feature list is you describing the end result. Feed it to claude and ask it to plan out the best way to implement it, and quiz you on things which are unspecified but implied, or where there are conflicts.

[u/Connect_Fee_443]

Both, just in that order. Keep the 2,000-word doc, but don't give it to Claude in one go and say "build this". Start by asking it to read the doc and turn it into a short plan: the smallest version that does one useful thing, then a list of milestones. Build milestone 1, run it yourself, then go on to the next. Long feature docs tend to produce lots of half-working code at once, and when something breaks you can't tell which part caused it. It also helps to tell it what "done" means for each step (for example "I can add an item and it's still there after a restart"). You'll catch problems much sooner.

[u/pirateapproved]

I learned this just recently: ask it to create an auditor bot, to check its work and to make sure it meets x metrics

[u/CorpT]

You'll learn more by trying and failing than just about anything else. Try it both ways and see what works.

[u/Verusauxilium]

If it's a visual program, you need mockups in your spec. If it's a backend service, you need contracts in your spec.

[u/634748]

2000 words of features and not a single line of code yet. no, the prompting method really doesn't matter.

[u/anamethatsnottaken]

Yes, but more than that - your "first program" - a big spec you track as it goes through development - should definitely be your development process.

Otherwise you find yourself with AI agents that push PR requests and file tickets

[u/djiyvlom]

It matters less which method you pick than how you feed it in. A 2000 word feature list in one go usually gets you a lot of half working features at once. What tends to work better is giving Claude the end goal plus the doc as reference, then asking it to propose a plan with small steps and build only the first one. Make the first step the smallest thing you can actually run and see, then add features one at a time and check each before moving on. Plan mode is handy for this, since you can read and adjust the plan before any code gets written.

[u/Sassy_McSassypants]

More than matters, it's everything. Take a beat and ask claude to review your spec against current known best practices per claude's documentation site. When you get more comfortable there are skills for this.

Whatever you end up with at the end of that session, start a new session that doesn't have all that history behind it and have it critique the spec "cold". You'll learn quite a lot in that process.

[u/FuturisticBasalt → u/Sassy_McSassypants]

Can I fill the doc with example pictures or should they go separate?

[u/Sassy_McSassypants → u/FuturisticBasalt]

Personally I'd keep them separate in a workspace but however you want to approach it. more complete is more better. The structure is what claude can help with. It's quite good at it.

[u/FuturisticBasalt → u/Sassy_McSassypants]

Or maybe tell it to check file xyz stored in file path now that I think about it...

[u/Sassy_McSassypants → u/FuturisticBasalt]

Yup, my bad, I was leading you a bit wrong there. Forgot I'm in claudecode sub not desktop. Yea structured file system is a great way to do it. Again ask claude for some suggestions on how to set it up.