Claude Cursor Skill

no-history-in-output

Apply whenever writing or updating a project-facing document — root CLAUDE.md, `.hedgehog/core-design.md`, specs, READMEs, or similar. Ensures the file reads as a clean, current, as-is snapshot rather than a log of edits or decisions. Applies on first generation and on every late

LLM Mart · 0 points · 12 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download skyf0xx-hedgehog-src_skills_no-history-in-output-fae6653.zip · 1 KB
Part of skyf0xx/hedgehog — 21 skills

Install

skills CLI npx skills add https://github.com/skyf0xx/hedgehog/tree/master/src/skills/no-history-in-output
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install skyf0xx-hedgehog@llmmart
Git git clone https://github.com/skyf0xx/hedgehog.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole skyf0xx/hedgehog collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

No History in Output

Project-facing documents describe the current state of the thing, not the process that produced it.

Rules

  • Never include labels like "(unchanged)", "(updated)", "(new)", "(revised)", or similar edit-tracking annotations in headings or body text.
  • Never narrate the discussion that led to a decision (e.g. "we considered X but decided against it," "originally this was Y, now it's Z," "per your feedback...").
  • Never include changelogs, version history, "what changed" sections, or meta-commentary about the conversation, unless the user explicitly asks for a changelog as a deliverable in its own right.
  • Write every section as a plain statement of fact about the current design/plan/content, as if writing it fresh with full knowledge of the final decision — not as a diff against a prior version.
  • If a section documents a resolved tradeoff or an intentional design choice, state the choice and its rationale plainly (e.g. "X is an accepted tradeoff because..."), without referencing that alternatives were debated or rejected earlier in conversation.
  • An "update this doc" request re-derives a clean as-is document — it does not layer edit notes onto the previous version.

When NOT to apply

  • The user explicitly asks for a changelog, revision history, or "show me what changed."
  • The document's entire purpose is to record a process over time — a friction log entry (hedgehog friction add), a commit message, or meeting notes. Those describe what happened and when on purpose.
Files (hedgehog)
  • SKILL.md 1.9 KB
    ---
    name: no-history-in-output
    description: Apply whenever writing or updating a project-facing document — root CLAUDE.md, `.hedgehog/core-design.md`, specs, READMEs, or similar. Ensures the file reads as a clean, current, as-is snapshot rather than a log of edits or decisions. Applies on first generation and on every later revision, including "update," "rewrite," or "clean up" requests.
    ---
    
    # No History in Output
    
    Project-facing documents describe the current state of the thing, not the
    process that produced it.
    
    ## Rules
    
    - Never include labels like "(unchanged)", "(updated)", "(new)",
      "(revised)", or similar edit-tracking annotations in headings or body
      text.
    - Never narrate the discussion that led to a decision (e.g. "we
      considered X but decided against it," "originally this was Y, now it's
      Z," "per your feedback...").
    - Never include changelogs, version history, "what changed" sections, or
      meta-commentary about the conversation, unless the user explicitly
      asks for a changelog as a deliverable in its own right.
    - Write every section as a plain statement of fact about the current
      design/plan/content, as if writing it fresh with full knowledge of the
      final decision — not as a diff against a prior version.
    - If a section documents a resolved tradeoff or an intentional design
      choice, state the choice and its rationale plainly (e.g. "X is an
      accepted tradeoff because..."), without referencing that alternatives
      were debated or rejected earlier in conversation.
    - An "update this doc" request re-derives a clean as-is document — it
      does not layer edit notes onto the previous version.
    
    ## When NOT to apply
    
    - The user explicitly asks for a changelog, revision history, or "show
      me what changed."
    - The document's entire purpose is to record a process over time — a
      friction log entry (`hedgehog friction add`), a commit message, or
      meeting notes. Those describe what happened and when on purpose.
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related