帮助开发者先定位 Eden 代码组件、关键类型与架构,再精准阅读相关文件
整体看是一个仅用于代码研究与导航的 prompt-only 技能,未声明密钥、远程端点或本机执行能力,风险较低。主要需要留意的是它面向大型源码仓库的阅读定位,可能引导访问较多本地代码,但这属于常规研究型工具能力。
未声明任何密钥、token 或环境变量需求,也未显示凭证收集/转发路径,因此没有明显凭证滥用面。
材料未给出任何远程端点 host,也未描述向外部服务发送用户数据,未见明确网络外发。
系统判定为 prompt-only,未见起进程、执行代码或调用系统级能力的描述。
技能会引导读取 eden/ 中的组件映射、架构图和相关源码文件,属于本地代码导航/研究的常规读取范围,但未见超范围写入或额外数据权限。
来源为 GitHub 且已开源,可审计性较好;但许可证未声明、社区采用为 0 star、维护状态未知,供应链可信度中等偏保守。
复制安装指令,让 AI 自动完成配置 · 推荐新手
请帮我安装 askskill 上的 "eden_research" 技能: 1. 下载 https://raw.githubusercontent.com/facebook/sapling/main/eden/.llms/skills/eden_research/SKILL.md 2. 保存为 ~/.claude/skills/eden_research/SKILL.md 3. 装好后重载技能,告诉我可以用了
先加载 eden_research,然后告诉我 Mononoke 中负责权限检查的组件在哪些文件里,并按“必读、次读、参考”列出阅读顺序。
返回对应组件的文件清单、建议阅读顺序,以及相关类型或架构线索。
先加载 eden_research,概述 EdenFS、Sapling 和 Mononoke 的关系,并指出每个系统最关键的入口文件和核心类型名。
输出一份精炼的架构概览,并附上各系统应优先阅读的文件与类型。
先加载 eden_research。我要修复 Sapling 中一次提交流程的问题,请根据组件映射告诉我应该先看哪些文件,再看哪些辅助模块。
给出面向修复任务的阅读路线,包括核心文件、辅助模块和排查重点。
Oncalls: scm_client_infra · scm_server_infra · sapling
Eden is Meta's source control ecosystem comprising three major sub-projects that together provide fast, scalable version control for massive monorepos. EdenFS lazily virtualizes the filesystem, Sapling provides the CLI, and Mononoke serves as the backend.
eden/common/Developer's machine Meta's servers
┌──────────────────────────────────┐ ┌──────────────────────────────────┐
│ Sapling CLI (eden/scm/) │ │ Mononoke (eden/mononoke/) │
│ Rust + Python │ oncall: sapling │ │ Rust │ oncall: scm_server_infra │
│ User commands: sl status, │ │ │
│ sl commit, sl goto, sl rebase │ │ ┌────────────────────────────┐ │
│ │ │ │ │ SLAPI Server │ │
│ ▼ │ │ │ (servers/slapi/) │ │
│ EdenFS (eden/fs/) │ │ │ EdenAPI REST endpoints │ │
│ C++ │ oncall: scm_client_infra │ │ └───────────┬────────────────┘ │
│ Virtual filesystem daemon │ │ │ │
│ Lazy-loads files on demand │ │ ┌───────────▼────────────────┐ │
│ │ │ │ │ Mononoke API │ │
│ ┌────▼─────────────────┐ │ │ │ (mononoke_api/) │ │
│ │ SaplingBackingStore │─── EdenAPI ──▶│ └───────────┬────────────────┘ │
│ │ (Rust FFI bridge) │ │ │ │ │
│ └──────────────────────┘ │ │ ┌───────────▼────────────────┐ │
│ │ │ │ Blobstore Stack │ │
│ ┌──────────────────────────┐ │ │ │ prefix→cache→multiplex │ │
│ │ eden/common/ │ │ │ │ →pack→sqlblob/manifold │ │
│ │ Shared: ImmediateFuture, │ │ │ └────────────────────────────┘ │
│ │ PathFuncs, FaultInjector,│ │ │ │
│ │ TraceBus, RefPtr │ │ │ ┌────────────────────────────┐ │
│ └──────────────────────────┘ │ │ │ SCS Server (Thrift) │ │
│ │ │ │ (servers/scs/) │ │
└──────────────────────────────────┘ └──────────────────────────────────┘
Also: eden/integration/ (Python, end-to-end tests), eden/addons/ (TypeScript, Interactive Smartlog UI).
User process reads file
→ Kernel VFS → EdenFS FsChannel (FUSE/NFS/PrjFS)
→ Dispatcher → InodeMap → FileInode
→ materialized? → Overlay (local disk)
→ non-materialized? → BlobAccess → ObjectStore
→ BlobCache hit? → return
→ miss → SaplingBackingStore (Rust FFI)
→ EdenAPI HTTP → Mononoke SLAPI Server
→ Mononoke API → Blobstore Stack → storage
sl commit)User runs `sl commit`
→ Sapling CLI (Rust command dispatch)
→ workingcopy lib: scan EdenFS for changes (Thrift: getScmStatusV2)
→ EdenFS: diff working copy vs parent commit
→ Sapling: create commit object
→ EdenAPI client → Mononoke: upload trees + files + commit
sl goto)User runs `sl goto <rev>`
→ Sapling CLI → EdenFS Thrift: checkOutRevision()
→ EdenServiceHandler → EdenMount::checkout()
→ rootInode->checkout() → computeCheckoutActions(): diff old→new tree
→ CheckoutAction::run(): materialize/dematerialize inodes
…
检索欧盟委员会组件库文档与代码示例,快速获取开发配方与参考实现