10 prompts for programmers: from code review to database migrations

Ten prompt templates for everyday developer tasks. Plug in your code and send it through the API: Python code, a cost estimate, and wording tips.

3 min · · development · автоматизация

Prompts for programmers save time on tasks that come up every day: checking code, rewriting a tangled function, writing tests, making sense of a traceback. Below are ten templates. Replace the placeholders in curly braces with your code and send them through a chat or the API. At the end you'll find Python code, a cost estimate, and tips for getting better answers.

Sending prompts through the API

All examples use Zukko's OpenAI-compatible API and the official openai Python SDK:

bash
from openai import OpenAI

client = OpenAI(
    base_url="https://api.zukko.pro/v1",
    api_key="fetch_your_key",
)

response = client.chat.completions.create(
    model="claude-sonnet-5",
    messages=[{"role": "user", "content": "your prompt"}],
)
print(response.choices[0].message.content)

Any model on the Zukko list works: claude-sonnet-5, claude-opus-5-5, gpt-5.6-sol, and for simple tasks the cheaper glm-5.3 or glm-5.3-flash. For the current list, call GET https://api.zukko.pro/v1/models or open the Models page in your dashboard. To find out which model handles your tasks best, send the same template to several models and compare the answers. More on the SDK in the Python reference. Without code, paste the templates into the browser chat.

1. Code review

Code for review: {CODE} Check the code for: 1. Logic errors and edge cases 2. Vulnerabilities 3. Project style violations ({STYLE}, e.g. PEP 8) 4. Missing error handling For each issue: line, what's wrong, a corrected snippet. If there are no issues, say so.

When to use: before committing and before opening a PR.

2. Refactoring

Rewrite this code so it's easier to read and maintain. Behavior and the public interface must stay the same. Language and version: {LANGUAGE_AND_VERSION}. {CODE} After the code, briefly list the changes and why each one helps.

When to use: long functions, duplication, deeply nested conditions.

3. Unit tests

Write pytest unit tests for this function. Cover normal cases, boundary values and errors. Tests must be independent; move shared data into fixtures. {CODE}

When to use: a new function, preparing for a refactor, raising coverage.

4. Debugging an error

Error (full traceback): {ERROR} Code where it happened: {CODE} Environment: {LANGUAGE_AND_LIBRARY_VERSIONS} Explain the cause, point to the place in the code, and propose a fix. If information is missing, say what else you need to see.

When to use: a confusing traceback, behavior you can't reproduce locally.

5. SQL query

Write a PostgreSQL query that: - {REQUIREMENT_1} - {REQUIREMENT_2} Schema: - users (id, name, email, created_at) - orders (id, user_id, total, created_at) - items (id, order_id, product_name, price) Size: orders has about {COUNT} rows. After the query, suggest indexes that would help it.

When to use: complex selects, reports, speeding up slow queries.

6. Regular expression

Write a Python regular expression for: {TASK}. Should match: {EXAMPLES} Should NOT match: {COUNTEREXAMPLES} Answer: pattern = r"..." plus a short explanation of each part.

When to use: parsing logs, validating formats, extracting data from text.

7. Documentation

Write a Google-style docstring for this function: parameters, return value, exceptions (Raises), and a short usage example. {CODE}

When to use: public functions, APIs, code before a release.

8. Commit message

Here is the diff: {DIFF} Write a commit message in Conventional Commits format: <type>: <title under 50 characters> <description if needed: what changed and why> Types: feat, fix, refactor, docs, test, chore.

When to use: before committing, especially after a big refactor. Passing the output of git diff --staged works well.

9. Database migration plan

Current schema: {CURRENT_SCHEMA} What needs to change: {REQUIREMENTS} The table has about {COUNT} rows and is under live load. Write an Alembic migration plan: 1. Ordered steps that avoid long table locks 2. How to roll back each step 3. How to verify the result

When to use: new columns, renames, type changes on large tables.

10. Security review

Code: {CODE} Check the code for: 1. SQL injection 2. XSS (if HTML is generated) 3. Missing input validation 4. Secrets hardcoded in the source 5. Broken access-control checks For each finding: the risk, an example attack, the fix.

When to use: code that handles user input, before shipping to production.

Example: a review script that tracks tokens

bash
from openai import OpenAI

client = OpenAI(
    base_url="https://api.zukko.pro/v1",
    api_key="fetch_your_key",
)

REVIEW_TEMPLATE = """Code for review:

{code}

Check the code for logic errors, vulnerabilities and missing error handling.
For each issue: line, what's wrong, a corrected snippet."""

Streaming is handy for long answers. The server sends a final chunk with usage and an empty choices, so check before touching chunk.choices[0]:

bash
stream = client.chat.completions.create(
    model="claude-sonnet-5",
    messages=[{"role": "user", "content": prompt}],
    stream=True,
)
for chunk in stream:
    if chunk.choices and chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="", flush=True)

Getting better answers

  • Be specific instead of "check the code". "Check for SQL injection and race conditions under concurrent requests" gets a more useful answer.
  • Examples. For regexes and parsers, show two or three examples of what should and shouldn't match.
  • Context. One line like "this is a FastAPI service handling 1000 RPS" changes the advice.
  • Answer format. Ask for a table, a list, or code only; it makes answers easier to parse and compare.

More on request parameters in the chat completions reference.

FAQ

Can I combine several templates in one request?

Yes, for example "first find the bugs, then write tests for the fixed version". But a long multi-step task in a single request usually comes out less tidy than two sequential requests.

How much does one request cost?

Cost is per token. In Zukko, claude-sonnet-5 and gpt-5.6-sol cost $0.3 per 1M input tokens and $0.3 per 1M output tokens. Say a template with a 50-line function takes 750 tokens and the answer takes 800. Then (750 + 800) × $0.3 / 1,000,000 ≈ $0.00047. Exact numbers for every request are in response.usage and on the Usage page of your dashboard. Create an API key in your dashboard.

How do I keep a history of prompts?

Write each call to JSONL along with the real usage figures:

bash
import json
from datetime import datetime


def log_call(prompt: str, answer: str, usage) -> None:
    entry = {
        "time": datetime.now().isoformat(),
        "prompt": prompt[:200],
        "answer": answer[:500],
        "prompt_tokens": usage.prompt_tokens,
        "completion_tokens": usage.completion_tokens,
    }
    with open("prompt_log.jsonl", "a", encoding="utf-8") as f:
        f.write(json.dumps(entry, ensure_ascii=False) + "\n")

What if a model is disabled?

The gateway returns HTTP 503 with code model_disabled. Pick another model from GET https://api.zukko.pro/v1/models and retry.

zukko

Pay 25×
less

for Claude Code & ChatGPT

One fetch_* key and base URL api.zukko.pro — for Cursor, Claude Code, Codex, and any SDK.

Get API keyDocumentation

api.zukko.pro · fetch_*

Prompts for programmers: 10 ready-made templates · Zukko