DEV Community: Maryam Saba

We Tried to Build a Tiny CLI… And Accidentally Built a Whole Thing

Maryam Saba — Fri, 21 Aug 2026 18:19:07 +0000

Made with ❤️ by 2Nerds
The original idea was… ridiculously simple
We had a tiny idea: make a CLI that generates a cute little “Made with ❤️ by 2Nerds” tagline.
That was it.
No database.
No dashboard.
No auth.
No microservices.
No Kubernetes cluster that absolutely nobody asked for.
Just:
taggie
Answer a few questions.
Get a tagline.
Done.
Except… apparently humans are incapable of leaving a small idea alone.
Then we started asking “what if…?”
What if the CLI could actually put the tagline inside a real app footer?
Okay. Add that.
What if it detects whether the project is React, Next.js, Vue, Svelte, or plain HTML?
Sure.
What if there is no footer?
Then create one.
What if we create a Footer component?
Then wire it into the app automatically.
What if someone runs the command again?
Please don't duplicate the footer.
And that tiny requirement led us to one of the most important ideas in the project: idempotency.
Wait… what does idempotent even mean?
In Taggie terms, it basically means:
Run it once → add the attribution.
Run it again → don't create another one.
Run it 37 more times → still don't create 37 footers.
The result should converge to one correct state.
So instead of:
Made with ❤️ by 2Nerds
Made with ❤️ by 2Nerds
Made with ❤️ by 2Nerds
Made with ❤️ by 2Nerds
…Taggie updates its own block in place.
Because apparently even a footer needs boundaries.
Then came --check
Once Taggie could modify projects, we realized we needed a way to ask:
“Is this project actually configured correctly?”
So we added:
taggie --check
It is completely read-only.
It detects the framework, finds the footer, checks Taggie's attribution, and reports whether everything matches the configured standard.
It also returns meaningful exit codes, which means it can be used in CI.
So now Taggie wasn't just generating text.
It was checking project state.
Then came configuration
Typing the same flags every time gets old very quickly.
So we added taggie.config.json.
For example:
{
"by": "2Nerds",
"for": "Acme",
"emoji": "❤️",
"template": "byline"
}
Now the project has a defined attribution standard.
We also added profiles for cases like open-source projects:
taggie --sync --profile opensource
And CLI arguments can override configuration for a single run without modifying the config file.
Because configuration precedence is apparently a thing we care about now.
And then we built --sync
This was the point where the original “tiny tagline generator” had officially left the building.
taggie --sync
Sync means:
• add the attribution if it is missing
• update it if it is outdated
• do nothing if it is already correct
In other words, the project converges to the desired state.
Run it once.
Run it again.
Run it from CI.
Run it tomorrow.
Same correct result.
We also added --dry-run because trust issues are healthy
Before a CLI modifies your source code, it is reasonable to want to know what it is about to do.
So:
taggie --sync --dry-run
doesn't write anything.
It just tells you what WOULD happen.
Same idea for removal:
taggie --remove --dry-run
No files sacrificed for the greater good.
Then we realized people have… multiple projects
Naturally, someone eventually wants to run the same operation across several projects.
So Taggie supports:
taggie --sync ./projects/*
Each project is handled independently.
If Project A succeeds and Project B has a broken config, Project A doesn't suddenly become collateral damage.
Taggie keeps each target isolated and refuses to write outside the directory it was given.
Tiny CLI.
Suspiciously serious safety rules.
We even made it friendly to coding agents
This part was probably inevitable in 2026.
You can run:
taggie --init-skill
and configure integration for Claude Code or other coding agents through AGENTS.md.
The idea is simple:
Instead of manually editing a Taggie-managed attribution block, tell your coding agent to add, check, sync, or remove the attribution.
The agent uses Taggie's lifecycle instead of randomly editing files.
Because “let the AI edit my source code” becomes slightly less terrifying when the tool has explicit boundaries.
Safety became a whole section
At some point, we stopped thinking:
“How do we make this work?”
and started thinking:
“How do we make this NOT destroy someone's project?”
So Taggie follows a few rules:
• It doesn't blindly overwrite source files.
• It only updates content inside its own marker block.
• --check never writes.
• --dry-run never writes.
• --remove doesn't delete a Footer component it created.
• Multi-project sync stays inside each target directory.
• Unsupported structures are reported instead of guessed at.
Basically: if Taggie isn't confident it can safely modify something, it refuses.
The final result
The funny part is that we started with:
“Let's make a CLI that generates a cute footer.”
And ended up with:
• interactive generation
• framework detection
• footer injection
• automatic component creation
• automatic wiring
• configuration
• profiles
• check mode
• sync mode
• multi-project sync
• dry-run support
• safe removal
• CI support
• coding-agent integration
• idempotent updates
• project-root safety
• tests for all the boring edge cases we absolutely needed
At some point we looked at the project and thought:
Wait.
This is not a tagline generator anymore.
What I actually learned from building it
The biggest lesson wasn't “how to make an npm CLI.”
It was learning to think about tools as systems instead of scripts.
A script asks:
“How do I make this happen?”
A useful developer tool also asks:
“What if it runs twice?”
“What if the config is broken?”
“What if the project is structured differently?”
“What if the user changes the generated code?”
“What if the target doesn't exist?”
“What if there are ten projects?”
“What if this runs in CI?”
“What if the safest thing is to do nothing?”

Those questions are where a tiny project starts becoming a real engineering project.
And honestly, that was the fun part.
Where we are now
Taggie is published as taggie-cli on npm and can be used locally or through npx.
The goal isn't to pretend we've invented the next Git.
We just wanted a small developer utility that solves one annoying problem cleanly, safely, and without requiring a dashboard, account, or another SaaS subscription to exist in our lives.
Two nerds.
One tiny idea.
Way too many edge cases.
Classic.

Final thought

If you ever start a project saying:
“It's just a small CLI.”
Please know that I am quietly judging you.
Because we did the same thing.
And look where that got us.

Last but not least:

🔗 Give it a spin & show some love!

NPM Package: npx taggie-cli
GitHub Repo: github.com/2nerds/taggie

XML Tagging in Prompts: The Secret to Getting Better Output from Claude and GPT

Maryam Saba — Mon, 03 Aug 2026 20:39:43 +0000

XML Tagging in Prompts: The Secret to Getting Better Output from Claude and GPT

A simple structuring trick that turns messy, unpredictable LLM outputs into clean, reliable ones.

If you've spent any time writing prompts for Claude, GPT, or any other large language model, you've probably hit this wall: your prompt works fine for a simple ask, but the moment you pack in multiple instructions — some context, a few examples, formatting rules, and the actual task — the model starts mixing things up. It answers the wrong part of the question. It ignores your formatting instructions. It treats your example output as part of the actual task.

The fix is almost embarrassingly simple: wrap your prompt sections in XML tags.

Why XML Tags Work So Well

LLMs are trained on enormous amounts of code, documentation, and markup. XML (and HTML) syntax is deeply embedded in that training data, which means models are very good at recognizing where one tagged section ends and another begins. Unlike plain paragraphs — where the boundary between "here's my context" and "here's my instruction" is fuzzy — a tag creates an unambiguous boundary.

Anthropic actually recommends this explicitly for Claude: wrapping distinct parts of a prompt (instructions, context, examples, output format) in tags like <instructions>, <context>, <example>, and <output_format> measurably improves consistency, especially in longer or more complex prompts.

Think of it like the difference between handing someone a wall of text versus handing them a form with labeled fields. Both contain the same information, but one is far easier to parse correctly — for a human, and for a model.

A Before-and-After Example

Without tags:

Summarize the article below in 3 bullet points. Keep it under 50 words.
Use a neutral tone. Here's an example of the style I want:
"- Company X raised $10M in Series A funding."
Now here's the article: [long article text]

The model has to guess where the instructions end and the article begins — and with a long article, it sometimes starts summarizing the example instead of the real content.

With tags:

<instructions>
Summarize the article in 3 bullet points, under 50 words total.
Use a neutral tone.
</instructions>

<example_style>
- Company X raised $10M in Series A funding.
</example_style>

<article>
[long article text]
</article>

Now there's zero ambiguity. The model knows exactly what's an instruction, what's a style reference, and what's the raw content to work on.

Common Tags Worth Using

You don't need a formal schema — these are just semantic containers the model can recognize. Some of the most useful:

<instructions> — the actual task
<context> — background info the model needs but shouldn't act on directly
<example> / <examples> — sample inputs/outputs (few-shot prompting)
<document> or <article> — source text to analyze/transform
<output_format> — exactly how you want the response structured
<thinking> — for models that support step-by-step reasoning before the final answer

You can also nest them, e.g., multiple <document index="1">, <document index="2"> blocks when feeding several sources at once — attributes work too, and models parse them correctly.

Bonus: Ask for Tagged Output Too

This trick isn't just for input — you can ask the model to return its answer in tags, which makes parsing the response programmatically trivial:

<answer>
Your final response here.
</answer>
<confidence>high</confidence>

If you're building this into an app (say, a Next.js API route calling the AI SDK), this turns a fragile "hope the model formats it right" problem into a simple string-extraction problem — no need for a full JSON schema when you just need one or two fields.

When Not to Bother

For a single, simple instruction ("Translate this to French"), tags are overkill — they add noise for no benefit. Reach for XML tagging when your prompt has multiple distinct components that could be confused with each other: instructions + context + examples + a document to process, all in one message.

Takeaway

XML tagging isn't a hack — it's closer to good API design applied to prompts. You're giving the model an explicit contract instead of hoping it infers your intent from prose. The next time a prompt feels like it's "almost working," try wrapping its parts in tags before you start rewriting the wording. Often, structure — not phrasing — was the actual problem.

I built an AI bestie for my Dad’s morning routine ⚡️☀️

Maryam Saba — Sat, 03 Jan 2026 17:50:03 +0000

Main Character Energy for your Mornings! ☕️✨

I lowkey got tired of seeing my Dad head to the office stressed, so I built something special. I created an AI Morning Reminder n8n template that sends a healthy, motivational, and straight-up high-vibe quote every morning before he leaves.

It’s basically a daily dose of "You got this!" delivered straight to his phone. 📈

Why you need this in your life:

Parental W: Set it up for your parents to make their day. 🧿

Main Character Vibes: Use it for yourself to stay locked in on your goals. 🎯

Fully Automated: Set it once and let the AI do the heavy lifting while you sleep. 😴

No More Boring Mornings: Start the day with clarity and energy instead of a random notification dump.

I’m dropping the template so you guys can use it too! Whether it’s for your own growth or to make your family smile, this is the ultimate productivity + mood hack. 🥂