Introduction
Agentic Collections is a Claude Code plugin marketplace from The Software House. It carries custom agents and skills you can install into any project.
The plugins are not an application: there is no build step and no runtime. They are mostly Markdown and JSON that Claude Code loads, plus the few hook and helper scripts some skills run. Every skill and agent is namespaced by its plugin, so you invoke a skill as /<plugin>:<skill> and mention an agent as @<plugin>:<agent>.
Three families
The marketplace publishes three families of plugins, and each one installs at a different scope.
| Family | What it carries | Install at |
|---|---|---|
Core (tsh-core) | The ground under both: one small plugin of tool mechanics that depend on neither your role nor the repo | User scope. It follows you everywhere |
Disciplines (tsh-<discipline>) | How we work: one plugin per discipline | User scope. Your job doesn't change from repo to repo |
Stacks (tsh-stack-<stack-name>) | What we work with: one plugin per technology stack | Project scope. The repo already knows what it is written in |
The Plugins page explains the scopes in more detail and links every plugin to its own page.
Verticals
The discipline plugins and the context tooling cover five verticals. Each one links to the work it does today on the Use cases page.
| Vertical | What it covers | Plugin |
|---|---|---|
| Product Management | Discovery workshop material — transcripts, Figma, PDFs, codebase context — turned into Jira-ready epics and user stories, a per-product domain dictionary and an outcome-based delivery roadmap, behind five human review gates | tsh-product-management |
| Product Engineering | Committed plan files, delegated implementer subagents, a Figma-backed UI verification gate driven by Playwright CLI capture, root-cause bug fixing guarded by a regression test, and structured pre-merge code review | tsh-product-engineering |
| Product Testing | Playwright end-to-end tests proven stable by repeated headless runs, and WCAG 2.1 AA accessibility audits that report the success criterion behind every finding | tsh-product-testing |
| Platform Engineering | Terraform modules, pipelines with OIDC and plan gates, Kubernetes workloads, observability with SLOs, secrets management and cloud cost audits — validated, not applied: devops-engineer runs a mutating command only on an explicit instruction naming that command | tsh-platform-engineering |
| Context management | The context files Claude Code loads in each repository — CLAUDE.md, path-scoped rules, decision records — and a project's shared knowledge base | tsh-core and the project-context skills in tsh-product-management |
Stacks
Stack plugins carry what would change if the repo switched language, framework or cloud. A stack is a runtime target or a cloud provider, not a language: a repository has exactly one cloud provider but may have more than one runtime target, such as a frontend, a Node service and a Lambda bundle in one repo. Install the ones the repo is built on. See Stacks for what they add to the work above.
tsh-core, the foundation
tsh-core holds what stays true regardless of discipline and stack: Git worktree lifecycle, the house standard for writing technical documents, authoring Claude Code extensions, the project-context files Claude Code loads, the decision-record format, and a one-command project setup. It also bundles three MCP servers: Atlassian for Jira and Confluence, Figma for design context, and Context7 for library documentation. Other plugins rely on those servers instead of shipping their own copies, so install tsh-core alongside whatever else you pick.
What's in the marketplace
Core
| Plugin | Version | Skills | Agents | Covers |
|---|---|---|---|---|
| tsh-core | 0.11.0 | 6 | 0 | What every TSH teammate needs regardless of discipline or stack: safe Git worktree lifecycle management, the house standard for writing technical documents, authoring Claude Code extensions, the project-context files Claude Code loads, the decision-record format and lifecycle, a one-command project setup that wires them all together, and three bundled MCP servers: Atlassian for Jira and Confluence, Figma for design context, and Context7 for library documentation. |
Disciplines
| Plugin | Version | Skills | Agents | Covers |
|---|---|---|---|---|
| tsh-product-engineering | 0.10.1 | 8 | 6 | Spec-driven feature implementation: committed plan files, delegated implementer subagents, a Figma-backed UI verification gate driven by Playwright-CLI capture, root-cause bug fixing guarded by a regression test, and TSH's structured pre-merge code review. |
| tsh-product-testing | 0.3.2 | 2 | 1 | Quality assurance: Playwright end-to-end tests proven stable by repeated headless runs, and WCAG 2.1 AA accessibility audits that report the success criterion behind every finding. |
| tsh-product-management | 0.5.1 | 16 | 7 | The business-analysis workflow end to end: discovery workshop materials — transcripts, Figma, PDFs, codebase context — become Jira-ready epics and user stories, a per-product domain dictionary and an outcome-based delivery roadmap, behind five human review gates, with a hook that, while a business-analysis session is open in the repository, refuses Jira writes to a project until the push gate is approved for that project. Also imports an existing Jira backlog for local iteration, and sets up a project's knowledge base — a `<project>-context` repository every code repository and role reads with cited sources and changes only through a branch and a pull request, with a second hook that guards its pointer in CLAUDE.md. Seven read-only worker subagents keep the heavy reading out of the conversation. |
| tsh-platform-engineering | 0.2.3 | 7 | 2 | Infrastructure, CI/CD and deployment the TSH way: Terraform modules, pipelines with OIDC and plan gates, production-shaped Kubernetes workloads, observability with SLOs, secrets management, and evidence-based cloud cost audits. |
Stacks
| Plugin | Version | Skills | Agents | Covers |
|---|---|---|---|---|
| tsh-stack-frontend | 0.3.0 | 3 | 0 | TSH conventions for browser-targeted frontend code: TypeScript compiler configuration for bundler-resolved applications, implementation conventions for any change to frontend code — React imports, components and hooks, module boundaries, and a Figma-first workflow when a design exists — and WCAG 2.1 AA accessibility implementation. |
| tsh-stack-nodejs | 0.2.0 | 3 | 0 | TSH conventions for TypeScript on Node.js: compiler configuration for a Node runtime, and NestJS API implementation and review. |
| tsh-stack-aws | 0.1.1 | 2 | 0 | AWS-specific infrastructure guidance: Terraform module patterns for VPC, EKS, RDS and S3, Well-Architected defaults, and a full evidence-based AWS cost and tagging audit that reads infrastructure code then validates it against the live account. |
| tsh-stack-azure | 0.1.2 | 2 | 0 | Azure-specific infrastructure guidance: Terraform module patterns for VNet, AKS, Flexible Server, Blob Storage, Application Gateway and Key Vault, Managed Identity and private-endpoint defaults, and a full evidence-based Azure cost and tagging audit driven by Resource Graph and Cost Management. |
| tsh-stack-gcp | 0.1.2 | 2 | 0 | GCP-specific infrastructure guidance: Terraform module patterns for VPC, GKE, Cloud SQL, Cloud Storage and Cloud Run, Workload Identity and CMEK defaults, and a full evidence-based GCP cost and labelling audit that reads infrastructure code then validates it against the live project. |
| tsh-stack-python | 0.1.0 | 2 | 0 | TSH conventions for modern Python 3.12+: general implementation and review practices, and Pydantic v2/dataclass/SQLModel/SQLAlchemy 2.0 data modeling. |
| tsh-stack-php | 0.1.0 | 2 | 1 | TSH conventions for PHP 7.4–8.5 and Symfony 5.4–8.x: version-aware design and implementation (YAGNI and KISS first, justified patterns, refactoring, PSR-12), Symfony framework features with their version differences, and a PHP code reviewer agent. |
| tsh-stack-serverless | 0.1.1 | 3 | 0 | TSH practices for AWS Lambda services on OSLS: which libraries we use and which we avoid, how a serverless project is structured, TypeScript and bundler configuration for a Lambda runtime, handler implementation with middleware, event validation and structured logging, and the service definition itself — least-privilege IAM, reserved concurrency, secrets resolved at runtime, Step Functions task rules, and checks over the packaged CloudFormation template. No bootstrap and no example project: the practices are what make a service come out TSH-shaped. |
Where to start by task
| You want to | Start with |
|---|---|
| Turn workshop material into Jira-ready epics and stories | /tsh-product-management:analyze-materials |
| Understand workshop material before committing to any backlog item | /tsh-product-management:explore-materials |
| Implement a feature, ticket or plan end to end | /tsh-product-engineering:orchestrating-feature-implementation |
| Fix a bug whose cause is not yet known | /tsh-product-engineering:debugging-code |
| Judge whether a change is ready to merge | /tsh-product-engineering:reviewing-code |
| Check whether a page matches its Figma design | /tsh-product-engineering:reviewing-ui |
| Write or de-flake Playwright end-to-end tests | @tsh-product-testing:e2e-engineer |
| Audit infrastructure for security, cost and practice gaps | @tsh-platform-engineering:infrastructure-auditor |
| Set up Claude Code's context in a repository | /tsh-core:init |
Most skills are model-invocable: describe the work in plain words, such as "implement this ticket" or "is this ready to merge", and Claude loads the matching skill. A few entry points, such as /tsh-core:init and /tsh-product-management:analyze-materials, run only when you type them.
How to start
- Check the prerequisites. Agentic Collections requires Claude Code v2.1 or newer.
- Install: add the marketplace once, then install the plugins you want.
- Connect your tools: sign in to Atlassian and Figma once per machine with
/mcp. - Take your first steps with the skills and agents you installed.
Where to go next
- Workflows — how the skills and agents work together on a real task.
- Plugins — every plugin, skill and agent, with its own page.
- Integrations — the MCP servers and the Playwright CLI the plugins use.
- Use cases — what each vertical does today.
- For CTOs — the case for adopting it across a team.