Try a change worth keeping
Turn recurring friction into a better default for your agents.
Your goal is one change that makes real work easier while keeping the quality bar. Start with a connected project and a saved task report.
1. Find one recurring problem
Open Agent work → Reports, or ask:
Use PhaseDrift to find one repeated obstacle in this project. Show the source examples. Propose one small code, tool, skill or workflow change and how we would check it. Wait for my choice before implementation.
Choose something specific, such as false test failures or repeated setup errors. A high complexity count alone does not mean a refactor will help.
2. Let the agent prepare and apply the fix
Once you choose it, say:
Implement this change and track it in PhaseDrift. Reuse the source-linked proposal. Save the original behavior, mark where the fix was implemented, and run the real verification. Write what changed and what happens now in plain language. Leave the result ready for review.
The agent prepares the plan and measurement. For a tool command, compare the same inputs and checks before and after. For a workflow, collect relevant task outcomes. Without a before point, the change remains a prospective test.
3. Review the result
Open Agent work → Improvements. Select the change. Read What changed for the problem and result; open Evidence & details for the checks and source reports.
| What you see | What to do |
|---|---|
| Matching evidence improves and quality passes | Keep the change |
| The idea needs a better implementation | Adjust and continue |
| It harms work or is no longer useful | Stop tracking; revert the code separately if needed |
| Evidence is missing | Continue relevant work before deciding |
These are the source-linked improvement decisions. Older direct effort trials have a separate review flow, documented below.
4. Try it during normal work
Use the updated checkout on the next relevant task. The agent records what it actually used and checked. A fix on another branch cannot explain this task's result.
A real command can be recorded without creating a trial:
phasedrift check run --check project-tests -- bun run testReplace the command with the project's existing recipe. Both failures and passes are retained.
Choose a measurement that matches the problem
| Problem | Check the fix by |
|---|---|
| Test files break each other's mocks | Repeating the same test cohort, including a real failure |
| A command needs manual setup | Running it from a fresh checkout |
| Agents repeatedly search the wrong modules | Checking recurrence on relevant tasks and the finished result |
A smaller token total is not a substitute for checking the specific problem.
Ask for a plan without implementing it
Use PhaseDrift to find one recurring obstacle. Show the source reports and propose one focused codebase, tool, or skill change. Name its scope, measurement, and quality check. Wait for my choice before changing the project or starting a trial.
Exact commands for the trial
These are the older direct per-turn comparison commands. For the main report-to-proposal loop, use the source-linked commands in the CLI reference.
Run inside your target project. Replace <trial-id> with the returned ID. Use the project's actual check recipe and select your supported coding host. These commands write trial records; the check command executes the command you supply.
Create the trial. This example uses Codex and measures searching before the first edit:
phasedrift trial start \
--title "Targeted project guidance" \
--hypothesis "Module guidance reduces searching on relevant tasks" \
--metric search-before-edit \
--harness codex \
--direction decrease \
--idempotency-key targeted-guidance-v1Use a fresh idempotency key for each distinct trial. Repeating the key reuses that trial.
Pin the before point before adding the guidance:
phasedrift trial capture <trial-id> \
--mode baseline \
--reason "Before adding the module guidance."Capture does not turn missing measurements into a baseline. If comparable turns are unavailable, collect them first or keep the plan prospective.
When the evidence is incomplete
| What you see | Next useful action |
|---|---|
| No comparable before point | Collect relevant work or keep the plan prospective. |
| Follow-up is missing | Do another relevant task, then capture follow-up. |
| A quality check fails | Fix or revert the change before claiming it helped. |
| Workload or host changed | Inspect the contributing sessions. Avoid attributing a mixed comparison to this change. |
A faster first edit is useful only if the right work follows. Include complete effort and accepted quality, not just the nicest measurement.
Make the useful lesson available
When the evidence supports your choice, review and activate a scoped lesson separately. Keep the implemented code or tooling change available in the working branch. Relevant agents can retrieve it at task entry. Watch whether it continues to help.