From patrick204nqh
Produces a short comparison table — 2–4 options against the same set of criteria — when the reader is making a decision and prose buries the differences. Make sure to use this skill whenever the user says "compare", "what's the difference", "X vs Y", "should I use A or B", "table this out", "side by side", or pastes parallel "X does this, Y does this" prose — even if they don't use those exact phrases.
How this skill is triggered — by the user, by Claude, or both
Slash command
/patrick204nqh:compare-tableThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Build a small table when the reader is choosing between things. Prose
Build a small table when the reader is choosing between things. Prose buries differences; a row-by-row scan reveals them.
Someone deciding. They want to glance down a column, glance down the next, and feel the contrast. They will not read a paragraph that says "X does A and Y does B and X also does C while Y…"
Trigger on any of:
Do not trigger when:
Two layouts. Pick before you draw.
| Shape | Use when | Header row | First column |
|---|---|---|---|
| Options-as-columns | 2–4 options, 4+ criteria | option names | criteria |
| Options-as-rows | many options, 2–4 criteria | criteria | option names |
Default to options-as-columns. It's how readers expect to compare. Switch to options-as-rows only when you have more than four options.
—, not "N/A" or "none". — reads
instantly; "N/A" stops the eye.**Takeaway:** [one sentence — what the reader should conclude]
| Criterion | Option A | Option B | Option C |
|---|---|---|---|
| [axis] | [≤5 words] | [≤5 words] | [≤5 words] |
| [axis] | [≤5 words] | [≤5 words] | [≤5 words] |
| [axis] | [≤5 words] | [≤5 words] | [≤5 words] |
[2-3 sentences: the caveat, the "it depends", the thing the table
cannot say.]
Bad (prose smuggling a table):
Postgres is a full relational database with strong concurrency and rich SQL features but you have to run it as a service. SQLite is a single-file embedded database that's trivial to deploy but has weaker concurrent-write performance. DynamoDB is fully managed and scales horizontally but locks you into AWS and a key-value model.
Good (takeaway + table + nuance):
Takeaway: Postgres for flexibility, SQLite for simplicity, DynamoDB for scale-without-ops.
| Criterion | Postgres | SQLite | DynamoDB |
|---|---|---|---|
| Deployment | Run as service | Single file | Fully managed |
| Concurrent writes | Strong | Weak | Strong |
| Query model | Full SQL | Full SQL | Key-value |
| Vendor lock-in | None | None | AWS only |
| Ops cost | Medium | None | Low |
If you're prototyping and may grow, start with Postgres — the cost of switching from SQLite later is real. DynamoDB only makes sense if you're already on AWS and know your access patterns.
npx claudepluginhub patrick204nqh/skills --plugin patrick204nqhCreates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.