How to Build a Custom Agent Stack for Your Team

A skill stack is a curated set of Agent Skills installed together so Claude has structured approaches to the recurring tasks your team actually does. Instead of describing what you want from scratch every time — or getting different output depending on who wrote the prompt — you install skills once and trigger them by context. The format is consistent. The process is consistent. The quality floor rises across the team, not just for the person who happens to write the best prompts.

Building a stack that works requires a different approach than building a collection. A collection is skills installed because they seemed useful. A stack is skills selected because they address specific, recurring tasks where consistent output matters. The difference shows up quickly: a collection gets ignored after two weeks; a stack becomes part of how the team works.

This guide covers how to identify which tasks are worth building around, how to select and evaluate skills, how to install them consistently across a team, and how to maintain the stack as the team’s work changes.

Start with the work, not the skills

Before you look at any skill catalog, list the recurring tasks your team spends the most time on. Not the interesting, high-judgment work — the surrounding layer that takes time without requiring deep expertise to produce, but still needs to be done consistently.

For most teams it’s some combination of:

• Writing the same types of documents repeatedly — status reports, spec reviews, meeting notes, project updates
• Research that follows a predictable pattern — competitive analysis, account research, literature review, vendor evaluation
• Communication that needs consistency — stakeholder updates, client emails, performance feedback, interview debrief notes
• Analysis work with a defined output format — pipeline reviews, data summaries, campaign performance reports

The tasks that take the most time with the least variation are the best candidates for Agent Skills. If you’re doing the same thing every Friday with the same structure every time, that’s a skill candidate. If a task requires substantial judgment that changes based on the specifics of each situation, a skill helps less.

The other good signal is inconsistency across team members. If two people run the same type of analysis and produce outputs in different formats with different sections covered, a skill standardises the output without requiring a style guide that no one reads.

Match tasks to skills

Once you have your list of recurring tasks, check what’s already built. Most recurring professional tasks have a skill on findskills.co. Search by job function or browse by audience:

• Developers → /audiences/developers
• Product managers → /audiences/product
• Marketers → /audiences/marketers
• Finance → /audiences/finance
• HR → /audiences/hr
• Sales → /audiences/sales
• DevOps → /audiences/devops
• Legal → /audiences/legal

Before installing anything, read the raw SKILL.md file linked on each skill’s detail page. The description on the page is a summary. The file is the actual product. Two things to check: does the process described match the actual workflow your team runs? And is the output format something your team would actually use?

If the process is close but not quite right, that’s often worth installing and evaluating on real work before deciding whether to customise. Many teams find that an existing skill handles 80% of their use case and requires only minor adjustment for the remaining 20%.

Or start from a pre-built stack that matches your team’s function — the curated stacks at /stacks are designed for specific roles and already have the obvious skills bundled.

Pick 5–8 skills to start

The most common mistake is installing everything. A stack with 30 skills gives Claude too much surface area — it starts matching on the wrong triggers, the structured behaviour becomes unpredictable, and team members don’t know which skill to reach for when.

Pick 5–8 skills that cover your highest-frequency tasks. Add more after those are working well. A focused stack that the team uses daily beats a comprehensive one that gets ignored.

Concrete selection criteria:

Frequency: Tasks that happen at least weekly. Daily is better. A skill for a task that happens monthly is a lower priority than one for a task that happens three times a week.

Output consistency matters: Tasks where the output format is important for downstream use. Status reports that go to stakeholders. Analysis outputs that get compared across weeks. Documents that need to follow a standard structure so reviewers know where to look.

Time cost is material: Tasks that currently eat 30+ minutes of focused time. Skills have the highest return on tasks where the setup and structure work takes a significant fraction of the total time.

Template dependency: Tasks where someone is currently maintaining a template in their head, in a doc, or in a Notion page that people reference inconsistently. A skill makes the template active rather than passive.

Install consistently across the team

The install command is the same for everyone:

npx skills add {owner}/{repo} --skill {path}

For example, installing the operations status report skill:

npx skills add anthropics/knowledge-work-plugins --skill operations

Each person runs this in their own Claude Code environment. The skill file is stored locally in their .claude/ directory. There’s no shared server or team account — each installation is local and immediate. This means installation needs to be communicated rather than deployed: the easiest approach is a short internal doc with the install commands for your stack, which team members run once when they set up their environment.

For teams using Claude.ai (the web interface) rather than Claude Code, skills can be pasted manually into a Project’s custom instructions. One setup, persistent across every conversation in that project. See the install guide for the step-by-step on both methods.

The onboarding recommendation: Add the stack install commands to your team’s engineering or onboarding docs alongside your other environment setup steps. New team members install the stack as part of getting set up, not as a separate thing they do if they remember.

Evaluate before you expand

After a week of using your initial 5–8 skills, the signal you want is simple: which skills are team members actually triggering? Usage is the right metric, not installation count.

Skills that get used regularly are working. Skills that got installed and haven’t been triggered are one of three things: the task isn’t as frequent as you thought, the skill’s trigger isn’t natural enough for the workflow, or team members don’t know it’s there.

Before adding more skills, make sure the existing ones are embedded. If someone on the team is still writing the same setup prompt manually for a task that has a skill installed, that’s a gap in awareness, not a gap in coverage.

Questions to evaluate after the first few weeks:

• Which skills are being triggered daily or weekly?
• Which outputs are actually being used as-is vs substantially rewritten?
• What recurring tasks are still taking longer than they should because there’s no skill for them?
• Is anyone doing the same setup work repeatedly that a skill could handle?

The answers determine whether you expand, trim, or swap skills in the stack.

Common mistakes to avoid

Installing skills for tasks that aren’t frequent enough. A skill for a task you do once a month provides minimal return. The skills that change daily work are the ones for daily and weekly tasks.

Not reading the skill file before installing. The description is marketing. If you install based on the description and the process doesn’t match your workflow, you’ll get output that looks structured but doesn’t match how your team actually works.

Over-specifying at the start. Some teams want a perfect, fully customised skill set before they start using anything. The faster path is to install what’s available, use it on real work, and customise based on what the output actually looks like rather than what you expected it to look like.

Installing and not communicating. Skills that are installed on one person’s environment and not shared with the team aren’t a team stack — they’re an individual tool. The install command needs to be documented somewhere the team can find it.

Treating the stack as static. The tasks that take the most time change as the team’s work changes. Revisit the stack every quarter: remove skills for tasks that have decreased in frequency, add skills for tasks that have become more frequent.

Start with a pre-built stack

If you’re not sure where to start, pick the closest pre-built stack to your team’s function and install it as-is. Trim it to the skills you actually use after a week of real work.

Pre-built stacks available:

• Developer Stack — code review, architecture, engineering workflow
• Marketing Team Stack — content, SEO, paid ads, analytics
• Sales Stack — account research, call prep, pipeline review
• Product Manager Stack — specs, roadmaps, sprint planning
• DevOps & Platform Stack — CI/CD, observability, incidents
• HR & People Ops Stack — recruiting, onboarding, performance reviews
• Data Science & Analytics Stack — SQL, analysis, dashboards
• Freelancer & Consultant Stack — proposals, contracts, client ops

→ Browse all stacks

---

→ Full install guide