Turning content strategy into a workflow the agent can run.

Content strategy that lives in one head cannot scale.

Content strategy work is the upstream work. Before a single line of UI text gets written, someone has to decide what content the feature even needs, what its purpose is, who it serves, how it maps to the user's journey, and what states and edges the system has to account for. This work is what determines whether the UI text written later is solving the right problem.

The trouble is where this work lives. Most of it sits in the content designer's head. The fragments that get written down end up scattered across project briefs, Slack threads, design files, and personal notes. When a designer leaves a team, the strategy leaves with them. When a new feature needs to ship, the strategy work gets restarted from scratch. When another team wants to learn from how content strategy was approached on a successful feature, there is nothing to learn from beyond the final UI.

Three failures follow. The work is hard to share, because no two designers approach it the same way. It is hard to repeat, because each new feature requires reconstructing the process from memory. And it is hard to scale, because the throughput of the entire practice is bounded by the number of senior content designers a team can hire. None of these failures can be solved by writing more documentation about content strategy. They have to be solved by changing what content strategy work produces.

Each step of content strategy becomes a skill the agent can run.

I designed a skills framework that treats content strategy work as a pipeline. Each step in the pipeline is a skill: a structured prompt the agent can execute against source material to produce a documented artifact. The skills run in sequence, with the output of each one feeding the next. By the end, the team has a complete content architecture for the feature in question, captured in documents, ready to inform UI writing.

Six skills, in sequence

The pipeline is organized around the actual stages of content strategy work. Each skill answers one strategic question. The skills run from broad to specific: from cataloging what exists, to deciding what the feature should do, to mapping how content shows up in the journey, to enumerating the states that need to be handled.

Authored by me, run by the agent

Each skill is a markdown file that defines the source material the skill needs, the strategic question it answers, the structure of the output, and the quality criteria the output has to meet. I author the skill. The agent executes it against the team's actual source material, producing a documented artifact specific to the feature in question.

This is the part that changes what content strategy is. The strategic thinking still belongs to me, encoded into the skills as constraints and quality criteria. The repetition, the structuring, the consistent documentation, the part that used to consume the most time and produce the most variance, gets handed to the agent. When someone else on the team runs the skills, they produce work grounded in my judgment without needing to learn how I approach the problem from scratch.

One skill, fully written.

Here is the structure of the /generate-feature-strategy skill, the second step in the pipeline. The skill takes source material from product, design, and research, and produces a one-page strategy document. The format is compact: a frontmatter block that defines when the skill applies, followed by the inputs required, the core strategic question, the output structure, and the quality criteria the output has to meet.

---
name: generate-feature-strategy
description: Produce a one-page content strategy for a single
             feature, defining purpose, audience, voice, and
             success criteria. Run after /generate-content-inventory.
---

## Inputs required

A completed content inventory (output of skill 01).
At least one of: PRD, design brief, research summary,
or stakeholder interview notes.

## Strategic question

What is this feature doing for the user, and how should the
content support that goal?

## Output structure

The skill produces a markdown document with five sections:

1. Feature purpose
   One sentence stating what the feature is for, in user terms.

2. Primary user and use case
   Who is using this feature and in what situation. Pulled
   from research where available, marked as assumed where not.

3. Content goals
   Three to five outcomes the content must achieve. Each goal
   tied to a measurable signal.

4. Voice and tone
   The voice baseline (from the agent persona, if applicable),
   plus any feature-specific tone adjustments.

5. Success criteria
   How the team will know the content is working. Includes both
   qualitative and quantitative signals where applicable.

## Quality criteria

Every section must be specific to the feature, not generic.
"Help users complete tasks" is not a content goal.
"Help users complete a work order in fewer than three steps,
measured by completion rate" is a content goal.

Every assumption must be marked as an assumption.
Every claim about the user must be sourced or marked unsourced.

The skill works because the strategic judgment is built into the structure itself. The five-section output structure is the strategic question, decomposed. The quality criteria are the standard. When the agent runs the skill, it pulls specifics from the source material into a structure that has already done the thinking about what good strategy work looks like.

The quality criteria do more than score the output. They act as a design linter for the skill itself. Statements like "every assumption must be marked as an assumption" or "'help users complete tasks' is a failure state" are negative constraints: the skill's own definition of what bad output looks like. Treating those constraints as enforceable rules, not aspirations, is what keeps the agent's output bounded by content design judgment rather than drifting into whatever the model happens to generate.

Strategy work became portable.

The framework changed three concrete things about how content strategy gets done.

The framework also closes the loop with the rest of the agent's behavior. The agent that executes these skills runs on the same response guidelines and reasoning rules it uses everywhere else. Its outputs get scored against the same evaluation rubric. The skills themselves follow the same modular folder structure as the conversation patterns. Content strategy stops being an isolated documentation exercise and becomes an integrated component of the actual system the agent operates in.