Try one new feature inside your existing app

Read as Markdown

Replace the [brackets] with your details, then paste this into your assistant.

Make one small, reviewable improvement to my existing app in [repository or approved local path]. The person using it needs to [one observable behavior]. A successful example is [specific input, action and expected result]. Keep the change within [files or functional area], using [local tools or an explicitly approved cloud coding environment]. My work limit is [time or tool budget]. Repository-write permission is [approved workspace and scope, or return a patch only].

First read the project's instructions, relevant code, existing tests and run commands. Identify the current revision, working-tree changes and the smallest path through the existing app that delivers this behavior. Record what already works and any existing failure relevant to the change. This is an addition to this codebase, not a replacement app or a set of unrelated prototypes. Preserve its conventions and existing behavior.

If repository writes are authorized, use a separate branch and isolated checkout or equivalent workspace from a recorded base revision. Preserve unrelated work; do not reset, overwrite, discard or sweep it into your change. If the feature depends on uncommitted work, explain the dependency and use it only within my approved scope. If repository writes are not authorized, prepare a reviewable patch against the identified base and state that it has not been applied. Do not imply a branch or commit exists unless you created and verified it.

Use only an available, supported coding-agent capability if delegating implementation. Before dispatch, confirm that the selected environment and repository access are within my authorization; a request to change code does not authorize uploading it to an arbitrary service. Give the coding agent the same file scope, behavior, budget and restrictions. Keep a task reference so you can inspect its output. A delegated agent's completion message is a claim to check, not proof that the feature works. If the capability is unavailable, work with the authorized local tools or report the missing capability.

Implement the smallest complete version using existing dependencies and the lockfile. Use synthetic fixtures where data is needed; label them. Do not add unrelated refactors, upgrade packages, change credentials, send repository content or user data to external services, make paid calls, open a public pull request, merge or deploy without separate approval. If a requirement needs broader access or a consequential action, stop at that boundary with a concrete blocker and the work completed so far.

Inspect the final diff yourself, including any delegated changes. Run the relevant existing checks and add a focused behavior test only if it meaningfully verifies the change. Where the runtime and browser are available, exercise the intended interaction and one important edge case in the actual changed app. Record the revision or workspace tested, exact commands, observed results and any pre-existing failures. Do not convert a passing build into a claim that the interaction was tested. If execution is unavailable, label the patch and preview status untested.

Return the branch or patch, a concise explanation of the change, how to run or open the private preview, and the check record. Include a screenshot of the observed behavior when available, with no private data. Separate implemented, observed working, failed and unchecked items. A screenshot alone is not proof of persistence or an end-to-end workflow. Stop at the budget or after one bounded repair pass, and leave a clear next step if incomplete. Keep the result ready for my review; do not merge it into the main branch or publish it.

Automatic copying is unavailable. Select the prompt text above and copy it.