opencode-skills-collection 4.0.42 → 4.0.44

package/bundled-skills/poka-yoke/SKILL.md

@@ -0,0 +1,172 @@
+---
+name: poka-yoke
+description: "Mistake-proof code, config and process: make the wrong action impossible or self-announcing rather than documented."
+category: development
+risk: safe
+source: rainmanjam/poka-yoke
+source_repo: rainmanjam/poka-yoke
+source_type: community
+date_added: "2026-08-25"
+author: rainmanjam
+tags: [mistake-proofing, code-review, api-design, guardrails, reliability]
+tools: [claude, cursor, codex]
+license: "MIT"
+license_source: "https://github.com/rainmanjam/poka-yoke/blob/v0.1.2/LICENSE"
+---
+
+# Poka-Yoke: Mistake-Proofing for Software
+
+Shigeo Shingo's insight, from the Toyota Production System: **people will always make
+mistakes; that is not the problem worth solving. The problem is letting a mistake become a
+defect.** So you stop trying to make humans more careful and start redesigning the work so
+the mistake either cannot physically happen or announces itself immediately.
+
+A poka-yoke ("poh-kah yoh-kay", ポカヨケ) is a *device*: a jig, a shape, a counter: not
+an instruction. In software: a type, a constraint, a hook, a schema, a state machine. The
+single most important consequence:
+
+> **A comment, a docstring, a wiki page, a code review checklist, or a line in CLAUDE.md
+> saying "don't do X" is not a poka-yoke.** It is training. Training degrades. A device
+> does not. If your proposed fix relies on someone remembering something, keep going.
+
+## When to Use This Skill
+
+- Use when the user says "poka-yoke this", "mistake-proof it", or "make this harder to get wrong".
+- Use when designing an interface, schema or state machine and the ask is "make invalid states unrepresentable" or "so callers cannot screw it up".
+- Use when auditing existing code for footguns: "what could bite us here", "what is easy to misuse".
+- Use after an incident, when the fix must close the class rather than the case: "make sure this never happens again", "this is the third time".
+- Especially for money, auth, permissions, deletion, migrations and pipelines, where failure is silent.
+
+## The two axes
+
+Every real poka-yoke answers two questions. Use both when you classify a hazard or propose a
+device. They are the difference between this method and generic code review.
+
+### Axis 1, Regulatory function: what happens when the mistake occurs?
+
+This is a strict preference ladder. Always reach for the highest rung you can afford.
+
+| Rung | Name | What it does | Software examples |
+|---|---|---|---|
+| **1** | **Control** | The mistake is **impossible**. The work cannot proceed. | Type won't compile · `NOT NULL` / `CHECK` / unique constraint · required function argument · private constructor + smart constructor · PreToolUse hook returns deny · protected branch |
+| **2** | **Warning** | The mistake is possible but **announced at the moment it happens**. | Lint error in the editor · failing CI gate · runtime assertion that throws · confirmation prompt naming the exact thing being destroyed |
+| **3** | **Detection** | The mistake ships, and something **finds it afterward**. | Tests · monitoring · alerting · reconciliation job |
+| **0** | *(not a poka-yoke)* | Relies on a human remembering. | Docs · comments · training · "be careful" · review checklists |
+
+Shingo's rule: prefer **control** over **warning**, always, and only settle for warning when
+control is genuinely too expensive, then say *why* out loud. In software the honest reason
+is usually "the language can't express it" or "it would break every existing caller," and
+both are worth stating explicitly so the tradeoff is visible.
+
+### Axis 2, Setting function: how does the device notice?
+
+Shingo's three detection methods map cleanly onto software. These are your **inspection
+lenses**, run all three over any interface and you will find hazards that a general
+code review misses.
+
+| Method | Factory floor | The question to ask code | Software devices |
+|---|---|---|---|
+| **Contact** | The part physically won't seat unless it's the right shape and orientation | **Can the wrong thing fit?** | Distinct types instead of shared primitives · branded/newtype IDs · parse-don't-validate at boundaries · units in the type · discriminated unions instead of bags of optionals |
+| **Fixed-value** | A counter says all 6 screws were fitted | **Can the wrong count or an incomplete set pass?** | Exhaustive `match`/`switch` over an enum · required fields · "all migrations applied" check · row-count guard on a bulk write · checksums · config validated as a whole at boot |
+| **Motion-step** | A sensor confirms step 3 happened before step 4 | **Can the steps happen in the wrong order, or be skipped?** | Typestate · builder that cannot `.build()` until required steps run · state machines with illegal transitions unrepresentable · idempotency keys · RAII / `defer` / context managers · transactions |
+
+### The third principle: inspect at the source
+
+Shingo separated **source inspection** from **informative inspection**, which finds the defect
+only after it exists and comes in two forms. Ranked best first, that is three places you can
+put the device.
+
+1. **Source inspection**: check the *conditions* before the error can occur. Designed in
+   where you can, enforced at runtime where you cannot.
+   The type, the constraint, the signature.
+2. **Self-check** (informative): the work checks itself as it happens. Runtime. Assertions,
+   fail-fast, validation at the boundary.
+3. **Successive check** (informative): the next station checks the previous one. Review, CI,
+   QA.
+
+Push every device as far up this list as it will go. A CI gate that catches a bad migration
+is good; a schema that makes the bad migration unwritable is better and costs less forever.
+
+## How to use this skill
+
+Apply the method directly to the subject in front of you. A Terraform module, a support
+runbook, a spreadsheet everyone edits, a release checklist, a
+prompt template, an onboarding process, a physical workflow: the method works on any of them,
+because Shingo developed it on an assembly line, for people fitting springs into switches, and
+not for software at all.
+
+Applying it directly means four steps, in order:
+
+1. **Name what is being done, and by whom.** A device protects a specific action taken by a
+   specific person or system. "The pipeline" is not an action; "an engineer re-runs the deploy
+   job after it fails halfway" is.
+2. **Run the three lenses** over that action, can the wrong thing fit, can an incomplete or
+   wrong-sized set pass, can the steps happen in the wrong order. Most subjects yield
+   something on at least one.
+3. **For each hazard found, state it as a mistake someone could make**, what happens when they
+   do, whether it is silent, and what exists today to stop it.
+4. **Propose the highest-rung device you can afford**, and say which rung it reaches. If you
+   land on Warning, say what Control would have required and why you did not take it.
+
+Then apply the two rules in *How to talk about this* below: name the mistake rather than the
+mistaken, and never let the answer come out as "be more careful" or "document it". Those are
+rung zero, and the whole method exists because they do not work.
+
+**If the request is bare**, `/poka-yoke` with nothing attached, look at what is actually in
+front of you: the current diff, the file under discussion, the thing the conversation has been
+about. Say what you picked in one line before starting, so it is cheap to redirect you. If
+there is genuinely no subject, ask what they want mistake-proofed rather than guessing.
+
+## How to talk about this
+
+Two habits keep the analysis honest and keep people from getting defensive:
+
+**Name the mistake, not the mistaken.** "This signature lets a caller swap the two IDs" is
+actionable and true. "The developer should have been more careful" is neither. Shingo was
+emphatic that blaming the operator is how organizations avoid fixing the process. Write
+findings about the code's affordances, never about who wrote it.
+
+**Say which rung you achieved, and what stopped you going higher.** A recommendation that
+reads "added a runtime assertion (warning), control would need a newtype, which touches 40
+call sites" gives the reader a real decision. One that reads "added validation" does not.
+
+## Example
+
+Suppose a destructive API accepts `deleteAccount(accountId: string, tenantId: string)`.
+The two identifiers can be swapped, and the call can target an account outside the caller's
+tenant.
+
+1. **Contact lens:** two plain strings have the same shape, so the wrong value fits.
+2. **Motion-step lens:** deletion can run before tenant ownership is established.
+3. **Control device:** replace the strings with distinct validated ID types and expose a
+   deletion operation that accepts only an account loaded through the authenticated tenant.
+4. **Warning fallback:** if compatibility prevents that interface change, reject ownership
+   mismatches at the boundary and require a confirmation that names the exact account. State
+   explicitly that this is weaker than making the invalid call unrepresentable.
+5. **Detection:** retain audit logging and reconciliation for failures the control does not
+   cover; do not present those after-the-fact checks as the poka-yoke itself.
+
+## Applying changes
+
+Propose before you edit. Show the hazard, the proposed device, and the rung it reaches, then
+wait for a go-ahead before changing files: the whole point of this method is that it changes
+the shape of an interface, and that is precisely the kind of change people want to see first.
+Once approved, apply it and record the prevented mistake where future maintainers can verify
+the constraint without mistaking the explanation itself for the device.
+
+The exception is when someone has explicitly asked you to write new code: mistake-proofing
+*is* the code they asked for, so build it, then narrate which hazards
+you designed out and why.
+
+## Limitations
+
+- Poka-yoke reduces predictable misuse; it cannot prove that a design is correct or cover
+  hazards the analysis never identifies.
+- The strongest control may be unavailable in the current language, platform or compatibility
+  envelope. When that happens, state the tradeoff and retain appropriate tests, monitoring and
+  recovery paths instead of presenting a warning as complete prevention.
+- A guard can itself be wrong, overbroad or operationally expensive. Validate proposed devices
+  against real callers and failure modes, especially for destructive, financial, authentication
+  and authorization flows.
+- This method complements, but does not replace, domain review, security review, testing,
+  observability or incident response.

