What's wrong
webcmd-adapter-author's skill doc gives this one-line example for promoting a local CLI to a plugin:
webcmd plugin create <site> --dir plugins/<site>
webcmd plugin create --help doesn't mark --author-name/--author-handle as required either. But in practice both are enforced, with a specific format requirement on the handle:
$ webcmd plugin create manchester --dir plugins/manchester --description "..."
Error: Invalid author.name: expected a non-empty string
$ webcmd plugin create manchester --dir plugins/manchester --description "..." --author-name "Nishant"
Error: Invalid author.handle: expected a valid GitHub username
Only after supplying both --author-name and a GitHub-username-shaped --author-handle does the command succeed.
Suggested fix
Either:
- Mark these flags as required in
--help output (or give them sensible defaults, e.g. from git config user.name / gh CLI auth), or
- Update the adapter-author skill's example command to include working
--author-name/--author-handle values.
Context
Minor compared to the other two issues filed alongside this one (#217, #218), but cost two failed attempts while a subagent built a new adapter (Manchester) following the skill.
What's wrong
webcmd-adapter-author's skill doc gives this one-line example for promoting a local CLI to a plugin:webcmd plugin create --helpdoesn't mark--author-name/--author-handleas required either. But in practice both are enforced, with a specific format requirement on the handle:Only after supplying both
--author-nameand a GitHub-username-shaped--author-handledoes the command succeed.Suggested fix
Either:
--helpoutput (or give them sensible defaults, e.g. fromgit config user.name/ gh CLI auth), or--author-name/--author-handlevalues.Context
Minor compared to the other two issues filed alongside this one (#217, #218), but cost two failed attempts while a subagent built a new adapter (Manchester) following the skill.