We published this repository just over a week ago. The project didn’t come together the way we originally planned.
Specifically, it came together through pain and suffering…
How it works
The repository is a set of SEO tools that run from the terminal and integrate with AI agents. You clone the repo into your project folder, open it in Claude Code, and you get SEO commands available as native agent skills. Type something like /nod-keyword-research "best CRM tools 2026", the agent queries Google through the API, returns keywords to a CSV, and you can keep going from there — ask it what to filter out, how to cluster results, which keywords are worth writing a brief for, and so on.
Under the hood, each skill runs Python scripts. The agent calls them following the instructions in SKILL.md, but you can also run them directly from the terminal without the AI agent.
The first version of the project was built by marketing (meaning me). The thinking was “we have Claude Code, who needs developers anymore”, so marketing delivers 80%, dev picks it up, polishes whatever needs polishing, and we ship.
TWO WEEKS, TOPS. EASY, RIGHT?
The first stop was the lawyer. He saw the MIT license and made clear that’s not how things work here. We’re a serious company — we can publish a public repo, but the documentation needed work and we needed a custom license. We went through several rounds of revisions, rewrote the README, the docs, and in some places the skills themselves. We spelled out what people can and can’t do with it. Progress was slow, but there was progress. By the time we wrapped up the licensing, we’d already burned through the two weeks we’d budgeted for the entire project. Great start.
Just a quick dev review and we’re done :)))
The real problems started when we enthusiastically decided that since we had Claude Code, we might as well add Python scripts to the SKILL.md files right away. From a marketing perspective, it made perfect sense. Claude handles things so well — why not generate production-ready scripts while we’re at it?
That was a mistake. We ended up with a set of scripts that worked on the author’s machine but had poor (or nonexistent) error handling, inconsistent dependencies, and were long and messy. Every skill did things its own way, and when dev took over, the team was not happy to put it mildly.
The marketing version worked, but it worked in a way that was hard to scale or maintain. From our side, those were details. From dev’s side, they were a threat to the infrastructure and a very irritating source of daily friction.
The disagreement came down to what “works” actually means. Marketing saw a working product. Dev saw a working prototype. In the end, the merge took longer than building it from scratch would have.
We eventually landed on a compromise. The product turned out well and can be built on further. The next PR, written properly this time, is already waiting in the dev queue.
Lessons learned
Assuming marketing can author the product while dev just wraps it up is a bold assumption. That approach requires clear processes and boundaries we simply didn’t have. Refactoring someone else’s working code is slower than starting fresh, especially when architectural decisions have to be renegotiated after the fact. If dev had been involved from the beginning with marketing in a product consultant role rather than primary author we would have shipped sooner despite everything.
On the plus side, we now have a clear picture of what marketing can deliver independently, what needs dev involvement from day one, and when to bring in legal. It’s at least a starting point for building proper processes.
If anyone’s interested in testing how this works, I’d love to hear feedback — it’ll help us keep improving things.
We published this repository just over a week ago. The project didn’t come together the way we originally planned.
Specifically, it came together through pain and suffering…
How it works The repository is a set of SEO tools that run from the terminal and integrate with AI agents. You clone the repo into your project folder, open it in Claude Code, and you get SEO commands available as native agent skills. Type something like /nod-keyword-research "best CRM tools 2026", the agent queries Google through the API, returns keywords to a CSV, and you can keep going from there — ask it what to filter out, how to cluster results, which keywords are worth writing a brief for, and so on.
Under the hood, each skill runs Python scripts. The agent calls them following the instructions in SKILL.md, but you can also run them directly from the terminal without the AI agent.
Details on the standard this was built on: https://agentskills.io/home
Now, to the point
The first version of the project was built by marketing (meaning me). The thinking was “we have Claude Code, who needs developers anymore”, so marketing delivers 80%, dev picks it up, polishes whatever needs polishing, and we ship.
TWO WEEKS, TOPS. EASY, RIGHT?
The first stop was the lawyer. He saw the MIT license and made clear that’s not how things work here. We’re a serious company — we can publish a public repo, but the documentation needed work and we needed a custom license. We went through several rounds of revisions, rewrote the README, the docs, and in some places the skills themselves. We spelled out what people can and can’t do with it. Progress was slow, but there was progress. By the time we wrapped up the licensing, we’d already burned through the two weeks we’d budgeted for the entire project. Great start.
Just a quick dev review and we’re done :)))
The real problems started when we enthusiastically decided that since we had Claude Code, we might as well add Python scripts to the SKILL.md files right away. From a marketing perspective, it made perfect sense. Claude handles things so well — why not generate production-ready scripts while we’re at it?
That was a mistake. We ended up with a set of scripts that worked on the author’s machine but had poor (or nonexistent) error handling, inconsistent dependencies, and were long and messy. Every skill did things its own way, and when dev took over, the team was not happy to put it mildly.
The marketing version worked, but it worked in a way that was hard to scale or maintain. From our side, those were details. From dev’s side, they were a threat to the infrastructure and a very irritating source of daily friction.
The disagreement came down to what “works” actually means. Marketing saw a working product. Dev saw a working prototype. In the end, the merge took longer than building it from scratch would have.
We eventually landed on a compromise. The product turned out well and can be built on further. The next PR, written properly this time, is already waiting in the dev queue.
Lessons learned
Assuming marketing can author the product while dev just wraps it up is a bold assumption. That approach requires clear processes and boundaries we simply didn’t have. Refactoring someone else’s working code is slower than starting fresh, especially when architectural decisions have to be renegotiated after the fact. If dev had been involved from the beginning with marketing in a product consultant role rather than primary author we would have shipped sooner despite everything.
On the plus side, we now have a clear picture of what marketing can deliver independently, what needs dev involvement from day one, and when to bring in legal. It’s at least a starting point for building proper processes.
If anyone’s interested in testing how this works, I’d love to hear feedback — it’ll help us keep improving things.