refactor: collapse the three HTML skills into one effective-html router#6
refactor: collapse the three HTML skills into one effective-html router#6kylesnowschwartz wants to merge 2 commits into
Conversation
Merge the html, html-diagram, and html-plan skills into a single effective-html skill that routes between artifact, diagram, and plan modes. The three skills shared an identical reference corpus and the same dark-mode requirement, and each bundled its own copy of references/html-effectiveness/, so this dedups ~24k lines of duplicated examples. - New skills/effective-html/SKILL.md routes by mode (artifact / diagram / plan) - Single references/html-effectiveness/ plus architecture-example.html - Drop disable-model-invocation so the model can reach for it - Update plugin.json, marketplace.json, skills.sh.json, and README
Point the codex agent interface at $effective-html covering all three modes, and enable implicit invocation to match dropping disable-model-invocation on the Claude side. Update the codex manifest description.
|
Okay, this is a fair change. I'll review this weekend seems like a fine approach though |
|
Howdy - checking up on this, as I keep sharing my fork instead of the canonical repo and I'd rather share yours! In my fairly heavy usage, the single-router design has worked really well. One effective-html skill that routes to artifact, diagram, or plan mode, instead of three separate skills. It triggers, and routing to the right mode from one entry point has been easier than picking between three skills. The PR shows conflicts against main now, since both the fork and upstream got new commits since June. Let me know if you'd like to entertain this more and I can rebase (my fork now includes a fix to floating windows so they don't overlap other content as much) |
2 participants
Thanks for this plugin, and for Plannotator, they're really effective.
I've got a suggestion, and I think it applies to your other plugins too: make the skills model-invokable, and at the same time fold very similar skills into one routing-table skill with a single, broader description.
Here's my reasoning.
Right now the three HTML skills are command-only (
disable-model-invocation: true), so I have to know to type/html-diagram. That works, but it puts the routing on me. If the skill is model-invokable I can just say "make me an HTML file that..." and the right mode fires on its own.The catch is that model-invocation and three-separate-skills don't sit well together. While they're command-only the overlap is harmless, I pick the one I want by name. But once the model is choosing, three descriptions that all say "produce an effective HTML artifact" compete for the same job. That costs context budget and lowers activation, the model's picking between near-identical descriptions so it's likelier to land on the wrong mode, or none. Folding them into one skill with a mode table sorts that out: one description gets the skill to fire, then the table picks artifact vs diagram vs plan.
Separately, and regardless of the above, the examples were literally triplicated. Each skill carried its own byte-identical copy of the
html-effectiveness/corpus (I checked withdiff -r), so the repo held three copies of the same ~25 files.What's in the PR:
effective-htmlskill with a routing table (artifact / diagram / plan) over shared setup. Each mode keeps its original guidance, including the diagram's pointer toarchitecture-example.htmland the plan's "keep the writing close to the input" note.references/html-effectiveness/plusarchitecture-example.html, dropping the two duplicate copies (~24k lines). The reference content itself is untouched..claude-plugin/plugin.json,marketplace.json,skills.sh.json, the codex.codex-plugin/plugin.json, andagents/openai.yaml.