Trajectory Editor

The Golden Rule

Explain WHY, not just WHAT. Every step should show expert-level reasoning about the decision being made.

Enhancing THOUGHT / REASONING

This is where most of your work goes. Turn generic statements into expert reasoning.

Let me look at the main classes mentioned in the PR description:

The prompt mentions two key classes: ChessGame (where I need to add the PGN constructor) and MoveValidator (where I need to add findPiece). Before writing any code, I should understand how the existing makeMove() method works, what coordinate system the board uses (the prompt mentions 0-7 indexing), and how MoveValidator.possibleMoves() resolves moves. Let me start with ChessGame since that's where the constructor will live.

Now let me check the test files to understand what's expected:

Before implementing anything, I should read the test files. They'll tell me the exact method signatures expected, what exceptions should be thrown, and what edge cases I need to handle. The tests are my contract — if I satisfy them, the implementation is correct.

(empty — no reasoning at all)

Now I have a complete picture of the MoveValidator class. It currently has possibleMoves() which returns valid destination squares. For findPiece(), I need to work backwards — given a destination and piece type from SAN, find which piece can make that move. I'll iterate through all pieces of the given color and type, check which can reach the destination, then apply disambiguation if multiple candidates exist.

Key Principles for THOUGHT

• First-person monologue — "I need to...", "Looking at this, I notice..."
• Show the reasoning chain — "Because X, I should Y"
• Explain decisions — "I'm choosing regex over a state machine because..."
• Acknowledge complexity — "The tricky part here is..."
• Reference the problem — "The prompt says empty PGN should throw an exception"
• Never leave empty — Every step needs reasoning (exception: in a sequence of similar tool calls for the same purpose, only the first needs a thought)

When to DELETE Steps

• Redundant — Agent read the same file multiple times
• Dead ends — Agent went down a wrong path then backtracked
• Noise — Irrelevant checks (e.g., "Is Docker available?")
• Repetitive exploration — Listed directory 5 times, keep one

After deleting, make sure surrounding steps still flow logically. You may need to edit the next step's thought to bridge the gap.

When to ADD Steps

• Missing analysis — Agent jumped to code without reading relevant files
• Missing reasoning — Correct decision but no explanation why
• Skipped verification — Agent never tested its code

Handling the Agent's Fix

If the agent passed tests: Focus on enhancing reasoning. Small improvements to tool calls are fine if you spot them. Your Guided Patch = the agent's .patch file.

If the agent failed tests: Use the Ground Truth Patch to understand the correct fix and adjust the final steps to lead there. Delete wasted steps where the agent went in circles. Your Guided Patch = the Ground Truth Patch, or your own fix if you wrote one.

Writing your own fix: If you can write a better fix — especially when the agent went completely off track — you're free to do so. Use your best judgement as a software engineer. The ground truth is a reference, not a strict requirement. Your Guided Patch = your git diff output.

Ideal Trajectory Flow

1. Understand the problem (read prompt, identify requirements)
2. Explore the codebase (read relevant files)
3. Plan the approach (reason about design decisions)
4. Implement the solution (write/edit code)
5. Verify (run tests, check output)

LLM Helper Buttons

The editor has two buttons that copy prompts to your clipboard. Paste into any LLM (ChatGPT, Claude, etc.) and copy the result back.

• LLM: Proofread — Cleans up your reasoning text for grammar, clarity, and professional tone.
• LLM: Format Output — Generates tool output in the correct SWE Agent format when you add new steps. Works well for create and str_replace. For bash and view commands, the content will be fake — use as a format template only and replace with real output.

Pre-Save Checklist

• Every step has a non-empty THOUGHT field (exception: in a sequence of similar tool calls for the same purpose, only the first needs a thought)
• Reasoning explains WHY, not just WHAT
• First-person monologue style throughout
• No redundant or dead-end steps remain
• Tool usage is efficient
• Trajectory flows logically
• Final patch aligns with target / passes tests
• Reasoning is natural and conversational