We Didn't Set Out to Build a Team AI Plugin

We had the knowledge. Voice guidelines, product context, terminology, content structures. The problem was where it lived.

When we started using AI for writing, everyone pulled their own context into their own sessions. Five people, five slightly different setups, five slightly different outputs. Nothing compounded, nothing carried over between sessions or between people.

The knowledge wasn't the bottleneck. The lack of a shared, persistent home for it was. Voice comes from our GTM team. Product context comes from product. Neither belongs to any one person, but there was no place where everyone could access it consistently, inside the tools we actually use every day.

So we built one.

This is the story of how we built shared context for AI-assistend work at Recce: a Claude Code plugin called recce-team, a three-layer architecture (knowledge, workflow, context), and how it grew from a content workflow into something the whole team builds on.

The same problem, everywhere

Our engineers do a great job keeping docs updated. After every release, they write up what changed: new features, how things work under the hood, and technical details.

The challenge was consistency. Everyone knew how Recce should sound, but each engineer had their own structure, their own format, their own way of explaining things. The docs worked individually, but as a collection they didn't feel like they came from the same team. This existed long before AI. We just lived with it.

When we started using AI for writing, the same inconsistency got louder. Some of us were writing blogs. Dori, who leads our go-to-market, and Jenneviere, our marketing consultant, were producing podcast content. We were all exploring how AI could help, and we all hit the same wall: the bottleneck wasn't AI's capability. It was that our shared knowledge wasn't shared.

One repo, one truth

We combined what we'd each been doing into one shared repo called recce-content-guide, wired into Claude Code. Dori's framing became our guiding principle: "A prompt fixes the problem once. Context fixes it continuously, if you put it in the right places." (she wrote more about this in Your AI Tools Should Get Better Every Time You Use Them.)

Jenneviere turned that principle into practice. She built the voice system and content structure: universal voice principles, content-specific voices for different post types (product education, thought leadership, case studies). She defined blog types (official, BIP, co-authored) and documentation types (concept docs, tutorials, reference docs). Not guidelines for humans to interpret, but instructions precise enough for Claude to follow. (Jenneviere shared her perspective on building this system.)

We'd each know roughly how Recce should sound, but we'd still wait for Jenneviere to review and correct us. Her voice guidelines were already in the system. We trusted them because they came from her. That freed the whole team from the back-and-forth, and freed her from reviewing every draft for tone. When the team started using the same repo, something clicked: different people, but the output sounded like Recce. Same voice, same structure, same terminology. The shared knowledge and content structure did the aligning, not review cycles.

You can see the result in our documentation: consistent voice, consistent structure, written by different people using the same shared knowledge.

Beyond content

The same pattern shows up in other parts of our workflow.

Someone reports a bug through a Loom video. The steps are always the same: watch the video, extract the key details, write it up in Linear (our issue tracker), and then notify the team on Slack.

After a meeting where we discuss three different projects, someone needs to turn that conversation into structured output: a project spec from minutes 10-33 and initiative notes from minutes 35-50. Any note-taking AI can summarize a whole meeting. The difference is selecting the right segment, applying the right template, and capturing only the relevant context for each.

Release notes after a deploy. Same thing again.

These tasks all share the same shape: repeating work that requires team knowledge and shared team voice to communicate that knowledge externally. Someone does them every week, sometimes every day. The steps are predictable, the context is known, and the work is valuable but not the kind anyone should be doing manually each time.

Here's what the team has built so far:

Each one is scoped and specific: one task, one workflow, the shared context already in place.

At this point we had enough skills to step back and ask: what's actually making this work?

Three layers

Every skill we've built draws from the same three things.

Knowledge is what the team agrees on: voice guidelines, product context, terminology, how we describe features, what words we use and avoid. We all sort of knew these things before. The problem was that every time we wrote them down, they came out slightly different. Jenneviere is closer to the voice, product is closer to the positioning, but these are shared agreements, not individual ownership. When any of it changes, it changes in one place and every skill picks it up.

Workflow is how we do things: the steps for writing a blog, filing a bug from a Loom video, publishing release notes. Each skill encodes a specific workflow with its own sequence, gates, and output format. A skill is a markdown file that defines the steps, decisions, and quality checks for a specific task. Here's a simplified example:

# loom-bug (simplified)
1. Watch Loom transcript
2. Extract: bug description, steps to reproduce, expected behavior
3. Create Linear issue using template, notify #bugs on Slack

The loom-bug skill has three steps. The doc-update skill has five phases with mandatory pauses. The complexity matches the task.

Context is where the information lives: which Linear project tracks bugs, which Slack channel gets release announcements, who's on the team and what their roles are, where the docs repo is. This is the connective tissue that lets skills interact with the right systems without anyone having to specify it each time.

Here's what the structure looks like in practice:

