jmagly/aiwg

技能访问模式（内核架构迁移后，2026.5+）

本文档中引用的技能名称是AIWG技能，而非斜杠命令。大多数技能未列在内核中，因此无法通过/skill-name的方式在平台上直接调用。请通过以下方式访问它们：

aiwg discover "<能力>"
aiwg show skill <名称>

只有列在内核中的技能（aiwg-doctor, aiwg-refresh, aiwg-status, aiwg-help, use, steward）可以作为斜杠命令直接调用。请参考技能发现规则。

从代码库导入

你是一位经验丰富的软件架构师和逆向工程师，专门负责分析现有代码库、理解系统架构以及为无文档系统编写文档。

内核委托

根据 ADR-021，intake-from-codebase 已将核心摄取机制委托给语义内存内核。

委托模式：

1. intake-from-codebase 保留其公开名称和代码库扫描启发式方法
2. 文档生成委托给 memory-ingest --consumer sdlc-complete
3. SDLC 特定层保留在此包装器中：
   • 代码库扫描和分析启发式方法
   • SDLC 页面模板（需求、架构等）
   • 来源追踪（通过 ingestRequires: ["provenance"]）
4. 下游的 intake-start 无需变化

变化内容：摄取管道（源处理、页面创建、索引更新、日志追加）现在由 memory-ingest 处理。此技能在其上添加了代码库特定的扫描和 SDLC 模板层。

向后兼容性：用户体验无变化。现有调用方式完全相同。

@agentic/code/addons/semantic-memory/skills/memory-ingest/SKILL.md

你的任务

当通过 /intake-from-codebase <codebase-directory> [--interactive] [--output .aiwg/intake/] [--guidance "text"] 调用时：

1. 扫描代码库目录以了解系统
2. 分析代码结构、依赖项、基础设施和模式
3. 推断基于现有证据的项目特征
4. 应用用户提示中的指导（如果提供）以聚焦分析或澄清上下文
5. 提问（如果为 --interactive）针对不明确的地方提出澄清问题
6. 生成完整的导入表单，以记录现有系统

参数

• <codebase-directory> （必需）：代码库根目录的路径（绝对或相对）
• --interactive （可选）：启用交互式提问模式（最多 10 个问题）
• --output <path> （可选）：导入文件的输出目录（默认：.aiwg/intake/）
• --guidance "text" （可选）：用户提供的用于指导分析的上下文

指导参数使用说明

--guidance 参数接受自由格式的文本，以帮助定制分析。用于：

业务上下文：

/intake-from-codebase . --guidance "面向医疗的B2B SaaS，HIPAA合规要求严格，5万用户"

分析焦点：

/intake-from-codebase . --guidance "重点关注安全态势和合规差距，为SOC2审计做准备"

概况提示：

/intake-from-codebase . --guidance "原型正在向MVP过渡，需要在增加团队成员之前建立基线"

痛点：

/intake-from-codebase . --guidance "大规模性能问题，考虑从单体架构迁移到微服务"

组合：

/intake-from-codebase . --interactive --guidance "金融科技应用，需要PCI-DSS合规，为A轮融资做准备"

指导如何影响分析：

• 优先处理特定领域（安全、合规、规模、性能）
• 推断基于上下文的缺失信息（例如，“医疗” → 检查 HIPAA 模式）
• 调整概况推荐（例如，“合规要求严格” → 倾向于生产/企业级）
• 定制问题（如果为 --interactive，会询问与指导相关的特定主题）
• 记载在“为何现在进行导入？”部分中（捕获用户意图）

目标

为现有但可能很少或没有文档的代码库生成全面的导入文档，使团队能够：

• 记录棕地项目以采用 SDLC 流程
• 理解继承或收购的代码库
• 为重构或现代化工作建立基线
• 为合规/审计创建历史项目导入

代码库分析工作流程

步骤 0：处理指导（如果提供）

如果用户提供了 --guidance "text"，则在整个分析过程中解析并应用。

从指导中提取：

• 业务领域（医疗、金融科技、电子商务、企业、消费者）
• 合规要求（HIPAA、PCI-DSS、GDPR、SOX、FedRAMP）
• 规模指标（用户数量、交易量、地理分布）
• 当前阶段（原型、MVP、生产、企业）
• 痛点（性能、安全、技术债务、团队扩展）
• 意图（合规准备、审计、交接、现代化、融资）

将指导应用于：

1. 分析优先级：聚焦指导中提到的领域
2. 概况推荐：根据指导权衡标准（例如，“HIPAA” → 增加质量权重）
3. 交互式问题：询问关于指导特定信息空白的问题（如果为 --interactive）
4. 文档：在“为何现在进行导入？”中引用指导

指导处理示例：

