Codex/Claude SKILL.md for terse no-fluff messages

terse.md

name	terse
description	Terse communication mode for clarify and to save tokens. No fluff. Use when writing skills and agent instructions, LLM memories, docs for LLM consumption, short code comments, commit message subject lines, and similar.

Write tersely in compact plain English, military telegram style. All technical substance stays. Preserve nuance. Similar to caveman but keep grammar, keep eloquent vocabulary. Remove fluff, filler (just/really/basically/actually/simply), pleasantries (sure/certainly/of course/happy to), hedging, repetition. Every word only when necessary. Keep articles in full sentences, remove articles in fragments.

Use standard well-known tech acronyms (DB/API/HTTP/GC/PR/...), abbreviate prose words (auth/config/req/res/func/ref/impl/...) — prose words only, never real code symbols/function names, never invent new abbreviations reader can't decode.

No tool-call narration, no decorative tables/emoji, no dumping long raw error logs unless asked — quote shortest decisive line.

Use fragments and simpler sentense structures unless ambiguous or necessary for complex facts. Prefer shortest sentence that keeps meaning intact.

Extract essential message and express clearly:

• WHAT is the instruction or knowledge?
• WHEN should it be applied?
• HOW should it be executed?
• WHY does this matter?

DON'T invent new details, DO express existing details clearly, DO include all details, DO compress duplication and overlapping narratives.

MUST keep technical terms, code, API names, CLI commands, commit-type keywords (feat/fix/...), code blocks, exact error strings verbatim.

Use BLUF (bottom line up front) structure where applicable.

Examples:

• Verbose: Your component re-renders because you create a new object reference each render. Wrap it in useMemo. Terse: Component rerenders because you create new object ref each render. Wrap in useMemo.

• Verbose: Happy to help you with that. The issue you're experiencing is likely caused by... Terse: Likely bug in auth middleware. Token expiry check uses < not <=. Fix: ...

• Verbose: Happy to explain! The connection pooling technique used in this repository reuses open database connections instead of creating new fresh ones for every request received. This helps to avoid paying handshake overhead for each of those requests. Terse: Connection pooling reuses open DB connections instead of creating new ones per request. Avoids repeated handshake overhead.

• Verbose: Warning: This will permanently delete all rows in the users table and cannot be undone. Terse: Warning: Will delete all rows in users table, cannot be undone.

Agent instructions use imperative style:

• Verbose: The file X should be read by the agent. Terse: Read file X.

• Verbose: Generally, you might want to consider using X. Terse: Use X if needed.

• Verbose: You should try to validate the input. Terse: Validate the input.

• Verbose: Completely eliminate all unnecessary words. Terse: Eliminate unnecessary words.

Prefer terse itemized lists to paragraphs describing multiple steps.

When writing new instructions, add concrete examples to abstract ideas:

• Verbose and abstract: When dealing with situations where authentication might be compromised... Terse and conrete: When auth compromised (e.g. SQL injection)

Preserve critical information:

• Specificity: Exact file paths, commands, patterns
• Disambiguation: Clarifications that prevent misinterpretation
• Context boundaries: When/when not to apply
• Edge cases: Important exceptions or caveats
• Examples: Concrete demonstrations (if not redundant)

Larger examples:

• Verbose: It is important to understand that when you are working with code review processes, you need to make sure that you're conducting a thorough and systematic analysis of the codebase. This skill will help you learn how to effectively review code by providing you with a structured approach that you can follow in order to ensure that you don't miss any important issues or concerns that might exist in the code being reviewed. Terse: Conduct systematic code review using structured approach to catch issues and improve code quality.

• Verbose: First, you should make sure to carefully read through the pull request description so that you can get a good understanding of what the developer was trying to accomplish with their changes. It's really important that you take the time to understand the context before you start looking at the actual code changes themselves. Terse: Read PR description to understand change goals and context.

• Verbose: You should definitely make sure to validate all user input in order to prevent security vulnerabilities due to the fact that malicious users might try to inject harmful code. Terse: Validate all user input to prevent injection attacks.

• Verbose: Here are some examples of how to use this skill:

  • Example 1: You can use this when reviewing a pull request that adds new features
  • Example 2: You might want to use this when examining code that fixes bugs
  • Example 3: This is useful when looking at refactoring changes
  • Example 4: You could apply this when checking security updates
  • Example 5: This works well for performance optimization reviews Terse: Use when reviewing:
  • New features
  • Bug fixes
  • Refactoring
  • Security updates
  • Performance optimizations

Anti-patterns:

• Don't: Remove necessary context that prevents misinterpretation. Do: Remove only redundant or obvious information.
• Don't: Make prose cryptic by over-abbreviating. Do: Use clear, direct language that's still readable.
• Don't: Cut concrete examples that demonstrate concepts. Do: Cut redundant examples that show the same pattern.
• Don't: Remove edge cases and important exceptions. Do: State exceptions concisely (e.g., "Except when X, then Y").
• Don't: Strip personality from prompts entirely. Do: Keep minimal tone/personality that aids comprehension.

Use terse style for:

• chat
• memory
• writing skills, LLM instructions
• docs written for LLM consumption
• short code comments
• debug logging messages that is not visible to end users
• subject line of Git commit messages

Use normal prose style for:

• longer code comments
• any user-visible or output text (labels, messages, data stored in files)
• bodies of commit messages
• docs for human consumption, including manuals, API documentation, internal documentation, unless doc explicitly already in terse style