package/bundled-skills/project-state-governor/SKILL.md

@@ -216,7 +216,7 @@ Example:
 session DONE != task DONE
 task DONE != milestone DONE
 milestone DONE != workstream DONE
-workstream DONE != mission success
+workstream COMPLETED != mission success
 ```
 
 ## 5. Session bootstrap and recall

package/bundled-skills/project-state-governor/references/project-state-schema.md

@@ -31,7 +31,7 @@ detailed record no longer affects future work.
 
 ## Milestones
 ### [Milestone ID or name]
-- Status: PROPOSED | ACTIVE | BLOCKED | PAUSED | DONE | DEFERRED
+- Status: PROPOSED | ACTIVE | BLOCKED | PAUSED | DONE | CANCELLED | DEFERRED
 - Goal: ...
 - DoD: ...
 - Parent: ...

package/bundled-skills/protocol-reverse/SKILL.md

@@ -0,0 +1,108 @@
+---
+name: protocol-reverse
+description: "Authorized reverse engineering of custom binary protocols, Protobuf/gRPC schemas, WebSocket frames, and PCAP-driven protocol recovery."
+risk: safe
+source: "https://github.com/zhaoxuya520/reverse-skill"
+source_repo: "zhaoxuya520/reverse-skill"
+source_type: community
+date_added: "2026-08-25"
+license: "MIT"
+license_source: "https://github.com/zhaoxuya520/reverse-skill/blob/main/LICENSE"
+---
+# Protocol Reverse Engineering
+## When to Use
+
+- Documenting an undocumented wire protocol from captures.
+- Decoding structured traffic during an authorized analysis.
+
+
+## 适用场景
+
+- 自定义 TCP/UDP 二进制协议
+- Protobuf / gRPC / FlatBuffers / MessagePack
+- WebSocket / MQTT / 私有 RPC
+- PCAP / PCAPNG 还原字段与状态机
+- 客户端-服务端校验、序列号、加密帧头
+
+## 不走本 skill
+
+| 情况 | 去哪 |
+|------|------|
+| 仅 HTTP 参数签名 / JS 加密 | `js-reverse/` |
+| 仅 TLS 证书问题 | `pentest-tools/` 或浏览器代理 |
+| 固件内协议栈深挖 + 仿真 | `firmware-pentest/` 后再回本 skill |
+
+## 工作流
+
+### Phase 1 — 采集与分诊
+
+```text
+□ 拿到样本：PCAP / 代理导出 / 客户端日志 / 二进制
+□ 标记方向：C→S / S→C；是否有握手、心跳、重连
+□ 固定头？魔数？长度字段？TLV？定长？
+□ 是否压缩（zlib/gzip/lz4）或加密（AES/ChaCha 帧内）
+□ tshark -r cap.pcap -T fields -e frame.number -e ip.src -e tcp.payload
+```
+
+### Phase 2 — 帧布局还原
+
+```text
+□ 对齐多个同类消息，找不变字节 / 自增序列号
+□ 长度字段：大端/小端、含头/不含头
+□ 校验：CRC16/32、checksum、HMAC 位置
+□ 画出状态机：Connect → Auth → Ready → Request/Response → Close
+□ 工具：Wireshark 自定义 dissector 草稿 / ImHex / 010 Editor 模板 / Kaitai Struct
+```
+
+### Phase 3 — 序列化与加密
+
+```text
+□ Protobuf：.proto 恢复（blackboxprotobuf / pbtk / protoc --decode_raw）
+□ gRPC：HTTP/2 headers + protobuf body
+□ 加密：找密钥派生（客户端 so/dll/JS）→ 联合 ida-reverse / js-reverse / apk-reverse
+□ 重放：仅在授权 scope 内；先无害字段再敏感操作
+```
+
+### Phase 4 — 产物
+
+```text
+MUST 产出：
+- 消息类型表（name / opcode / fields）
+- 至少 1 条可复现的解码命令或脚本
+- Evidence：原始 hex 摘录 + 解码结果（脱敏）
+```
+
+## 工具链
+
+| 工具 | 必需 | 用途 | 自举 |
+|------|------|------|------|
+| tshark / Wireshark | 强烈建议 | PCAP 解析 | 手动 / winget |
+| Python3 | 是 | 解码脚本 | 系统 |
+| blackboxprotobuf | 可选 | 未知 protobuf | pip |
+| ImHex / 010 | 可选 | 结构模板 | 手动 |
+| IDA / r2 / Ghidra | 按需 | 客户端序列化函数 | 见对应 skill |
+
+## 参考
+
+- `references/protocol-workflow.md` — 帧布局与 Protobuf 速查
+- 相关：`../ida-reverse/` `../js-reverse/` `../firmware-pentest/` `../pentest-tools/`
+
+## 路由上下文
+
+**上游**: `MASTER-ROUTING` R21 · `routing.md`  
+**下游**: 需客户端算法 → `ida-reverse`/`js-reverse`；需利用重放 → `pentest-tools`/`api-security`  
+**同级**: `malware-analysis`（C2 协议）、`digital-forensics`（流量取证）
+
+## 任务完成自检
+
+- [ ] 是否还原了消息布局或状态机（而非只贴 hex）？
+- [ ] 是否有可复现解码命令？
+- [ ] 是否遵守 scope / 脱敏？
+- [ ] 是否回写 field-journal / 报告 Checklist？
+
+## Limitations
+
+- Encrypted or session-keyed protocols need key material first.
+- Stateful protocols may require long, varied capture sessions.
+
+> Adapted from [zhaoxuya520/reverse-skill](https://github.com/zhaoxuya520/reverse-skill) (MIT).

package/bundled-skills/protocol-reverse/references/protocol-workflow.md

@@ -0,0 +1,29 @@
+# Protocol reverse 速查
+
+> 适用：`protocol-reverse` skill · 2026-07-18
+
+## 常见布局模式
+
+| 模式 | 特征 | 提示 |
+|------|------|------|
+| 定长头+体 | 前 2/4 字节长度 | 注意是否包含头长 |
+| 魔数 | 固定 `0xDEAD` 等 | 便于流再同步 |
+| TLV | type-length-value 重复 | type 枚举即消息字典 |
+| Protobuf | 字段号 varint | `protoc --decode_raw` |
+| 加密帧 | 熵高、无明文 URL | 先找 nonce/IV 邻域 |
+
+## 最小 Python 骨架
+
+```python
+import struct
+def parse_frame(buf: bytes):
+    magic, length, msg_type = struct.unpack_from(">IHI", buf, 0)
+    body = buf[10:10+length]
+    return {"magic": magic, "type": msg_type, "body": body}
+```
+
+## PCAP 提取 TCP payload
+
+```bash
+tshark -r cap.pcap -Y "tcp.port==4433" -T fields -e tcp.payload | head
+```

package/bundled-skills/pwn-chain/SKILL.md

@@ -0,0 +1,209 @@
+---
+name: pwn-chain
+description: "Go from reverse engineering to a working exploit: stack/heap/kernel pwn workflows with pwntools, libc-database, ROP, and stabilization from CTF to authorized remote targets."
+risk: offensive
+source: "https://github.com/zhaoxuya520/reverse-skill"
+source_repo: "zhaoxuya520/reverse-skill"
+source_type: community
+date_added: "2026-08-25"
+license: "MIT"
+license_source: "https://github.com/zhaoxuya520/reverse-skill/blob/main/LICENSE"
+---
+> **⚠️ AUTHORIZED USE ONLY**
+> This skill is for educational purposes or authorized security assessments only.
+> You must have explicit, written permission from the system owner before using this tool.
+> Misuse of this tool is illegal and strictly prohibited.
+
+> **Mandatory confirmation gate**
+> Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:
+> 1. Ask the user to state the exact target URL, IP, account, or resource.
+> 2. Ask the user to confirm written authorization and the permitted scope.
+> 3. Show the exact command(s) and explain their expected effect.
+> 4. Wait for explicit confirmation in the current conversation.
+>
+> Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.
+
+## When to Use
+
+- A binary vulnerability is understood and needs a reliable exploit.
+- Porting a CTF-style exploit to an authorized real-world target.
+
+## 适用范围
+
+当任务属于以下场景时使用本 skill：
+
+1. **拿到二进制 + 已知漏洞点** — 静态/审计/fuzz 已经找到溢出/UAF/double free，需要从触发到拿 shell
+2. **CTF 题已经本地通了，远程打不通** — 远端环境差异导致脚本失效，需要稳定化
+3. **真实目标的二进制利用** — SRC / 红队场景下，已经识别到内存损坏漏洞，需要构造 RCE
+4. **Linux 内核驱动的 ioctl bug** — 用户态触发，目标是提权到 root
+
+**前提**：你已经知道"哪里炸了"。本 skill 不负责发现漏洞（那是 fuzzing / 审计），只负责"从漏洞点写出 exploit"。
+
+### 与其他 skill 的分工
+
+| 场景 | 用什么 |
+|------|--------|
+| 识别 custom VM / anti-debug / 复杂 obfuscation | `reverse-engineering/` |
+| 从零打开二进制做静态分析 | `ida-reverse/` 或 `radare2/` |
+| **有漏洞点，写 exploit 打通远程** | **本 skill** |
+| 把 pwn 拿到的 shell 整合进完整攻击链 | `attack-chain/`（下游） |
+
+`reverse-engineering/` 关注"理解程序在干什么"（模式识别、协议还原、解 CTF 题里的奇怪机制）；本 skill 关注"把已经看懂的漏洞变成可执行的攻击"。两者经常配套使用，但分工清晰。
+
+## 核心工作流
+
+```text
+Step 1: 确认漏洞类型 + 保护机制
+   ├─ checksec ./vuln（NX / Canary / PIE / RELRO / Fortify）
+   ├─ file ./vuln  + readelf -d ./vuln
+   ├─ 漏洞分类：栈溢出 / 格式化字符串 / 堆 (UAF/DF/OF) / 整数 / 竞态 / 内核
+   └─ → 决定走哪个 references/
+
+Step 2: 选择利用策略
+   ├─ NX 关 + 无 ASLR → 直接 shellcode
+   ├─ NX 开 + 给 libc → ret2libc / one_gadget
+   ├─ NX 开 + 不给 libc → leak 后 libc-database 反查
+   ├─ 堆 → 按 glibc 版本对应技术 (tcache/fastbin/unsorted/large)
+   └─ 内核 → commit_creds / modprobe_path / core_pattern
+
+Step 3: 准备 libc + gadget
+   ├─ libc-database：./find puts 0x6f0
+   ├─ ROPgadget --binary ./libc.so.6 --only "pop|ret"
+   ├─ one_gadget ./libc.so.6
+   └─ 计算 base：leak_addr - libc.sym['puts']
+
+Step 4: 写 pwntools 模板（本地 process）
+   ├─ context.binary = ELF('./vuln')
+   ├─ p = process('./vuln')  /  p = gdb.debug('./vuln','b *main+xx')
+   ├─ payload = cyclic(N) + p64(ret) + ...
+   └─ p.interactive()
+
+Step 5: 本地通
+   ├─ 反复 attach + 看寄存器 + 调 offset
+   ├─ 用 pwndbg/GEF 的 vmmap / heap / bins / telescope
+   └─ 跑通后切 remote()
+
+Step 6: 远程稳定化
+   ├─ libc 偏移：用 leak 反查 libc-database，不要拍脑袋
+   ├─ 栈对齐：16-byte 不对齐 → movaps 崩 → 加一个 ret gadget
+   ├─ 远程网络延迟 → recvuntil 精确锚字符串，禁用模糊 sleep
+   ├─ 远程缓冲：sendlineafter 比 sendline 更稳
+   ├─ 堆喷成功率：放大 spray 数量 + 留 padding chunk 防合并
+   └─ 多次跑：写 while True 验证成功率 ≥ 95%
+```
+
+## 典型场景
+
+### 场景 1：远程 64 位二进制 (NX+PIE+canary, 给了 libc)
+
+```text
+已有：./vuln（64-bit ELF, NX, PIE, canary）+ ./libc.so.6 + nc host port
+漏洞：read(buf, 0x200) 但 buf 只有 0x40 字节 → 栈溢出
+保护：canary 拦住，PIE 让 .text 随机化
+
+策略：
+1. 先 leak canary（栈/格式化字符串/部分读）
+2. 再 leak 一个 libc 函数地址（puts@got）
+3. 用 libc.address = leaked - libc.sym['puts'] 算 libc base
+4. one_gadget ./libc.so.6 选一个约束能满足的 magic gadget
+5. payload = padding + canary + saved_rbp + (pop_rdi + bin_sh + system) 或直接 one_gadget
+6. 加一个 ret gadget 修栈对齐（关键！）
+```
+
+完整模板参见 `references/stack-pwn.md`。
+
+### 场景 2：Linux 内核驱动 ioctl 越界写 → 拿 root
+
+```text
+已有：vmlinux + bzImage + initramfs.cpio.gz + 自定义 vuln.ko
+漏洞：ioctl(0x1337, ptr) 里 copy_from_user 长度可控 → kernel heap overflow (kmalloc-64 slab)
+保护：SMEP, SMAP, KASLR, KPTI
+
+策略：
+1. 改 init 脚本拿到 root shell（CTF）或先 leak KASLR base 再继续（真实）
+2. 通过 /proc/kallsyms（可能限权）或未初始化堆喷 leak 内核基址
+3. 在 kmalloc-64 slab 里喷 tty_struct / msg_msg / pipe_buffer
+4. 覆盖 vtable 指针指向用户态 → 不行（SMEP），改走 stack pivot + 内核 ROP
+5. ROP 链：prepare_kernel_cred(0) → commit_creds → swapgs+iretq → 用户态 execve("/bin/sh")
+6. 或更省事：覆盖 modprobe_path 为 "/tmp/x"，写一个 /tmp/x，然后触发 modprobe
+```
+
+完整模板参见 `references/kernel-pwn.md`。
+
+## 按需自举 (On-Demand Bootstrap)
+
+### 工具依赖
+
+| 工具 | 用途 | 安装方式 |
+|------|------|---------|
+| pwntools | exploit 编写框架 | `pip install pwntools` |
+| GEF | gdb 增强（推荐内核 + 用户态） | `git clone https://github.com/bata24/gef` (fork 维护活跃) |
+| pwndbg | gdb 增强（堆调试体验最好） | `git clone https://github.com/pwndbg/pwndbg && ./setup.sh` |
+| ROPgadget | gadget 搜索 | `pip install ropgadget` |
+| Ropper | gadget 搜索（备选，支持架构多） | `pip install ropper` |
+| one_gadget | libc magic gadget 查找 | `gem install one_gadget`（需 ruby） |
+| libc-database | libc 指纹反查 | `git clone https://github.com/niklasb/libc-database && ./get` |
+| qemu-system-x86_64 | 内核题调试 | `apt install qemu-system-x86` |
+| binwalk / cpio | initramfs 拆包 | `apt install binwalk cpio` |
+| patchelf | 切换 libc 版本 | `apt install patchelf` |
+
+### Bootstrap 检查脚本
+
+```bash
+# 一键检查 + 安装核心工具
+for t in pwntools ropgadget ropper; do
+  pip show $t >/dev/null 2>&1 || pip install $t
+done
+
+command -v one_gadget >/dev/null || gem install one_gadget
+
+[ -d ~/tools/libc-database ] || git clone https://github.com/niklasb/libc-database ~/tools/libc-database
+[ -d ~/tools/libc-database/db ] || (cd ~/tools/libc-database && ./get ubuntu debian)
+
+[ -d ~/tools/pwndbg ] || (git clone https://github.com/pwndbg/pwndbg ~/tools/pwndbg && cd ~/tools/pwndbg && ./setup.sh)
+```
+
+### 同一工具自动安装失败 2 次后
+
+停止重试，输出结构化手动安装步骤（pip 源 / gem 源 / git 国内镜像 / apt 源）让用户确认。
+
+## 路由上下文
+
+**上游入口**: `skills/SKILL.md`（总控）、`routing.md`
+**触发条件**: 有二进制 + 已识别漏洞点，需要写 exploit
+
+**上游 skill（先用它们再回到本 skill）**:
+- 还没看懂二进制在干什么 → `reverse-engineering/`
+- 需要静态详细分析 → `ida-reverse/`
+- 快速侦察确认架构/保护机制 → `radare2/`
+
+**下游 skill（拿到 shell 之后）**:
+- 整合进完整攻击链（横向、提权、持久化）→ `attack-chain/`
+
+**子模块导航**:
+- 栈类利用（ret2libc / ret2csu / one_gadget / 栈对齐）→ `references/stack-pwn.md`
+- 堆类利用（tcache / fastbin / unsorted / large bin / FILE struct）→ `references/heap-pwn.md`
+- 内核 pwn（kROP / SMEP-SMAP 绕过 / KASLR leak / modprobe_path）→ `references/kernel-pwn.md`
+
+## 注意事项
+
+- **不要在本地跑通就交差** — 本地 libc / ASLR / 网络环境都和远程不同，必须在 remote 模式下连续跑 20 次以上验证稳定性
+- **libc 版本必须确认** — 用 leak + libc-database 反查，不要假设是 Ubuntu 22.04 默认 libc
+- **栈对齐是 64 位的常见坑** — `movaps xmm0, [rsp]` 在 rsp 未 16 字节对齐时段错误，加一个空 `ret` gadget 解决
+- **堆利用对 glibc 版本极敏感** — tcache 在 2.27 引入，safe-linking 在 2.32 引入，2.34 移除 hooks，每个版本利用路径不同
+- **内核 pwn 必须先确认 cpu 标志** — qemu 启动参数里有没有 +smep +smap +pku 直接决定 ROP 链怎么写
+- **KASLR leak 一次就够** — 拿到一个内核地址后所有地址都算偏移，不要反复 leak
+
+## 任务完成自检（声称完成前 MUST 通过）
+
+- [ ] 我是否执行了工作流中的每一步（而不是只阅读）？
+- [ ] 我是否基于 `tool-index` 使用了真实工具路径？
+- [ ] 我是否产出了可复现证据（命令/脚本/截图/报告）？
+- [ ] 我是否完成并回写了 RULES 要求的 Checklist 项？
+
+## Limitations
+
+- Exploit development only on systems you are authorized to attack.
+- Mitigations (full RELRO, CFI, MTE) raise difficulty substantially.
+
+> Adapted from [zhaoxuya520/reverse-skill](https://github.com/zhaoxuya520/reverse-skill) (MIT).