MODULE 18 / 18 · PART 5 · LEAD THE AGENT & THE INTERFACE
Feature Fix, Refine & Improve
Improve a live feature without breaking the users already depending on it.
THE SHORT ANSWER
What this module changes.
Improving a live feature is harder than building a new one because the constraint is users, data and behavior already in production. Establish a baseline and change one thing at a time.
Improving an existing feature is harder than building a new one, because the constraint is not the code — it is the users, the data, and the behavior already in production. These prompts force the agent to establish a baseline, name the invariant that must survive, and change one thing at a time.
Feature requests from sales, support tickets and a workflow staff use every day rarely point at the same change. Watch the workaround before you redesign the feature; the workaround is often the real requirement.
THE MODULE PROMPT LIBRARY
20 prompts for fix, refine & improve.
Copy any prompt, replace the [bracketed] slots with your own project context, and attach the files the agent needs. Use “Copy all prompts” when you want the full module in one place.
20 copy-ready prompts. Bracket text is a slot for your own context — replace it before you send the prompt.
Here is [feature] and how it currently behaves: [context]. Before changing anything, describe what it does today, what it was originally designed to do, and where those two have diverged.
Why it worksMost "improvements" are really drift corrections; you cannot fix drift you have not named.
Fix [bug/defect] in [feature]. First reproduce it as a failing test, then fix it, then show me the test passing and the diff.
Why it worksAnchors the fix to evidence and guarantees the defect cannot silently return.
Refine [feature] to [goal]. State the invariant that must not change, then give me the smallest diff that achieves the goal without touching it.
Why it worksConstrains the change to the goal instead of the agent's enthusiasm.
Improve [feature] for [user segment / use case]. What do they struggle with today, and what is the smallest change that removes the biggest friction?
Why it worksDirects improvement at a real user problem rather than at code aesthetics.
What is the current baseline for [feature] — latency, error rate, conversion, support tickets? Give me the measurement plan before the improvement plan.
Why it worksYou cannot claim an improvement without a number to improve on.
Here is [feature] and its known weaknesses: [list]. Rank them by user impact, frequency, and cost to fix. Then propose the order.
Why it worksTurns a pile of complaints into a prioritized sequence.
Improve [feature] without changing its public interface, its data format, or its error semantics. Tell me what is left that you can still improve.
Why it worksForces improvement inside the compatibility envelope instead of breaking callers.
Refine [feature] for the edge cases: empty, single item, huge input, slow dependency, concurrent use, and partial failure. What breaks, and what is the fix for each?
Why it worksEdge cases are where "working" features actually fail in production.
Improve the error handling in [feature]: every failure should be visible, actionable, and attributable. Show me the before and after for each path.
Why it worksConverts silent or cryptic failures into diagnosable ones.
Refine [feature] for performance: profile it first, tell me where the time actually goes, then propose the change with the measured delta.
Why it worksPrevents speculative optimization and demands a before/after number.
Improve [feature]'s UX: for each step, tell me what the user is trying to do, what the interface makes them do instead, and the smallest change that closes the gap.
Why it worksFrames UX improvement as intent-versus-effort, which is measurable.
Refine [feature] to be more maintainable: identify the parts that are hardest to change, explain why, and propose the refactor that lowers that cost.
Why it worksTargets maintainability where it actually hurts rather than where it is easy.
Improve [feature]'s observability: what would I need to see to know it is healthy, degrading, or broken — and what is missing today?
Why it worksMakes the improvement verifiable in production, not just in review.
Here is [feature] and its test suite: [context]. Which behaviors are untested, which tests are tautological, and what would you add before changing anything?
Why it worksEstablishes a safety net before the improvement, not after the regression.
Refine [feature] to reduce its surface area: what can be removed, merged, or defaulted away without losing capability?
Why it worksSubtraction is the most under-used improvement and the cheapest to maintain.
Improve [feature] incrementally: give me a sequence of shippable steps, each of which leaves the feature working and measurably better than the last.
Why it worksPrevents the big-bang rewrite that never lands.
Refine [feature] for accessibility: keyboard, screen reader, contrast, and motion. List the gaps and the fix for each.
Why it worksAccessibility gaps are defects, not enhancements, and they are usually cheap to close early.
Improve [feature]'s resilience: what happens when its dependencies are slow, down, or returning garbage? Show me the degradation path for each.
Why it worksImprovement that ignores failure modes just moves the outage.
Refine [feature]'s configuration and defaults: what should be the default, what should be configurable, and what should be removed entirely?
Why it worksBad defaults are a permanent tax; good ones are an improvement nobody has to configure.
Improve [feature] and tell me how I will know it worked: the metric, the target, the time window, and the rollback trigger if it does not.
Why it worksCloses the loop — an improvement without a success signal is just a change.
PRACTICE · 20–30 MINUTES
Try it on a project you actually own.
Pick one live feature. Measure its baseline, list its known weaknesses, and ship one small improvement with a success metric and a rollback trigger.
- Pick one prompt from this module that matches a real task.
- Replace every bracketed slot with context from the feature you are working on now.
- Attach only the files the agent needs. Keep secrets, credentials and personal data out of the chat.
- Ask for the artifact — a spec, diff, test, runbook or decision note — and the evidence that it works.
- Record what changed and what remains unverified in the repository.
Want the same prompts across every module? Search the full prompt library or return to the course overview.