prometheus

prometheus 🔥

Principle: The harness cannot raise the model's limits. It only makes the model reach its own limits — by forcing verification, completion, and investigation as procedures. (The initial code form came from fivetaku/fablize, but its effect figures are based on a different model family, so they were not carried over here. The effect on GLM-5.2 is unmeasured.) If what's blocking you is a capability limit (open-ended creation, autonomous discovery), escalate (§5).

0. Bundle files (kindling)

• ~/.agents/skills/prometheus/packs/investigation-protocol.txt — debugging investigation discipline
• ~/.agents/skills/prometheus/packs/verification-grounding-pack.txt — render artifact verification discipline

Note — goals.pyhas been deprecated. The multi-story engine brought over from fablize (goals.py)은 ZCode /goal overlapped with the command, and more importantly, the verification gate in goals.py had a weakness — that it "only triggers when the agent voluntarily calls goals.py". No matter how strict the gate is, if the entrance is soft it's meaningless. ZCode /goal은 runtimeevaluates at the end of every turn, so such an entrance doesn't exist in the first place. Therefore, the verification gate is delegated not to goals.py but to ZCode /goal. However, the agent cannot set /goaldirectly — the agent designs a verifiable goal statement and proposes it to the user, and the user sets it with /goal(or /goal replace). (For the background of this decision, see the "Why we dropped goals.py" section in the README.) Multi-story execution follows the §2 procedure.

1. Before decomposition — securing context (mandatory, do not skip)

The quality of decomposition depends on context. If you decompose without context, the model makes up stories by guessing, and if those guesses are wrong the entire task goes off track. So before decomposition before you must secure context. Don't skip this step and go straight to /goal.

If you went through forge: The list of acceptance criteria that forge produced is the secured context. Steps 1–3 of 1-A are already filled in, so you just need to move those acceptance criteria into stories (§1-C). Skip the 1-B re-exploration.

1-A. Context sufficiency self-check

Check four points yourself regarding the task you want to decompose. If even one is "I don't know," the context is insufficient:

1. Do you concretely know the codebase area(files/modules/functions) this task will touch? — Not "somewhere" but the actual path.
2. Do you know that area's current structure and rules(architecture, naming conventions, dependencies)?
3. The task's success conditionsDo you know it in an observable form? — Not "it works well," but "this command/test produces this result."
4. (If it's a research task) existing known approaches/solutionsdid you investigate?

1-B. If context is insufficient — force an exploration-only subagent

If anything from 1-A is lacking, do not guess on your own — launch an exploration-only subagent (Agent tool, subagent_type=Explore) to gather context. The main agent does not do exploration and decomposition at the same time — exploration is done by the subagent, and decomposition is done only by the main agent after context is secured.

Agent tool call (subagent_type: "Explore")
prompt:
  "이 작업을 분해하기 위해 필요한 맥락을 모아라. 탐색 범위: [코드베이스 영역 또는 연구 주제].
   특히:
   1) 관련 파일/모듈의 실제 경로와 역할
   2) 그 영역의 구조/규칙/의존성
   3) 이 코드베이스에서 비슷한 작업이 어떻게 구현됐는지
   4) 성공 조건을 관측 가능하게 만드는 진입점(테스트, CLI, 엔드포인트)
   파일 내용을 쏟지 말고 결론만 반환하라."

Only after receiving the exploration results, re-check 1-A. If it is still lacking, narrow the exploration scope and try once more. Never before context becomes sufficient /goal propose the sentence to the user.

1-C. Once context becomes sufficient — decompose into independent units

Now design the stories. Every story must satisfy the following:

• Independently verifiable: When only this story is complete, that fact must be provable by command/observation. ("Cleaned up the code" is not verifiable — "ruff check .has 0 errors" is verifiable.)
• Independently executable: A story that cannot even be started without the result of another story is either too large or incorrectly ordered. (Having dependencies is fine — sequential stories are exactly that. But if "without reading the previous story's output, you don't even know the starting point," then the decomposition is incomplete.)
• One-dimensional goal: One story, one thing. "Add API + modify UI + test" is three stories.
• Verifiable goal statement: Each story should be expressible in a form matching ZCode /goal— "this command produces this result" (§2-C).
• The last one is a verification story: The final story must be end-to-end verification.

1-D. Decomposition examples (good / bad)

User: "Fix the login error"

❌ Bad decomposition (guessing without context):

• G001: Analyze the error
• G002: Fix the error
• G003: Verify

Problem: "Analyze the error" has no observable artifact. "Fix the error" doesn't say what or how to do it. Each story is not independently verifiable. If you put such vague goals into /goal, even the judge is fooled by the vagueness, and self-deception begins.

✅ Good decomposition (after 1-B exploration identifies auth/login.ts:42, error logs, and existing test patterns):

• G001: Write an error reproduction script → node repro.js outputs the same error log when run
• G002: auth/login.ts:42fix the cause of → npm test auth/login passes
• G003: Final verification → repro.js no errors when re-running + all npm test passes

Difference: Each story of a good decomposition has concrete path + observable evidence. This is only possible because there was 1-B exploration.

2. Decomposition execution — sequential /goal multiple stories (2 or more sequential goals)

After securing context in §1 and designing the decomposition, convert each story into a ZCode /goal sentence and propose it to the userand, when the user sets it as a goal, work on only that story. Each time a story ends, propose the next story sentence.

2-A. 왜 /goalauthorization (not goals.py)

ZCode /goalThis makes prometheus enforce at runtime the "verification gate" that it previously tried to implement directly with goals.py the runtime enforces:

