Product update · August 7, 2026
71 skills installed. Your agent reads almost none of them.
The most common objection to a pack this size is that it must bloat the context window. It doesn't, and the reason is the whole design: every skill stays installed and silent until a request actually matches it. Four new skills landed since the last update, an optional MCP server adds seven read-only tools, and the pack now runs from a design pass to a shipped release to getting a denied Amazon refund back.
Always installed, almost never loaded
A skill is a plain SKILL.md file. The agent keeps only the frontmatter in context: the skill's name and its description. That's a couple of lines each. The body, the references, the scripts, the templates, none of it enters the window until the description matches what you actually asked for.
So the install count and the context cost are separate numbers. Installing 71 skills costs you the 71 descriptions. Running one costs you that one skill.
The second half is suitability, and it's the part most packs skip. Every Suede description carries an explicit NOT FOR line that routes the request somewhere else when the fit is wrong:
suede-ship — NOT FOR: high-volume, well-specified work that splits into independent worker-sized tasks (use suede-codex-fleet); findings-only review with no code change (use suede-code-review); CI and branch-protection wiring (use suede-ci-gate).
That line does real work. Without it, a broad pack degrades into whichever skill has the most eager description, and the agent fires a fifty-agent shipping DAG at a one-line typo fix. The negative boundary is what keeps a 71-skill pack from becoming 71 competing claims on the same request. More on why that gets better as the pack grows: NOT FOR: the two words that make a big skill pack work.
You can read every one of those rules before you run them. That's the point of shipping Markdown instead of a binary.
Where your memory file should have been all along
The same mechanism solves a problem most agent setups have and don't name. Durable knowledge, the operating rules you've accumulated over months, usually lives in a memory file, and a memory file loads unconditionally. Every rule costs tokens on every turn, including the turns where none of it applies. Worse, the rules start competing for attention: add the twentieth and the first nineteen get slightly less obeyed, silently.
Most of what ends up in memory is conditional. It starts with an implicit "when." When I'm deploying, when it's this repo, when the task touches the App Store. Every one of those is a trigger description, and everything after it is a skill body sitting in the wrong layer, compressed to fit a budget it shouldn't be paying.
Moving it into a skill saves the context. The part I didn't expect is that it also improves the knowledge. Memory forces you to write "always use worktrees" because that's what fits. A skill can carry the six paragraphs you actually know: the two places worktrees hide, why the session registry lies about which ones are live, what a squash-merged branch looks like when you're deciding whether to delete it. Behind a trigger, length is nearly free, so the rule finally gets to be complete.
Longer version of that argument: Your memory file is a tax you pay on every prompt.
What shipped since the last update
suede-ship is the canonical shipping DAG: scout, multi-lens research, a gap critic, a lane plan with explicit file ownership, disjoint parallel build lanes, dual-lens review, adversarial refutation, an integration gate, and release verification. Roughly fifty agents arranged as a graph instead of a chain. It halts on a blocking hazard, a real secret in a tracked file or a live process holding a target worktree, rather than plowing through. It reads production and never deploys.
suede-ship-copy is the same idea for writing, decomposed differently. suede-ship splits work by file ownership, so two lanes never write the same file. suede-ship-copy splits by message ownership, so two sections never make the same argument. It runs five blind research lenses, an audit that closes the set of assertable claims, disjoint section writers, four-lens review, adversarial refutation, a deslop pass, and a publish-readiness gate. It reads the live surface and never publishes.
suede-ci-gate makes CI actually hold the line: path-aware builds, required checks, branch protection, duplicate pipeline repair, and merge gates that don't deadlock.
suede-clip-to-guide turns a video moment into a long-form asset, with rights routing, moment scoring, a clip brief, exact post copy, and a publishing sequence that requires visible-identity approval before anything goes out.
Seven read-only MCP tools, optional
The pack ships an optional MCP server. It's read-only by design and it exists for the moments when structure beats prose: list_suede_skills and get_suede_skill for discovery, suede_install_options for install paths, then suede_code_grade, suede_visibility_grade, suede_copy_seo_audit, and suede_qa_checklist for scaffolded audits.
You don't need it. The skills work on their own, with no accounts, API keys, or configuration. Add the MCP when you want a catalog, a checklist, or an audit scaffold returned as data instead of paragraphs.
Design, code, and a refund Amazon already denied
The breadth is deliberate, and it's easiest to see at the edges. The same install that runs an A-F code review with OWASP and deploy-risk checks also runs a design and visual-QA pass on the screen you just built, an SEO and answer-engine audit on the page describing it, and a rights-and-royalty prep pass on a music release.
Then there's the far end. amazon-returns-recovery audited a real account and recovered $448.31 across three documented cases, including a $372.69 refund that had already been denied. Mechanically it's unglamorous: evidence gathering, policy research, and patient support work, which is exactly the kind of task a person abandons and an agent doesn't.
None of that costs the code reviewer anything. The returns skill sits in the same install, one description long, until the day you need it. On why that changes which tasks are worth automating at all: Why breadth is free now.
Also shipped: three essays on why any of this matters
The mechanics above are short because each one has an argument behind it that deserved its own piece. All three published alongside this release:
- Your memory file is a tax you pay on every prompt — why unconditional memory costs attention as well as tokens, the one test that sorts memory from skills, and why moving knowledge behind a trigger makes it more complete rather than just cheaper.
- NOT FOR: the two words that make a big skill pack work — why the failure mode of a large pack is the wrong skill firing rather than a skill breaking, and why explicit boundaries make a pack more precise as it grows.
- Why breadth is free now, and what that changes — what happens to "do one thing well" when an unused capability costs one line, and which abandoned tasks become worth automating as a result.
Install it
Claude Code — full pack:
/plugin marketplace add JasonColapietro/suede-creator-skills
/plugin install suede-skills@suedeFocused subsets, if 71 is more than you want:
/plugin install suede-agent-workflows@suede
/plugin install suede-code@suedeAny other agent (Cursor, Copilot, Windsurf):
npx skills add JasonColapietro/suede-creator-skills