Skills Don't Lie Dormant. Triggers Do.

Why AI workflows fail less from bad outputs than from bad activation design, and how precise triggers turn dormant skills into compounding systems.

I built a daily artifact factory in May. The system was real: one observation per day, turned into a published Claude Skill, agent config, or workflow. Quality bar. QA gate. A compounding log that would let me look back in six months and see exactly what I'd built. The whole thing was structured, intentional, and I was fairly confident well-designed.

Then I went three weeks without a single queued idea.

The factory wasn't broken. The skills were configured correctly. The QA gate worked. The compounding log had entries from the first week. But nothing was entering the input queue, because nothing in my actual working day was prompting me to feed it. Every observation I had at the end of a session - a friction point, a pattern I'd noticed, something that felt unnecessarily manual - just evaporated. The factory sat idle, perfectly built to process inputs it was never receiving.

This is the failure mode that killed it. Not the output format. Not the schema. Not the escalation path. The capture hook. The thing that fires the thing.

The part nobody talks about

AI workflow design has a well-documented set of concerns: prompt quality, schema design, output structure, model selection, latency, cost per call. There's an enormous amount of writing about how to build the right output. There's almost nothing written about how to trigger the right input.

The assumption underneath most workflow design is that users will invoke the system when appropriate. They'll notice the relevant moment. They'll remember the tool exists. They'll decide this is the right time to use it.

That assumption is wrong. Humans don't operate that way. We use things when those things are in front of us, or when something specific in our environment reminds us of them. Not when we might theoretically benefit from them.

I've built well over two dozen production AI agents at this point, across healthcare systems, agency work, and my own infrastructure. The failure pattern I've seen more consistently than any other isn't bad prompting. It's tools that were never invoked. Skills sitting in a library nobody opened. Workflows that got used twice in the first week because they were top of mind, then never again.

The trigger is where most AI workflow debt accumulates. And it's almost never treated as a design decision.

Two ways triggers fail

There are exactly two failure modes. They look different but share the same root cause.

The first is no trigger at all. The system relies on the user to remember to invoke it. This sounds obviously bad, but it's extremely common, because "remember to use this tool" is the implicit design of almost every AI workflow that doesn't have explicit activation logic. The tool exists. The user knows it exists. The expectation is that when the relevant situation arises, they'll connect the two.

What actually happens: you use it when you're already thinking about the tool. That's a narrow window. You won't use it when you're mid-client-call and notice something. You won't use it at 6pm when you're wrapping up and a friction point surfaces. You won't use it when you're annoyed or distracted or just trying to close the laptop. Those are exactly the moments when you need it most.

No capture hook means no captures. The system only runs when you remember to run it, which decays fast from the day you built it.

The second failure mode is a hook that's too broad. This is more insidious because it feels like you've solved the problem. The SKILL.md says "Use for AI tasks" or "Use when working on client workflows." The trigger description is there. But it never creates a specific enough this is the moment signal.

The problem with broad triggers: they're applicable constantly, which means they're applicable never. If a trigger could fire twenty times a day, it doesn't fire reliably on any of them, because invoking it becomes a judgment call, and judgment calls require attention bandwidth you rarely have at the exact moment you need the tool.

I've written SKILL.md trigger descriptions so broad I genuinely couldn't tell, in the moment, whether the current situation was supposed to invoke them. That's not a trigger. That's a note you'll forget you wrote.

What a real trigger looks like

A good trigger is specific enough that you don't have to decide whether it applies. It just fires.

Three forms work consistently:

A specific phrase

"I noticed X today" -> capture it.

"I'm about to call them" -> pull the call script.

"Sam says 'I have an idea about'" -> run observation-to-idea.

These are close-to-verbatim strings, not descriptions of situations. The closer the trigger is to something you'd actually say, the lower the activation cost.

A specific event

"Artifact QA says PASS" -> publish and log.

"Client signed" -> generate intake.

"New lead drops a URL" -> run the full audit pipeline.

Events are unambiguous. Either they happened or they didn't. There's no judgment about whether it applies.

A specific state change

Moving a deal to a new pipeline stage. Marking a task complete. A calendar event starting.

State changes happen at a defined moment, and they're already reliable because they're part of a workflow that's already running.

The test I use: if someone would have to think about whether this trigger applies, it's not specific enough. The trigger should feel like a reflex. Reflexes don't involve deciding. They fire when the stimulus arrives.

Building the capture hook: a case study

The artifact factory failure sent me back to the design. The system was solid everywhere except the front end - the moment where an observation became a queued idea. That moment had no infrastructure at all. It was entirely dependent on me noticing, deciding to act, and having the energy to do it.

So I built a skill to close that gap: observation-to-idea.

