Skip to content

change review prompt#12

Merged
piqoni merged 1 commit intomainfrom
review_prompt
Oct 5, 2025
Merged

change review prompt#12
piqoni merged 1 commit intomainfrom
review_prompt

Conversation

@piqoni
Copy link
Owner

@piqoni piqoni commented Oct 5, 2025

No description provided.

@piqoni piqoni merged commit b31fec8 into main Oct 5, 2025
2 checks passed
@piqoni piqoni deleted the review_prompt branch October 5, 2025 15:31
@github-actions
Copy link

github-actions bot commented Oct 5, 2025

∇ Vogte Code Review

Summary:

  • Low-risk text-only change to an LLM prompt. Main risk is inconsistency and duplication in instructions that can confuse the model or break snapshot/tests.

Findings:

  • [Severity: Medium] llm/llm.go:~311 — Inconsistent/duplicated prompt sections
    Explanation: The change updates the first occurrence of “Output format should be in Markdown...” to “Format your response in markdown...” and adds “It should have these sections:”. A second occurrence of the old phrasing remains later in the prompt. The prompt appears to include “What to do” and “Output format…” blocks twice. Conflicting/duplicated instructions can degrade LLM adherence, increase token usage, and may break any snapshot tests that assert the full prompt content.
    Suggestion: Make both occurrences consistent or deduplicate so the instructions appear once. If duplication is intentional (e.g., composing prompts), ensure both use the same updated phrasing.

    Quick patch (synchronize the second occurrence):

    • Replace the later “Output format should be in Markdown syntax and have these sections:” with:
      “Format your response in Markdown, with code examples where relevant using appropriate syntax highlighting.
      It should have these sections:”
    • Alternatively, remove the duplicated earlier block if it’s truly redundant.
  • [Severity: Low] llm/llm.go:~311 — Minor style inconsistency and potential downstream formatting impact
    Explanation: The new text requests code examples with syntax highlighting, which may encourage fenced code blocks. If any downstream renderer/parsers are sensitive to fences or heavy formatting, this could cause issues. Also “markdown” vs “Markdown” casing differs between occurrences.
    Suggestion: Confirm consumers handle fenced code blocks. Use consistent casing (“Markdown”) across the prompt.

  • [Severity: Low] Tests/snapshots — Potential snapshot/string match failures
    Explanation: If you have tests that snapshot the prompt string or assert specific substrings (e.g., “Output format should be…”), they may fail.
    Suggestion: Update snapshots and assertions to the new wording; add a test to ensure there’s only one copy of each instruction block.

Verdict: Needs attention


This review was automatically generated by vogte

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant