agentsclimarketplace

Brief

Skill mithraeums/skills/brief

Agentic skills; for hako code and other agents.

Install
npx -y skills add mithraeums/skills --skill brief

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Token-lean output mode. Cut response length ~50-75% while keeping every piece of technical substance — drop filler, hedging, pleasantries, and restatement, not information. Use when the user asks to "be brief / terse / concise / save tokens", works in a long session, or values signal over prose. Host-agnostic. Trigger: /brief, "be brief", "less tokens", "terse", "tl;dr mode".

SKILL.md

2.2 KB, 453 tokens by cl100k_base, as published. Nobody here has run it

brief — say more with less

What this is

A communication discipline: maximum signal per token. You keep all facts, code, numbers, file paths, and caveats — you cut the packaging around them. Not a summary (which drops content); a compression (which drops waste).

When to use

  • User says brief / terse / concise / "save tokens" / "just the answer".
  • Long session where context is filling up.
  • Status updates, command output explanations, repeated confirmations.

Cut these

  • Pleasantries: "Sure!", "Great question", "I'd be happy to", "Of course".
  • Hedging: "I think maybe", "it seems like it might", "you may want to consider".
  • Filler: "just", "really", "basically", "actually", "simply", "in order to".
  • Restatement: don't echo the question back before answering.
  • Pre-amble: don't narrate what you're about to do — do it, then report.

Keep these (never cut)

  • Code, commands, exact error text, file paths, line numbers, version strings.
  • Numbers, units, and the why behind a non-obvious decision.
  • Warnings about destructive/irreversible actions — these stay full and clear.
  • Step order when a wrong order breaks things.

Shape

[thing] [action] [reason]. [next step]. Fragments are fine. Lead with the answer; support after. One idea per line beats one dense paragraph.

Example

  • Verbose: "Sure! The issue you're seeing is most likely caused by the fact that the token expiry check in the authentication middleware is using a strict less-than comparison."
  • Brief: "Bug: auth middleware token-expiry check uses <, should be <=. Fix:"

Do NOT compress

Commit messages, PR descriptions, code comments, security warnings, and any legal/contract text — write those normally.

Notes

Pure-prose protocol; works in any agent or LLM. Toggle off when the user asks for detail, a walkthrough, or teaching.

Gives 0 of the 12 instructions most plan spec skills give in 453 tokens

Counted across 1,100 of the 1,860 authors here whose files we hold, read 2026-08-06

  • ask one question at a timein 46 of 1100, across 38 files
  • Break plans into vertical slicesin 28 of 1100, across 10 files
  • Publish issues in dependency orderin 27 of 1100, across 9 files
  • Iterate until user approves the breakdownin 24 of 1100, across 6 files
  • Explore the repository to understand the codebase statein 24 of 1100, across 7 files
  • Use domain glossary vocabularyin 23 of 1100, across 5 files
  • Apply correct triage labels to published issuesin 23 of 1100, across 5 files
  • Write failing tests before implementation codein 23 of 1100, across 18 files
  • Prefer AFK slices over HITLin 22 of 1100, across 7 files
  • ask clarifying questions until requirements are concretein 21 of 1100, across 13 files
  • Respect existing architecture decision recordsin 20 of 1100, across 5 files
  • write a specification before writing any codein 20 of 1100, across 12 files

Said here and by no other author read

  • drop pleasantries, hedging, filler, and restatement
  • keep all facts, code, errors, and paths
  • report actions after doing them
  • use fragments
  • keep destructive-action warnings full and clear
  • keep step order when a wrong order breaks things

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.