Packages are how teams stop copy-pasting their operating system

Every good team has a pile: the review prompt, the release checklist, the debugging ritual, the internal security rules, the docs voice, the migration playbook, the command that only works if you remember the weird flag. The pile is valuable. The pile is not a system.

AI agents make this worse because workflow instructions matter more than ever. If the agent does not inherit the team’s judgment, it will rediscover that judgment badly every session.

The prompt pile

Copy-pasted prompts are where workflows go to rot. They drift, lose context, hide assumptions, and cannot carry UI, scripts, trust policy, or package metadata. A serious agent workflow needs a unit that can be installed, inspected, versioned, updated, and removed.

Workflow as package

MendCode packages can carry more than text. The manifest shape supports artifacts like commands, agents, profiles, skills, plugins, prompts, MCP, themes, context, worktree policy, and extensions. That is the right abstraction: a workflow is a bundle of behavior, surface, and judgment.

{
  "version": 0,
  "id": "acme.security-review",
  "title": "ACME Security Review",
  "artifacts": {
    "agents": [".mendcode/agents/security.md"],
    "skills": [".mendcode/skills/threat-model/SKILL.md"],
    "prompts": [".mendcode/prompts/pr-risk-review.md"],
    "extensions": [".mendcode/widgets/risk-meter.tsx"],
    "context": [".mendcode/context/security-boundaries.md"]
  }
}

Package lifecycle

A package is not done when it installs. It has a lifecycle: author, inspect, install, enable, use, update, disable, remove. Every stage should be boring enough to trust. If a package changes how the agent thinks, what UI it renders, or which commands it suggests, the user needs a way to understand that before the package starts shaping work.

The lifecycle also matters for teams. A release package might start as one founder’s checklist, become a repo convention, then become a shared package across several projects. That path should preserve authorship and intent instead of turning into copy-pasted fragments.

Marketplace shape

The obvious future is marketplace-ish, but not in the shallow plugin-store sense. Useful packages will encode release workflows, model roles, UI surfaces, custom widgets, project templates, docs standards, and compliance checks. The hard part is not distribution. The hard part is trust.

Team OS

A team has an operating system whether it admits it or not. How it reviews, how it ships, how it handles secrets, how it writes docs, how it escalates risk, how it talks to customers. Packages let that operating system become explicit enough for agents to follow.

That does not remove human judgment. It gives human judgment a durable shape. The agent starts from the team’s known workflow instead of improvising a new one every session.

What not to package

The package boundary should be strict about what does not belong. Secrets do not belong. Local machine state does not belong. One-off project hacks do not belong in a global package. Private customer data does not belong in examples. A package should carry workflow, not accidental environment leakage.

This is not paranoia. Packages are how workflows spread. Anything sloppy inside the package spreads too.

Safe modularity

Shareability creates a supply-chain surface. MendCode package design has to make contents inspectable, secrets excluded, trust visible, and destructive behavior bounded. Otherwise package sharing becomes prompt injection with better branding.

How packages evolve

The best packages will not be written perfectly up front. They will be extracted from repeated work. A team notices the same review ritual happening every week. A founder keeps asking for the same launch checklist. A security pass keeps producing the same set of questions. That repetition is the signal: package this.

This is where agents help. They can notice repetition, propose a package boundary, generate a first manifest, and list what should stay local. But the human should still decide whether the pattern is real, reusable, and safe to share.

Not just sharing

Packages are not just a convenience feature. They are how workflows become portable without becoming mysterious. A good package lets a team say: this is how we do releases, this is how we review risk, this is how our agent should behave here.

The real product is not the prompt. It is the workflow boundary the prompt lives inside.