• The agent does not declare completion. At the end of every turn, the runtime judge evaluates whether the goal has been reached, and if not, automatically proceeds to the next turn.
• It rejects proxy signals. Passing tests/build success/writing code alone is not accepted as "completion" — every condition required by the goal must be covered by evidence.
• Uncertainty is treated as incomplete. "It seems roughly done" is not completion — verify more or keep working.

This is the decisive difference from goals.py. goals.py enforced checkpoint gates with sys.exit(), but whether to call goals.py itself was the agent's voluntary choice— a soft entrance neutralizes the gate. /goalhas no such entrance; the runtime intervenes every turn.

2-B. Division of roles — the agent designs, the user configures

Important: the agent cannot directly set /goal. /goalis a ZCode chat input command and is not reachable from the agent's bash shell or tools. All the agent can do is create a verifiable goal sentence and propose it to the user. The user does the configuration. Do not deceive yourself about this limitation — every piece of writing that assumes goals can be created by prompts instantly fails.

Roles:

• Agent (prometheus): decompose stories with §1, convert each story into a 2-C format /goal sentence and present it to the user. When the user sets it, work on only that story.
• User: copy the sentence presented by the agent and set it in chat input as /goal(first story) or /goal replace(subsequent stories).
• ZCode runtime: run the judge at the end of every turn for the configured goal. It judges independently of the agent's completion declaration.

2-C. How to make a good /goal sentence

Convert each story into a verifiable sentence in exactly the form designed in 1-C. Avoid vague expressions, and write the verification command and expected result directly in the sentence. The agent presents this sentence to the user as is.

Good goal sentence (verifiable):

/goal auth/login.ts:42의 EAUTH 원인을 고쳐라. 검증: `npm test auth/login`이 9 passed로 통과하고, `node repro.js`가 exit code 0으로 끝나며 에러 로그를 출력하지 않는다.

Bad goal sentence (unverifiable, self-deception risk):

/goal 로그인 에러를 우아하게 해결하라.

Difference: a good goal has objective conditions (command + expected result) that a judge can adjudicate. A bad goal containing vague words like "elegantly" deceives even the judge, and that becomes self-deception.

2-D. Sequential multi-story loop

1. §1에서 설계한 목록의 각 스토리를 2-C 형식의 /goal 문장으로 바꿔, 전체 목록을 한 번에 사용자에게 제시한다.
2. 첫 스토리 문장을 /goal로 설정하라고 사용자에게 말한다. (사용자가 채팅 입력에 친다.)
3. 사용자가 설정됐다고 신호하면(또는 시스템이 goal 모드를 알리면) 그 스토리만 작업한다. 다른 스토리는 건드리지 마라.
4. 런타임 판정기가 통과시키면(= 시스템 리마인더가 목표 도달을 알리면) 다음 스토리 문장을 제시하고 "/goal replace로 교체하라"고 말한다.
5. 마지막 스토리까지 반복. 마지막 스토리는 항상 엔드투엔드 검증이어야 한다.

Rules:

• At a time, one active goal is worked on. It is not parallel.
• The agent never directly /goaldoes not hit. Always present the sentence to the user and leave the setting to them.
• Do not declare a false "complete" just because you are stuck — the runtime will filter it out anyway. Instead, gather more evidence or move to the §3 investigation procedure.
• Single-step tasks (decomposition is 1 story) skip this loop — one goal is enough. However, §1 context acquisition can be useful even in a single step, for example identifying the cause of a bug.

2-E. State tracking

You may also record the progress of each story in parallel with the TodoWrite tool (to show the user a visual progress indicator). However, the completion judgment is made by /goal the runtime judge, not by TodoWrite — TodoWrite is an indicator, not a gate. Do not confuse them.

3. Deep investigation (debugging / unknown cause / review)

~/.agents/skills/prometheus/packs/investigation-protocol.txtRead and follow: first reproduce → form 3 or more competing hypotheses → collect evidence for each hypothesis → trace the entire causal chain (removing symptoms is not removing the defect) → verify before and after → report rejected hypotheses. For reviews, report all low-confidence findings and filter them in a separate step.

4. Verification grounding (render/execution artifacts — always)

For artifacts whose correctness is revealed only by running them (HTML, SVG, games, UI, charts), follow ~/.agents/skills/prometheus/packs/verification-grounding-pack.txt: run in the actual renderer → observe the actual output → fix what the observation reveals → rerun. Static parsing only confirms well-formedness, not correctness.

Perform this loop yourself — it is not "telling the user to open it and stopping." Run and observe directly with a headless browser, script execution, reading screenshots, etc.

4-1. Work style (always)

Start with the result. Stay within the requested scope (no accidental refactoring/abstraction). Ground every completion claim in this session's tool results. Confirm before destructive or hard-to-reverse actions.

5. Capability limits (escalation)

Signals that you have reached the model's limits: being stuck on the same problem 2 or more times; open-ended creation where the detail itself is the value; deep review requiring discovery beyond the spec. This is capability, not procedure, and the harness cannot fill it. In order: (1) GLM-5.2 has two thinking-effort levels (High, Max) and scales according to reasoning difficulty. Proceed with High by default, and if the above limit signal appears, raise it to Max to activate deeper reasoning — Z.ai recommends Max for coding tasks. If the client does not expose Max or the current session is pinned to High, advise the user to switch to the stronger reasoning mode (Max); (2) if that is still insufficient, hand it off to a stronger model in a new session along with an evidence package (symptoms, attempts, failure points, reproduction); (3) otherwise, honestly report the limitation and mark the point where human intervention is needed.