What this repo is, what it deliberately is not, and the principle behind every exclusion.
Most repos define themselves by what they contain. This one is also defined by what it deliberately leaves out — and each exclusion has a reason that ties back to one of the other documents in this directory.
Frontify/skills ships universal agent-workflow skills for product-development tasks — code authoring and documentation production. Each skill is a self-contained discipline that an agent loads when the task matches its description.
| Domain | Shape of skills shipped |
|---|---|
| Code authoring | Workflow skills for implementing features, fixing bugs, refactoring, rewriting, migrating, optimising performance, and improving test coverage. |
| Documentation production | Author-time skills for specs, research, audits, bug reports, user-facing documentation, and Architectural Decision Records. |
| Specialised work | Single-purpose skills like explaining code faithfully and stabilising flaky tests. |
| Quality gates | Cross-cutting disciplines like empirical proof (paste-output), adversarial review, and distillation discipline (drop-vs-keep accountability when summarising). |
| Conditioning | Standalone persona-<name> skills — one per role-shaped task type (builder, skeptic, architect, researcher, auditor, …). Each is independently installable. |
Every skill answers the question "how should an agent shape its work for tasks of this type?" — not "what should an engineer know about this domain?".
Six categories are deliberately excluded. Each exclusion has a documented reason.
Out of scope: auth-patterns, observability, caching, postmortem-format,
incident-response, idempotency, rate-limiting, runbooks
Why. Skills here describe how an agent works on a task, not what an engineer should know about a problem. A skill called auth-patterns would either:
- prescribe one company's chosen pattern (couples the skill to a stack — see also the next exclusion); or
- enumerate every possible pattern (an everything-skill, anti-pattern [6] and length-cap violation [2][5]).
Either way the failure mode is documented in the literature. The skill is rejected.
The right home for this content is the consuming repo's AGENTS.md > Architecture and AGENTS.md > Conventions, which the universal skills already reference. See Self-containment § The AGENTS.md contract.
Empirical reinforcement. ETH Zurich's evaluation of
AGENTS.mdfiles [32] measured this split directly. Tool-specific commands in the consuming repo'sAGENTS.mdproduced an explicit-tool call rate of 2.5 per task when mentioned vs 0.05 when not — a ~50× lift. Architectural overviews and engineering-domain narrative, by contrast, contributed almost nothing measurable; LLM-generated context files of that style cost +20 % in tokens for –3 % in success rate. The repo's split (universal how-to-work skills here, project-specific what-to-run commands in the consumer'sAGENTS.md) is the empirically supported configuration.
Out of scope: react-19-best-practices, postgres-index-patterns, datadog-alerts,
snowflake-warehouse-design, aws-vpc-conventions
Why. Skills are loaded into context regardless of the project the agent is working in. A skill that speaks React 19 is dead weight in a Python service. Beyond the cost in tokens, the agent is left to disambiguate which skill applies — directive saturation [3] (discussion section).
Stack-specific patterns belong in stack-specific repos that consumers install only when the stack is in play. The README's external skill repos section lists user-globally-installable collections (vercel-labs/agent-skills, wshobson/agents, elastic/agent-skills, etc.) that complement this one without being conflated with it.
Out of scope: internal product knowledge, business-logic wikis, vendor-specific runbooks
Why. Same reason as the previous two — coupling. Internal product knowledge lives in product repos; this repo is generic so it can be installed across them.
Out of scope: scripts/validate.mjs, .github/workflows/*.yml, eval harnesses,
build-readme generators, plugin manifests
Why. The repo's purpose is to be a container for skills + their surrounding documentation, nothing more. Automation has three failure modes that work against that purpose:
| Failure | Consequence |
|---|---|
| Drift — automation falls out of sync with the skills it's supposed to validate. | The signal becomes false; reviewers either chase ghosts or learn to ignore the alerts. |
| Lock-in — automation chooses one runtime, one validator, one evaluation harness. | A consumer on a different stack inherits an obstacle. |
| Scope creep — automation invites tooling-of-tooling (workflow workflows, eval evals, …). | The repo accretes infrastructure that has nothing to do with the skills themselves. |
If validation tooling proves load-bearing, it lives in its own repo consumed by the maintainer's CI — not in this repo. Reviews are reviewer-driven against the rules in CONTRIBUTING.md and the directives in AGENTS.md.
Out of scope: personas-core, write-core, validation-core, any "loader" skill that other skills depend on
Why. This is a direct application of Self-containment. The progressive-disclosure model [1][2] says each skill loads on its own metadata; introducing a "core" skill that other skills assume is loaded breaks that model. The persona discipline demonstrates the alternative — a folder per persona, each independently installable, no shared core, no cross-references.
Out of scope: any skill whose description matches every task
("handles all X", "use on every request",
"general assistance", catch-all triggers)
Why. The community catalogue [6] names this directly under three headings — The Everything Skill, Description Soup, and Missing Exclusions — and Anthropic's own framing [17] draws the architectural line: skills are for multi-step procedures loaded on trigger; persistent context (facts, project conventions, project commands) belongs in CLAUDE.md / AGENTS.md. A "skill" authored to always be resident is the wrong primitive — its content lives in the consuming repo's AGENTS.md instead. The eager-loading bug in current Claude Code [34][35] compounds the cost: even disciplined skills consume ~100 tokens of metadata each at session start, so an "always loaded" description multiplies a problem the consumer can already barely afford. Full case in Activation § The "always-load" anti-pattern.
flowchart LR
P[The skill must be useful in any consumer repo, by itself, with no implicit dependencies.]
P --> E1[No engineering-domain prescriptions]
P --> E2[No stack flavour]
P --> E3[No vendor lock-in]
P --> E4[No internal product knowledge]
P --> E5[No automation in this repo]
P --> E6[No core/loader skills]
P --> E7[No skills designed to 'always load']
Every exclusion above is a corollary of one principle: a skill must be useful in any consumer repo, by itself, with no implicit dependencies on other skills, on this repo's tooling, or on a particular stack.
When a candidate skill is proposed, the gating question is:
Could this skill be installed by a team using a different language, a different framework, a different CI provider, and a different agent — and still produce its intended behaviour, with no other skill in context?
If the answer is "yes", the skill belongs here. If "no", it belongs somewhere else — usually the consuming project's own AGENTS.md, a stack-specific skill repo, or an internal docs site.
- Self-containment — the principle that drives every exclusion above.
- Task files — externalised state is in scope (it's a workflow shape); engineering-domain knowledge is not.
README.md§ Other public skill repos worth knowing about — where stack-specific and vendor-specific content lives instead.CONTRIBUTING.md§ Workflow — the gating questions a new-skill PR must clear.- Sources — full bibliography.