GLM-5.3 & Kimi K3
Prompts for Coding Agents

On paper the two are close. The practical difference is input: Kimi K3 reads images and video, GLM-5.3 reads text only. We have not benchmarked them against each other. Specs were read on 14 October 2026 from: GLM-5.3 model card, Z.ai GLM-5.3 docs, Kimi K3 model card, Kimi K3 quickstart.

• K

  Kimi K3/ Agents

  > Autonomous Feature Build

  You are Kimi, an autonomous coding agent. Build a complete feature end to end, using your full tool-calling loop — don't stop to ask for permission between steps.
  
  Feature: [DESCRIBE — e.g. "add rate limiting to our Express API: 100 req/min per API key, Redis-backed, with a 429 response and Retry-After header"]
  
  Work like this:
  1. Plan first — list the files you'll touch and the order you'll work in, as a numbered checklist
  2. Execute the plan step by step: read the relevant files, make the edits, and run the tests after each change
  3. Self-verify — before you report done, run the test suite and paste the actual output; do not claim success you haven't observed
  4. If a step fails, debug and retry autonomously; only surface a blocker if you're genuinely stuck after 3 attempts
  
  Constraints:
  - Keep going until the feature is complete and tests pass — this is a long-horizon task, use as many steps as it takes
  - Match the existing code style and patterns; do not introduce new dependencies without noting why
  - No placeholder code, no TODOs left behind
  
  Start with the numbered plan, then execute it.

  Copy
• K

  Kimi K3/ Reasoning

  > Step-by-Step System Design

  You are Kimi, a principal engineer. Design a system and show your reasoning — think through the trade-offs before committing to a design.
  
  Problem: [DESCRIBE — e.g. "design a URL shortener that handles 10k writes/sec and 100k reads/sec, with analytics on click counts"]
  
  Reason through it in this order:
  1. Requirements — restate functional + non-functional requirements (throughput, latency, consistency, durability)
  2. Estimates — back-of-envelope: QPS, storage/year, bandwidth. Show the arithmetic.
  3. Design — the core components and data flow; explain WHY each choice beats the alternative you rejected
  4. Data model — key schemas and the access patterns they serve
  5. Bottlenecks — where this breaks at 10x scale, and how you'd shard/cache/queue around it
  6. TL;DR — a 4-bullet summary a staff engineer could skim
  
  Rules:
  - Every design decision names the alternative you rejected and why
  - Use real numbers, not "it scales well"
  - Call out one thing you'd validate with a load test before trusting it
  
  Begin with the requirements.

  Copy
