Every developer has seen the “10 Best Prompt Engineering Tips” articles. They all say the same thing: “be specific,” “provide context,” “use examples.” Thanks, very helpful.
Here’s the thing — I actually use AI prompts professionally, every single day. Not just for fun experiments or writing emails. I run an entire blog (this one) through a system where I send a Korean message to a Telegram bot, and AI handles everything: writing, formatting, SEO optimization, image selection, WordPress publishing, and scheduling. The prompts I use aren’t theoretical. They’re battle-tested.
This post shares the actual prompts I use daily, explains why they work, and shows you the difference between a vague prompt and one that gets results.
1. Blog Post Writing Prompts: The Real Template
Let me show you the actual system prompt my Telegram bot sends to Claude when I request a new blog post. This isn’t simplified — this is the real thing:
You are managing the blog reapbountifully.com.
The user wants to write a new blog post. Here is their request (in Korean):
"{topic}"
IMPORTANT: Do NOT publish the post yet. Only WRITE the post content.
Follow these steps:
1. Write the blog post in English based on the user's Korean input.
2. The post should follow the blog's style:
- Conversational, natural tone (not stiff or AI-sounding)
- Include a "How This Post Was Made" section at the end
- End with the transparency footer
- Show the process of how the post was made
3. Suggest the most appropriate category from:
- 12: Vibe Coding
- 13: Blog Building
- 14: Side Hustle
- 15: AI & Tech Trends
- 16: Korea & Current Events
Respond with EXACTLY this format (in Korean):
---
제목: [English title]
카테고리: [category name] (ID: [number])
---
[Full post content in English below]
Let’s break down why this works:
- Role assignment: “You are managing the blog reapbountifully.com” — not “you are a helpful assistant.” The AI knows exactly what it’s doing and for whom.
- Input language ≠ Output language: My input is Korean, but the output is English. The prompt explicitly handles this translation layer.
- Style constraints are specific: “Conversational, natural tone” is vague on its own, but combined with “not stiff or AI-sounding” and required sections like “How This Post Was Made,” the AI has concrete guardrails.
- Structured output format: The exact response format is defined. No guessing, no “here’s what I came up with!” preamble.
- Explicit negation: “Do NOT publish the post yet” prevents the AI from jumping ahead in the pipeline.
2. Code Generation Prompts: Being Specific About What Matters
When I ask AI to generate code, the biggest mistake developers make is leaving too much to interpretation. Here’s how I approach it.
Bad prompt:
Write a function that uploads photos to a server.
This will give you something generic, probably in the wrong language, with no error handling, and using libraries you don’t want.
What I actually use (from my blog’s photo upload pipeline):
Write a Python async function that:
1. Downloads a photo from Telegram using bot.get_file(file_id)
2. Saves it locally to /tmp/bot_photos/ with the file_unique_id as filename
3. SCPs it to a remote server using sshpass (asyncio.create_subprocess_shell)
4. Returns a list of dicts with {index, remote_path} for each uploaded file
5. Handles individual photo failures without crashing the batch
6. Logs each upload with logger.info
The difference? The second prompt specifies:
- Language and paradigm: Python, async
- Exact libraries/APIs: Telegram bot API, sshpass, asyncio subprocess
- File paths and naming conventions: /tmp/bot_photos/, file_unique_id
- Return type: List of dicts with specific keys
- Error handling strategy: Don’t crash the batch on individual failures
- Logging expectations: Use logger.info, not print()
Every unspecified detail is a decision the AI makes for you. Sometimes that’s fine. Often it’s not.
3. Debugging Prompts: Give the AI Everything
Debugging is where prompt engineering really shines — or really fails. Here’s the template I use:
I'm getting this error:
[paste exact error message and stack trace]
Here's the relevant code:
[paste the function/file]
Here's what I expect to happen:
[describe expected behavior]
Here's what actually happens:
[describe actual behavior]
Environment: Python 3.9, Ubuntu 22.04, WordPress CLI
The key elements:
- Exact error, not a summary: “It doesn’t work” vs. the actual traceback — night and day difference.
- Relevant code, not all code: Don’t paste your entire project. Paste the function that’s failing and its immediate dependencies.
- Expected vs. actual: This is the most underrated part. The AI needs to understand the gap between what you want and what you got.
- Environment details: Python version, OS, relevant tools. A solution for Python 3.12 might not work on 3.9.
Real example from building this blog’s bot: I was getting timeout errors when Claude took too long to generate posts. My debugging prompt included the exact asyncio.TimeoutError traceback, the run_claude() function code, and the fact that I was using asyncio.wait_for with a 300-second timeout. The AI immediately identified that the issue was in how I was handling the subprocess communication, not the timeout value itself.
4. System Prompts vs. User Prompts: When to Use Each
This is something most “prompt engineering” articles skip entirely, but it matters a lot in production systems.
System prompts define WHO the AI is and HOW it should behave. They persist across the entire conversation. Use them for:
- Role definition (“You are managing the blog reapbountifully.com”)
- Output format requirements
- Tone and style guidelines
- Safety rails and forbidden actions
- Category lists, configuration data — anything that doesn’t change between requests
User prompts define WHAT the AI should do RIGHT NOW. They change every time. Use them for:
- The specific topic or task
- User feedback (“make it shorter,” “add more examples”)
- Dynamic data (current draft content, photo paths, server responses)
In my blog system, the system-level instructions (style, categories, format) are hardcoded in the bot. The user prompt is whatever I type into Telegram. This separation means I don’t have to repeat “use a conversational tone” every time — it’s baked into the system.
Here’s what my feedback/revision prompt looks like — notice how the system context (blog identity, format rules) is repeated, but the user input is dynamic:
You are managing the blog reapbountifully.com.
You previously wrote a blog post draft. Here is the current draft:
---
{current draft content}
---
The user has provided feedback (in Korean):
"{user feedback}"
Please revise the draft based on this feedback. Keep the same format.
5. The Biggest Mistake: Being Too Vague vs. Too Specific
There’s a sweet spot in prompt engineering, and most people miss it in both directions.
Too vague:
Write a blog post about AI.
You’ll get 800 words of generic fluff that sounds like every other AI-generated article. No personality, no specific examples, no unique angle.
Too specific (yes, this is a thing):
Write a 1,247-word blog post about AI. The first paragraph must be exactly 3 sentences. Use the word "innovative" exactly 4 times. Include 7 subheadings. The second subheading must mention Python. End every third paragraph with a question.
This produces robotic, unnatural writing because the AI is spending all its capacity counting words and following arbitrary rules instead of writing well.
The sweet spot:
Write a blog post about how I use AI to run my blog.
- Conversational tone, not corporate
- Include real examples from my workflow
- Target audience: developers considering starting a blog
- Include a "How This Post Was Made" section
- Keep it practical — what works, what doesn't
This gives the AI enough direction to be useful while leaving room for natural, creative writing. You constrain the intent and style, not the mechanics.
6. Chain-of-Thought Prompting for Complex Tasks
When a task has multiple steps, don’t dump everything into one prompt and hope for the best. Break it into a chain.
My blog publishing pipeline is actually a three-stage chain:
Stage 1 — Write: Generate the blog post content (no publishing)
Stage 2 — Review: I read the draft, send feedback, AI revises (can loop multiple times)
Stage 3 — Publish: SSH into server, save content, create WordPress post, set SEO fields, handle featured image, assign category
Each stage gets its own focused prompt. The publishing prompt alone handles:
- SSH connection to the server
- Saving post content to a temp file
- Creating the WordPress post with WP-CLI
- Setting the post status (publish/future)
- Checking existing scheduled posts to avoid conflicts
- Setting Yoast SEO focus keyphrase and meta description
- Downloading and importing a featured image
- Assigning the correct category
If I tried to combine writing + reviewing + publishing into one prompt, the quality of each step would drop. The AI would rush through writing to get to publishing, or forget SEO fields because it was focused on content quality.
The rule: One prompt, one clear objective. Chain prompts for multi-step workflows.
7. Before and After: Real Prompt Refinement
Let me show you a real evolution from my blog workflow.
My first attempt at a trending topics prompt:
What are some good blog topics based on trending keywords?
Result: Generic suggestions like “Write about AI trends” and “Cover the latest tech news.” Useless.
My refined version (actually in production):
You are a blog content strategist for reapbountifully.com.
The blog is run by a Korean developer living abroad. The blog covers:
- Vibe Coding (AI-assisted development)
- Blog Building (WordPress, SEO, automation)
- Side Hustle (making money with tech/AI)
- AI & Tech Trends
- Korea & Current Events (Korean perspective on global issues)
Here are the current TRENDING keywords in the US:
{keyword_context}
Suggest exactly 5 blog post ideas that:
1. Connect a trending topic to the blog's niche/perspective
2. Have high SEO potential (people are searching RIGHT NOW)
3. Could include a unique Korean developer's perspective
4. Are interesting enough to click on
For each suggestion, provide:
- A catchy English title
- Which trending keyword it's based on
- Which blog category it fits
- One sentence explaining the angle
Result: Specific, actionable topic suggestions that combine trending search terms with my blog’s actual niche. The suggestions are publishable ideas, not vague directions.
What changed? Everything:
- Role assignment (content strategist, not generic assistant)
- Context about the blog (niche, audience, perspective)
- Real data input (actual trending keywords, not “trending keywords”)
- Specific output requirements (5 ideas, not “some”)
- Quality criteria (SEO potential, unique angle, clickworthy)
- Structured output format (title, keyword, category, angle)
The Takeaway: Prompts Are Code
If you’re a developer, think of prompts the way you think of function signatures. A good function has:
- Clear input types (what data goes in)
- Defined return types (what you expect back)
- Error handling (what to do when things go wrong)
- Documentation (what this function is for)
Good prompts have the exact same properties. The role is documentation. The format requirements are return types. The constraints are error handling. The context is input data.
Stop treating prompts as casual conversation. Start treating them as interfaces to a system. That’s what actually works in 2026.
How This Post Was Made
I told Claude (in Korean): “개발자를 위한 프롬프트 엔지니어링 글 써줘. 뻔한 팁 나열 말고, 내가 실제로 매일 쓰는 프롬프트 보여주면서 설명해.”
Claude pulled the actual prompt templates from my Telegram bot’s source code — the same bot that published this very post. The code examples in this article aren’t made up. They’re extracted from bot.py, the file that powers the entire reapbountifully.com publishing workflow.
The irony isn’t lost on me: this is a post about prompt engineering, written by an AI, using prompts that were engineered by a human, published through a system that’s itself a prompt engineering project. It’s prompts all the way down.
This post was written with Claude AI. I provided the direction, topic, and key points in Korean — Claude turned it into the article you just read. The code examples are real, pulled directly from the production codebase that runs this blog.