# Aboutsecurity Content Ingestion

> AboutSecurity 内容吸收与 Skill 更新 SOP

- Skill: `wgpsec/aboutsecurity-content-ingestion` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add wgpsec/aboutsecurity-content-ingestion`
- Raw SKILL.md: https://api.skillmd.com/api/skills/wgpsec/aboutsecurity-content-ingestion/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: wgpsec (https://skillmd.com/u/wgpsec)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/wgpsec/aboutsecurity-content-ingestion

---


# AboutSecurity 内容吸收与 Skill 更新 SOP

这个 skill 用于把外部安全资料转化为 AboutSecurity 仓库中的高质量 skill/reference 内容。目标不是“搬运全文”，而是把可信、可复用、符合项目结构的方法论沉淀到正确位置。

## 工作原则

- 先理解仓库，再理解资料，再动手写。AboutSecurity 的价值来自结构化方法论，不是堆命令。
- 只写能确认来源或能合理验证的内容。不能确认的说清楚，不要补脑、不要编造工具参数、API 名称或能力边界。
- 保护贡献者内容。更新已有内容时优先“纠错、去重、归位、压缩”，避免无理由覆盖近期贡献。
- 中文解释，英文命令。正文面向中文读者；命令、参数、路径、API、工具名保持原文。

## Phase 1: 建立项目上下文

每次开始前先快速读取当前项目状态，避免按过期记忆修改：

1. 检查 `CONTRIBUTING.md`，重点确认：
   - `SKILL.md` 是 YAML frontmatter + Markdown
   - `description` 是触发器，要写清触发场景
   - 正文是方法论驱动，不是工具调用清单
   - `SKILL.md` 控制在 500 行以内，深度内容放 `references/`
   - 不使用 `{{target}}` 这类不会被替换的模板变量
2. 查看相关目录：
   - `skills/<category>/<skill>/SKILL.md`
   - `skills/<category>/<skill>/references/*.md`
   - `.claude/skills/` 仅用于项目级 Claude skill，不等同于 AboutSecurity 安全知识 skill
3. 查看 git 状态和近期提交：
   - 当前改动是否来自用户/其他贡献者
   - 远端是否有新合入内容
   - 本次修改会不会覆盖近期 PR 的新增内容

如果用户要求“先 pull”或“别覆盖远端贡献者内容”，先处理 git 状态，再开始内容吸收。

### 远端贡献者保护

当用户关心远端新内容、近期 PR 或贡献者改动时，先执行安全检查：

```bash
git fetch origin --prune
git status -sb
git log --oneline --left-right --graph origin/master...HEAD
git diff --name-status $(git merge-base HEAD origin/master)..origin/master
```

判断原则：

- 远端新增或修改的文件不能被本地旧内容覆盖。
- 本地和远端分叉时，先报告领先/落后关系和远端新增文件，不要直接 reset、rebase 或强行覆盖。
- 如果用户明确说“本地修改不关心，可以覆盖”或“对齐远端”，才可以执行 `git reset --hard origin/master` 这类破坏本地改动的操作。
- 如果只需要拉取远端且保留本地改动，优先使用 merge-style pull + autostash，避免重写本地提交历史。

## Phase 2: 理解输入资源

把用户给的资料当作原始材料，而不是最终文本。先回答这几个问题：

| 问题 | 目的 |
|---|---|
| 资料属于哪个攻击阶段/安全主题？ | 决定 skill 归属 |
| 是方法论、工具说明、payload 清单、漏洞 PoC、还是案例？ | 决定放 SKILL.md 还是 references/ |
| 哪些内容是 AboutSecurity 已有的？ | 避免重复 |
| 哪些内容是新增、可验证、对实战有价值的？ | 提取增量 |
| 哪些内容存在不确定、过时、夸大或无法验证？ | 不写入或标注限制 |

对大资料源先做差距分析：

```text
资源主题
├─ 已覆盖：AboutSecurity 已有位置 + 是否需要补充
├─ 可新增：建议文件 + 新增价值
├─ 应跳过：重复/低价值/无法验证/不符合项目边界
└─ 待验证：需要查源或运行帮助命令确认的参数/API/工具能力
```

动手修改前先形成落点清单，尤其是资料量大或会改多个文件时：

```text
实施前落点清单
├─ 来源内容 A → 目标文件 X → 原因 → 验证方式
├─ 来源内容 B → 目标文件 Y → 原因 → 是否需要更新 SKILL.md 入口
├─ 来源内容 C → 跳过 → 原因（重复/低价值/无法验证/不符合边界）
└─ 来源内容 D → 待验证 → 需要确认的参数、API、权限或版本
```

落点清单是为了防止边读边改导致范围失控。用户没有要求先确认时，可以简短汇报后继续；如果清单里有新增 skill、大范围移动、删除近期贡献内容，先停下来让用户确认。

## Phase 3: 决定落点

按内容类型选择落点：

```text
内容类型？
├─ 高层流程、决策树、阶段化方法 → 更新对应 SKILL.md
├─ 长命令、工具细节、payload、API 端点、对照表 → 放 references/*.md
├─ 单一工具完整用法 → 优先放 skills/tool/<tool-name>/SKILL.md 或创建 tool skill
├─ 跨多个云/平台的通用策略 → 放更上层方法论 skill，references 按平台拆分
├─ 与当前文件标题不符 → 移动到正确 skill，不要硬塞
└─ 找不到合适位置 → 先向用户说明建议新增 skill，而不是随意放入相近文件
```

判断是否应该创建新文件：

- 已有 reference 与主题高度一致：编辑已有文件。
- 已有文件过长或新内容是独立子主题：新增语义化 reference 文件。
- 新主题会改变 skill 触发范围：同时更新 `SKILL.md` 的 description/深入参考索引。
- 只是补少量内容：不要为了“整齐”创建新文件。

## Phase 4: 提取与改写

把原始资料改写成 AboutSecurity 风格：

- 用“什么时候用、为什么用、怎么判断下一步”组织内容。
- 命令示例保留最小可执行骨架；长安装教程、环境搭建流水账要压缩。
- 对工具能力写边界：需要什么权限、适用什么场景、会产生什么日志/副作用。
- 重复内容只保留一个权威位置，其他地方用相对链接指向。
- 对有攻击链的资料，优先写成阶段流程和前置条件，不要只列命令。

反模式：

- 把外部文档整段翻译粘贴进来。
- 为了补齐链路而编造不存在的 cmdlet、API、参数或默认权限。
- 在“未授权枚举”文件里加入需要凭据的后渗透工具。
- 在 SKILL.md 里堆大量工具命令，导致触发后上下文噪声过高。
- 使用 `{{target}}` 这类模板变量。

## Phase 5: 验证真实性

写入前或写入后必须做真实性检查，尤其是用户明确要求“不允许虚假/编造”时。

新增每个高风险事实时，至少满足一个条件：

- 来自用户提供资料的明确原文。
- 来自官方文档、工具 README、`--help`、源码或可信上游资料。
- 来自 AboutSecurity 现有内容的整理、去重或归位。

不满足这些条件的内容不要写成确定性结论，可以放入“待验证”或直接跳过。高风险事实包括工具参数、API 端点、默认权限、版本变化、云服务默认行为、攻击效果和检测规避效果。

优先验证：

1. 工具参数：查上游 README、`--help`、已有源码或可信资料。
2. 云 API/CLI 名称：查官方文档、CLI help 或源资料是否一致。
3. 权限/默认行为：确认是否是默认配置、版本相关，还是特定条件。
4. 时间敏感内容：标出版本或日期限制，避免写成永久事实。
5. 攻击效果：区分“可枚举”“可读取”“可写入”“可提权”，不要扩大能力。

如果无法验证：

- 不要写成事实。
- 可以放入“待验证/注意”清单供用户后续手动确认。
- 如果资料来自单一来源且看起来可疑，优先跳过。

## Phase 6: 实施修改

实施顺序：

1. skill 的改动和编写前，请加载 /skill-creator
2. 先编辑最小必要文件。
3. 保持原有标题层级、语言风格和相对链接风格。
4. 新增 reference 时检查是否需要从 SKILL.md 或相邻 reference 增加入口链接。
5. 不创建无关 docs、计划文件或总结文件，除非用户明确要求。
6. 不提交 git commit，除非用户明确要求提交。

写作格式：

- 标题中文，文件名英文短横线。
- 命令块语言标注准确，如 `bash`、`powershell`、`yaml`。
- 表格用于决策和对比，不用于堆砌长列表。
- 链接使用相对路径指向仓库内文件。
- 对外部项目链接只保留必要入口，避免把 README 复制进来。

## Phase 7: 复核 diff

完成后检查：

```text
质量复核
├─ 结构：内容是否放在正确 skill/reference？
├─ 去重：是否与现有内容重复？是否可用链接替代？
├─ 真实性：工具参数、API、权限是否已验证？
├─ 方法论：是否解释了判断逻辑，而不是只列命令？
├─ 安全边界：是否没有夸大、编造或混淆未授权/已认证场景？
├─ 贡献者安全：是否避免覆盖远端新合入内容？
└─ 格式：Markdown、链接、代码块、frontmatter 是否正确？
```

推荐检查命令：

```bash
git status --short
git diff --stat
git diff --check
git diff -- <changed-file>
```

如果修改了近期贡献者刚加的内容，在最终说明里明确：

- 哪些是纠错
- 哪些是移动归位
- 哪些是去重压缩
- 哪些内容因为无法验证而删除或保留为待验证

删除或大幅压缩近期新增内容前，必须能说明具体理由：

- 与已有内容重复，且已有位置更权威。
- 放错文件或混淆场景，例如把已认证工具放进未授权枚举。
- 参数、API、权限或攻击效果无法验证。
- 与文件标题、skill 触发范围或 AboutSecurity 写作规范不符。
- 内容过度工具手册化，需要压缩为方法论并把细节移入 references。

## 输出给用户的格式

完成后用简短中文汇报：

```text
已完成 AboutSecurity 内容吸收/更新。

改动：
- <文件>：<做了什么，为什么>
- <文件>：<做了什么，为什么>

验证：
- <验证了哪些参数/API/来源>
- <哪些内容因无法确认而跳过>

风险/注意：
- <是否涉及近期 PR 内容、是否需要用户人工复核>
- <如删除/压缩了内容，说明具体理由>
```

不要声称“全部正确”或“已完全验证”，除非确实逐项验证过。