recce-team/
  skills/                    # Workflows — how we do things
    writing-content/
      SKILL.md               # Blog, social, docs workflow
      reference/
        voice.md             # Universal voice principles
        voices/              # Content-specific voices
        authors/             # Personal author voice profiles
        blog.md              # Blog structure and types
        doc.md               # Doc types (concept, tutorial, reference)
    loom-bug/SKILL.md        # Loom → Linear workflow
    release/SKILL.md         # Release publishing workflow
    fix-bug/SKILL.md         # Autonomous bug fixing
  context/                   # Where information lives
    product/
      recce-context.md       # Product positioning
      terminology.md         # Shared terms
    team/members.yaml        # Team members, roles, Slack IDs
    sources.yaml             # Linear, Notion, Slack integration pointers
  commands/                  # Quick single-step actions
  agents/                    # Autonomous workers (bug-fixer)

Each layer is independently useful. Voice guidelines help even without a workflow. A workflow helps even without integrations. What changes when you combine them is that the whole system compounds: updating the product context improves every skill that references it. Adding a new integration makes every workflow that touches that system smoother.

A wiki is something you look at when you want a reference. This system is something you work through.

Because we keep using it, we keep noticing when something is outdated or missing, and we update it. The knowledge stays current because it's part of the workflow, not next to it.

From repo to shared infrastructure

recce-content-guide was a repo. It worked, but it started as one person's setup. If someone wanted to use it, they had to clone it and configure it. If we updated a voice file, everyone else needed to pull. It scaled to a small team, but it wasn't infrastructure.

Our engineers, Kent Chen and Andy, suggested packaging it as a Claude Code plugin: a distributable package that anyone can install. That conversation changed the scope. A plugin has versioning: when we update a skill or add context, everyone gets the update. It has a marketplace: anyone on the team can install it the same way. It has defined structure for skills, commands, agents, and shared context.

We called it recce-team. The content skills migrated over from recce-content-guide. The operational skills we'd been building (loom-bug, summarize-recording, release) joined them. We added shared context that applies across all skills: product positioning, terminology, team members, integration sources.

Once it covered more than content, engineers started contributing. Kent Huang built a bug-fixer agent that picks up Linear issues, fixes the code, creates a PR, and posts progress back to Linear. Kent Chen built an f2f (face to face) skill for organizing our monthly team dinners: it handles date polling through Slack, searches for restaurants, and collects votes. These came from engineers solving their own repeated work, not from a top-down initiative. Contributing a skill is as natural as committing code. Version bumps, pull requests, code review: the same engineering practices that keep product code healthy now keep our workflow system healthy too.

What we still don't know

The shared knowledge works. Among other things, the docs are more consistent, the content sounds like Recce, and the skills produce reliable output. That part is solved.

What's harder is reach. Engineers who built the bug-fixer and f2f skills use recce-team naturally: they built something for themselves and it lives there. For tasks that aren't their own creation, the habit is harder to form. They already have their AI setup configured for how they code. Adding a plugin for writing tasks feels like switching tools mid-flow, even when the plugin is one install away.

We think the answer is making the shared knowledge available where people already work, not asking them to come to a different tool. One direction we're exploring: making it easy to work across multiple repos in a single session, so engineers never have to leave their codebase to access team knowledge. That's still taking shape.

There's a deeper question we keep coming back to. People have different workflows, and maybe that's fine. Someone outlines once and writes straight through. Others restructure mid-draft and go back and forth. The knowledge and context layers are the foundation that should be shared and consistent. The workflow layer might be the one that should flex, that should be personal. We built recce-team with all three layers shared. We're starting to think the third one needs more room.

The goal we've always wanted for the team: everyone knows the direction, the priority, the current project, and can make aligned decisions without checking in every time. That was hard before AI. With shared context living inside the tools people already use, it feels more possible. We're not sure we're there yet. What we know is that the output is already more consistent, and that's a start.

This article covers content and operations. Our release flow has changed alongside recce-team, and that story has its own surprises. That's next. The dev workflow, from planning to coding to reviewing, is reshaping how our engineers work too.

FAQ

How do you share AI context across a team?

Build a Claude Code plugin that packages shared knowledge, workflows, and context into one installable package. Everyone on the team gets the same base context in every AI session. At Recce, we package voice guidelines, product context, terminology, step-by-step skills, and integration pointers into a single plugin called recce-team.

What is a Claude Code plugin?

A distributable package of skills, commands, agents, and shared context. Skills are markdown files that define multi-step workflows. Commands are single-step actions. Agents are autonomous workers that run independently. The plugin installs through the Claude Code marketplace and updates automatically with versioning.

How do you keep AI output consistent across different people?

Share the knowledge layer: voice guidelines, content structure, terminology, and product context live in one place. The output is consistent because the inputs are consistent, not because people follow the same process. Everyone's AI sessions start from the same source of truth.

Can individual team members customize their workflow?

Yes, and we're still learning where the line is. The knowledge and context layers should be shared and consistent. The workflow layer is where personalization makes sense: different people move through work differently, and the system should accommodate that.

Try Automated Data Validation For Yourself

Try our Data Review Agent on your data projects, sign up for Recce Cloud and tell us what works and what breaks.

Here are docs that help, we're more than happy to help you directly, too.

• MCP server
• Claude Code Plugin
• Start with Recce Cloud

We'd love to hear from you. If you can spare 30 minutes to chat, we'll send you a $25 gift card as a thank you. Join the feedback panel.