aaione
aaione/everything-claude-code-zh
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/aaione/everything-claude-code-zh --skill code-tour命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Kubernetes 工作负载模式、资源管理、RBAC、probes、autoscaling、ConfigMap/Secret 处理，以及面向生产级部署的 kubectl 调试。
完成任何非平凡任务后使用。智能体按 5 个维度自评输出——准确性、完整性、清晰度、可执行性、简洁性——每项都给出具体证据。生成结构化 1-5 评分卡和具体改进建议。
在 competitive-platform-analysis 产出分层竞品集合后使用。按九个加权维度（定位、声音、视觉工艺、offer packaging、证据、enterprise-readiness、thought leadership、定价、客户 strategic tension）为每个竞品评分，使用明确 1–5 rubrics 和 tension-plot。位于 competitive-report-structure 之前。
基于 SOC 职业分类
正在显示 SKILL.md
| name | code-tour |
| description | 创建 CodeTour `.tour` 文件 — 面向特定角色的分步导览，带有真实文件和行号锚点。用于入职导览、架构导览、PR 导览、RCA 导览和结构化的"解释其工作原理"请求。 |
| origin | ECC |
创建 CodeTour .tour 文件用于代码库导览，直接打开到真实文件和行范围。导览文件存放在 .tours/ 中，采用 CodeTour 格式，而非临时的 Markdown 笔记。
好的导览是为特定读者讲述的故事：
仅创建 .tour JSON 文件。不要将修改源代码作为此技能的一部分。
在以下情况下使用此技能：
示例：
| 替代 code-tour | 使用 |
|---|---|
| 聊天中的一次性解释就够了 | 直接回答 |
用户想要散文式文档，而非 .tour 制品 | documentation-lookup 或仓库文档编辑 |
| 任务是实现或重构 | 执行实现工作 |
| 任务是广泛的代码库入职，不需要导览制品 | codebase-onboarding |
在写任何内容之前先探索仓库：
在理解代码结构之前不要开始编写步骤。
根据请求决定角色和深度。
| 请求类型 | 角色 | 建议深度 |
|---|---|---|
| "入职"、"新成员" | new-joiner | 9-13 步 |
| "快速导览"、"大概看看" | vibecoder | 5-8 步 |
| "架构" | architect | 14-18 步 |
| "导览这个 PR" | pr-reviewer | 7-11 步 |
| "为什么会出问题" | rca-investigator | 7-11 步 |
| "安全审查" | security-reviewer | 7-11 步 |
| "解释这个功能如何工作" | feature-explainer | 7-11 步 |
| "调试这个路径" | bug-fixer | 7-11 步 |
每个文件路径和行号锚点必须是真实的：
绝不猜测行号。
.tour写入到：
.tours/<persona>-<focus>.tour
保持路径确定性和可读性。
完成前：
谨慎使用，通常只用于收尾步骤：
{ "title": "下一步", "description": "你现在可以端到端地追踪请求路径了。" }
不要让第一步仅包含内容。
用于引导读者了解模块：
{ "directory": "src/services", "title": "服务层", "description": "核心编排逻辑位于此处。" }
这是默认的步骤类型：
{ "file": "src/auth/middleware.ts", "line": 42, "title": "认证网关", "description": "每个受保护的请求都先经过这里。" }
当一个代码块比整个文件更重要时使用：
{
"file": "src/core/pipeline.ts",
"selection": {
"start": { "line": 15, "character": 0 },
"end": { "line": 34, "character": 0 }
},
"title": "请求管道",
"description": "此代码块连接了验证、认证和下游执行。"
}
当精确行号可能漂移时使用：
{ "file": "src/app.ts", "pattern": "export default class App", "title": "应用入口" }
在有帮助时用于 PR、问题或文档：
{ "uri": "https://github.com/org/repo/pull/456", "title": "该 PR" }
每段描述应回答：
保持描述紧凑、具体，并立足于实际代码。
除非任务明显需要不同的结构，否则使用以下叙事弧线：
导览应该感觉像一条路径，而非一份清单。
{
"$schema": "https://aka.ms/codetour-schema",
"title": "API 服务导览",
"description": "支付服务请求路径的导览。",
"ref": "main",
"steps": [
{
"directory": "src",
"title": "源码根目录",
"description": "服务的所有运行时代码从此处开始。"
},
{
"file": "src/server.ts",
"line": 12,
"title": "入口点",
"description": "服务器在此处启动，在任何路由被访问之前连接中间件。"
},
{
"file": "src/routes/payments.ts",
| 反模式 | 修复 |
|---|---|
| 扁平的文件列表 | 用有依赖关系的故事串联步骤 |
| 通用描述 | 命名具体的代码路径或模式 |
| 猜测的锚点 | 先验证每个文件和行号 |
| 快速导览步骤太多 | 大幅裁剪 |
| 第一步仅包含内容 | 将第一步锚定到真实文件或目录 |
| 角色不匹配 | 为实际读者编写，而非通用工程师 |
codebase-onboardingcoding-standardscouncilmicrosoft/codetour