try

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Try: Structured Library Exploration

试用：结构化库探索

You are exploring a library the user wants to evaluate. Your job is to bridge the gap between a too-simple quickstart and full codebase integration. You will:

Set up an isolated workspace
Discover the library's real API surface (not just what the README shows)
Write small, runnable scripts that each prove ONE primitive works
Write a composition script that wires primitives together
Document everything in Tutorial.md with an honest verdict

Keep this scoped to disposable exploration only. Do not refactor or integrate the target library into the user's production repository during this skill.

你正在探索用户想要评估的一个库。你的任务是填补过于简单的快速入门文档与完整代码库集成之间的空白。你需要：

搭建隔离的工作区
发现库的真实API表面（不只是README中展示的内容）
编写小型可运行脚本，每个脚本仅验证一个原语的功能
编写一个组合脚本，将多个原语串联起来
在Tutorial.md中记录所有内容并给出真实测评结论

请将范围限定在一次性探索内。在此技能使用过程中，请勿将目标库重构或集成到用户的生产仓库中。

Invocation Patterns

调用场景

The user will say something like:

```
/try ComposioHQ/agent-orchestrator
```

/try https://github.com/some/repo — help me build X

explore langgraph, I want to understand the state machine primitives

```
kick the tires on better-auth
```

They may optionally provide:

A screenshot or context about what they want to build
A specific angle ("focus on the streaming API")
A constraint ("I need this to work with Bun")

用户会以类似以下方式提出需求：

```
/try ComposioHQ/agent-orchestrator
```

/try https://github.com/some/repo — 帮我构建X

探索langgraph，我想了解它的状态机原语

```
初步体验better-auth
```

用户可能还会额外提供：

一张截图或关于想要构建内容的上下文
特定探索方向（“重点关注流式API”）
约束条件（“我需要它能在Bun环境下运行”）

Phase 0: Setup

阶段0：环境搭建

WORKSPACE SETUP
───────────────
  ┌──────────────┐     ┌──────────────┐     ┌──────────────┐
  │ User says    │     │ Clone repo   │     │ Create       │
  │ "/try X"     │────>│ into         │────>│ scratch/     │
  │              │     │ /tmp/try-X/  │     │ workspace    │
  └──────────────┘     └──────────────┘     └──────────────┘

Determine the target: Parse the repo URL, package name, or shorthand.

Clone or install into an isolated directory:

GitHub repo →
```
git clone --depth 1
```
into
```
/tmp/try-<name>/
```

npm package →

mkdir /tmp/try-<name> && cd $_ && npm init -y && npm i <pkg>

pip package →

mkdir /tmp/try-<name> && cd $_ && python -m venv .venv && source .venv/bin/activate && pip install <pkg>

Create the scratch workspace inside the clone:

/tmp/try-<name>/
├── scratch/           ← your scripts go here
│   ├── 01-<primitive>.{ts,py,js}
│   ├── 02-<primitive>.{ts,py,js}
│   ├── ...
│   └── 99-compose.{ts,py,js}
└── Tutorial.md        ← your writeup

try

CLI (github.com/tobi/try) is installed and the user wants filesystem isolation, use it. Otherwise,

/tmp/

is fine — this is disposable exploration.

WORKSPACE SETUP
───────────────
  ┌──────────────┐     ┌──────────────┐     ┌──────────────┐
  │ 用户输入     │     │ 克隆仓库到   │     │ 创建         │
  │ "/try X"     │────>│ /tmp/try-X/  │────>│ scratch/     │
  │              │     │              │     │ 工作区       │
  └──────────────┘     └──────────────┘     └──────────────┘

确定目标：解析仓库URL、包名或简写形式。

克隆或安装到隔离目录：

GitHub仓库 → 执行
```
git clone --depth 1
```
克隆到
```
/tmp/try-<name>/
```

npm包 → 执行

mkdir /tmp/try-<name> && cd $_ && npm init -y && npm i <pkg>

pip包 → 执行

mkdir /tmp/try-<name> && cd $_ && python -m venv .venv && source .venv/bin/activate && pip install <pkg>

在克隆的仓库内创建临时工作区：

/tmp/try-<name>/
├── scratch/           ← 你的脚本存放位置
│   ├── 01-<primitive>.{ts,py,js}
│   ├── 02-<primitive>.{ts,py,js}
│   ├── ...
│   └── 99-compose.{ts,py,js}
└── Tutorial.md        ← 你的测评文档

