I've been building an AI-assisted editorial pipeline in Cursor. Notion cards capture observations, skills score and schedule them, and agents draft markdown that eventually syncs to dev.to. In that setup, a skill is a markdown file the agent loads when you invoke a workflow: it defines what the agent may do, what it must not do, and how it routes between sub-steps.
When I started, that model felt safest as one skill per action. Create a card here. Enrich a card there. Reclassify somewhere else. Each prompt got a clean boundary. Each file stayed small. Decomposition felt like good engineering.
That assumption started to fight the domain.
When every action gets its own skill
The first version of my inbox skill only created Inbox cards. That matched early usage: capture an observation, normalize it into a canonical shape, attach a small set of grounded references, and stop. The skill was create-only and treated each new card as immutable once it left Inbox.
As capture matured, the same card kept needing more work while it was still Inbox:
- Create when a new observation arrived
- Enrich when new evidence or framing changed the normalized shape
- Reclassify when routing rules decided the card should be sparse vs rich, or a quick note vs a planned blog post
Those felt like three different jobs. They had different verbs. They had different retrieval triggers. Splitting them into separate skills seemed obvious.
The split failed in ordinary corrections. I would enrich an Inbox card with new evidence, then realize it should change from a quick note into a planned blog post. That meant a second skill invocation for reclassify, with a second copy of the same lifecycle rules. For a moment it was unclear which skill was still responsible for keeping the page as one current write-up instead of an accumulating edit history. Get the order wrong and you did the work twice: an enrich that left the card type stale, or a reclassify that ignored the evidence rewrite you still needed.
The deeper problem was ownership. All three operations touched the same owned object: a single Inbox card in a Notion database. They shared the same lifecycle gate (the card must stay in Inbox), the same mutation boundaries (never change lifecycle status, source path, or published URLs on existing pages), and the same routing rules for how sparse or rich the card should be and whether it was a quick note or a planned post. They also shared the same rule: after every update, the page must hold exactly one current normalized write-up and exactly one captured observation. Notion history is the revision log; the operational card is not an append-only audit log.
Treating Create, Enrich, and Reclassify as three skills meant three prompts trying to enforce one coherent capability. The boundaries were at the wrong layer.
Consolidation made the skill clearer
The fix was to stop pretending those were separate capabilities. One inbox skill now owns the full Inbox lifecycle: Create, Enrich, and Reclassify while the card remains in Inbox.
The operator still invokes one skill. The skill routes internally:
| User-facing command | What it does |
|---|---|
| create inbox card | Creates an Inbox card with a canonical write-up and grounded references |
| enrich inbox card | Folds new evidence into the existing Inbox page as one current write-up |
| Same-thread continuation | Treats further capture in the same chat as enrich on the page just created |
Reclassify is not a separate user command. It is detected inside enrich when the routing rules decide the card should be richer or thinner than before, or should shift from a quick note to a planned post. Sparse captures can become richer field reports. The skill rebuilds the current Inbox representation when those derived choices change; it does not append enrichment history sections.
That consolidation expanded the inbox skill from create-only immutability to Inbox-lifecycle ownership. The skill file grew, but the system got simpler: one place owns Inbox normalization, one shared rule set, one place with authority over the rules.
That was the opposite of what I expected. I thought a bigger skill file would feel heavier. Instead routing got easier. I stopped wondering which inbox skill to invoke for a correction vs a note-to-post change. I invoked the inbox skill, and the routing rules decided whether enrich included reclassify.
One capability, many internal operations
The incident suggests a short consolidate-vs-split test:
- Same owned object under the same lifecycle gate. If lifecycle stage or artifact type diverges, stop consolidating.
- Compatible mutation rules and safety boundaries. If the operations need conflicting write permissions or rejection rules that cannot share one authority, keep them separate.
- Same type-and-shape rules across operations. Given the same input, if the operations would disagree about what kind of thing it should become, keep them separate.
Those are internal operations, not separate capabilities.
A parallel already existed elsewhere in the pipeline. A triage skill scores Inbox cards, recommends promotions out of Inbox, and archives the weakest rows. Those are different mutations, but they live inside one triage skill because they share the same queue-review ownership. I did not split score, promote, and archive into three skills. The operations differ; the owned workflow does not.
That comparison has limits. Triage promotion requires an explicit apply command after a dry-run report. Inbox enrich rejects cards that have already left Inbox. The internal gates differ without splitting ownership. The pattern is still recognizable: one skill per coherent capability, with internal routing between operations.
That does not mean every related action belongs in one skill. Scheduling, drafting, critique, and publishing own different artifacts and stop lines, so they remain separate.
The resource mattered more than the verb
You do not need Cursor to recognize the shape. A REST API does not usually become a separate service for every operation on the same resource.
POST creates. PATCH updates. DELETE removes. Different operations, same resource contract. Reclassification in my system is just another mutation of that same Inbox card resource.
Splitting those operations into separate agent skills was like building one service for create, another for update, and a third for delete. The endpoints looked clean in isolation. Ownership of the resource was fragmented.
Agentic workflows drift toward that decomposition because actions are easier to name than ownership. "Create card" and "enrich card" are vivid verbs. "Own Inbox normalization throughout the Inbox lifecycle" is accurate but abstract. The verbs made the skills easy to name. The resource revealed where the boundary actually belonged.
Your domains may decompose differently. The useful question is not "how many skills do I have?" but "what object does this capability own, and are these verbs operations on that object or different capabilities entirely?"
Takeaway: Start with one skill per action if that helps you ship. When multiple operations share an owned object, lifecycle, and compatible safety boundaries, consolidate them into one capability module and route internally. The risk was no longer a skill becoming too broad. It was one capability having multiple competing owners.
If you'd like to see the project behind these workflow experiments, try Codenames AI.
Top comments (1)
This really highlights a common mistake in AI workflows. Breaking work into one clear skill per action makes prompts easier to maintain, debug, and improve over time. Small structural changes like this can have a surprisingly big impact on the final results. Great insight! 👏