AgentSkillsCN

infocompressor

当用户需要在保留所有关键细节的前提下,对冗长的内容进行压缩、精简或概括时使用此功能。可通过“压缩这个”“让它更短但保留全部内容”“制作一份备忘录”“密集摘要”“参考格式”“紧凑版”“信息密集”。不适用于随意的摘要——只有当用户明确希望在零数据丢失的情况下实现最高密度时才使用此功能。

SKILL.md
--- frontmatter
name: infocompressor
description: |
  Use when the user needs to compress, condense, or summarize lengthy content while preserving ALL
  critical details. Triggers: "compress this", "make it shorter but keep everything", "create a
  cheat sheet", "dense summary", "reference format", "compact version", "information-dense". NOT
  for casual summaries—only when user explicitly wants maximum density with zero data loss.

Text Compression Skill

Transform verbose documents into dense, human-readable reference specs.

Core Principles

  • Style: Spec/reference guide — imperative, terse, scannable
  • Format: Markdown with minimal nesting
  • Redundancy: Zero. State each fact once.
  • Notation: Plain language with minimal intuitive symbols.
  • Target: 40-60% reduction for most technical documents.
  • DRY: Don't repeat. Reference existing docs instead of duplicating.
  • Progressive disclosure: Link to details, don't inline everything.

Referencing Other Documents

When information exists elsewhere, reference it — don't copy it.

Syntax:

  • @DocumentName — mention another doc in same system
  • [Label](URL) — link to external resource
  • Imperative prefix: "Read @Auth for token handling"

Patterns:

Instead of...Write...
Copying auth flow from another doc"Auth flow: Read @Authentication"
Repeating error format spec"Error format: See @APIConventions#errors"
Duplicating setup instructions"Setup: Follow @GettingStarted first"

When to reference vs inline:

SituationAction
Info exists in canonical sourceReference it
Info is 1-2 lines, critical to flowInline it
Reader needs context to proceedInline minimum, reference full
Info changes frequentlyReference (single update point)

Example:

markdown
## Create Order

Purpose: Submit new order for processing

`POST /orders`

Prerequisites: Read @Authentication for token setup