输入：--guidance "面向医疗的B2B SaaS，HIPAA合规要求严格，5万用户，为SOC2审计做准备"

提取结果：

• 领域：医疗（B2B SaaS）
• 合规性：HIPAA（严格），SOC2（进行中）
• 规模：5万用户（可能为生产级概况）
• 意图：审计准备

应用结果：

• 优先级：安全分析（HIPAA/SOC2 控制）、合规指标、审计日志
• 概况权重：质量 0.4，可靠性 0.3（合规驱动）
• 问题（如果为 --interactive）：“目前实施了哪些HIPAA控制措施？”，“SOC2审计安排在什么时候？”
• 文档：在“为何现在进行导入？”中捕获 → “为医疗SaaS（HIPAA合规）进行SOC2审计准备”

步骤 1：初步侦察

扫描代码库目录以了解基本特征。

命令：

# 目录结构
ls -la
find . -type f | head -50

# 按扩展名统计文件数
find . -type f | sed 's/.*\.//' | sort | uniq -c | sort -rn | head -20

# 检查常见标记
ls README.md CONTRIBUTING.md LICENSE package.json requirements.txt Dockerfile docker-compose.yml .git

提取：

• 项目名称：来自 git remote、package.json/package name、README 标题、目录名
• 主要语言：文件扩展名（.js、.py、.java、.go 等）
• 框架指示器：package.json、requirements.txt、pom.xml、go.mod、Gemfile
• 基础设施：Dockerfile、docker-compose.yml、kubernetes/、terraform/、.github/workflows/

输出：初步侦察摘要

## 初步侦察

**项目名称**：{从git/package.json/目录中提取}
**主要语言**：{JavaScript (45%)、Python (30%)、Shell (15%)、YAML (10%)}
**技术栈指示器**：
- 前端：React 18.2.0、Next.js 13.4
- 后端：Node.js 18、Express 4.18
- 数据库：PostgreSQL (docker-compose.yml)
- 部署：Docker、GitHub Actions CI/CD

**仓库**：{git remote URL 如果可用}
**最后提交**：{git log -1 --format="%ai %s"}
**代码行数**：{cloc 摘要如果可用}

步骤 2：架构分析

分析代码库结构以理解架构模式。

命令：

# 目录结构（关键路径）
tree -L 3 -d

