It started as a folder. A directory in the Attractor repository called /specs/patterns/, containing three NLSpec files that described common software patterns in natural language. An authentication flow. A CRUD API. A webhook receiver. Each specification was three to five pages of precise, plain-language description: what the software should do, how it should behave under failure, what edge cases existed, and what "correct" looked like.
Jay had written the first three during a weekend when he was procrastinating on something else. He committed them without fanfare. The commit message said "add pattern specs" and it was the most understated introduction to a library that would, within two months, become one of the most forked directories on GitHub.
The library grew. Navan added a specification for an event-driven message bus. Justin added one for a rate-limited API gateway. A contributor in Seoul—someone none of them had met—submitted a pull request with a specification for a real-time collaborative editing backend. The specification was excellent. It described conflict resolution, operational transforms, cursor presence, and graceful degradation with a clarity that suggested the author had built such systems before and had spent a long time thinking about what mattered.
By November, the library had forty-seven specifications. Each one was a blueprint of intent. Not code. Not pseudocode. Language. Description. A precise account of what a piece of software should do, written so that an agent could read it and produce an implementation, and so that a human could read it and understand what the software was for.
"It's a library of intent," Navan said, coining the phrase that would later appear in three blog posts and a conference talk. "You don't check out a book of code. You check out a book of what the code should be."
The patterns were composable. The authentication spec could be combined with the CRUD API spec and the webhook receiver spec to produce, in a single Attractor run, a fully functional authenticated REST API with event notifications. The agents understood the composition. The specifications were written to reference each other, to share terminology, to build on common definitions. The library was not just a collection. It was a vocabulary.
Most people didn't know the library existed. It wasn't prominently featured. It wasn't marketed. It sat in a subdirectory of a repository that most people browsed for the pipeline runner, not the specifications. Those who found it tended to find it by accident, or by following a link in the Discord, or by reading the fine print of the Attractor README.
"Should we promote it more?" Jay asked.
"No," Justin said. "The people who need it will find it. The people who find it will understand what it is. Marketing a library of intent to people who don't yet understand intent-driven development would just create confusion."
"So it grows by word of mouth."
"It grows by use. Every specification someone writes and contributes back makes the library more valuable. The incentive structure is self-reinforcing. We don't need to promote it. We need to make it excellent."
The library grew. Quietly. Steadily. Like something that had always been waiting to exist.
"A library of intent." Three words that describe the future of software development better than any manifesto I've read. Navan has a gift for naming things.