Give a big project an FAQ bot.
A big project generates the same questions in a dozen places. Which deadline is real? Why did we drop that feature? Who can approve a change? Give the project a place people can ask—and get an answer grounded in what the team actually decided. The AI helps build the bot, connect its sources and keep its answers current as the work changes.
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
- Find recurring questions in project email, chat and meeting transcripts, then connect the answers to current plans and decisions.
- Build a source-linked FAQ bot, test it with different project participants' questions and set up a practical update process.
What to have ready
- A project name, link or rough description; the AI investigates the records and tools you can access.
- A useful export or a few representative records if direct connections are unavailable.
Where you come in
- Choose who should use the bot and agree which sources each audience may see.
- Resolve disputed project facts, try the bot and review the proposed sharing and update setup.
What you'll get
A usable project FAQ bot with checked answers, source links and an update process, or a clearly identified source-pack-and-prompt version when a persistent bot cannot be created.
You're done when
Project participants can ask the bot useful questions, follow its sources and see current answers after a tested update. If the available tools permit only a source pack and reusable prompt, that working version and its remaining sharing or refresh steps are clearly identified.
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. Help me give a big project an FAQ bot: a usable place where its participants can ask questions and receive current, source-linked answers. Investigate the project, build the chosen experience and test both answers and updates. Keep my contribution focused on access that requires me, consequential choices and corrections. ### Find the project, its people and their questions Start with the project name, link or rough description I supplied. Inspect available connections with actual reads. Search project plans, schedules, issue trackers, decision records, relevant email and chat—including WhatsApp where accessible—and meeting transcripts. Follow names, workstreams and dates found there. Use calendars and attendee lists to identify the people involved and the occasions on which questions arise. Look for repeated questions, inconsistent answers, newly changed plans, unresolved requests and terminology that different groups use differently. Establish the intended audiences from actual roles, correspondence and expressed concerns: for example, the delivery team may need acceptance criteria while a sponsor needs the next decision and its consequences. These are examples, not assumed audiences. Distinguish documented needs from your proposed test questions. Inspect the accounts, folders and tools you can actually access before asking me to prepare a packet. If access fails, investigate a permitted connection or export and request the smallest specific action needed. A few representative records can support a first version; keep missing sources and date coverage explicit. Do not claim a whole-project answer from an isolated document. ### Build a reliable source base Collect the current authoritative material alongside the history needed to explain it. Record source title, location, owner if known, dates, relevant passages and what question each source can answer. Distinguish proposals, final decisions, reported decisions and open issues. Follow amendments back to the thing they change; a later file timestamp alone does not prove a later decision. For a large project, divide source review into bounded workstreams or periods. Give each researcher the actual records, scope, required question-and-answer evidence and coverage report. Use successive waves if needed. Reconcile conflicting findings centrally before constructing answers. Without subagents, use manageable passes or fresh-session handoffs and state which review shares context. Create a small initial question set from real requests. For each question prepare the supported current answer, source references, relevant history and any uncertainty. Ask me one focused question when an unresolved conflict changes the answer, waiting before treating it as settled. Continue building unrelated answers. A missing answer should lead to an explicit gap and an appropriate project role to consult, not an invented policy. ### Choose where people will use it Inspect the project's existing collaboration, document and AI tools and available creation permissions. Research current official documentation for plausible routes in this environment: an existing internal assistant, a document-grounded chat experience, or a small project web application. Show the few routes that actually fit through a concrete interaction—where someone asks, what they receive, how they check the source and how a correction gets incorporated. Compare source connections, user access, citations, updates, the effort to maintain it and where it can be shared. Let me choose a practical first version if the existing context does not already establish one. Do not turn a small project bot into a platform project. Establish who owns source corrections and how the bot is kept current. Use the intended participant's access as the boundary for sources and answers. A manager's access does not make all the underlying material shareable with the whole project. If the platform cannot enforce different audiences' access, propose separate permitted source collections or one common-access version rather than relying on a prompt to hide retrievable secrets. ### Build the actual bot and its update process Create the selected experience using tools you can operate. Load or connect the permitted source base, preserve retrievable source references and dates, and write its answering instructions. It should identify the current position, cite the supporting passage or record, show relevant supersession when useful and state when it cannot establish an answer. Questions that depend on missing records should return a useful clarification rather than false certainty. Make it easy to suggest a correction or flag an unhelpful answer. Store unresolved questions where the owner can address them; do not send colleagues messages without authorization. Build the supported update route: refresh connected sources, ingest approved new records on a schedule, or provide a clear manual refresh if that is all the platform supports. Track the last successful refresh and failures, preserving the prior usable version if an update breaks. If building requires a user-only setup action, prepare the exact settings or files, explain that action and resume after its result. If a persistent bot is unavailable, create a curated source pack and a complete reusable question-answering prompt in a supported tool. Explain that this version needs the sources and conversation reopened or refreshed; do not label it an always-current shared bot. ### Test the questions, sharing and a changed decision Have a fresh tester, where available, use the actual bot with ordinary project questions, different participants' questions, an ambiguous request, a missing fact and a question whose answer changed. Give the tester the intended role and necessary sources, without coaching it toward the bot's answer. Check that citations support the actual response and that superseded material does not silently win. Test sharing from an intended user's account or ask for the specific account check only that person can perform. Check that a participant cannot retrieve material outside their permitted source collection. If access cannot be tested, keep that acceptance item open. In a separate test collection, add a new decision that amends an earlier one, run the update process and ask the question again. Verify that the current answer changes while history stays available. Test a correction and a failed or missing source. Do not inject fictional decisions into the real project record. Repair substantive problems and repeat the affected tests. If independent review is unavailable, perform a separate pass and disclose its limit. ### Deliver a usable project resource Give me the actual bot or supported source-pack-and-prompt version, its sharing location, covered sources and dates, a few useful example questions, and the correction and update controls. Record which sharing and refresh checks passed and any outstanding activation or access step. Ask me to try a real question, incorporate the feedback and finish with the resource people can use. A static FAQ or a deployment plan alone is not a completed bot. 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
Give a big project an FAQ bot.
What the AI will do
- Find recurring questions in project email, chat and meeting transcripts, then connect the answers to current plans and decisions.
- Build a source-linked FAQ bot, test it with different project participants' questions and set up a practical update process.
What you can provide
- A project name, link or rough description; the AI investigates the records and tools you can access.
- A useful export or a few representative records if direct connections are unavailable.
Where you'll take part
- Choose who should use the bot and agree which sources each audience may see.
- Resolve disputed project facts, try the bot and review the proposed sharing and update setup.
What you'll get
A usable project FAQ bot with checked answers, source links and an update process, or a clearly identified source-pack-and-prompt version when a persistent bot cannot be created.
Activity context
A big project generates the same questions in a dozen places. Which deadline is real? Why did we drop that feature? Who can approve a change? Give the project a place people can ask—and get an answer grounded in what the team actually decided. The AI helps build the bot, connect its sources and keep its answers current as the work changes.
For the user
Start with the project name or whatever material you have. The AI finds the recurring questions and source records, helps choose a home for the bot, then builds and tests it. You supply the judgments the documents cannot settle and try asking questions as a project participant would.
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
Help me give a big project an FAQ bot: a usable place where its participants can ask questions and receive current, source-linked answers. Investigate the project, build the chosen experience and test both answers and updates. Keep my contribution focused on access that requires me, consequential choices and corrections.
Find the project, its people and their questions
Start with the project name, link or rough description I supplied. Inspect available connections with actual reads. Search project plans, schedules, issue trackers, decision records, relevant email and chat—including WhatsApp where accessible—and meeting transcripts. Follow names, workstreams and dates found there. Use calendars and attendee lists to identify the people involved and the occasions on which questions arise.
Look for repeated questions, inconsistent answers, newly changed plans, unresolved requests and terminology that different groups use differently. Establish the intended audiences from actual roles, correspondence and expressed concerns: for example, the delivery team may need acceptance criteria while a sponsor needs the next decision and its consequences. These are examples, not assumed audiences. Distinguish documented needs from your proposed test questions.
Inspect the accounts, folders and tools you can actually access before asking me to prepare a packet. If access fails, investigate a permitted connection or export and request the smallest specific action needed. A few representative records can support a first version; keep missing sources and date coverage explicit. Do not claim a whole-project answer from an isolated document.
Build a reliable source base
Collect the current authoritative material alongside the history needed to explain it. Record source title, location, owner if known, dates, relevant passages and what question each source can answer. Distinguish proposals, final decisions, reported decisions and open issues. Follow amendments back to the thing they change; a later file timestamp alone does not prove a later decision.
For a large project, divide source review into bounded workstreams or periods. Give each researcher the actual records, scope, required question-and-answer evidence and coverage report. Use successive waves if needed. Reconcile conflicting findings centrally before constructing answers. Without subagents, use manageable passes or fresh-session handoffs and state which review shares context.
Create a small initial question set from real requests. For each question prepare the supported current answer, source references, relevant history and any uncertainty. Ask me one focused question when an unresolved conflict changes the answer, waiting before treating it as settled. Continue building unrelated answers. A missing answer should lead to an explicit gap and an appropriate project role to consult, not an invented policy.
Choose where people will use it
Inspect the project's existing collaboration, document and AI tools and available creation permissions. Research current official documentation for plausible routes in this environment: an existing internal assistant, a document-grounded chat experience, or a small project web application. Show the few routes that actually fit through a concrete interaction—where someone asks, what they receive, how they check the source and how a correction gets incorporated.
Compare source connections, user access, citations, updates, the effort to maintain it and where it can be shared. Let me choose a practical first version if the existing context does not already establish one. Do not turn a small project bot into a platform project. Establish who owns source corrections and how the bot is kept current.
Use the intended participant's access as the boundary for sources and answers. A manager's access does not make all the underlying material shareable with the whole project. If the platform cannot enforce different audiences' access, propose separate permitted source collections or one common-access version rather than relying on a prompt to hide retrievable secrets.
Build the actual bot and its update process
Create the selected experience using tools you can operate. Load or connect the permitted source base, preserve retrievable source references and dates, and write its answering instructions. It should identify the current position, cite the supporting passage or record, show relevant supersession when useful and state when it cannot establish an answer. Questions that depend on missing records should return a useful clarification rather than false certainty.
Make it easy to suggest a correction or flag an unhelpful answer. Store unresolved questions where the owner can address them; do not send colleagues messages without authorization. Build the supported update route: refresh connected sources, ingest approved new records on a schedule, or provide a clear manual refresh if that is all the platform supports. Track the last successful refresh and failures, preserving the prior usable version if an update breaks.
If building requires a user-only setup action, prepare the exact settings or files, explain that action and resume after its result. If a persistent bot is unavailable, create a curated source pack and a complete reusable question-answering prompt in a supported tool. Explain that this version needs the sources and conversation reopened or refreshed; do not label it an always-current shared bot.
Test the questions, sharing and a changed decision
Have a fresh tester, where available, use the actual bot with ordinary project questions, different participants' questions, an ambiguous request, a missing fact and a question whose answer changed. Give the tester the intended role and necessary sources, without coaching it toward the bot's answer. Check that citations support the actual response and that superseded material does not silently win.
Test sharing from an intended user's account or ask for the specific account check only that person can perform. Check that a participant cannot retrieve material outside their permitted source collection. If access cannot be tested, keep that acceptance item open.
In a separate test collection, add a new decision that amends an earlier one, run the update process and ask the question again. Verify that the current answer changes while history stays available. Test a correction and a failed or missing source. Do not inject fictional decisions into the real project record. Repair substantive problems and repeat the affected tests. If independent review is unavailable, perform a separate pass and disclose its limit.
Deliver a usable project resource
Give me the actual bot or supported source-pack-and-prompt version, its sharing location, covered sources and dates, a few useful example questions, and the correction and update controls. Record which sharing and refresh checks passed and any outstanding activation or access step. Ask me to try a real question, incorporate the feedback and finish with the resource people can use. A static FAQ or a deployment plan alone is not a completed bot.
Done when
Project participants can ask the bot useful questions, follow its sources and see current answers after a tested update. If the available tools permit only a source pack and reusable prompt, that working version and its remaining sharing or refresh steps are clearly identified.
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.