Move from static to always-updating strategy documents.
A strategy can lose its influence because the world it describes has moved on. A hoped-for future fails to arrive; a worry never materializes; a new leader or a surprising quarter changes what matters. Build a strategy document that notices those changes and responds within tolerances you set.
Try it now
Copy the prompt into your AI tool of choice, then answer its questions as they come.
Paste it into any AI chat to start. For most people, this is all you need.
Everything on this page in one paste: the prompt plus the full plan, every step and what to check. Use it for longer moves, to plan ahead, to share with a colleague, or if your AI can't open links.
How it goes
What the AI will do
- Reads your strategy alongside the decisions, financial results, customer information and market developments that could change it.
- Builds a connected system that keeps the document current, makes agreed minor updates and alerts you when a larger change calls for a decision.
What to have ready
- An existing strategy or plan, or a rough description of where it lives and what it is meant to achieve.
- Access to the relevant records and a place the system can run; the AI investigates what is available and identifies any missing setup.
Where you come in
- Clarify the assumptions and strategic commitments the record leaves uncertain.
- Decide what the system may update by itself, what should reach you immediately and who owns those decisions.
- Review a demonstrated update and alert before the recurring system begins operating.
What you'll get
A strategy document connected to a working update and alert system, with visible sources, change history and a cadence you choose. Missing connections are identified explicitly; a system awaiting them is not yet continuously updating.
You're done when
You have a strategy document whose connected system has demonstrated an update and a significant-change alert, with agreed tolerances, source coverage and verified recurring operation. If an essential connection or runtime is still missing, you have the built and tested portion plus the exact remaining setup, clearly marked as unfinished.
These are general instructions, not a description of this user's particular AI system, tools, access, or circumstances. Adapt the method to the user's goal and the capabilities you can actually use, while preserving the activity's essential sequence, review points, and intended result. ### Start with the activity and the user's context Read the complete activity and guide the user through it. Use the activity prompt yourself; the user does not need to paste it again. Keep the responsibilities of the user, the AI, and any colleague clear. Begin with what the user has already supplied. Establish the intended result and resolve missing context through focused questions when needed. Work within the activity's stated scope, permissions, required confirmations, and stopping points, including any deliberate order for introducing information. Make progress with the available information and reasonable, clearly identified assumptions where the activity allows them. ### Check the capabilities needed for this work Inspect relevant available tools, connectors, and data. Use small, relevant, non-destructive checks to establish whether necessary access or a capability actually works. Naming a product does not establish access to it. Let this activity determine what needs checking; do not impose a universal preliminary questionnaire or a full system audit. When useful access is missing: - Explain what you cannot reach and how that material would help. - Investigate practical setup, connection, export, or other access alternatives before asking the user to gather material or troubleshoot. - If progress depends on access, request only the specific user action or permission needed to enable it or provide the material another way. Continue useful independent work while awaiting the response. - Offer to walk the user through an export or upload. Welcome files, links, copied text, rough notes, or an interview as supported by your system and the activity, and use the best available route. If the missing access is optional, continue with what is available. ### Ask focused questions and respect the answers Ask questions only when necessary to complete the work well or satisfy the activity's required review points. Build on answers already supplied. Ask one question at a time, or a small group of closely related questions. Wait on work that depends on the answer, and continue useful work that does not. Explain unfamiliar language with examples where helpful. Confirm answers or decisions you supply on the user's behalf before treating them as the user's final answers or decisions. This does not require separate approval of every sourced finding; follow the activity's specific review requirements. ### Keep evidence and independent contributions distinct Distinguish evidence, inference, and missing information. Check your work against the source material. Use independent agents when your system actually supports delegation and independent investigation or review would improve the work: - Give each agent a bounded brief and the context appropriate to its role. - Keep discovery independent until synthesis where the activity requires it. Preserve any requirement for the user or colleagues to contribute before seeing other explanations. - Follow the activity's stated fallback and any required confirmation when independent agents or fresh contexts are unavailable. Preserve reviewer isolation where required; describe shared-context or sequential passes accurately. ### Produce, check, and revise the result Do the substantive investigation and production. Carry the activity through to the most complete, usable result within its scope, rather than ending with a plan or handing the main work back to the user. When missing information does not prevent useful work, proceed with clearly identified assumptions where the activity permits them. Check the result against the activity's completion criteria. At each substantive delivery, state what is complete and any material unfinished work, assumptions, helpful missing information, and remaining uncertainty. Explain how these affect what the user can use, and help the user revise the result. Preserve the activity's stopping point. Do not turn a rehearsal, investigation, or test-design activity into execution that the user has not authorized. ### Establish the strategy and its current authority Build a system that continuously updates my strategy document as the underlying world changes. Keep the document useful for decisions, with minor changes handled automatically within tolerances I set and significant developments brought to me with the decisions they create. Start with the strategy or rough description I provide. Identify its purpose, time horizon, audience, owner and current authoritative version from the material available. Search relevant email, chats and other messages, including WhatsApp where accessible, calendar items, leadership and planning meeting transcripts, strategy drafts, decision records and related plans. Use names, initiatives, dates and distinctive phrases from the strategy as search terms. Establish which choices remain in force, which later decisions superseded earlier ones and who uses the document. Do this investigation before asking me to reconstruct its history. Ask one focused question at a time when a consequential ambiguity remains. ### Map what could make the strategy change Extract the objectives, commitments, milestones, explicit assumptions, hoped-for developments and feared developments. Identify implied assumptions separately as your interpretation and ask me to confirm those that materially affect the system's behavior. For each important assumption or commitment, identify the evidence that would support, weaken or invalidate it. Search the relevant P&L statements and finance records, operating reports, customer records and feedback, sales information, leadership announcements, organization changes and market sources. Read the correspondence and meeting discussions that explain the numbers or events. Check definitions, periods and source versions before treating an apparent variance as a change. Distinguish a public market development from a prediction about its effect on us. Create a compact map from each strategic element to its relevant documents and data sources, the signal to monitor, the responsible person and the likely decision when it changes. Include evidence of things that have failed to happen: a missed milestone or an expected market development whose date has passed. Repeated mentions of the same event are one signal, not corroboration. For large collections, use bounded research assignments by strategic theme or source family when agents are available. Give each assignment its question, period, source references and required evidence. Keep a coverage record, reconcile conflicts centrally and use successive passes when parallel agents are unavailable. ### Inspect the actual connections and explain what is needed Inspect and try the available access to every source family in that map. Verify that records can be read and refreshed, that the strategy can be updated in its intended location, and that the proposed runtime can store state, run on a schedule or event and deliver alerts. Consult current official documentation for the actual tools and integrations when implementing; do not assume a chat connection provides background execution or document-writing access. Tell me plainly what is already usable and what this system still needs: particular source permissions, document access, a place to run, persistent storage, a schedule or event trigger and an alert destination. Investigate the setup and prepare the configuration, code and connection steps yourself before asking for the specific action only I or an administrator can perform. Offer to draft a narrowly scoped access request if needed. An export can support initial analysis and a working local demonstration; it cannot establish a live connection. Carry missing sources and their effect on coverage through the result. ### Set the tolerances, then build Use the evidence to propose concrete rules for my review. State what counts as a minor update, what constitutes a significant deviation, which sections may change automatically and what strategic commitments require a decision. For example, refreshing an observed metric may be automatic; changing a target, abandoning an initiative or reallocating resources may require an alert and a choice. Agree on numerical and qualitative triggers suitable for this strategy, how several small changes accumulate into a significant one, the monitoring cadence and who receives which alerts. Wait on unresolved consequential choices; carry out independent implementation work meanwhile. Use authority I have already given without asking again. Build the actual system in the available environment. It must: - Refresh all relevant connected sources and record their freshness and any gaps. - Compare new evidence with the strategy's current assumptions and commitments, using source links and dates. - Apply permitted minor updates to the intended document, preserving the previous version and a readable explanation of each change. - Hold significant proposed changes for the relevant decision maker and send a concise alert explaining what changed, which assumption or commitment is affected and the decisions now available. - Record subsequent human decisions and incorporate the resulting authorized revision, so the next cycle uses the updated strategy. Build a single coordinated update process so overlapping runs or repeated events do not produce duplicate alerts or conflicting edits. Make source failures visible; missing data must not look like confirmation that the strategy remains current. Include a simple way to pause the system, change tolerances and restore a previous document version. ### Demonstrate the complete cycle and put it into use Test the system against representative past changes and controlled examples: a minor permitted update, a major change needing a decision, a hoped-for event that does not arrive, conflicting evidence and an unavailable source. Verify the actual edited document, retained prior version, source references and alert destination. Confirm that a significant proposed change does not silently become an adopted strategy. Give an independent reviewer the document changes, original strategy, evidence and agreed tolerances, without your explanation of why the implementation should work. Ask whether the changes preserve meaning and whether a decision maker can act on the alert. If a separate reviewer is unavailable, run a distinct review pass and say so. Repair material findings and recheck the affected behavior. Show me the working update and decision cycle. Within the authority agreed above, activate the recurring job and verify its first real run and next scheduled run. Provide the live document, system location, coverage and freshness view, change history and simple operating instructions. If an essential permission or runtime remains unavailable, deliver the implementation and tested demonstration, identify the exact remaining action and label recurring operation as incomplete. A proposed architecture alone does not complete this activity. These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.
View full AI instructions
Move from static to always-updating strategy documents.
What the AI will do
- Reads your strategy alongside the decisions, financial results, customer information and market developments that could change it.
- Builds a connected system that keeps the document current, makes agreed minor updates and alerts you when a larger change calls for a decision.
What you can provide
- An existing strategy or plan, or a rough description of where it lives and what it is meant to achieve.
- Access to the relevant records and a place the system can run; the AI investigates what is available and identifies any missing setup.
Where you'll take part
- Clarify the assumptions and strategic commitments the record leaves uncertain.
- Decide what the system may update by itself, what should reach you immediately and who owns those decisions.
- Review a demonstrated update and alert before the recurring system begins operating.
What you'll get
A strategy document connected to a working update and alert system, with visible sources, change history and a cadence you choose. Missing connections are identified explicitly; a system awaiting them is not yet continuously updating.
Activity context
A strategy can lose its influence because the world it describes has moved on. A hoped-for future fails to arrive; a worry never materializes; a new leader or a surprising quarter changes what matters. Build a strategy document that notices those changes and responds within tolerances you set.
For the user
Begin with a strategy or plan you would like to keep alive. A document link or a rough explanation is enough to start. The AI will investigate the supporting records and build the system; you will resolve important ambiguities, set its freedom to act and review how it behaves.
Guidance for the AI
These are general instructions, not a description of this user's particular AI system, tools, access, or circumstances. Adapt the method to the user's goal and the capabilities you can actually use, while preserving the activity's essential sequence, review points, and intended result.
Start with the activity and the user's context
Read the complete activity and guide the user through it. Use the activity prompt yourself; the user does not need to paste it again. Keep the responsibilities of the user, the AI, and any colleague clear.
Begin with what the user has already supplied. Establish the intended result and resolve missing context through focused questions when needed. Work within the activity's stated scope, permissions, required confirmations, and stopping points, including any deliberate order for introducing information. Make progress with the available information and reasonable, clearly identified assumptions where the activity allows them.
Check the capabilities needed for this work
Inspect relevant available tools, connectors, and data. Use small, relevant, non-destructive checks to establish whether necessary access or a capability actually works. Naming a product does not establish access to it. Let this activity determine what needs checking; do not impose a universal preliminary questionnaire or a full system audit.
When useful access is missing:
- Explain what you cannot reach and how that material would help.
- Investigate practical setup, connection, export, or other access alternatives before asking the user to gather material or troubleshoot.
- If progress depends on access, request only the specific user action or permission needed to enable it or provide the material another way. Continue useful independent work while awaiting the response.
- Offer to walk the user through an export or upload. Welcome files, links, copied text, rough notes, or an interview as supported by your system and the activity, and use the best available route. If the missing access is optional, continue with what is available.
Ask focused questions and respect the answers
Ask questions only when necessary to complete the work well or satisfy the activity's required review points. Build on answers already supplied. Ask one question at a time, or a small group of closely related questions. Wait on work that depends on the answer, and continue useful work that does not. Explain unfamiliar language with examples where helpful.
Confirm answers or decisions you supply on the user's behalf before treating them as the user's final answers or decisions. This does not require separate approval of every sourced finding; follow the activity's specific review requirements.
Keep evidence and independent contributions distinct
Distinguish evidence, inference, and missing information. Check your work against the source material.
Use independent agents when your system actually supports delegation and independent investigation or review would improve the work:
- Give each agent a bounded brief and the context appropriate to its role.
- Keep discovery independent until synthesis where the activity requires it. Preserve any requirement for the user or colleagues to contribute before seeing other explanations.
- Follow the activity's stated fallback and any required confirmation when independent agents or fresh contexts are unavailable. Preserve reviewer isolation where required; describe shared-context or sequential passes accurately.
Produce, check, and revise the result
Do the substantive investigation and production. Carry the activity through to the most complete, usable result within its scope, rather than ending with a plan or handing the main work back to the user. When missing information does not prevent useful work, proceed with clearly identified assumptions where the activity permits them.
Check the result against the activity's completion criteria. At each substantive delivery, state what is complete and any material unfinished work, assumptions, helpful missing information, and remaining uncertainty. Explain how these affect what the user can use, and help the user revise the result.
Preserve the activity's stopping point. Do not turn a rehearsal, investigation, or test-design activity into execution that the user has not authorized.
Your AI prompt
Establish the strategy and its current authority
Build a system that continuously updates my strategy document as the underlying world changes. Keep the document useful for decisions, with minor changes handled automatically within tolerances I set and significant developments brought to me with the decisions they create.
Start with the strategy or rough description I provide. Identify its purpose, time horizon, audience, owner and current authoritative version from the material available. Search relevant email, chats and other messages, including WhatsApp where accessible, calendar items, leadership and planning meeting transcripts, strategy drafts, decision records and related plans. Use names, initiatives, dates and distinctive phrases from the strategy as search terms. Establish which choices remain in force, which later decisions superseded earlier ones and who uses the document. Do this investigation before asking me to reconstruct its history. Ask one focused question at a time when a consequential ambiguity remains.
Map what could make the strategy change
Extract the objectives, commitments, milestones, explicit assumptions, hoped-for developments and feared developments. Identify implied assumptions separately as your interpretation and ask me to confirm those that materially affect the system's behavior.
For each important assumption or commitment, identify the evidence that would support, weaken or invalidate it. Search the relevant P&L statements and finance records, operating reports, customer records and feedback, sales information, leadership announcements, organization changes and market sources. Read the correspondence and meeting discussions that explain the numbers or events. Check definitions, periods and source versions before treating an apparent variance as a change. Distinguish a public market development from a prediction about its effect on us.
Create a compact map from each strategic element to its relevant documents and data sources, the signal to monitor, the responsible person and the likely decision when it changes. Include evidence of things that have failed to happen: a missed milestone or an expected market development whose date has passed. Repeated mentions of the same event are one signal, not corroboration.
For large collections, use bounded research assignments by strategic theme or source family when agents are available. Give each assignment its question, period, source references and required evidence. Keep a coverage record, reconcile conflicts centrally and use successive passes when parallel agents are unavailable.
Inspect the actual connections and explain what is needed
Inspect and try the available access to every source family in that map. Verify that records can be read and refreshed, that the strategy can be updated in its intended location, and that the proposed runtime can store state, run on a schedule or event and deliver alerts. Consult current official documentation for the actual tools and integrations when implementing; do not assume a chat connection provides background execution or document-writing access.
Tell me plainly what is already usable and what this system still needs: particular source permissions, document access, a place to run, persistent storage, a schedule or event trigger and an alert destination. Investigate the setup and prepare the configuration, code and connection steps yourself before asking for the specific action only I or an administrator can perform. Offer to draft a narrowly scoped access request if needed. An export can support initial analysis and a working local demonstration; it cannot establish a live connection. Carry missing sources and their effect on coverage through the result.
Set the tolerances, then build
Use the evidence to propose concrete rules for my review. State what counts as a minor update, what constitutes a significant deviation, which sections may change automatically and what strategic commitments require a decision. For example, refreshing an observed metric may be automatic; changing a target, abandoning an initiative or reallocating resources may require an alert and a choice. Agree on numerical and qualitative triggers suitable for this strategy, how several small changes accumulate into a significant one, the monitoring cadence and who receives which alerts. Wait on unresolved consequential choices; carry out independent implementation work meanwhile. Use authority I have already given without asking again.
Build the actual system in the available environment. It must:
- Refresh all relevant connected sources and record their freshness and any gaps.
- Compare new evidence with the strategy's current assumptions and commitments, using source links and dates.
- Apply permitted minor updates to the intended document, preserving the previous version and a readable explanation of each change.
- Hold significant proposed changes for the relevant decision maker and send a concise alert explaining what changed, which assumption or commitment is affected and the decisions now available.
- Record subsequent human decisions and incorporate the resulting authorized revision, so the next cycle uses the updated strategy.
Build a single coordinated update process so overlapping runs or repeated events do not produce duplicate alerts or conflicting edits. Make source failures visible; missing data must not look like confirmation that the strategy remains current. Include a simple way to pause the system, change tolerances and restore a previous document version.
Demonstrate the complete cycle and put it into use
Test the system against representative past changes and controlled examples: a minor permitted update, a major change needing a decision, a hoped-for event that does not arrive, conflicting evidence and an unavailable source. Verify the actual edited document, retained prior version, source references and alert destination. Confirm that a significant proposed change does not silently become an adopted strategy.
Give an independent reviewer the document changes, original strategy, evidence and agreed tolerances, without your explanation of why the implementation should work. Ask whether the changes preserve meaning and whether a decision maker can act on the alert. If a separate reviewer is unavailable, run a distinct review pass and say so. Repair material findings and recheck the affected behavior.
Show me the working update and decision cycle. Within the authority agreed above, activate the recurring job and verify its first real run and next scheduled run. Provide the live document, system location, coverage and freshness view, change history and simple operating instructions. If an essential permission or runtime remains unavailable, deliver the implementation and tested demonstration, identify the exact remaining action and label recurring operation as incomplete. A proposed architecture alone does not complete this activity.
Done when
You have a strategy document whose connected system has demonstrated an update and a significant-change alert, with agreed tolerances, source coverage and verified recurring operation. If an essential connection or runtime is still missing, you have the built and tested portion plus the exact remaining setup, clearly marked as unfinished.
These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.
These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.