InkLoom
A newsroom that happens to be AI.
After restructuring left one writer covering two products, I designed InkLoom: five specialized AI skills that work like an editorial team, drafting, editing, building templates and governing terminology, while final approval stays human.
12 → 3
PM EDITS
ROLE
Content Systems Designer & Technical Writer
TIMELINE
2026, 2-months
TEAM
Enablement & Customer Education, CX, Product
TOOLS
Claude Cowork, Notion, Slack, Guru
01
The challenge
One writer was doing the work of an editorial team.
A restructuring left me responsible for documentation across two product platforms on a six-week release cycle. The workload wasn't simply a matter of writing more articles. Every feature guide already ran through the same sequence: research, structure, draft, edit, verify terminology, publish. That took roughly 9.5 hours per guide, and it had to hold together across a master glossary of more than 1,500 terms.
More capacity and more consistency don't usually move in the same direction. Move faster, because there's less writing capacity. Stay consistent, because more content is passing through fewer hands. Simply asking one writer to work faster wasn't a scaling strategy.
02
The insight
AI didn't need to become the writer. It needed to become the team.
The obvious solution was to use generative AI to draft articles faster. I rejected it. A general-purpose drafting assistant could write fluent copy fast, but it still had to find the right information, use approved terminology, and apply editorial standards before anything was ready to publish. Worse, cramming all of that into one prompt made every one of those responsibilities harder to control. Speed without governance would just create inconsistency faster.
So instead of asking how to make one writer faster, I asked how a newsroom would split the work. Traditional editorial teams don't ask one person to handle every responsibility at once. They divide it into roles. I applied the same principle to AI: one skill, one job.
03
THE SYSTEM
Five skills. One editorial workflow.
InkLoom uses five specialized AI skills modeled on an editorial team. Each has one job and only the context it needs to do it.
Drafter: Turns a content request into a structured first draft, using the template library and product facts from the Everything Da Vinci Plugin.
Editor: Runs a five-point pass on style, terminology and clarity, plus an accuracy check against the plugin.
Template builder: Reverse-engineers published articles into reusable templates, starting from the eight topic types I designed for the help centers.
Term scout: Finds new terminology after publishing and checks it against a master glossary of more than 1,500 governed terms, each typed as a feature, concept, UI element, technical term, business term, product name or deprecated term.
Glossary keeper: Prunes and dedupes the glossary, then syncs approved terms back into the plugin. It's the only skill allowed to change a shared resource, so it always waits for approval.
Work comes in two ways. Release content starts from a Feature Dossier brief. Everything else starts from a standard content request. The writer reviews every draft and does the final publish.
No single skill owns the article. The workflow does.
04
Key Decisions
The architecture mattered more than the prompts.
01
Give every skill a bounded responsibility.
Each skill has a specific editorial job. The drafter doesn't redefine terminology. The editor doesn't rewrite the templates. The terminology skills don't decide product behavior. Those boundaries make individual skills easier to improve and failures easier to diagnose.
02
Give each role only the context it needs.
A skill doesn't become better simply because it can see more information. Too much context creates noise. InkLoom separates product knowledge, editorial instructions, terminology, templates, and publishing requirements so each role works from the information relevant to its responsibility.
03
Make governance shared.
Specialization creates a new risk: five skills can become five different interpretations of the rules. So shared resources sit outside individual skills. Approved terminology, templates, and editorial standards act as common infrastructure. When those resources change, the system changes with them. That makes governance part of the architecture rather than something added during final QA.
04
Don't automate the approval.
InkLoom can draft, edit, build templates and check terminology. It cannot decide that governed information should change without human approval. Any skill touching a shared resource requires an approval gate. Local, single-file production changes can move without that overhead. That distinction lets the system move quickly without allowing automation to quietly redefine the rules everyone else depends on.
05
The Transformation
From one person doing five jobs to one person directing the system.
Before InkLoom, the same writer moved manually through every editorial role. The design decisions that made it useful were about responsibility, context, governance, and control.
BEFORE
Writer: Research → Draft → Self-edit → Check terminology → Revise → PM review → Revise again → Publish
Cost: 9.5 hours and 5 review rounds
AFTER
InkLoom: Brief or request → Draft → Edit → Terminology check → Writer & PM review → Publish
Cost: 2.25 hours and 2 review rounds
06
the outcome
Faster and more consistent, not one or the other.
For seven months, one writer and InkLoom covered two products on a six-week release cycle. When a second writer joined, they joined a system, not a backlog.
InkLoom reduced average feature-guide production time from 9.5 hours to 2.25 hours. That's a 76% reduction. Updating an existing guide dropped from 5 hours to 1.5.
Speed alone wasn't the success criterion. Writer review rounds fell from five per article to two, while PM edit-related comments dropped from approximately 12 to 3 per article.
That matters because the system wasn't producing drafts faster only to push more cleanup downstream. The drop in review and edit comments showed the workflow was improving consistency at the same time it increased capacity.
07
What I Actually Designed
Not an AI writer. An editorial operating system.
The most visible part of InkLoom is the five AI skills, but the skills themselves are only one layer of the system.
I designed the role architecture that determines which editorial responsibility belongs to which skill.
I defined the handoffs that determine what each role receives and what it must produce for the next.
I structured the context boundaries that keep each skill focused on the information necessary for its job.
I built the shared resource model that gives every skill access to the same approved terminology, templates, and standards.
I established the governance model that distinguishes local production changes from changes that affect the whole editorial system.
And I designed the human approval gates that keep editorial ownership with the writer.
08
The bigger idea
Scaling judgment is different from replacing it.
A lot of AI content tooling starts from the same assumption: If writing takes too long, automate the writing.
InkLoom started somewhere else. Writing was only one part of the work. The expensive part was repeatedly coordinating the judgment around it: finding the right information, applying the right structure, checking the right terminology, reviewing the result, and preparing it correctly.
Those responsibilities could be distributed. Editorial accountability couldn't.
InkLoom therefore uses AI to scale the work surrounding judgment, while keeping the consequential decisions with the human responsible for the content.
The goal wasn't to remove the editor. It was to give the editor a newsroom.
09
Reflection
The hardest part wasn't the skills. It was assuming one person would own them.
Building a general-purpose AI writer would have been simpler. Designing InkLoom required decomposing editorial work into responsibilities precise enough that each skill could operate independently without losing the coherence of the whole. Some tasks belonged to individual roles. Some rules needed to be shared. Some actions could safely happen automatically. Others needed an explicit human gate.
That governance model was built around one writer holding every shared decision. For seven months, that's exactly how it ran. Then a second writer joined, and each product now has its own owner working inside the same system. The approval gates still catch bad changes, but they were never designed to settle two owners wanting to move the same glossary term or template in different directions. That's the problem I'm solving next: not more roles, but more owners.
Want to see how the approval gates actually work, or what almost slipped through before they existed? Reach out and I can go into the details!