# Team skills Source: https://www.hyperagent.com/docs/concepts/teams/team-skills > For AI agents: the documentation index is at https://www.hyperagent.com/llms.txt and the complete documentation in one file at https://www.hyperagent.com/llms-full.txt. Any docs page is also served as Markdown by appending `.md` to its URL. Share reusable methods with a Team, choose which account runs them, and decide when to use the shared source or fork it. A skill gives an agent a reusable method. Team skills let many people and agents follow the same one without keeping a copy each. Improve the shared skill and every agent using it improves with it. Nobody redistributes anything, and nobody is quietly running last quarter's version. Four choices shape how a Team skill works: Decide whether Owners and Editors maintain it together or one personal owner keeps the source. Make it discoverable across the workspace or link it only to named agents. Run actions through the sharer's account or require each member to connect their own. Follow the maintained method or create an independent variation. ## Choose who maintains it [#choose-who-maintains-it] A skill can be **Team-owned** or **shared from a personal owner**. **Owners and Editors maintain it together.** Every Team member can use the shared method. Choose this for an operating practice the Team owns, such as the escalation procedure Scout uses to classify urgent support requests. **One person maintains the source.** The Team uses that skill by reference. Choose this when one person should remain accountable for the method while several teammates or agents use it. A shared personal skill stays connected to the original rather than becoming a frozen copy. When its owner clarifies how Scribe should format troubleshooting steps, every agent using it gets the new version immediately. Delete the personal skill and the Team keeps no snapshot. Use a shared skill when that dependency is intentional; use Team ownership when it isn't. ## Choose which agents can use it [#choose-which-agents-can-use-it] Owning a skill and exposing it are separate decisions. On the skill's **Agents & Discoverability** section, two controls decide who can pick it up. Any agent or thread in the workspace can find and use the skill without anyone attaching it first. It joins the pool every agent searches. Link specific agents and only they get the skill, regardless of what the rest of the workspace can discover. Leave a general method discoverable so agents pick it up when the work calls for it. Restrict a skill to named agents when it's specialized enough that another agent reaching for it would be a mistake, or when it carries credentials only certain agents should act through. ## Choose whose account performs actions [#choose-whose-account-performs-actions] Sharing a method doesn't decide whose account performs its actions. When a skill carries credentials, sharing offers two choices: Runs use the account connected by the person who shared the skill, and members do nothing. Use this for an approved shared account with one accountable maintainer; the connected service sees that account, its access, and its limits. If the sharer's credentials go missing, a member's next run posts a **Credentials missing** card in the chat rather than a dead end: they can add their own credentials to run it themselves, or ask the owner to restore the setup. Each runner connects their own account, so actions carry the runner's identity and access. **Open the shared skill.** It shows who shared it and the amber status **Needs your credentials to run**. **Select Add credentials.** The member enters their own keys, which stay encrypted and are never visible to the person who shared the skill. **Run as yourself.** The status changes to **Using your credentials**, and every action carries that member's identity and access. If a member runs it before connecting, nothing fails silently. The run stops and posts a card in the chat: A member can also choose their own credentials on a **Use my credentials** skill: opening it offers **Use my own credentials instead**, and their account takes over for their runs from then on. ## Use the shared source or fork [#use-the-shared-source-or-fork] Source improvements remain current for everyone using the skill. The new personal copy can change without affecting the shared source, and later source updates do not flow into it. Most teammates should follow the team's documentation style skill so Scribe holds the standard. A technical writer who needs a different structure for API references forks it and gets an editable variation without touching the team's version. The tradeoff is maintenance. A fork can diverge freely, but its owner now owns it, and later improvements to the shared source never reach it. Fork when divergence is the point, not to make one small edit. ## FAQs [#faqs] The team loses it. A shared skill is used by reference rather than copied, so there's no frozen snapshot left behind. When the team shouldn't depend on you keeping it alive, make it team-owned. Whichever mode was chosen when it was shared. **Use my credentials** runs everything on the sharer's account, so the connected service sees one identity. **Each member adds their own** makes each runner connect first, so actions carry their own identity and access. If the skill is set to **Each member adds their own**, they need to connect their own account before the credentialed part will run. The method is shared with them either way; only the external action is blocked. Edit the shared one when the change is an improvement everyone wants. Fork when you genuinely need a variation, and accept that you now maintain it: later improvements to the shared source won't reach your copy. No. A writing standard, a checklist, or a decision framework has no external account to act through, so it just runs.