28 Kimi Prompts for Coding (2026)

Write a [LANGUAGE version] function that [WHAT IT SHOULD DO]. Inputs: [DESCRIBE INPUTS AND TYPES]. Output: [DESCRIBE RETURN]. Constraints: [PERFORMANCE / MEMORY / STYLE]. Handle invalid input explicitly. Return the function with a short docstring, then list any assumptions you made and any edge cases the caller still needs to handle.

Scaffold a [WHAT] in [LANGUAGE / FRAMEWORK version]. It should [CORE FEATURES]. Give me the file structure first as a tree, then the contents of each file, using idiomatic patterns for this framework. Keep dependencies minimal and note which ones I need to install. End with the exact commands to run it locally.

Write a [METHOD] endpoint at [ROUTE] in [FRAMEWORK version] that [WHAT IT DOES]. Validate the request body against these rules: [RULES]. Return proper status codes for success, validation errors, and server errors, and never leak internal errors to the client. Include the route handler, the validation schema, and a sample request and response.

Write a command-line script in [LANGUAGE version] that [WHAT IT SHOULD DO]. It takes these arguments/flags: [DESCRIBE THEM]. Handle missing or bad arguments with a clear usage message, print progress for long operations, and exit with meaningful codes. Add a --help output and a one-line comment above each main step.

Convert this [SOURCE LANGUAGE] code to [TARGET LANGUAGE version], keeping the behavior identical: [PASTE CODE]. Use idiomatic patterns and standard libraries for the target language rather than a literal line-by-line translation. Point out anything that doesn't map cleanly, and note any behavior differences I should test after the port.

Turn on Thinking mode. I'm getting this error in [LANGUAGE / FRAMEWORK version]: [PASTE ERROR]. Here's the relevant code: [PASTE CODE]. Walk through the likely root cause step by step, give me the corrected code, and explain in two sentences what was actually wrong. If more than one cause is possible, rank them by likelihood. Then verify the fix against the error and list any edge cases you didn't handle.

Turn on Thinking mode. This code is supposed to [EXPECTED BEHAVIOR] but instead it [ACTUAL BEHAVIOR]. There's no error thrown. Here's the code: [PASTE CODE]. Input that triggers it: [PASTE INPUT]. Reason through the execution path step by step, find where the actual and expected behavior diverge, and give me the fix plus a one-line explanation of the bug.

Turn on Thinking mode. This concurrent code in [LANGUAGE version] occasionally [HANGS / RETURNS WRONG DATA / DEADLOCKS] under load, but works in single-threaded tests: [PASTE CODE]. Identify the shared state and the interleavings that cause the problem, explain the exact sequence that goes wrong, and give me a corrected version. Note which synchronization primitive you chose and why.

Explain this stack trace in plain English and tell me where to start looking: [PASTE STACK TRACE]. My environment is [LANGUAGE / RUNTIME / FRAMEWORK version]. Identify the actual failing line versus library noise, the most likely cause, and the two or three things I should check first. If you need to see a specific file to be sure, tell me which one.

Turn on Thinking mode. This code is slower than it should be for input of size [SIZE]: [PASTE CODE]. Analyze its time and space complexity, identify the actual bottleneck (not just style), and propose the highest-impact optimization first. Give me the improved code, state the new complexity, and note any tradeoff in readability or memory I'm accepting.

Refactor this code for readability and maintainability without changing behavior: [PASTE CODE]. Improve naming, reduce nesting, extract logic where it clarifies intent, and remove dead code. Keep it idiomatic for [LANGUAGE version] and add no new dependencies. Return the refactored version, then a short bullet list of what you changed and why.

Modernize this legacy [LANGUAGE] code to current [LANGUAGE version] idioms and best practices, keeping behavior identical: [PASTE CODE]. Replace deprecated APIs, use modern language features where they genuinely improve the code, and keep the public interface stable. List each change with the reason, and flag anything that needs a test before I ship it.

Add robust error handling and logging to this code without changing its happy-path behavior: [PASTE CODE]. Handle the failure modes that actually matter here (bad input, network, timeouts, missing data), fail loudly where it should and gracefully where it can recover, and log enough context to debug in production without leaking secrets. Use idiomatic [LANGUAGE version] patterns and explain each addition briefly.

Review this code as a senior engineer would before approving the merge: [PASTE CODE OR DIFF]. Check correctness, edge cases, error handling, security, and readability. List issues grouped as Blocking, Should-fix, and Nitpick, each with the line or function and a concrete suggested change. Be direct; don't pad the review with praise.

