snippify-base

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Snippify Base

Snippify 基础

Give reusable content a small, consistent identity without changing its behavior.

为可复用内容赋予小巧、一致的标识，且不改变其原有行为。

Metadata envelope

元数据封套

Use a single-line JSON object prefixed by

snippify-metadata:

. Include:

```
schema
```
: always
```
snippify/file-metadata/v1
```
.

tag

: a concise discovery category such as

code

rule

prompt

skill

decision

workflow

, or

documentation

```
purpose
```
: one concise statement of how the reusable material should be used.
```
title
```
: a human-readable name, at most 240 bytes.
```
summary
```
: one concise sentence describing the reusable purpose.
```
source_path
```
: repository-relative path when known. Omit for content without a stable path.
```
language
```
: lowercase language or format name when known.
```
tags
```
: optional short, non-sensitive discovery terms. Omit rather than emit an empty list.

Do not add owner, user, agent, Workspace, approval, visibility, review, trust, Artifact ID, version, timestamps, credentials, or secrets. Snippify derives identity and review state from the authenticated operation.

Example payload, shown without a comment wrapper:

text

snippify-metadata: {"schema":"snippify/file-metadata/v1","tag":"code","purpose":"Reuse the outbound HTTP retry policy.","title":"Retry policy","summary":"Defines bounded retry behavior for outbound requests.","source_path":"internal/client/retry.go","language":"go","tags":["http","reliability"]}

使用以

snippify-metadata:

为前缀的单行JSON对象。包含以下字段：

```
schema
```
：固定为
```
snippify/file-metadata/v1
```
。
```
tag
```
：简洁的检索分类，例如
```
code
```
、
```
rule
```
、
```
prompt
```
、
```
skill
```
、
```
decision
```
、
```
workflow
```
或
```
documentation
```
。
```
purpose
```
：用一句简洁的话说明该可复用材料的使用方式。
```
title
```
：人类可读的名称，最多240字节。
```
summary
```
：用一句简洁的话描述可复用用途。
```
source_path
```
：已知时为仓库相对路径。无稳定路径的内容可省略该字段。
```
language
```
：已知时为小写的语言或格式名称。
```
tags
```
：可选的简短非敏感检索词。宁可省略也不要返回空列表。

请勿添加所有者、用户、Agent、工作空间、审批、可见性、评审、信任、Artifact ID、版本、时间戳、凭证或密钥。Snippify会从已认证的操作中推导身份与评审状态。

示例载荷如下（未添加注释包装）：

text

snippify-metadata: {"schema":"snippify/file-metadata/v1","tag":"code","purpose":"Reuse the outbound HTTP retry policy.","title":"Retry policy","summary":"Defines bounded retry behavior for outbound requests.","source_path":"internal/client/retry.go","language":"go","tags":["http","reliability"]}

Add metadata to a file

为文件添加元数据

Inspect the file and its mandatory preamble. Search the opening portion for
```
snippify-metadata:
```
before editing.
If a header already exists, do not add another or rewrite it unless the user asks to refresh it.
If comments are supported, wrap the envelope in the native comment syntax and place it near the top without displacing required syntax:
- Keep Unix shebangs and Python encoding declarations first.
- Keep Go build constraints together at the beginning; add the metadata after the constraint block and its required blank line.
- Keep XML declarations, doctypes, and Markdown/YAML front matter first.
- Keep license headers in their required position; place metadata immediately after them.
Preserve formatting and executable behavior. Add only the metadata comment and any separator newline required by the language.

Use

//

for Go, JavaScript, TypeScript, Java, C, C++, Rust, and similar languages;

for Python, Ruby, shell, YAML, and TOML;

--

for SQL and Lua;

<!-- ... -->

for Markdown, HTML, and XML; and

/* ... */

for CSS. Follow an existing valid comment convention when it differs.

Do not insert comments into JSON or another comment-free format. Do not edit binary, generated, vendored, lock, checksum, migration-history, or externally maintained files merely to add metadata. In those cases, carry the envelope in the draft Artifact request instead.

检查文件及其必需的前置内容。编辑前先在文件开头部分搜索是否存在
```
snippify-metadata:
```
。
如果已存在该头，请勿重复添加或重写，除非用户要求刷新。
如果文件支持注释，使用原生注释语法包装元数据封套，并将其放置在靠近文件顶部的位置，不得挪动必需语法的位置：
- Unix shebang和Python编码声明必须放在最前面。
- Go构建约束需统一放在文件开头；在约束块及其所需的空行之后添加元数据。
- XML声明、doctype、Markdown/YAML front matter必须放在最前面。
- 许可证头需保留在其规定位置；将元数据紧跟在许可证头之后放置。
保留原有格式与可执行行为。仅添加元数据注释以及语言要求的分隔换行符。

Go、JavaScript、TypeScript、Java、C、C++、Rust及类似语言使用

//

；Python、Ruby、shell、YAML、TOML使用

；SQL和Lua使用

--

；Markdown、HTML、XML使用

<!-- ... -->

；CSS使用

/* ... */

。若存在已有的有效注释约定，请遵循该约定。

请勿在JSON或其他不支持注释的格式中插入注释。请勿仅为了添加元数据而编辑二进制文件、生成文件、vendored文件、锁文件、校验和文件、迁移历史文件或外部维护的文件。在这些情况下，请将元数据封套放在Artifact草稿请求中。

Prepare a draft Artifact

准备Artifact草稿

Before an authorized

create_artifact

suggest_artifact_version

call, read an existing header when present; otherwise infer the envelope from the selected content and path. Map it as follows:

```
tag
```
,
```
purpose
```
,
```
title
```
, and
```
summary
```
become the corresponding tool fields.
Put the reusable material in
```
text
```
.
Map relevant files to
```
files
```
entries with
```
name
```
,
```
size
```
,
```
path
```
, and optional
```
summary
```
.

Creating or suggesting changes external state. Prepare metadata proactively, but call mutation tools only when the user explicitly asks to capture, sync, save, upload, or suggest the content. Follow the connected server's current schema and

$snippify-contribute

for authentication, draft replacement semantics, and result reporting.

在调用已授权的

create_artifact

或

suggest_artifact_version

之前，若存在现有头则读取之；否则根据所选内容与路径推导元数据封套。映射规则如下：

```
tag
```
、
```
purpose
```
、
```
title
```
和
```
summary
```
映射为对应的工具字段。
将可复用材料放入
```
text
```
字段。
将相关文件映射为
```
files
```
条目，包含
```
name
```
、
```
size
```
、
```
path
```
以及可选的
```
summary
```
。

创建或建议变更会修改外部状态。可主动准备元数据，但仅在用户明确要求捕获、同步、保存、上传或建议内容时才调用变更工具。身份认证、草稿替换语义与结果上报需遵循所连接服务器的当前schema以及

$snippify-contribute

规范。

Report

报告

State whether metadata was added to the file, reused from an existing header, or supplied only in the draft request. Mention skipped files and the compatibility reason; never claim a draft was uploaded unless the tool call succeeded.

说明元数据是已添加到文件中、从现有头复用，还是仅在草稿请求中提供。需提及跳过的文件及兼容性原因；除非工具调用成功，否则不得声称草稿已上传。