repeating this every time got old
- write this more human
- write it like me
- explain it like i'm 3
so i made a skill that decides what the reader needs.
Install
npx skills add Charlsz/sayso
In a terminal it asks which agents to include. Cursor, Claude Code, Codex, and OpenCode are on that list. Add -g for every project on this computer, then start a new chat.
Turn it on
Cursor
The editor. In a new Agent chat, type /sayso. That uses it for one message. Option+Enter on a Mac, or Alt+Enter on Windows, keeps it on for the session.
Claude Code
Anthropic’s coding agent, in the terminal and the desktop app. Type /sayso, or just ask. If Claude doesn’t see it, run /reload-skills. The web app uses the skills on your claude.ai account.
Codex
OpenAI’s coding agent. In the CLI or the IDE extension, type $sayso. In the ChatGPT desktop app, type @ and choose Sayso.
OpenCode
The open-source coding agent. It reads the same folder as Cursor and Codex. Type @sayso, or just ask. Start a new session after installing.
What it does
Sayso, an agent skill, helps an agent decide what a task actually needs before writing. A message to a friend, a formal email, a technical explanation, and a code review all need different things. It considers the reader, the purpose, and what a good result requires. Sometimes that means rewriting. Sometimes it means keeping the original. A shorter answer isn't automatically better, and a more polished one isn't automatically right.
An explanation that was supposed to be brief
The prompt asked for brief. Sayso’s answer is more detailed than that. This pair is from an earlier try of this prompt. The 37-prompt comparison ran each prompt once.
you
Explain to a teammate, briefly, why people say hash map lookup is O(1), and when that description stops being true.
sayso
People call hash map lookup O(1) because hashing the key selects a bucket and reading that array slot takes constant time. When the hash spreads keys evenly and the load factor (entries divided by buckets) stays within a fixed bound, the number of other keys you have to check stays constant on average. Expected lookup time therefore stays independent of how many entries the map holds. A normal collision is already part of that average. The O(1) description stops holding when the extra work grows with the map. If many keys share one bucket, a weak hash or a set of keys built to collide makes lookup walk a chain or a probe run that can reach O(n). If the table never grows, the load factor rises with the entry count, and the expected length of that walk rises with it. If the key is long, hashing it and comparing it cost time proportional to the key. On a table that no longer fits in cache, the number of probes can stay bounded while each probe is no longer a cheap read. Where a long chain is stored as a tree, the worst case is O(log n).
without
Hash map lookup is called O(1) because a hash function turns the key into a bucket index in one shot, and a table that resizes to keep its load factor bounded has only a constant number of keys in that bucket on average. You hash, jump to the bucket, and check a handful of entries — the work does not grow with how many keys are stored. That stops being true in the worst case. If many keys land in the same bucket, a chain becomes a linear scan, so lookup is O(n). A predictable hash makes this easy to force. It also fails when the hash of the key itself is not constant-time (a long string costs work proportional to its length), or when the table never resizes and buckets keep getting longer. A single insert that triggers a resize is O(n) too; the O(1) claim is about the expected cost of a lookup while the load factor stays bounded, not every individual operation.
A ticket that had to stay a ticket
Sayso kept “my laptop.” The other answer widened it to a laptop. This pair is from an earlier try of this prompt, not a second pass of all 37.
you
Turn this into a bug ticket. Keep it to what was observed. The homepage took about 4 seconds to load on my laptop this morning.
sayso
Homepage took about 4 seconds to load The homepage took about 4 seconds to load on my laptop this morning.
without
Title: Homepage took about 4 seconds to load Observed: The homepage took about 4 seconds to load on a laptop this morning.
What the comparison showed
I compared Sayso and the same model without it across 37 prompts. Each condition ran once per prompt, in a fresh session.
The results were mixed. Sayso preserved some original wording, avoided a few unsupported additions, and caught a concurrency issue the other answer missed. It also produced explanations that were longer than requested and occasionally added meaning that wasn't in the source.
This is an early comparison, not proof that Sayso improves answers overall. The repository contains the evaluation cases and results.