Explain what this code does to a developer new to [LANGUAGE / LIBRARY version]: [PASTE CODE]. Start with a one-paragraph overview of its purpose, then walk through the tricky parts block by block. Call out any bugs, edge cases, or performance concerns you notice along the way, and end with the one thing I most need to understand before changing it.

Write thorough unit tests for this function using [TEST FRAMEWORK]: [PASTE FUNCTION]. Cover the happy path, edge cases, invalid inputs, and boundary conditions. Give each test a clear name and a one-line comment on what it verifies. If any behavior in the function looks like a bug or is ambiguous enough to need a spec decision, note it separately instead of testing the buggy behavior as correct.

Generate a set of test inputs for a function that [WHAT IT DOES], with signature [PASTE SIGNATURE]. Cover typical cases, boundaries, empty and null values, extreme sizes, and malformed input. Present them as a table: input | why it matters | expected behavior. Call out any inputs where the correct behavior isn't obvious and needs a decision.

Write an integration test in [TEST FRAMEWORK] for this flow: [DESCRIBE THE FLOW, e.g. request hits endpoint, writes to DB, returns response]. Here's the relevant code: [PASTE CODE]. Set up and tear down any state cleanly, test the real interaction rather than mocking everything, and assert on the observable outcome. Note any external dependency I should stub and why.

I just fixed this bug: [DESCRIBE THE BUG AND THE FIX]. Here's the fixed code: [PASTE CODE]. Write a regression test in [TEST FRAMEWORK] that would have failed before the fix and passes now, so this exact bug can't come back silently. Name the test after the bug, and add a one-line comment linking it to what went wrong.

Write a [PostgreSQL] query for this request: [WHAT I WANT]. Here's the schema: [PASTE TABLES / COLUMNS]. Return the query, a one-line explanation of each join and filter, and a note on which indexes would keep it fast at scale. If my request is ambiguous, state the assumption you made rather than guessing silently.

Turn on Thinking mode. This [DATABASE version] query is slow: [PASTE QUERY]. Schema and rough row counts: [PASTE DETAILS]. Here's the query plan if it helps: [PASTE EXPLAIN OUTPUT]. Explain why it's slow, rewrite it for performance while returning identical results, and recommend the specific indexes to add. Show the before-and-after and estimate the impact.

Build a regex for [LANGUAGE / FLAVOR] that matches [WHAT TO MATCH] but not [WHAT TO EXCLUDE]. Give me the pattern, a plain-English breakdown of each part, and 6 test strings (4 that should match, 2 that shouldn't) with the expected result for each. Keep it as simple as the task allows, and warn me about any catastrophic-backtracking risk.

Explain how [ALGORITHM] works to a developer who knows the basics but hasn't used it. Walk through the intuition, then the steps with a small worked example, then the time and space complexity and why. Show a clean reference implementation in [LANGUAGE version], and note when this is the right choice versus a simpler alternative.

Turn on Thinking mode. Design a system for [WHAT IT DOES] at roughly [SCALE: users / requests per second / data size]. Cover the high-level architecture, the main components and how they communicate, the data stores and why, and how it handles load, failures, and growth. Discuss two or three key tradeoffs explicitly, and call out the biggest risk in your design.

Use Agent Mode. Build a working [WHAT THE APP IS] using [STACK / FRAMEWORK version]. Core features: [LIST THEM]. Constraints: [AUTH / DATABASE / STYLING / NO PAID SERVICES]. Plan the file structure first and show it to me, then build each file, run the app, and fix any errors you hit. When it runs, give me the exact commands to start it locally and a short list of what's done versus what I'd add next.

Use Agent Mode. In this project, add [FEATURE]. Files that likely matter: [LIST OR "explore the repo first"]. Trace how the current code handles [RELATED EXISTING FEATURE], mirror that pattern, and touch as few files as possible. Update any tests and docs affected, run the test suite, and fix failures. When you're done, summarize every file you changed and why, and flag anything you were unsure about.

Use Agent Mode with this screenshot: [ATTACH IMAGE OF THE UI / MOCKUP]. Build it as a responsive [FRAMEWORK version] component using [STYLING APPROACH]. Match the layout, spacing, and states you can see, use semantic HTML and accessible markup, and use placeholder data where the real content isn't shown. Build it, render it, and adjust until it matches the screenshot, then show me the final files and note anything you had to guess.

Use Agent Mode. This project is failing with: [PASTE ERROR / DESCRIBE THE BROKEN BEHAVIOR]. Reproduce the failure by running [COMMAND / STEPS], then find the root cause across the relevant files, apply the fix, and re-run to confirm it's resolved. Don't change unrelated code. When it passes, show me the diff, explain what was wrong in two sentences, and add a test that would have caught it.