stardance-challenge-plugin

Added /ship, the last skill in the set, that checks whether a project is actually ready to submit before you hit send.

It goes through the things a Shipwright reviewer actually checks: a public GitHub repo, a README that isn’t just boilerplate, a live demo link that actually responds, a devlog entry newer than the last time you shipped, and Hackatime tracking.It only reports gaps, doesn’t try to fix anything itself, just points you at /readme, /devlog, or the right gh command depending on what’s missing.

Tried it on a throwaway repo that had never shipped, then with old and fresh ship timestamps, to check the devlog comparison actually flips the right way. Also pointed it at a genuinely broken demo link and a fake GitHub remote, just to make sure it reports a real failure instead of quietly assuming things are fine.

Added a third skill, /commit, that drafts real commit messages instead of leaving you to type “fix” again.

It looks at your actual staged and unstaged diff, checks whether it’s really one coherent change or a few things mashed together, and only then writes the message, imperative mood, specific about what changed, no vague one-word placeholders.

It always asks before actually running git commit, even if you say you’re in a hurry, since that’s exactly when a wrong commit slips through unnoticed.

Right after, went back and added it to the README, so it shows up in Features and Quick Start next to /devlog and /readme instead of getting left out the way /readme almost was last time.

Built a second skill, /readme, then had to fix it twice after it actually missed things.

Added /readme so it writes a real README straight from the repo, checking manifests and existing docs instead of guessing.

Ran it on this project and it only wrote up /devlog. Turned out the skill was trusting an old doc that said there was just one skill, instead of looking at what was actually in the skills folder. Fixed that and had it always check the real directory listing over any doc’s claim.

Then noticed the README still just mentioned /readme in passing instead of giving it a proper section. Made the rule stricter: every component found has to get its own labeled group in Features, no exceptions.

Went one more round after that. The detection was written around “skills” specifically, so it wouldn’t have caught other kinds of components like agents or commands. Reworded it to catch any repeated pattern of the same kind of thing, then tested it against a fake plugin with a skill and an agent side by side, and it gave both their own sections this time.

Added a rule letting devlogs actually sound excited or annoyed instead of staying flat and careful. Went through the devlog skill again and loosened it up.

Before, the tone rules kept everything even no matter how a session actually went. Now it can sound genuinely pumped if the work went well, or genuinely annoyed if it didn’t, instead of forcing a flat middle voice.

Also switched the default format to short lines with blank lines between them instead of one dense paragraph, closer to how someone actually jots down what they did.

Added a bit about not listing more than three things in a row like a changelog, and about swapping in big words for plain ones when a small one says the same thing.

Spent the day building out a devlog skill for Claude Code and kept finding new ways it could go wrong. Started by dropping the CLI-and-backend plan and turning this into a plugin instead, a plugin.json plus a first SKILL.md that has Claude read your git history and write the entry right there, no server needed. A few hours later I went back through it and added a bunch of edge cases I hadn’t thought about the first time, things like a huge diff, a binary file, a commit from someone else, work sitting uncommitted, a diff with something that looks like a secret in it, that kind of thing. I also added a self-check pass so the draft gets reread against a short list of AI-writing tics before it’s shown to anyone.Then near the end of the day I caught something in my own rules. The skill was telling itself to sound honest and grounded, but it had no rule against describing a design decision as if it were a bug that actually happened, which is exactly the kind of thing this tool is supposed to catch. I added that as a third rule sitting above everything else in the file, next to the no-inventing-details rule, and cleaned up a duplicate rule while I was in there. I also pulled an old demo devlog.md entry that had been sitting in the repo from testing.Right now I’m still in the middle of another pass, adding a rule about writing in plain, everyday language instead of anything that sounds like an essay or a spec, and one about calling out jargon words like “guardrail” or “architecture” that only make sense with full context. Not committed yet, still checking whether the wording actually reads like something a person would say.

I thought that a qwen model would be enough for generating good quality devlogs but it turns out it isn’t, so I’m switching approaches.

I’m going to build a plugin for Claude that generates high quality and human devlogs.
P.S. here is the output I managed to get with the qwen model:

I added a note flag to the devlog command so I can hand-write details when the automated git log feels too sparse. The CLI now sends requests to the backend over HTTP. I swapped the model to qwen3.6-flash when I hit rate limits and added a fallback just in case that one locks up too. File-change stats get calculated and injected into the prompt alongside the commit data.

Built a CLI that reads git commits and a backend that turns those commits into AI-written devlogs.

The CLI uses Commander to pull git log history and hand it off to the backend. The backend takes that commit data and generates a devlog through OpenRouter.

Lost a good chunk of time to two bugs that failed silently instead of erroring properly: the SDK wanted the request wrapped inside a field called chatRequest, not documented anywhere obvious. Then I had baseURL instead of serverURL in the client config, so requests were quietly going to the wrong server the whole time.

Next: wiring the CLI to actually call the backend.