The skill takes a raw, messy observation - a friction point you noticed, a pattern that felt off, something you did manually three times in a row - and turns it into a formatted idea file ready for the next build session. Messy input in, structured output ready for the queue.

Two design decisions mattered most, and neither of them were about the output.

First: the trigger conditions. I made them explicit and narrow in the SKILL.md: Sam says "I have an idea about X" or Sam pastes rough notes and says "capture this." Those are the activation phrases. Not "when thinking about workflow improvements." Not "when you want to log an observation." Specific phrasing. Two options. Either one fires it immediately.

Second: messy input is explicitly okay. I added this to the skill documentation on purpose. If a skill requires well-formatted input, you'll skip it when things are rough. And things are always rough at the moment of observation. You're mid-session, you're tired, you have six tabs open. The observation is half-formed. "I keep having to do X manually and I don't know why" is a good enough input. The skill handles the structure - that's its job.

The result: there's now a connected path from observation to queued idea. The artifact factory has something to process. The gap that killed the first version of the system is closed.

That said, I'm still working on making the trigger even more reflexive. Right now it requires me to shift context enough to type a trigger phrase. The next version might be a keyboard shortcut or a Slack integration that captures anything I send to a specific channel. The activation cost is still higher than I want. Getting it to zero is the goal.

Why teams can't use the workflows they build

This failure mode doesn't stay personal. It scales badly, and in specific ways.

I've seen it in healthcare AI deployments: a clinical team works with product for months to build a genuinely useful workflow assistant. The prompts are good. The schema handles edge cases. IT has approved it. The pilot ran well. Everyone left the kickoff meeting feeling like the problem was solved.

Six weeks after launch, usage has collapsed to two people, the ones most involved in building it. Everyone else reverted to whatever they were doing before.

The post-mortem answer is almost always "change management" or "training." But the actual problem, consistently, is triggers. The workflow was designed to be invoked by users who already know to invoke it. There was no specific event in the clinical day that activated it. No phrase that fired it. No state change in their existing tools that triggered it automatically.

The workflow became personal knowledge - owned by the builders - instead of team infrastructure, which fires from shared events that everyone hits.

The fix is the same at any scale. Go back to the trigger. Find the exact moment in the actual workflow when the tool should fire. Make it specific enough that it's not a judgment call. Connect it to something that already happens in the environment - a phrase people already use, an event that already occurs, a state change in a tool they're already in.

If you're building AI workflows for a team and you're thinking about adoption, you're thinking about the right problem. But training people to use the tool is usually the wrong solution. Engineering the activation conditions is the right one.

How to audit your own triggers

If you have existing skills, agents, or workflows, three questions will find your exposure quickly.

1. What is the exact condition that fires this?

Write it down. If you can't write a specific phrase, event, or state change, you have either a broad trigger or no trigger. Both produce inconsistent usage that decays toward zero.

2. When was the last time this system was invoked without you first thinking "I should use this"?

If the answer is never, if you've only used it when you were already thinking about the tool, you have no real trigger. The system depends on you keeping it top of mind, which is not infrastructure. That's just memory.

3. Would you invoke it if you were tired and mid-task?

Observations rarely arrive at optimal times. If using the tool requires any reformatting of input, any non-obvious activation step, or any decision about whether this situation qualifies, you won't invoke it when you're distracted or running low. That eliminates most of the moments when you'd actually benefit from it.

The threshold I aim for: skipping the trigger should be the harder path. If the capture hook is a specific phrase you've already half-typed, completing it is less friction than stopping. That's what you're building toward. Not a tool you remember to use. A system where using it is the path of least resistance.

The trigger is the product

There's a version of workflow design where 80% of the time goes into the output format and 20% goes into activation. That ratio should probably be inverted.

A skill with a precise trigger and a decent output will outperform a skill with a perfect output and a vague trigger every time, because the first one actually runs when you need it. The second one runs when you remember to run it, which is less often, at worse moments, with worse inputs.

The artifact factory taught me this the slow way. Everything downstream of the input queue worked. The QA gate caught quality issues. The compounding log built useful depth. But the front end - the capture hook - had a gap, and every observation that fell through that gap was gone. The system couldn't compound observations it never received.

observation-to-idea isn't a sophisticated skill. The logic is straightforward - take messy input, structure it, queue it. But it closed the one opening the whole system depended on: the space between noticing something and doing something with it.

Build the hook before you optimize the output. Fix the trigger before you refine the schema. The most important thing about a workflow is whether it runs when you need it to.

The trigger is the product.

Working through more of these gaps in my own system right now. If you're building AI workflows - for yourself or for a team - I'd be curious where your systems are losing inputs. What's your equivalent of the unhooked artifact factory?