AWS Quick guide: treat shared agent skills like code

Amazon Web Services published a guide on 9 November 2026 to building and sharing "skills" in AWS Quick, its agent workspace, and its main warning is that a skill that works for its author may fail for the colleagues it is shared with. The post, by AWS's Jed Lechner, is vendor-published guidance, not a customer deployment, so it reports no results from any company.

What a skill is in Quick

AWS says a skill is a folder with a SKILL.md Markdown file at its root, plus optional scripts and reference files, and that Quick skills follow the Agent Skills specification that Anthropic originally released as an open standard. The file's name and description decide when a skill triggers. The agent reads only those two fields until a request calls for the skill, then loads the full instructions.

The post gives the specification's limits: a name of up to 64 characters, a description of up to 1,024 characters, and instructions it recommends keeping under 5,000 tokens. AWS says much of Quick's default behaviour, such as producing Word, PowerPoint, Excel and PDF files, comes from built-in system skills that you can turn on or off but not edit, share or delete.

Publishing is not sharing

According to AWS, you can create a skill from a chat, from a .md or .zip file, or from a folder. Publish and Share are separate steps, so publishing alone gives nobody else access. People you share with add the skill under Shared with me, and their copy stays in sync each time you publish again.

The practices AWS recommends

• Document prerequisites. If you share a skill, say which sources and connectors it needs, because recipients get answers only from sources they can already reach.
• Plan for failure. AWS's example adds a check and a fallback to a step: after "Send the report to the recipient over email", verify the report is in the Sent folder, and if not, stop and tell the user. It calls this more important when agents run on a schedule with no human watching.
• Test every change. Write test cases for several scenarios, add more as the skill changes, and run them in the environment your users will use.
• Keep changing values such as file paths or a Slack channel name out of the steps and declare them as inputs.
• Record release notes, dated changes, where each reference file came from, and a checksum of the skill's files, and check the structure after every change, the way a linter does.

Shared agents run with the user's access

The post says a custom agent can be limited to chosen spaces, connectors and skills, and that by default an agent can use all of your skills until you pick specific ones. AWS warns that a shared agent runs with the access of the person using it, so the same request can reach different data for each person and return incomplete answers when a source is visible only to the author.

AWS also points to an official catalog of pre-built skills, which it says is tested and scanned for quality and security before publication, and to a Skill Architect skill that applies these practices. The post does not say how the scanning works or what it checks.

What the post leaves out

It gives no usage figures, no cost for running skills, and no example of a skill failing in production. It does not describe an approval step before a skill is shared to a group, or how a team would audit what a shared skill did. Those are the questions an operations lead would want answered before letting staff publish skills to colleagues. AWS's advice amounts to treating skills as code, but it does not say who reviews them.