chore: Improve agent instructions #19

lucas · 2026-11-13T09:44:08+01:00

lucas commented

2026-11-13 09:44:08 +01:00

No description provided.

lucas added 1 commit

2026-11-13 09:44:08 +01:00

chore: Improve agent instructions

Build / build (pull_request) Successful in 1m34s

Details

Build / build (push) Successful in 1m3s

Details

b4db215f10

lucas scheduled this pull request to auto merge when all checks succeed

2026-11-13 09:44:15 +01:00

omp-deck reviewed

2026-11-13 09:44:52 +01:00

omp-deck left a comment

Config-only change; the YAML is well-formed (the surrounding example lines stay comments because they start at column 0) and the prompt itself is clear and consistent — it draws the "what is wrong" / "what to do" line sharply enough that an agent can actually follow it. Two things worth confirming before merge, both inline.

.omp/forgejo.yaml

					
				@ -36,2 +36,2 @@

				#   issue_handler: |

				#     State the affected component and the blast radius before anything else.

				  issue_handler: |

				    Triage and root cause analysis are your entire job on this issue, on this turn and on every

"on this turn and on every later turn in this session" lines up with the header comment above (system_prompts): a session that has triaged an issue keeps using issue_handler for the rest of its life.

Worth double-checking what that means for the labels this repo already configures: implementation.planning_label: Agent/Planning and planned_label: Agent/Planned. If a planning run can land in the same session that did the triage, this prompt forbids exactly what that run is supposed to produce ("no plan", "no design options or comparison of approaches"), and the plan_issue prompt would be the one that never applies. If planning/implementation always get a fresh session with the plan_issue / implementer kind, then there's no conflict and this is fine as written — but it's the one way this prompt can misfire.

"on this turn and on every later turn in this session" lines up with the header comment above (`system_prompts`): a session that has triaged an issue keeps using `issue_handler` for the rest of its life. Worth double-checking what that means for the labels this repo already configures: `implementation.planning_label: Agent/Planning` and `planned_label: Agent/Planned`. If a planning run can land in the *same* session that did the triage, this prompt forbids exactly what that run is supposed to produce ("no plan", "no design options or comparison of approaches"), and the `plan_issue` prompt would be the one that never applies. If planning/implementation always get a fresh session with the `plan_issue` / `implementer` kind, then there's no conflict and this is fine as written — but it's the one way this prompt can misfire.

.omp/forgejo.yaml

					
				@ -38,1 +49,4 @@

				    Say nothing about what happens next: no readiness verdicts, no label suggestions, no offers to

				    plan, implement, or open a pull request. End with the analysis.

				#   pull_request: |

Fragility note rather than a defect: these example lines are only comments because they start at column 0, i.e. are less indented than the block scalar body above. Anyone who later tidies them to line up with issue_handler's 4-space body will silently turn them into prompt text instead of YAML keys, with no parse error to catch it.

Moving the now-active issue_handler key below the commented examples (or above all of them) would keep the real entry out of the middle of the example block and make that accident less likely.

Fragility note rather than a defect: these example lines are only comments because they start at column 0, i.e. are less indented than the block scalar body above. Anyone who later tidies them to line up with `issue_handler`'s 4-space body will silently turn them into prompt text instead of YAML keys, with no parse error to catch it. Moving the now-active `issue_handler` key below the commented examples (or above all of them) would keep the real entry out of the middle of the example block and make that accident less likely.