Skip to content

Instantly share code, notes, and snippets.

@jannismain

jannismain/oscare_gutachten_ki-2026-01-20.html

Created January 21, 2026 10:31
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save jannismain/4b75384f776c4f5397fb5229cfbf7ba9 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save jannismain/4b75384f776c4f5397fb5229cfbf7ba9 to your computer and use it in GitHub Desktop.
Download ZIP
Agent session: oscare_gutachten_ki - ## Code review guidelines: # Review guidelines: You are acting as a reviewer for a proposed code ch
Raw
oscare_gutachten_ki-2026-01-20.html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>oscare_gutachten_ki - Agent Session</title>
<style>
:root {
--bg: #0d1117;
--surface: #161b22;
--surface-hover: #21262d;
--border: #30363d;
--text: #e6edf3;
--text-muted: #8b949e;
--accent: #58a6ff;
--accent-muted: #388bfd;
--user-bg: #1c2128;
--assistant-bg: #1a1f26;
--success: #3fb950;
--warning: #d29922;
--tool-bg: #1a2332;
--thinking-bg: #1f1a24;
--agent-accent: #9d7cd8;
}
* { box-sizing: border-box; margin: 0; padding: 0; }
body {
font-family: 'SF Mono', Monaco, 'Cascadia Code', 'Consolas', monospace;
background: var(--bg);
color: var(--text);
line-height: 1.5;
}
/* Header */
header {
background: var(--surface);
border-bottom: 1px solid var(--border);
padding: 16px 24px;
position: sticky;
top: 0;
z-index: 100;
}
.header-content {
max-width: 900px;
margin: 0 auto;
display: flex;
align-items: center;
justify-content: space-between;
flex-wrap: wrap;
gap: 12px;
}
.header-left {
display: flex;
flex-direction: column;
gap: 4px;
}
h1 {
font-size: 1.1rem;
font-weight: 600;
color: var(--text);
}
.session-meta {
font-size: 0.8rem;
color: var(--text-muted);
display: flex;
gap: 12px;
flex-wrap: wrap;
}
.session-meta .agent-name {
color: #d4a574;
}
.session-meta .agent-name.codex {
color: #7dd3fc;
}
.controls {
display: flex;
gap: 12px;
align-items: center;
}
/* CSS-only toggle buttons using checkbox hack */
.toggle-input {
position: absolute;
opacity: 0;
pointer-events: none;
}
.toggle-label {
display: inline-flex;
align-items: center;
gap: 6px;
padding: 6px 12px;
background: var(--surface-hover);
border: 1px solid var(--border);
border-radius: 6px;
color: var(--text);
cursor: pointer;
font-size: 0.85rem;
user-select: none;
transition: background 0.15s, border-color 0.15s;
}
.toggle-label:hover {
background: var(--border);
}
.toggle-input:checked + .toggle-label {
background: var(--accent-muted);
border-color: var(--accent);
}
.toggle-indicator {
display: inline-block;
width: 8px;
height: 8px;
border-radius: 50%;
background: var(--text-muted);
transition: background 0.15s;
}
.toggle-input:checked + .toggle-label .toggle-indicator {
background: var(--text);
}
/* Main content */
main {
max-width: 900px;
margin: 0 auto;
padding: 24px;
}
.messages {
display: flex;
flex-direction: column;
gap: 16px;
}
.message {
padding: 16px;
border-radius: 8px;
border: 1px solid var(--border);
}
.message.user {
background: var(--user-bg);
border-left: 3px solid var(--accent);
}
.message.assistant {
background: var(--assistant-bg);
border-left: 3px solid var(--agent-accent);
}
.message-header {
display: flex;
justify-content: space-between;
margin-bottom: 8px;
font-size: 0.8rem;
}
.message-role {
font-weight: 600;
text-transform: uppercase;
letter-spacing: 0.5px;
}
.message.user .message-role { color: var(--accent); }
.message.assistant .message-role { color: var(--agent-accent); }
.message-time { color: var(--text-muted); }
.message-content {
white-space: pre-wrap;
word-break: break-word;
font-size: 0.9rem;
}
.message-content code {
background: var(--bg);
padding: 2px 6px;
border-radius: 4px;
font-family: inherit;
font-size: 0.85em;
}
.message-content pre {
background: var(--bg);
padding: 12px;
border-radius: 6px;
overflow-x: auto;
margin: 12px 0;
}
.message-content pre code {
background: none;
padding: 0;
}
/* Thinking blocks - hidden by default */
.thinking-block {
background: var(--thinking-bg);
border-left: 2px solid #8b5cf6;
padding: 12px;
margin: 8px 0;
border-radius: 4px;
font-style: italic;
color: var(--text-muted);
display: none;
}
.thinking-label {
font-size: 0.75rem;
font-weight: 600;
color: #8b5cf6;
text-transform: uppercase;
letter-spacing: 0.5px;
margin-bottom: 4px;
font-style: normal;
}
/* Messages that only contain thinking content */
.message.thinking-only {
display: none;
}
/* When thinking toggle is checked, show thinking blocks */
#thinking-toggle:checked ~ main .thinking-block {
display: block;
}
#thinking-toggle:checked ~ main .message.thinking-only {
display: block;
}
.tool-block {
background: var(--tool-bg);
border-left: 2px solid var(--warning);
padding: 8px 12px;
margin: 8px 0;
border-radius: 4px;
font-size: 0.85rem;
}
/* Sort order toggle - reverse message order when checked */
#sort-toggle:checked ~ main .messages {
flex-direction: column-reverse;
}
/* Footer */
footer {
max-width: 900px;
margin: 40px auto;
padding: 16px 24px;
border-top: 1px solid var(--border);
font-size: 0.8rem;
color: var(--text-muted);
text-align: center;
}
footer a {
color: var(--accent);
text-decoration: none;
}
footer a:hover {
text-decoration: underline;
}
/* Responsive */
@media (max-width: 600px) {
header {
padding: 12px 16px;
}
main {
padding: 16px;
}
.header-content {
flex-direction: column;
align-items: flex-start;
}
}
</style>
</head>
<body>
<!-- CSS-only toggles using the checkbox hack -->
<input type="checkbox" id="thinking-toggle" class="toggle-input">
<input type="checkbox" id="sort-toggle" class="toggle-input">
<header>
<div class="header-content">
<div class="header-left">
<h1>oscare_gutachten_ki</h1>
<div class="session-meta">
<span class="agent-name codex">Codex</span>
<span>2 messages</span>
<span>2026-01-20 16:19:48</span>
</div>
</div>
<div class="controls">
<label for="thinking-toggle" class="toggle-label">
<span class="toggle-indicator"></span>
Thinking
</label>
<label for="sort-toggle" class="toggle-label">
<span class="toggle-indicator"></span>
Newest first
</label>
</div>
</div>
</header>
<main>
<div class="messages">
<div class="message user" data-index="0">
<div class="message-header">
<span class="message-role">user</span>
<span class="message-time">2026-01-20 16:19:48</span>
</div>
<div class="message-content">## Code review guidelines:
# Review guidelines:
You are acting as a reviewer for a proposed code change made by another engineer.
Below are some default guidelines for determining whether the original author would appreciate the issue being flagged.
These are not the final word in determining whether an issue is a bug. In many cases, you will encounter other, more specific guidelines. These may be present elsewhere in a developer message, a user message, a file, or even elsewhere in this system message.
Those guidelines should be considered to override these general instructions.
Here are the general guidelines for determining whether something is a bug and should be flagged.
1. It meaningfully impacts the accuracy, performance, security, or maintainability of the code.
2. The bug is discrete and actionable (i.e. not a general issue with the codebase or a combination of multiple issues).
3. Fixing the bug does not demand a level of rigor that is not present in the rest of the codebase (e.g. one doesn't need very detailed comments and input validation in a repository of one-off scripts in personal projects)
4. The bug was introduced in the commit (pre-existing bugs should not be flagged).
5. The author of the original PR would likely fix the issue if they were made aware of it.
6. The bug does not rely on unstated assumptions about the codebase or author's intent.
7. It is not enough to speculate that a change may disrupt another part of the codebase, to be considered a bug, one must identify the other parts of the code that are provably affected.
8. The bug is clearly not just an intentional change by the original author.
When flagging a bug, you will also provide an accompanying comment. Once again, these guidelines are not the final word on how to construct a comment -- defer to any subsequent guidelines that you encounter.
1. The comment should be clear about why the issue is a bug.
2. The comment should appropriately communicate the severity of the issue. It should not claim that an issue is more severe than it actually is.
3. The comment should be brief. The body should be at most 1 paragraph. It should not introduce line breaks within the natural language flow unless it is necessary for the code fragment.
4. The comment should not include any chunks of code longer than 3 lines. Any code chunks should be wrapped in markdown inline code tags or a code block.
5. The comment should clearly and explicitly communicate the scenarios, environments, or inputs that are necessary for the bug to arise. The comment should immediately indicate that the issue's severity depends on these factors.
6. The comment's tone should be matter-of-fact and not accusatory or overly positive. It should read as a helpful AI assistant suggestion without sounding too much like a human reviewer.
7. The comment should be written such that the original author can immediately grasp the idea without close reading.
8. The comment should avoid excessive flattery and comments that are not helpful to the original author. The comment should avoid phrasing like &quot;Great job ...&quot;, &quot;Thanks for ...&quot;.
Below are some more detailed guidelines that you should apply to this specific review.
HOW MANY FINDINGS TO RETURN:
Output all findings that the original author would fix if they knew about it. If there is no finding that a person would definitely love to see and fix, prefer outputting no findings. Do not stop at the first qualifying finding. Continue until you've listed every qualifying finding.
GUIDELINES:
- Ignore trivial style unless it obscures meaning or violates documented standards.
- Use one comment per distinct issue (or a multi-line range if necessary).
- Use ``<code>suggestion blocks ONLY for concrete replacement code (minimal lines; no commentary inside the block).
- In every </code>`<code>suggestion block, preserve the exact leading whitespace of the replaced lines (spaces vs tabs, number of spaces).
- Do NOT introduce or remove outer indentation levels unless that is the actual fix.
The comments will be presented in the code review as inline comments. You should avoid providing unnecessary location details in the comment body. Always keep the line range as short as possible for interpreting the issue. Avoid ranges longer than 5–10 lines; instead, choose the most suitable subrange that pinpoints the problem.
At the beginning of the finding title, tag the bug with priority level. For example &quot;[P1] Un-padding slices along wrong tensor dimensions&quot;. [P0] – Drop everything to fix. Blocking release, operations, or major usage. Only use for universal issues that do not depend on any assumptions about the inputs. · [P1] – Urgent. Should be addressed in the next cycle · [P2] – Normal. To be fixed eventually · [P3] – Low. Nice to have.
Additionally, include a numeric priority field in the JSON output for each finding: set &quot;priority&quot; to 0 for P0, 1 for P1, 2 for P2, or 3 for P3. If a priority cannot be determined, omit the field or use null.
At the end of your findings, output an &quot;overall correctness&quot; verdict of whether or not the patch should be considered &quot;correct&quot;.
Correct implies that existing code and tests will not break, and the patch is free of bugs and other blocking issues.
Ignore non-blocking issues such as style, formatting, typos, documentation, and other nits.
FORMATTING GUIDELINES:
The finding description should be one paragraph.
OUTPUT FORMAT:
## Output schema — MUST MATCH _exactly_
<pre><code>{
&quot;findings&quot;: [
{
&quot;title&quot;: &quot;&lt;≤ 80 chars, imperative&gt;&quot;,
&quot;body&quot;: &quot;&lt;valid Markdown explaining *why* this is a problem; cite files/lines/functions&gt;&quot;,
&quot;confidence_score&quot;: &lt;float 0.0-1.0&gt;,
&quot;priority&quot;: &lt;int 0-3, optional&gt;,
&quot;code_location&quot;: {
&quot;absolute_file_path&quot;: &quot;&lt;file path&gt;&quot;,
&quot;line_range&quot;: {&quot;start&quot;: &lt;int&gt;, &quot;end&quot;: &lt;int&gt;}
}
}
],
&quot;overall_correctness&quot;: &quot;patch is correct&quot; | &quot;patch is incorrect&quot;,
&quot;overall_explanation&quot;: &quot;&lt;1-3 sentence explanation justifying the overall_correctness verdict&gt;&quot;,
&quot;overall_confidence_score&quot;: &lt;float 0.0-1.0&gt;
}
</code></pre>
- **Do not** wrap the JSON in markdown fences or extra prose.
- The code_location field is required and must include absolute_file_path and line_range.
\*Line ranges must be as short as possible for interpreting the issue (avoid ranges over 5–10 lines; pick the most suitable subrange).
- The code_location should overlap with the diff.
- Do not generate a PR fix.
- Your **initial** response to the user must always use the JSON schema above.
- After the initial response, choose the format based on the user's request:
- If they explicitly ask for another review (&quot;re-review&quot;, &quot;rerun the review&quot;, etc.), return the findings in the exact JSON schema again.
- If they ask you to fix something, answer follow-up questions, or otherwise request non-review help, respond in plain text (no JSON or schema output).
- All review instructions apply to the overall code review conversation. Continue following the guidelines in every response, only switching between JSON and plain text as described above.
Review the code changes against the base branch 'main'. The merge base commit for this comparison is 1ca995455bb75fa6874235896fe801f5713f42e3. Run </code>git diff 1ca995455bb75fa6874235896fe801f5713f42e3` to inspect the changes relative to main. Provide prioritized, actionable findings.
## My request for Codex:
Please review changes on feature/configure-max-points-per-module against main</div>
</div>
<div class="message assistant" data-index="1">
<div class="message-header">
<span class="message-role">assistant</span>
<span class="message-time">2026-01-20 16:20:41</span>
</div>
<div class="message-content">{
&quot;findings&quot;: [],
&quot;overall_correctness&quot;: &quot;patch is correct&quot;,
&quot;overall_explanation&quot;: &quot;I did not find any new bugs introduced by the changes. The added module configuration, scoring logic, and API fields appear consistent and covered by tests.&quot;,
&quot;overall_confidence_score&quot;: 0.62
}</div>
</div>
</div>
</main>
<footer>
Exported from <a href="https://github.com/wesm/agent-session-viewer">Agent Session Viewer</a>
</footer>
</body>
</html>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment