Create shared AI tools repo.
One useful AI tool can help many colleagues. Sharing can start with a helpful prompt or skill and grow to include code, applications and configuration instructions that direct an AI tool toward company-specific information.
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
- Investigate existing collections, tools, policies and owners.
- Compare suitable approaches and produce the proposal, starter materials and pilot workflow.
What to have ready
- Your intended colleagues and any context the AI cannot find.
Where you come in
- Choose an approach, work with IT and help review the pilot.
What you'll get
A concrete shared-library proposal and starter package, or a working pilot when access and approvals permit.
You're done when
You have a reviewed approach and ready-to-use starter materials; where IT approval and access are available, a shared collection has passed a small contribution-and-use pilot.
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. ### Find what already exists I'm interested in creating a shared AI tools repo for my colleagues. Help me figure it out. By repo I mean an organized shared collection: useful prompts, skills, code, applications, and configuration additions that direct an AI tool toward company-specific context. Inspect what company sources you can actually access. Search the intranet, shared drives, Teams or Slack channels, relevant emails, IT guidance, developer documentation and existing source repositories for AI tool libraries, prompt collections, skills, approved integrations and related initiatives. Search broadly across these available sources, using focused queries and bounded reads rather than claiming to inspect everything. Keep a coverage record, identify owners, and distinguish current guidance from old discussions. Find existing policies on sharing, review, data access and running code. If access is missing, investigate connection or export options before asking me to gather material. Do not assume absence from your search means no collection exists. ### Propose a useful shared home Establish who will use and contribute to the collection, what kinds of material they need, how technical they are, and who in IT should help. Find evidence in the records first, then ask focused questions. Consider extending an existing service before proposing a new one. Research current official documentation for two or three approaches that fit the company. Possibilities include a private GitHub organization repository with invited members and reviewed changes, an existing internal knowledge library with links to maintained code, or tools already operated in the company's Microsoft/Azure, AWS or Google Cloud environment. These cloud names are contexts to investigate, not interchangeable ready-made tool libraries. Check the actual product, access controls, review workflow, search, version history, ease of contribution, cost and ownership. Link current sources and say when checked. [GitHub repository roles and visibility](https://docs.github.com/en/enterprise-cloud%40latest/repositories/creating-and-managing-repositories/about-repositories) and [code-owner reviews](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) are starting references, not a required solution. Show the practical tradeoffs and recommend an approach. Wait for my choice and identify which decisions need the actual IT or policy owner. Prepare concise questions and a proposal they can review; do not treat our discussion as their approval. ### Make the proposal concrete Design a small initial collection with clear places for prompts, skills, configuration guidance and runnable tools. Make an entry template with purpose, intended user, owner, files or links, setup and use instructions, an example, required access, review status and last-checked date. Keep supporting files together. Configuration instructions should explain their scope and how to apply or reverse them; never imply that sharing a file grants access to company information. Define who can submit, who can approve, what review is required for each kind of contribution, and how duplicates, updates and retirement are handled. Include safety and policy review appropriate to the material, especially executable code and configurations that change access or behavior. Keep drafts distinguishable from approved tools, and identify who maintains a contribution after the initial enthusiasm fades. Make this usable for nontechnical colleagues too. Prepare the actual starter documents, contribution instructions and review checklist in a reviewable form. Use a few existing permitted examples if accessible; do not fabricate tested tools or publish someone's work without the required authorization. Show how one contribution moves from submission through review to discovery and use. ### Pilot and finish With the necessary organizational approval, help implement the chosen space and run a small pilot: one contributor submits something, a reviewer processes it, and a colleague finds and uses the approved item. Correct the friction and verify permissions and version selection through that actual flow. I can give you the human observations where you cannot inspect them directly. If IT or another owner must act first, deliver the complete decision-ready proposal and starter package, identifying their exact remaining action. Once access and approval arrive, continue the setup and pilot. Distinguish a working shared collection from a proposal awaiting implementation. Do not create a public repository or invite people merely to demonstrate the plan. 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
Create shared AI tools repo.
One useful AI tool can help many colleagues. Sharing can start with a helpful prompt or skill and grow to include code, applications and configuration instructions that direct an AI tool toward company-specific information.
A shared collection can save people from solving the same problem repeatedly and help good ideas travel across the company. It is worth the effort to make it work well.
This is more than creating a folder. You need to decide who can contribute, who reviews submissions for safety, policy and redundancy, and how people find the right version. You will almost certainly need your IT team to help decide where and how to store these tools. Start with what your company already has.
For the user
Give the AI this prompt. It will investigate existing resources and policies, propose suitable ways to share tools, and help you develop a concrete proposal with IT.
Done when
You have a reviewed approach and ready-to-use starter materials; where IT approval and access are available, a shared collection has passed a small contribution-and-use pilot.
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
Find what already exists
I'm interested in creating a shared AI tools repo for my colleagues. Help me figure it out. By repo I mean an organized shared collection: useful prompts, skills, code, applications, and configuration additions that direct an AI tool toward company-specific context.
Inspect what company sources you can actually access. Search the intranet, shared drives, Teams or Slack channels, relevant emails, IT guidance, developer documentation and existing source repositories for AI tool libraries, prompt collections, skills, approved integrations and related initiatives. Search broadly across these available sources, using focused queries and bounded reads rather than claiming to inspect everything. Keep a coverage record, identify owners, and distinguish current guidance from old discussions. Find existing policies on sharing, review, data access and running code. If access is missing, investigate connection or export options before asking me to gather material. Do not assume absence from your search means no collection exists.
Propose a useful shared home
Establish who will use and contribute to the collection, what kinds of material they need, how technical they are, and who in IT should help. Find evidence in the records first, then ask focused questions. Consider extending an existing service before proposing a new one.
Research current official documentation for two or three approaches that fit the company. Possibilities include a private GitHub organization repository with invited members and reviewed changes, an existing internal knowledge library with links to maintained code, or tools already operated in the company's Microsoft/Azure, AWS or Google Cloud environment. These cloud names are contexts to investigate, not interchangeable ready-made tool libraries. Check the actual product, access controls, review workflow, search, version history, ease of contribution, cost and ownership. Link current sources and say when checked. GitHub repository roles and visibility and code-owner reviews are starting references, not a required solution.
Show the practical tradeoffs and recommend an approach. Wait for my choice and identify which decisions need the actual IT or policy owner. Prepare concise questions and a proposal they can review; do not treat our discussion as their approval.
Make the proposal concrete
Design a small initial collection with clear places for prompts, skills, configuration guidance and runnable tools. Make an entry template with purpose, intended user, owner, files or links, setup and use instructions, an example, required access, review status and last-checked date. Keep supporting files together. Configuration instructions should explain their scope and how to apply or reverse them; never imply that sharing a file grants access to company information.
Define who can submit, who can approve, what review is required for each kind of contribution, and how duplicates, updates and retirement are handled. Include safety and policy review appropriate to the material, especially executable code and configurations that change access or behavior. Keep drafts distinguishable from approved tools, and identify who maintains a contribution after the initial enthusiasm fades. Make this usable for nontechnical colleagues too.
Prepare the actual starter documents, contribution instructions and review checklist in a reviewable form. Use a few existing permitted examples if accessible; do not fabricate tested tools or publish someone's work without the required authorization. Show how one contribution moves from submission through review to discovery and use.
Pilot and finish
With the necessary organizational approval, help implement the chosen space and run a small pilot: one contributor submits something, a reviewer processes it, and a colleague finds and uses the approved item. Correct the friction and verify permissions and version selection through that actual flow. I can give you the human observations where you cannot inspect them directly.
If IT or another owner must act first, deliver the complete decision-ready proposal and starter package, identifying their exact remaining action. Once access and approval arrive, continue the setup and pilot. Distinguish a working shared collection from a proposal awaiting implementation. Do not create a public repository or invite people merely to demonstrate the plan.
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.