engineering

Code Generation Prompt

Step-by-step prompt engineering template for generating production-quality code from requirements — covering input gathering, constraint specification, output formatting, and iterative refinement.

code-generationprompt-engineeringai-promptstemplates

Works well with agents

Code Generator Agent Prompt Engineer Agent Vibe Coder Agent

Works well with skills

PRD Writing Technical Spec Writing

$ npx skills add The-AI-Directory-Company/(…) --skill code-generation-prompt

code-generation-prompt/

SKILL.md

Markdown

1
2	# Code Generation Prompt
3
4	## Before you start
5
6	Gather the following from the user before generating any code:
7
8	1. What does the code need to do? — Specific behavior, not vague goals
9	2. What language and framework? — Including version constraints
10	3. What are the inputs and outputs? — Data types, formats, example values
11	4. What are the constraints? — Performance requirements, dependencies allowed, compatibility targets
12	5. Where does this code live? — Standalone script, library function, API endpoint, UI component
13	6. Are there existing patterns to follow? — Link to existing code in the repo or style guide
14
15	If any of these are missing, ask before proceeding. Generating code from incomplete requirements produces throwaway output.
16
17	## Procedure
18
19	### 1. Define the requirement in structured form
20
21	Write the requirement as a structured block before generating code. This prevents drift between what was asked and what gets built.
22
23	```
24	TASK: [one sentence describing the function]
25	LANGUAGE: [language + version]
26	FRAMEWORK: [framework + version, or "none"]
27	INPUTS: [list each input with type and example value]
28	OUTPUTS: [return type with example value]
29	CONSTRAINTS: [performance, security, compatibility requirements]
30	ERROR CASES: [what should happen when inputs are invalid]
31	```
32
33	### 2. Choose the generation strategy
34
35	Select one based on complexity:
36
37	- Direct generation — For isolated functions under 50 lines. Write the full implementation in one pass.
38	- Scaffold-then-fill — For modules with multiple functions. Generate the interface (function signatures, types, exports) first, then implement each function.
39	- Test-first generation — For logic-heavy code. Generate test cases from the requirements first, then write the implementation to pass them.
40
41	### 3. Write the prompt
42
43	Structure the prompt in this order:
44
45	1. Role and context — What the code is part of, what conventions to follow
46	2. Exact task — What to implement, referencing the structured requirement
47	3. Input/output contract — Types, validation rules, example values
48	4. Constraints — What NOT to do (no external dependencies, no async, no mutation, etc.)
49	5. Output format — Single file, multiple files, include tests, include types
50
51	### 4. Generate and validate
52
53	After receiving generated code:
54
55	1. Read the code line by line — do not assume correctness
56	2. Verify every input is validated before use
57	3. Verify every error case from the requirement is handled
58	4. Check that no hallucinated imports or APIs are referenced
59	5. Run the code or tests if possible
60
61	### 5. Iterate with targeted follow-ups
62
63	If the output needs changes, do not re-prompt from scratch. Use targeted corrections:
64
65	- "The function handles the happy path but does not validate that `email` is non-empty. Add input validation for all string parameters."
66	- "Replace the `lodash.groupBy` dependency with a native `Object.groupBy` or manual reduce."
67	- "The error messages are generic. Use specific messages: 'Email is required', 'Email must contain @'."
68
69	## Prompt templates
70
71	### Template A: Standalone function
72
73	```
74	Write a [LANGUAGE] function called [NAME] that:
75	- Takes: [PARAM1: TYPE], [PARAM2: TYPE]
76	- Returns: [RETURN_TYPE]
77	- Behavior: [EXACT DESCRIPTION]
78	- Edge cases: [LIST EACH CASE AND EXPECTED BEHAVIOR]
79	- Do not use external dependencies.
80	- Include JSDoc/docstring with parameter descriptions.
81	```
82
83	### Template B: API endpoint
84
85	```
86	Write a [FRAMEWORK] [METHOD] endpoint at [PATH] that:
87	- Accepts: [REQUEST BODY/PARAMS SCHEMA]
88	- Returns: [RESPONSE SCHEMA] with status [CODE]
89	- Validation: [RULES FOR EACH FIELD]
90	- Error responses: [STATUS CODE + BODY FOR EACH ERROR CASE]
91	- Authentication: [REQUIRED/OPTIONAL, METHOD]
92	- Follow the existing patterns in [REFERENCE FILE].
93	```
94
95	### Template C: UI component
96
97	```
98	Write a [FRAMEWORK] component called [NAME] that:
99	- Props: [LIST EACH PROP WITH TYPE AND DEFAULT]
100	- Renders: [DESCRIBE THE VISUAL OUTPUT]
101	- Interactions: [CLICK, HOVER, FOCUS BEHAVIORS]
102	- States: loading, error, empty, populated
103	- Accessibility: [ARIA LABELS, KEYBOARD NAVIGATION]
104	- Use [STYLING APPROACH] for styles.
105	```
106
107	## Quality checklist
108
109	Before delivering generated code, verify:
110
111	- [ ] Every input from the requirement is used in the implementation
112	- [ ] Every output matches the specified type and format
113	- [ ] Error cases are handled with specific messages, not silent failures
114	- [ ] No hallucinated imports — every dependency actually exists
115	- [ ] No hardcoded values that should be parameters or constants
116	- [ ] Code follows the language's naming conventions and idioms
117	- [ ] The code is readable without the prompt — someone seeing it for the first time can understand it
118
119	## Common mistakes
120
121	- Prompting with vague requirements. "Write a function that processes data" produces useless code. Specify exact inputs, outputs, and edge cases.
122	- Accepting generated code without reading it. AI-generated code compiles but may contain subtle logic errors, hallucinated APIs, or security gaps. Read every line.
123	- Over-constraining the prompt. Specifying implementation details (use a for loop, use reduce) instead of behavior leads to awkward code. Specify WHAT, not HOW.
124	- Ignoring the iteration step. First-pass generation is rarely production-ready. Plan for 2-3 rounds of targeted refinement.
125	- Skipping error handling in the prompt. If the prompt does not mention error cases, the generated code will not handle them. Always specify what happens when things go wrong.
126	- Not including examples. One concrete input/output example in the prompt eliminates more ambiguity than three sentences of description.
127