Repo-Level Coding Prompts for GLM Coding Plan

A common failure mode with GLM Coding Plan on repo-level tasks: you write a one-line requirement, the model edits the wrong files, and you blame the model. More often the problem is context organization. Repository-level work spans multiple files and module dependencies, so the model needs not just a goal but constraints, boundaries, and acceptance criteria. This post lays out a prompt structure that works well with the GLM-5 series, especially with thinking mode enabled.

The Five-Part Structure for Repo-Level Prompts

Single-file tasks allow loose prompts, but for repository-level work, fix your structure. Five sections, none optional:

1. Role and objective: one sentence, verb-first, no vague "take a look at" or "optimize this". 2. Repository context: tech stack, key parts of the directory tree, responsibilities of the relevant modules. GLM-5 models handle large context windows, but a precise slice beats dumping the whole repo. 3. Constraints: coding conventions, files that must not be touched, dependency version limits, compatibility requirements. 4. Execution steps: have the model output a plan before writing code. With thinking mode this is especially effective—deep reasoning unfolds along the steps you define instead of improvising. 5. Acceptance criteria: what counts as done, which tests to run, expected output format.

Template 1: Task Breakdown (New Feature)

text
[Role] You are a senior engineer on this project, familiar with all modules.

[Task] Add "phone number binding" to the user service module:
- POST /api/user/phone/bind endpoint, accepts a verification code and completes binding
- Code valid for 5 minutes; same phone number limited to one send per 60 seconds

[Repo context]
- Stack: Spring Boot 3 + MyBatis-Plus + Redis + MySQL 8
- Relevant files:
  - src/user/controller/UserController.java (existing endpoint style reference)
  - src/user/service/UserService.java (business logic layer)
  - src/common/exception/BizException.java (unified exception)
- SMS sending utility already exists at src/common/sms/SmsClient.java, reuse it

[Constraints]
- Do not modify any existing logic beyond the new files listed above
- Follow existing style: constructor injection, unified Result wrapper
- Output SQL changes as a separate migration file

[Steps]
1. First output an implementation plan (files involved, endpoint signatures, schema changes)
2. After I confirm the plan, output the full code

[Acceptance]
- List unit test cases to add
- Cover edge cases: expired code, duplicate binding, concurrent sends

The plan-first-then-code step is the key. Asking for code directly on repo-level tasks often misses related files; splitting into two rounds lets you review the plan before code exists—far cheaper than rolling back afterwards.

Template 2: Bug Fix (with Repro Info)

text
[Task] Fix intermittent 500 errors on the order list endpoint.

[Symptoms]
- ~5% reproduction rate, concentrated on high-volume merchant accounts
- Key log excerpt:
  NullPointerException at OrderListService.java:87
- Sample request: { "merchantId": 88231, "page": 1, "size": 50 }

[Already investigated]
- This merchant has 3 legacy orders with refund_status = NULL
- Suspect missing null handling in the status filter, not yet confirmed

[Requirements]
1. Root-cause analysis first (cite specific code lines); mark anything uncertain as "to be confirmed"
2. Minimal-diff fix only, no drive-by refactoring
3. Add one regression unit test

[Output format] Root cause → fix diff → test code, three separate sections

The most common mistake in bug-fix prompts is omitting what you've already ruled out. Include both confirmed facts and suspicions—the model converges along existing leads instead of re-deriving the whole call chain. That saves tokens and raises accuracy.

Multi-Turn Iteration and Context

Repo-level work rarely finishes in one turn. Two habits that help:

• Append incremental info only: don't resend the whole template each turn. Use relative references like "in file 3 from the previous step, change the param validation to…". Sessions in GLM Coding Plan carry continuous context; repasting large code blocks dilutes the signal.
• Start a fresh session per phase: when development ends and code review begins, open a new session with just the diff. Late in long sessions, models can get anchored to earlier failed attempts—a new session is a clean context rebuild.

Versus Direct API Calls

If you also use the BigModel API for automated pipelines (say, generating commit messages in CI), the same five-part structure applies—but API calls carry no session memory, so every request must include full context inline. Whether the thinking parameter is enabled also affects output structure and latency; check the official docs for exact parameters. The same holds for self-hosting the open weights: context organization is unchanged, the differences are mainly context length and inference configuration.

Repo-level prompting isn't about writing longer prompts—it's about writing clearer constraints and acceptance criteria. Swap in your own fields in the two templates above and they're ready to run; after a handful of real tasks you'll naturally evolve versions tailored to your own repo.