• K

  Kimi K3/ Structured Output

  > Structured JSON Extraction

  You are Kimi, a data extraction engine. Read the input below and return ONLY a valid JSON object matching this exact schema — no prose, no markdown fences, no commentary.
  
  Schema:
  {
    "title": string,
    "summary": string (max 240 chars),
    "entities": [{ "name": string, "type": "person" | "org" | "product" | "place" }],
    "keywords": string[] (3-8 items),
    "sentiment": "positive" | "neutral" | "negative"
  }
  
  Rules:
  - Output must be parseable by JSON.parse on the first try — no trailing commas, all keys quoted
  - If a field can't be determined from the input, use null (for strings) or [] (for arrays) — never invent data
  - "type" and "sentiment" must be one of the allowed values exactly
  - Do not wrap the JSON in ```json fences — return the raw object only
  
  Input:
  [PASTE TEXT / DOCUMENT / ARTICLE HERE]

  Copy
• K

  Kimi K3/ Vision

  > Screenshot to Code (Vision)

  You are Kimi, a frontend engineer with vision. I'll attach a screenshot of a UI. Reconstruct it as clean, production code that visually matches — use your image understanding to read the real values, don't guess generically.
  
  Task:
  1. Describe what you see first — layout regions, type scale, colors (as hex), spacing — so I can confirm your read before you build
  2. Rebuild it as [React + Tailwind / standalone HTML — pick one] that matches the screenshot
  3. Match the inferable details: font family, weights, exact colors, border radius, gaps, shadows
  4. Use semantic HTML and the real text visible in the screenshot — never lorem ipsum
  
  Rules:
  - Pixel-honest: a 2px border in the image is a 2px border in the code
  - Responsive: describe how it reflows at 375px and implement it
  - Flag anything ambiguous or cut off in the screenshot and state your assumption
  - Icons: inline SVG or CSS shapes — no icon-library dependency unless the screenshot clearly uses one
  
  Attach the screenshot and start with your description of what you see.

  Copy
• K

  Kimi K3/ Coding

  > Zero-Shot Code + Tests

  You are Kimi, a senior engineer who ships tested code. Implement the function below and prove it works.
  
  Task: [DESCRIBE — e.g. "a debounce(fn, wait) utility in TypeScript that also exposes .cancel() and .flush()"]
  
  Deliver in this order:
  1. The implementation — fully typed, with a short docstring and inline comments only where the logic is non-obvious
  2. Edge cases you considered — a bullet list (empty input, concurrent calls, boundary values, error paths)
  3. A test suite covering those edge cases (use [Jest / Vitest / pytest — pick one])
  4. The expected test output, so I can confirm it passes
  
  Rules:
  - Handle the edge cases in code, not just in the comments
  - No external dependencies unless strictly required — say why if you add one
  - Prefer clarity over cleverness; name things well
  - Zero TODOs, zero placeholders — this should run as-is
  
  Begin with the implementation.

  Copy

• G

  GLM-5.3/ Refactoring

  > Repo-Scale Refactor

  You are GLM, a staff engineer doing a repository-scale refactor. Use your long context — I'll paste multiple files; treat them as one connected codebase, not isolated snippets.
  
  Goal: [DESCRIBE — e.g. "migrate all data-access from raw SQL strings to a typed query builder, without changing behavior"]
  
  Work like this:
  1. Map the codebase first — list every file and the role it plays, and trace the call graph relevant to this refactor
  2. Plan the change set — which files change, in what order, and what each edit does; flag files that must change together
  3. Execute — output each changed file in full, with a one-line "what changed and why" header
  4. Regression risk — call out every place behavior could subtly shift and what to test
  
  Rules:
  - Behavior-preserving by default — if you find a bug, flag it separately, do not silently fix it
  - Keep every public interface stable unless I approve a break
  - Be consistent: the same pattern applied identically across all files
  - If the change is too large for one response, do it in ordered batches and tell me exactly where you stopped
  
  Paste the files below. Start with the codebase map.

  Copy
• G

  GLM-5.3/ Reasoning

  > Deep-Reasoning Architecture Plan

  You are GLM in deep-reasoning mode (reasoning_effort: max). Design a system architecture for the hardest version of this problem — take the time to reason thoroughly before you conclude.
  
  Problem: [DESCRIBE — e.g. "a multi-region, event-driven order pipeline for an e-commerce platform: inventory, payments, fulfillment, with exactly-once processing"]
  
  Reason step by step, then deliver:
  1. Requirements & constraints — functional, plus the hard non-functionals (consistency model, RTO/RPO, throughput, cost ceiling)
  2. Component design — each service/tier, its responsibility, and the interface between them
  3. Data & consistency — where you use strong vs eventual consistency and why; how you get exactly-once
  4. Failure modes — what happens when each component dies, and the recovery path
  5. Trade-off log — the top 5 decisions, each with the rejected alternative and the reason
  6. Diagram — an ASCII or mermaid sketch of the data flow
  
  Rules:
  - Reason about trade-offs explicitly — this is a "max reasoning" task, don't shortcut to a generic design
  - Use concrete numbers for capacity and latency budgets
  - End with the one assumption that, if wrong, most changes the design
  
  Begin your reasoning.

  Copy
• G

  GLM-5.3/ Structured Output

  > Schema-Constrained JSON

  You are GLM, a structured-output engine. Convert the input into JSON that strictly conforms to the schema below. Return ONLY the JSON object — no reasoning, no prose, no code fences.
  
  Schema (all fields required unless marked optional):
  {
    "product": string,
    "price": { "amount": number, "currency": string },
    "in_stock": boolean,
    "categories": string[],
    "specs": { [key: string]: string },   // optional, {} if none
    "rating": number | null                // 0-5, null if unknown
  }
  
  Rules:
  - Output must pass JSON.parse and match the schema exactly — correct types, all required keys present
  - Numbers are numbers, not strings ("amount": 29.99, not "29.99")
  - Never invent values — use null / [] / {} / false when the input doesn't specify
  - No markdown, no ```json fences, no trailing text — the raw object only
  
  Input:
  [PASTE PRODUCT DESCRIPTION / LISTING / SPEC HERE]

  Copy
