There is a ceiling on how far "copy my prompt" culture can take a team.

At first it feels efficient. One engineer figures out a good flow for PR review, CI triage, migration planning, or bug investigation. A few teammates borrow it. Then a few more. Soon there are seven slightly different versions of the "same" process living in local files, chat snippets, Slack pastes, or somebody's memory.

That works right up until the team needs consistency.

Once a workflow is part of how a team ships software, the question changes. It is no longer "who has the best version?" It becomes:

• what is the canonical version?
• who can update it?
• how does the team review changes?
• how do individuals experiment without polluting the standard path?

That is why we added team workflow repos.

The Marketplace Is Not Your Operating System

The public marketplace still matters. It is the right place for discovery, sharing patterns with the community, and finding ideas worth adapting.

But a team's execution layer needs a different home.

Team workflows are not just content. They are process. They encode review standards, escalation paths, repo routing, evidence expectations, and organizational judgment. That means they need version control, change review, and a clean boundary between canonical workflows and personal experimentation.

In other words, they should live where teams already know how to govern change: Git.

The Model We Landed On

The new team workflow system is Git-backed, CLI-managed, and designed around a simple reality:

teams want the safety of a canonical source, but people still need room to experiment locally.

So the model is:

• a team has a canonical workflow repo
• limerIQ keeps a local mirror for fast access
• canonical team workflows are runnable directly
• editing starts in a local draft workspace, not in-place on the canonical copy
• the draft can later become a personal variant or a PR back to the team repo

That last point matters a lot.

We intentionally did not build this as a read-only catalog plus a million confirmation dialogs. The product flow is much better if editing is immediate and the governance decision happens at finalize time.

That means a person can click into a team workflow, make changes, test them, run them again, and only later decide:

• this is just for me
• this should update the team standard

That is a far more realistic workflow for how engineers actually work.

Drafts Are a Feature, Not a Leak

One of the mistakes tools make in this area is treating drafts as an implementation detail.

They are not.

Drafts are the bridge between local thinking and team governance.

If a team member wants to improve a canonical workflow, they should not have to choose between two bad options:

• edit the team version directly and hope they do not break it
• fork it completely and lose the connection to the canonical flow

The draft model gives them a third option:

start from the team workflow, iterate locally, preserve provenance, then decide where the change belongs.

That is how you get both consistency and velocity.

Why Git Review Still Wins

There is a reason this feature is Git-backed instead of inventing its own approval system.

Teams already understand Git review, branch protections, history, blame, and pull requests. The hard problem is not teaching them a new governance model. The hard problem is making workflow governance fit naturally into the one they already trust.

That is exactly what a team workflow repo does.

If a workflow update should become canonical, it can go through the same review muscle the team already uses for code:

• change proposed
• diff reviewed
• approval granted
• canonical version updated

That is much healthier than letting a shared execution standard drift via ad hoc local edits.

Why This Matters More Than a Shared Folder

It is tempting to think this feature is basically "workflow sharing."

It is not.

A shared folder solves access. It does not solve governance.

The difference shows up in all the details:

• limerIQ can distinguish canonical workflows from team drafts and personal variants
• the system preserves provenance about where the draft came from
• the canonical version can stay clean while people test changes repeatedly
• the team source can refresh from Git without turning the product into a fragile sync problem

This is the difference between "everyone can see the file" and "the team has a governed execution standard."

That distinction is a big part of the new product positioning.

The Team Standard Becomes Real

Once workflows live in a team repo, a bunch of things become possible that are hard to do with informal sharing:

• onboarding can point people to the actual canonical workflow
• quality expectations become executable instead of tribal
• one team can hand another team a process, not just a suggestion
• the standard evolves through review instead of drifting through folklore

That last part matters more than most teams realize.

A surprising amount of "process pain" is really just the pain of undocumented exceptions, half-remembered conventions, and standards that exist only in the heads of senior people. A team workflow repo gives those standards a durable form.

Why This Fits the New limerIQ

If limerIQ were still just a tool for individuals getting better results from their preferred coding agent, this feature would be nice to have.

But if limerIQ is going to be the governed execution layer for AI-native software delivery, then team workflow repos are foundational.

Because once AI work becomes shared operational infrastructure, the workflow itself becomes part of the system of record.

It needs a home.
It needs versioning.
It needs review.
It needs a clear path from local idea to canonical team standard.

That is what this feature gives you.