如果已安装try CLI（github.com/tobi/try）且用户需要文件系统隔离，则使用该工具。否则，使用

/tmp/

目录即可——这是一次性的探索环境。

Phase 1: Recon

阶段1：侦察

Goal: Understand the library's actual surface area. Do NOT start writing code yet.

RECON SEQUENCE
──────────────
  README → package.json/pyproject.toml → src/ tree → exports → examples/ → tests/

Read in this order. Stop at each step and extract:

README / docs/: What does the library claim to do? What's the mental model?
Package manifest: What are the dependencies? What does it actually export?

Source tree:

find src/ -name "*.ts" -o -name "*.py" | head -40

— get the shape.

Public API: Read the main entry point (index.ts, init.py, mod.rs). Extract every public function/class/type. This is the REAL API, not the README's cherry-picked version.
Examples/: If they exist, read them. Note what they cover and what they skip.
Tests/: Read 2-3 test files. Tests reveal edge cases, expected failures, and the library author's actual mental model better than docs do.

After recon, produce a mental inventory (don't write this to a file yet, just hold it):

PRIMITIVES IDENTIFIED
─────────────────────
  1. <PrimitiveName> — what it does, one line
  2. <PrimitiveName> — what it does, one line
  ...
  N. <Composition> — how they wire together

If the user gave a specific angle ("help me build an agent orchestrator"), filter primitives to what's relevant. If not, cover the top 5-8 most important ones.

目标：了解库的实际功能范围。请勿立即开始编写代码。

RECON SEQUENCE
──────────────
  README → package.json/pyproject.toml → src/ 目录结构 → 导出内容 → examples/ → tests/

按上述顺序查阅内容。在每个步骤暂停并提取信息：

README / docs/：该库声称能解决什么问题？它的核心设计思路是什么？
包清单：它的依赖项有哪些？实际导出了哪些内容？

源码目录：执行

find src/ -name "*.ts" -o -name "*.py" | head -40

—— 了解源码结构。

公开API：阅读主入口文件（index.ts、init.py、mod.rs）。提取所有公开的函数/类/类型。这才是真实的API，而非README中精心挑选的版本。
Examples/：如果存在示例，阅读它们。注意示例覆盖了哪些内容，以及遗漏了哪些内容。
Tests/：阅读2-3个测试文件。测试能比文档更准确地揭示边缘情况、预期故障模式以及库作者的真实设计思路。

侦察完成后，在脑海中整理出一份清单（无需写入文件，仅作记录）：

已识别的原语
─────────────────────
  1. <PrimitiveName> — 功能描述，一行即可
  2. <PrimitiveName> — 功能描述，一行即可
  ...
  N. <Composition> — 原语之间的组合方式

如果用户指定了特定探索方向（“帮我构建一个agent编排器”），则筛选出相关的原语。否则，覆盖最重要的5-8个原语。

Phase 2: Primitive Scripts

阶段2：原语脚本

Goal: One script per primitive. Each script is self-contained and runnable.

SCRIPT STRUCTURE
────────────────
  ┌─ scratch/01-<name>.ts ──────────────────────────┐
  │                                                   │
  │  // PRIMITIVE: <Name>                             │
  │  // WHAT: <one-line description>                  │
  │  // EXPECT: <what should happen when you run it>  │
  │                                                   │
  │  <minimal setup>                                  │
  │  <exercise the primitive>                         │
  │  <print/assert the result>                        │
  │                                                   │
  │  // FINDINGS:                                     │
  │  // - <what you learned>                          │
  │  // - <gotchas, if any>                           │
  │  // - <what the docs didn't mention>              │
  │                                                   │
  └───────────────────────────────────────────────────┘

Rules for primitive scripts:

One concept per file. No script should exercise more than one primitive.
Actually run each script after writing it. Capture stdout/stderr.
If it fails, debug it. The failure itself is valuable intel — note it in FINDINGS.
If the docs are wrong, note it. This is one of the main values of /try.
Use the library's native patterns, not wrappers. You want to feel the raw API.
Name files with numeric prefix for reading order: 01-, 02-, 03-, etc.
Match the library's language. If it's a TS library, write TS. If Python, write Python.

After each script runs, update your mental model. Adjust the plan for remaining scripts if you discover something unexpected.

目标：每个原语对应一个脚本。每个脚本需独立且可运行。

脚本结构
────────────────
  ┌─ scratch/01-<name>.ts ──────────────────────────┐
  │                                                   │
  │  // PRIMITIVE: <原语名称>                         │
  │  // 功能: <一行描述>                              │
  │  // 预期结果: <运行脚本后应出现的情况>             │
  │                                                   │
  │  <最小化初始化代码>                                │
  │  <调用原语进行测试>                                │
  │  <打印/断言执行结果>                                │
  │                                                   │
  │  // 测评发现:                                     │
  │  // - <你学到的内容>                              │
  │  // -  <注意事项（如果有）>                        │
  │  // - <文档中未提及的内容>                        │
  │                                                   │
  └───────────────────────────────────────────────────┘

原语脚本编写规则：

每个文件仅对应一个概念。单个脚本不得测试多个原语。
编写完成后立即运行。编写每个脚本后都要执行它，捕获标准输出/错误。
如果脚本运行失败，进行调试。失败本身就是有价值的信息——在“测评发现”中记录它。
如果文档内容有误，记录下来。这是
```
/try
```
技能的核心价值之一。
使用库的原生模式，不要使用包装器。你需要感受最原始的API体验。
文件名称添加数字前缀以指定阅读顺序：01-、02-、03-等。
与库的开发语言保持一致。如果是TS库，就写TS脚本；如果是Python库，就写Python脚本。

每个脚本运行后，更新你的认知模型。如果发现意外情况，调整剩余脚本的编写计划。

Phase 3: Composition Script

阶段3：组合脚本

Goal: Wire 2-4 primitives together into something that resembles a real use case.

  scratch/99-compose.ts
  ─────────────────────
  // COMPOSITION: <what this demonstrates>
  // PRIMITIVES USED: 01, 03, 05
  // SCENARIO: <realistic-ish use case>

This is where you find out if the library's primitives actually compose well or if there are impedance mismatches. The composition script should:

Use the primitives you proved work in Phase 2
Simulate a realistic (but minimal) workflow
Handle at least one error case
Print clear output showing what happened at each step

If the user provided a screenshot or description of what they want to build, the composition should approximate that.

目标：将2-4个原语组合成一个类似真实使用场景的示例。

  scratch/99-compose.ts
  ─────────────────────
  // COMPOSITION: <本脚本展示的内容>
  // 使用的原语: 01, 03, 05
  // 场景: <接近真实的使用案例>

这一步是为了验证库的原语是否能良好组合，或者是否存在适配问题。组合脚本应满足：

使用阶段2中已验证可用的原语
模拟一个真实（但极简）的工作流程
处理至少一种错误情况
打印清晰的输出，展示每个步骤的执行情况

如果用户提供了截图或想要构建内容的描述，组合脚本应尽量接近该需求。

Phase 4: Tutorial.md

阶段4：Tutorial.md文档

Write

Tutorial.md

in the repo root. Structure:

markdown

undefined

在仓库根目录下编写

Tutorial.md

。结构如下：

markdown

undefined

Trying: <library-name>

试用：<库名称>

<one-line verdict: would you use this in production?>

<一行结论：你是否会在生产环境中使用它？>

What It Is

库简介

<2-3 sentences. What problem does it solve? What's the mental model?>

<2-3句话。它解决什么问题？核心设计思路是什么？>

Key Primitives

关键原语

1. <Primitive Name>

1. <原语名称>

<功能描述。你发现的惊喜之处。链接到scratch/01-*脚本。>

2. <Primitive Name>

2. <原语名称>

...

Composition

组合示例

<原语如何组合在一起。哪些部分运行顺畅，哪些部分存在不便。链接到scratch/99-compose脚本。>

Gotchas

注意事项

<项目符号列表。文档未提及的内容。故障模式。缺失的功能。版本问题。>

Verdict

最终结论

<Honest assessment:> <- Maturity (alpha/beta/production)> <- API ergonomics (1-5)> <- Docs quality (1-5)> <- Would I build on this? Why/why not?> <- What I'd want to see before committing> ```

<真实测评：> <- 成熟度（alpha/beta/生产级）> <- API易用性（1-5分）> <- 文档质量（1-5分）> <- 你是否会基于它进行开发？为什么？> <- 投入使用前你希望看到哪些改进>

undefined

Execution Discipline

执行准则

Throughout all phases, follow this cadence:

LOOP (per script)
─────────────────
  WRITE ──> RUN ──> OBSERVE ──> NOTE FINDINGS
    ^                                 │
    └─────── ADJUST PLAN ─────────────┘

Write small, run often. Don't write 5 scripts then run them all.
Capture real output. Include actual stdout in Tutorial.md findings, trimmed.
If something takes >2 minutes to debug, note it as a complexity signal and move on.
Don't fake it. If a primitive doesn't work, say so. The user is evaluating whether to invest time in this library. Honest signal > polished demo.

在所有阶段中，遵循以下流程：

循环（每个脚本）
─────────────────
  编写 ──> 运行 ──> 观察 ──> 记录发现
    ^                                 │
    └─────── 调整计划 ─────────────┘

小步编写，频繁运行。不要一次性编写5个脚本再统一运行。
捕获真实输出。在Tutorial.md的发现部分中包含实际的标准输出（可适当精简）。
如果调试时间超过2分钟，记录为复杂度信号并继续下一步。
不要造假。如果某个原语无法正常工作，如实记录。用户正在评估是否要投入时间学习该库，真实的反馈比完美的演示更重要。

Output Checklist

输出检查清单

Before declaring done, verify:

  ✓ scratch/ contains 3-8 numbered primitive scripts
  ✓ scratch/99-compose.{ts,py} exists and runs
  ✓ Every script in scratch/ was actually executed
  ✓ Tutorial.md exists with all sections filled
  ✓ Tutorial.md verdict is honest, not promotional
  ✓ All gotchas from debugging are captured

完成所有步骤前，验证以下内容：

  ✓ scratch/目录下包含3-8个带数字前缀的原语脚本
  ✓ scratch/99-compose.{ts,py}存在且可运行
  ✓ scratch/目录下的所有脚本均已实际执行
  ✓ Tutorial.md已存在且所有章节均已填写
  ✓ Tutorial.md中的结论真实客观，无夸大宣传
  ✓ 调试过程中发现的所有注意事项均已记录

Edge Cases

边缘情况

Repo requires API keys: Note it, mock if possible, skip if not. Don't ask the user for keys unless they offered.
Repo is huge (monorepo): Focus on the specific package the user mentioned. Use
```
find
```
and
```
grep
```
to navigate, don't try to read everything.
Repo is broken / won't install: That IS the finding. Write a short Tutorial.md noting what failed and bail. This saves the user hours.
Library is for a different runtime (e.g., user wants Bun but lib is Node-only): Try it anyway, note compatibility issues.
User provides a screenshot: Use the screenshot as context for what the composition script should approximate.

仓库需要API密钥：记录该情况，尽可能模拟，无法模拟则跳过。除非用户主动提供，否则不要向用户索要密钥。
仓库体积庞大（单体仓库）：聚焦用户提到的特定包。使用
```
find
```
和
```
grep
```
命令导航，不要试图阅读所有内容。
仓库损坏/无法安装：这本身就是重要发现。编写一份简短的Tutorial.md记录失败原因即可结束任务。这能为用户节省数小时的时间。
库适用于其他运行时（例如：用户希望在Bun环境下使用，但库仅支持Node.js）：仍尝试运行，记录兼容性问题。
用户提供截图：将截图作为组合脚本的参考，尽量接近截图中的需求。

Update Check

更新检查

On first use in a session, silently check for a newer version:

Fetch

https://raw.githubusercontent.com/abpai/skills/main/versions.json

Compare the version for
```
try
```
against this file's
```
metadata.version
```
.
If the remote version is newer, tell the user once:
try update available (local {X.Y} → remote {A.B}). Update:
```
npx skills update try
```
· or
```
cd <skills-repo> && git pull
```
If the fetch fails or web access is unavailable, skip silently.
Never block or delay the task for this check.

在会话中首次使用此技能时，静默检查是否有新版本：

获取

https://raw.githubusercontent.com/abpai/skills/main/versions.json

文件。

将本地
```
try
```
技能的版本与文件中的版本进行比较。
如果远程版本更新，仅告知用户一次：
try 技能有可用更新（本地版本 {X.Y} → 远程版本 {A.B}）。更新方式：
```
npx skills update try
```
· 或
```
cd <skills-repo> && git pull
```
如果获取失败或无网络访问权限，静默跳过此步骤。
永远不要因更新检查而阻塞或延迟任务执行。

undefined