Plugins

Agentic Collections publishes three families of plugins: core for what holds regardless of role and stack, disciplines for how we work, and stacks for what we work with. The families exist so they can install differently: a discipline plugin travels with you, a stack plugin with the repo, and tsh-core with you, because it depends on nothing at all.

Every skill and agent is namespaced by its plugin. Invoke a skill as /<plugin>:<skill> and mention an agent as @<plugin>:<agent>. The install commands live on the installation page, which renders the repository README.

Core — the ground under both

Install it at User scope, the same as your discipline plugin. It depends on neither your role nor the repo, so it should follow you everywhere.

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.

tsh-core is one plugin, not a family. Anything that would change if you switched job belongs in a discipline plugin, and anything that would change if the repo switched language belongs in a stack plugin. Its admission bar is the highest in the repo, because everyone installs it and every skill in it spends every teammate's context.

Other plugins may assume it is installed and refer to it by name. It bundles the Atlassian, Figma and Context7 MCP servers, which the discipline plugins use instead of shipping their own copies.

Disciplines — how we work

Install the one that matches your job, at User scope. Your job doesn't change from repo to repo.

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.

When work spans two disciplines, it lives in the plugin that owns the outcome, not the one that owns the tooling: an accessibility audit belongs to tsh-product-testing even though it reads component code.

Stacks — what we work with

Install what the project is built on, at Project scope. The repo already knows what it is written in, so everyone working on it should get the same guidance, and nobody should carry another stack's skills around.

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.

A stack here 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. The frontend, Node and serverless plugins all carry TypeScript guidance, because a browser app, a Node service and a Lambda bundle need different compiler configuration. Every stack gets its own plugin, named tsh-stack-<stack-name>, once it has real content to ship.

Scopes

Each install asks you to pick a scope.

Scope	Who gets it	Where it's written
User	You, in every project	Your user settings
Project	Everyone working on this repo	The repo's .claude/settings.json, which is committed, so it travels with the repo
Local	You, in this repo only	.claude/settings.local.json, which you keep out of git

• Scope is resolved against your current directory. Run project and local installs from the target repo's root.
• Scopes stack. A committed project set is a starting point: anyone can add their own plugins on top at user or local scope, and both sets load together.
• Installing never copies plugin files into your project. Everything lives in ~/.claude/plugins/marketplaces/, whatever the scope. Scope decides which projects load a plugin, not where it is stored.

Installing at project scope writes the repo's .claude/settings.json for you; commit that file and the whole team gets the set. The README section Onboarding a whole project team at once shows the file and why tsh-core is deliberately left out of it.