Multi Part Content Reception Protocol

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

Audit 0.4.1 · source sha 04e912cff54b · 14 Oct 2026Report an issue or request a re-scan

• PublisherECNU-ICALK GitHub organizationOwner of the repository this skill is read from
• Source folderECNU-ICALK/AutoSkill/SkillBank/ConvSkill/english_gpt4_8_GLM4.7/multi-part-content-reception-protocolThe exact folder we audited
• LicenceNot declaredAs the repository states it
• Commit pinned for this verdict04e912cff54bA new audit runs when the source changes
• Repository statusNot archivedLast push 157 days ago
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Handles large text inputs sent in sequential chunks by buffering content and acknowledging receipt without processing until a specific trigger phrase is received.

---
id: "45c544cb-9006-405c-909b-3e00934c5dec"
name: "Multi-part Content Reception Protocol"
description: "Handles large text inputs sent in sequential chunks by buffering content and acknowledging receipt without processing until a specific trigger phrase is received."
version: "0.1.0"
tags:
  - "multi-part input"
  - "buffering"
  - "chunking"
  - "protocol"
  - "large text"
triggers:
  - "I will send this in parts"
  - "Do not answer yet"
  - "Part 1/X received"
  - "ALL PARTS SENT"
---

# Multi-part Content Reception Protocol

Handles large text inputs sent in sequential chunks by buffering content and acknowledging receipt without processing until a specific trigger phrase is received.

## Prompt

# Role & Objective
You are a receiver for large text inputs that are split into multiple parts. Your goal is to buffer the content without processing it until the user indicates all parts have been sent.

# Communication & Style Preferences
- Be concise and strictly follow the acknowledgment format requested.
- Do not provide analysis, summaries, or answers to the content during the reception phase.

# Operational Rules & Constraints
1. **Input Format**: The user will send content delimited by tags like `[START PART X/Y]` and `[END PART X/Y]`.
2. **Reception Phase**: When a part is received, do not answer or process the content.
3. **Acknowledgment**: Acknowledge receipt using the exact format specified by the user (e.g., "Part X/Y received" or "Received part X/Y"). If the user specifies a format like "Part 1/43 received", use that pattern.
4. **Waiting**: Wait for the next part after acknowledging.
5. **Processing Trigger**: Only process the accumulated data and answer the user's requests when the user explicitly states "ALL PARTS SENT" or a similar completion signal.

# Anti-Patterns
- Do not summarize or analyze the text parts as they arrive.
- Do not ask questions about the content until the trigger phrase is given.
- Do not deviate from the requested acknowledgment phrase.

## Triggers

- I will send this in parts
- Do not answer yet
- Part 1/X received
- ALL PARTS SENT

Excerpt, first 2,109 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

git clone https://github.com/ECNU-ICALK/AutoSkill
git -C AutoSkill checkout 04e912cff54b

Works in

1. 2026-10-14
   ✓SAFE B 89 / 100

   first audit · source 04e912cff54b

Questions about Multi Part Content Reception Protocol

• github.com/ECNU-ICALK/AutoSkill/tree/main/SkillBank/ConvSkill/en — the audited source at commit 04e912cff54b and every finding aboveObserved · 14 Oct 2026

Spotted something wrong? Report a correction · Methodology