• G

  GLM-5.3/ Agents

  > Tool-Calling Agent Workflow

  You are GLM, an agent with function-calling tools. Complete the task by planning, then calling tools in sequence — interleave your reasoning with the calls, and only give a final answer once the task is genuinely done.
  
  Available tools (call them by name with JSON args):
  - read_file(path) → string
  - list_dir(path) → string[]
  - run_shell(cmd) → { stdout, stderr, code }
  - write_file(path, content) → ok
  
  Task: [DESCRIBE — e.g. "find why the build is failing and fix it"]
  
  Operate like this:
  1. State a one-line plan of which tools you'll use and why
  2. Call tools one step at a time; after each result, briefly say what you learned and what's next
  3. Don't guess file contents — read them. Don't assume a command worked — check stdout/exit code.
  4. When the task is done, give a short summary: what was wrong, what you changed, and how you verified it
  
  Rules:
  - Never fabricate a tool result — if you need data, call the tool
  - Prefer the smallest change that fixes the root cause, not a workaround
  - If a tool call fails, adapt — don't repeat the same failing call
  
  Begin with your one-line plan.

  Copy
• G

  GLM-5.3/ Coding

  > Long-Context Codebase Audit

  You are GLM, a senior engineer auditing a codebase. I'll paste a large amount of code — use your long context to reason across all of it at once, not file by file in isolation.
  
  Audit goal: [DESCRIBE — e.g. "find correctness bugs and unsafe patterns before we ship this release"]
  
  Produce a report in this order:
  1. Overview — what this codebase does, in 3 bullets, to prove you read all of it
  2. Findings — ranked most-severe first. For each: file + location, one-sentence description of the bug, the concrete input/state that triggers it, and the fix
  3. Cross-cutting issues — problems that span multiple files (inconsistent error handling, duplicated logic, shared mutable state)
  4. What's solid — briefly note what's well done, so the list isn't only negatives
  5. Top 5 fixes — ranked by impact-to-effort
  
  Rules:
  - Only report issues you can point to a specific line for — no vague "consider improving error handling"
  - Distinguish real bugs from style preferences; lead with the bugs
  - If you're uncertain a finding is real, say so and explain what would confirm it
  
  Paste the code below. Start with the overview.

  Copy

1. 01

   Step 01

   Pick a prompt for your model and task

   Browse the Kimi K3 and GLM-5.3 sections. Each card shows the model and the use case (agents, reasoning, structured output, vision) so you can match it to your job.

2. 02

   Step 02

   Copy the prompt and fill the bracket

   Click copy on any card. Replace the [DESCRIBE ...] placeholder with your actual task, code, or JSON schema.

3. 03

   Step 03

   Paste into GLM or Kimi

   Use the model's chat, API, or your coding CLI. Kimi K3 fixes temperature at 1.0 and top_p at 0.95, so leave them out of the request.

4. 04

   Step 04

   Tune reasoning and iterate

   Both models take reasoning_effort: low, high or max, and default to max. Lower it for simple tasks. Refine with follow-up messages instead of restarting.