Chrome extension prompts should make execution contexts and permissions explicit. A popup, content script and background worker do not share one ordinary application lifecycle. A feature can appear correct while the popup is open, then fail after background work restarts. These prompts help an agent review the manifest, trace message boundaries and verify behavior under the conditions a real extension encounters.
Identify where the code runs
Provide the manifest, supported Chrome version and relevant code from each context. Describe the target page origin and the user action that starts the feature. Include error output from the context where it occurred. A background error and a page-console error can describe different failures even when they happen during the same interaction.
The Chrome permissions documentation distinguishes API permissions, host permissions and optional access. Use the relevant API reference before changing the manifest. The prompts below ask for a minimal permission map instead of recommending broad access to make an error disappear.
Connect each permission to a feature
A manifest review should explain why each permission exists and whether the user needs to grant it at installation or at the moment of use. Ask what happens if optional access is declined or later removed. Include existing users in the plan, since a permission change may affect their update experience as well as a clean install.
Review {{manifest_path}} for {{extension_features}}.
Map every permission and host pattern to the code and user action that
needs it. Identify unnecessary access and feasible optional permissions.
Describe declined/revoked access behavior and update considerations.
Propose a focused manifest change and checks against our supported Chrome
version. Do not replace narrow host access with all-sites access by default.
Trace messages across trust boundaries
A message handler should know which context is allowed to request an action and how input is validated. Provide the sender and receiver rather than only the failing listener. Ask the agent to follow response handling and error propagation. A successful send call is not proof that a privileged operation completed correctly.
Review messaging for {{feature}} across {{sender_paths}} and {{receiver_paths}}.
Map sender identity, message types, validation and privileged actions.
Check response and error behavior, unexpected fields and messages from
unapproved contexts. Add focused tests for {{invalid_message_case}}.
Keep sensitive data and credentials out of message logs and examples.
Test restart and interrupted interactions
Choose a workflow that spans more than the popup's lifetime. Ask which state survives a worker restart and how in-progress work is recovered or abandoned. A useful test includes closing the popup, re-opening it and repeating the action. Define whether duplicate work is acceptable and how the person learns the result.
Investigate {{lifecycle_bug}} in {{worker_and_ui_paths}}.
List required state, where it is stored and how initialization runs again.
Build a reproduction that closes the popup and restarts background work.
Define interrupted-operation and duplicate-action behavior.
Propose the smallest repair and browser verification steps. Report which
lifecycle checks were actually performed and which remain manual.
Validate the installed extension, not only modules
Inspect the packaged files and load the intended build in a test browser profile. Check permissions, message errors and recovery after restarting the browser when those conditions matter. Keep a separate list of store publication work; a locally functioning extension is not automatically reviewed or published in the Chrome Web Store.
Save the approved extension prompt in Kipt with variables for context, manifest and failure sequence. Use the security review prompts for a broader assessment of privileged actions and untrusted page input.