**Input:**
- items: array of {sku, qty}
- shipping: address object (see @DataTypes#address)

**Flow:**
Validate → Check inventory (@InventoryService) → Reserve → Confirm

**Errors:**
Standard error format. See @APIConventions#errors
- 400: invalid items
- 409: insufficient stock

Information Priority

Preserve in order of criticality. Never lose critical items.

PriorityCategoryExamples
CriticalIdentifiersNames, IDs, versions, dates, codes
CriticalValuesNumbers, thresholds, percentages, limits
CriticalEntitiesPeople, systems, components, orgs
HighRelationshipsX depends on Y, A contains B
HighCausalityIf X then Y, triggers, because
HighActionsWhat was done, chosen, rejected
MediumSequencesOrder, steps, workflows
MediumConstraintsLimits, conditions, exceptions
LowContextBackground, history, rationale

Representation Selection

Pick the first format that fits:

Data ShapeUse
Single factInline text
List of items (no attributes)Bullet points
Named propertieskey: value pairs
Simple sequence (no branching)Numbered list
Sequence with branchingMermaidJS flowchart
2+ attributes per itemTable

Language Rules

Sentence Construction

  • Imperative mood. "Validate input" not "The input should be validated"
  • Present tense. "System returns error" not "System will return"
  • Active voice. "User submits form" not "Form is submitted by user"
  • 3-7 words per statement when possible

Words to Cut

RemoveReplace With
In order to(delete, use infinitive)
It is necessary toMust
Due to the fact thatBecause
In the event thatIf
At this point in timeNow
Has the ability toCan
Is responsible for(verb directly)
Basically, essentially, actually(delete)
Please note that(delete)
The fact that(delete)
In cases whereWhen / If
There is/are(rephrase)
It should be noted(delete)
As a matter of fact(delete)
For the purpose ofFor / To
In the process of(delete, use -ing verb)
On a daily basisDaily
At the present timeNow / Currently
In the near futureSoon
A large number ofMany
The vast majority ofMost
In spite of the fact thatAlthough / Despite
Perhaps, might, it seems(delete or commit)
Moving on to(delete)
As mentioned earlier(delete)

Standard Qualifiers

Use consistently throughout:

  • Must — required, will fail without
  • Should — recommended, best practice
  • May — optional, allowed
  • Never — prohibited

Relationship Notation

Use these intuitive symbols inline when clearer than prose:

SymbolMeaningExample
leads to, causes, then, outputsInput → Validate → Store
depends on, requires, fromService ← Database
bidirectionalClient ↔ Server
|or, alternativeJSON | XML
+and, combinedAuth + Logging
? :if-then-elseValid ? Process : Reject
..range1..100, A..Z

Pattern Transformations

Convert verbose patterns to compact forms:

Verbose PatternCompressed
"X results in Y"X → Y
"X depends on Y"X ← Y
"X and Y communicate"X ↔ Y
"If X then Y, otherwise Z"X ? Y : Z
"from X to Y"X..Y
"X or Y"X | Y
"X followed by Y followed by Z"X → Y → Z
"X contains A, B, and C"X: A, B, C
"the value ranges from 10 to 100"value: 10..100

Structure Templates

Concept / Definition

markdown
## Term Name

Short definition in one sentence.

- property: value
- property: value
- related: Other Concept

Process / Flow (with branching)

markdown
## Process Name

Brief purpose (1 line).

​```mermaid
flowchart LR
    A[Start] --> B{Condition?}
    B -->|yes| C[Action 1]
    B -->|no| D[Action 2]
    C --> E[End]
    D --> E
​```

**Errors:**
- Condition X: return 400
- Condition Y: return 401

Process / Flow (linear)

markdown
## Process Name

1. Actor does action
2. System validates
3. System creates record
4. Return confirmation

Or inline for simple flows:

markdown
## Process Name

Input → Validate → Transform → Store → Respond

Constraint / Rule

markdown
## Rule Name

Applies to: [scope]

- condition: description
- condition: description

Violation: what happens

API Endpoint

markdown
## Endpoint Name

Purpose: what business problem this solves (1 line)

`METHOD /path/{param}`

**Input:**
- param (path): description
- field (body): type, constraints

**Output:** description of success response

**Errors:**
- 400: invalid input
- 401: not authenticated
- 404: resource not found

Configuration / Options (simple)

markdown
## Config Section

- timeout: 30s
- retries: 3
- cache: enabled

Configuration / Options (with attributes)

markdown
## Options

| Option | Type | Default | Description |
|--------|------|---------|-------------|
| timeout | int | 30 | Seconds before abort |
| retries | int | 3 | Max retry attempts |

Decision Record

markdown
## Decision Name

Context: brief situation

| Option | Outcome |
|--------|---------|
| A | consequence |
| B | consequence |

Chosen: A — reason

Compression Pipeline

Step 1: Segment

Read document. Tag each chunk:

  • Concept — defines something
  • Flow — describes sequence
  • Rule — states constraint
  • Config — lists settings
  • Example — shows usage

Step 2: Normalize

  • Pick one term per concept. Use everywhere.
  • Convert to active voice, present tense.
  • Replace verbose phrases (see Words to Cut).

Step 3: Structure

  • Match each segment to a template.
  • Extract only required fields.
  • Discard prose that doesn't fit.

Step 4: Compress

  • Shorten sentences to 3-7 words.
  • Remove articles (a, an, the) where clear.
  • Use bullets over paragraphs.
  • Use key-value over bullets when named.
  • Use flowchart over list when branching.
  • Apply relationship notation where clearer than words.
  • Remove hedging — commit to statements or omit.
  • Remove transitions between sections.
  • Remove attribution when source is obvious.
  • Replace duplicated content with @references to canonical source.

Step 5: Validate

  • All requirements preserved?
  • All error/edge cases listed?
  • All config options present?
  • No duplicate information?
  • Can reader reconstruct full meaning?

Density Levels

Choose based on audience:

LevelReductionUse For
Light30-40%General audience, first-time readers
Medium40-60%Technical audience, reference docs
Heavy60-75%Expert audience, quick lookup, cheat sheets

Default to Medium for most technical documentation.


Example

Before (147 words)

code
User Authentication Process

When a user wants to log in to the system, they need to provide their 
email address and password. The system will first check if the email 
exists in the database. If the email is not found, an error message 
will be displayed indicating that the account does not exist.

If the email is found, the system will then verify the password. The 
password is checked against the hashed version stored in the database. 
If the password is incorrect, the system will increment the failed 
login counter and return an error. After 5 failed attempts, the 
account will be temporarily locked for 15 minutes.

If the password is correct, the system will generate a session token 
and return it to the user. This token must be included in all 
subsequent requests.

After (67 words, 54% reduction)

markdown
## Login

Purpose: Authenticate user, issue session token for API access

`POST /auth/login`

**Input:**
- email: string
- password: string

**Flow:**

​```mermaid
flowchart TD
    A[Receive credentials] --> B{Email exists?}
    B -->|no| C[404]
    B -->|yes| D{Password valid?}
    D -->|no| E[Increment fails]
    E --> F{Fails >= 5?}
    F -->|yes| G[Lock 15 min]
    F -->|no| H[401]
    G --> H
    D -->|yes| I[Generate token]
    I --> J[Return token]
​```

**Rules:**
- Lock after: 5 failed attempts
- Lock duration: 15 minutes
- Token required for all subsequent requests

**Errors:**
- 404: email not found
- 401: invalid password
- 423: account locked

Final Checklist

Before delivering compressed document:

Preservation (Critical)

  • All numerical values present?
  • All identifiers/codes present?
  • All named entities present?
  • All causal relationships captured?
  • All decision points captured?
  • Sequence order maintained?

Quality

  • Every sentence under 10 words?
  • No passive voice?
  • No filler phrases?
  • No hedging language?
  • Simplest representation used?
  • No repeated information?
  • References used instead of duplication?
  • All edge cases covered?

Readability

  • Readable without original document?
  • No ambiguity introduced?
  • Notation used consistently?
  • Compression ratio 40-60%?