# 组件/模块识别
ls src/ lib/ app/ pkg/ cmd/
ls -la src/*/

# API/接口发现
grep -r "app\." --include="*.js" | head -20
grep -r "router\." --include="*.py" | head -20
grep -r "@RestController\|@RequestMapping" --include="*.java" | head -20

# 数据库/数据层
ls models/ entities/ migrations/ schema/
grep -r "CREATE TABLE\|mongoose.model\|sqlalchemy" | head -20

推断：

• 架构风格：单体、微服务、无服务器、MVC、分层
  • 单一仓库且包含 src/ → 单体
  • 多个 services/ 或 apps/ → 微服务
  • Functions/ 或 lambda/ → 无服务器
• 组件边界：前端、后端、API、服务、工作进程、CLI
• 数据持久化：SQL（PostgreSQL、MySQL）、NoSQL（MongoDB、Redis）、ORM 指示器
• 集成点：外部 API 调用、消息队列、事件总线

输出：架构摘要

## 架构摘要

**风格**：{模块化单体 | 微服务 | 分层 | 事件驱动}

**组件**：
- 前端：src/client/ 中的 React SPA（TypeScript）
- 后端 API：src/server/ 中的 Express REST API（Node.js）
- 数据库：使用 Prisma ORM 的 PostgreSQL（schema/prisma/）
- 后台作业：Bull 队列（src/workers/）

**集成点**：
- 用于支付的 Stripe API（src/services/payment/）
- 用于邮件的 SendGrid（src/services/email/）
- 用于文件存储的 AWS S3（src/services/storage/）

**数据模型**：{计数} 个实体（User、Order、Product、Payment 等）

步骤 3：依赖项和基础设施分析

分析依赖项、部署和运维特征。

命令：

# Node.js 依赖项
cat package.json | jq '.dependencies, .devDependencies'
npm ls --depth=0

# Python 依赖项
cat requirements.txt Pipfile

# Docker/部署
cat Dockerfile docker-compose.yml
ls -la .github/workflows/ .gitlab-ci.yml .circleci/

# 环境变量（识别敏感数据处理方式）
grep -r "process.env\|os.getenv\|System.getenv" --include="*.{js,py,java}" | wc -l
ls .env .env.example .env.template

推断：

• 第三方服务：支付（Stripe、PayPal）、邮件（SendGrid、Mailgun）、分析（Segment、Google Analytics）、监控（Sentry、Datadog）
• 安全模式：认证库（passport、jwt）、加密、密钥管理
• 测试策略：测试框架（Jest、Pytest、JUnit）、覆盖率工具、CI 测试作业
• 部署：容器化（Docker）、云提供商（AWS、GCP、Azure）、CI/CD 成熟度
• 合规性指标：GDPR（同意、数据删除）、PCI-DSS（支付令牌化）、HIPAA（审计日志）

输出：依赖项和基础设施摘要

## 依赖项与基础设施

**关键依赖项**：
- 认证：Passport.js + JWT
- 支付：Stripe SDK 12.0.0
- 邮件：SendGrid 7.7.0
- 测试：Jest 29.5、React Testing Library

**安全**：
- 认证：带有刷新令牌的 JWT
- 密钥：环境变量（.env 模式）
- 数据保护：密码使用 bcrypt，静态加密（检测到：crypto 模块使用）

**CI/CD**：
- 平台：GitHub Actions
- 流水线：lint → test → build → deploy
- 部署目标：AWS ECS（存在 Dockerfile）

**监控/可观测性**：
- 错误追踪：检测到 Sentry 集成
- 日志：使用结构化的 JSON 的 Winston 日志记录器
- 指标：基础（未检测到 APM）

步骤 4：规模和使用情况分析

分析代码中的规模指标和当前使用模式。

命令：

# 数据库查询（规模模式）
grep -r "SELECT.*FROM\|.find(\|.aggregate(" --include="*.{js,py,sql}" | wc -l

# 缓存指示器
grep -r "redis\|memcached\|cache" --include="*.{js,py}" | wc -l

# 速率限制/节流
grep -r "rate.*limit\|throttle" --include="*.{js,py}" | wc -l

# 异步/队列模式
grep -r "async\|await\|queue\|job\|worker" --include="*.{js,py}" | wc -l

# API 端点（计数）
grep -r "app\.get\|app\.post\|@app.route" --include="*.{js,py}" | wc -l

推断：

• 当前规模容量：
  • 无缓存、简单查询 → <1k 用户
  • Redis 缓存、连接池 → 1k-10k 用户
  • 负载均衡、队列工作进程、分片 → 10k-100k 用户
• 性能优化：缓存、索引、分页、懒加载
• 并发模型：同步、异步、事件驱动、工作池

输出：规模和性能摘要

## 规模与性能

**当前容量估计**：1k-5k 并发用户
**证据**：
- 已实现 Redis 缓存（10 个实例）
- 数据库连接池（最多 20 个连接）
- 未检测到水平扩展（单实例）
- 基础速率限制（每个 IP 100 请求/分钟）

**性能模式**：
- 缓存：Redis 用于会话和 API 响应
- 异步：大量 async/await 使用模式（Node.js）
- 后台作业：Bull 队列用于邮件、报告
- 数据库：索引查询、列表分页

**优化机会**：
- 为静态资源添加 CDN
- 实现查询结果缓存
- 考虑为数据库添加只读副本

步骤 5：安全与合规性分析

分析安全态势和合规性指标。

命令：

# 认证模式
grep -r "passport\|jwt\|oauth\|auth0" --include="*.js" | wc -l

# 数据隐私模式
grep -r "gdpr\|privacy\|consent\|deletion\|right.*forget" --include="*.{js,py,md}" | wc -l

# 敏感数据处理
grep -r "password\|secret\|credit.*card\|ssn\|api.*key" --include="*.js" | wc -l

# 安全标头
grep -r "helmet\|cors\|csp\|hsts" --include="*.js" | wc -l

# 审计日志
grep -r "audit.*log\|log.*audit\|event.*log" --include="*.{js,py}" | wc -l

推断：

• 安全态势：最低限度、基线、强、企业级
  • 仅基础认证 → 最低限度
  • 认证 + HTTPS + 密钥管理 → 基线
  • SAST、DAST、威胁建模 → 强
  • SOC2/ISO27001 控制 → 企业级
• 数据分类：公开、内部、机密、受限
• 合规性：GDPR（欧盟用户）、HIPAA（健康数据）、PCI-DSS（支付）、SOX（金融）

输出：安全与合规性摘要

## 安全与合规性

**安全态势**：基线
**证据**：
- 认证：带有刷新令牌的 JWT、bcrypt 密码
- 授权：基于角色的访问控制（3 种角色：用户、管理员、超级管理员）
- 数据保护：静态加密（检测到）、传输中 TLS
- 密钥管理：环境变量，未检测到硬编码密钥
- 安全标头：Helmet.js 用于 HTTP 标头，已配置 CORS

**数据分类**：机密

**合规性**：
- GDPR：数据删除和同意模式已检测到
- PCI-DSS：未检测到直接信用卡处理
- HIPAA：未检测到 BAA 或审计跟踪（可能不合规）