Token导航 LogoToken导航

Agent Skill · 研究检索

tdl(TDL 搜索)

tdl 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

tdl 是研究检索类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为需要联网;许可证为 MIT,第三方扫描已通过,按安装量在研究检索类的 73,675 个 Skill 里排第 64,698。

总安装 294周安装 12GitHub Stars 公开资料未说明下载 94核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
MIT

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:tdl(TDL 搜索)
来源仓库:https://github.com/takuan-osho/ccmarketplace
仓库路径:skills/tdl
安装命令:
npx skills add https://github.com/takuan-osho/ccmarketplace --skill tdl
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。不同来源提供的安装方式可能略有差异;本站展示可直接复制的安装命令,安装前请核对来源页面。

skills.shnpx skills
npx skills add https://github.com/takuan-osho/ccmarketplace --skill tdl

这个 Skill 是做什么的

研究检索类 Skill 主要解决「找资料、核对事实、把来源整理清楚」的问题,通常会让助手先检索再总结。

TDL 提供软件开发可追溯性的系统化方法,含五阶段工作流程。通过随机 ID 防冲突、脚本自动化与模板标准化提升文档一致性。适用于中大型项目需求追踪与分布式团队协作。适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

每周安装量较低,建议评估社区活跃度后再集成。tdl 属于研究检索类 Skill,可作为该场景下的辅助能力补充。

来源仓库内路径:skills/tdl

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/takuan-osho/ccmarketplace --skill tdl;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它需要需要联网,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

tdl 怎么安装?

在终端执行 npx skills add https://github.com/takuan-osho/ccmarketplace --skill tdl。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

tdl 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

tdl 需要什么权限?

权限级别是需要联网。该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

tdl 是免费的吗?

来源标注的许可证是 MIT。本站不代收任何费用,也不托管安装包;能否商用、要不要署名,以许可证原文为准。

tdl 用的人多吗?

公开数据是累计安装 294 次,近一周安装 12 次,下载 94 次。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

tdl 安全吗?

第三方扫描结果为通过,但这只覆盖已知的静态检查项,不能替代自己读一遍源码和安装命令。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 3 个目录同时收录,说明这个 Skill 流传比较广。
  • 许可证明确为 MIT,商用和分发边界好判断。
  • 第三方扫描已通过,常见的高风险行为没有命中。

先想清楚的地方

  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理研究检索类任务、又不想每次都手写提示词的人。
  • 需要许可证清楚、并且有第三方扫描结果的团队项目。

不太适合

  • 需要厂商级技术支持和 SLA 的生产系统。

研究检索类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
find-skills

寻找技能 · Codex、Claude

31,199,81316,486操作浏览器MIT有提醒
self-improving-agent

自我改进 Agent · OpenClaw

16,464,0023,396接触敏感数据MIT-0通过
soultrace

灵魂追踪 · Codex、Claude

7,588,94412需要联网未明确有提醒
self-improving

自我完善 · OpenClaw

6,829,2841,046需要联网MIT-0通过
microsoft-foundry

微软代工厂 · Codex、Claude

6,614,144764调用外部服务未明确有提醒
tdl

TDL 搜索 · 本页

294—需要联网MIT通过

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

Traceable Development Lifecycle (TDL) Skill

Overview

TDL is a template-based development process that ensures complete traceability from requirements to implementation. It supports parallel development by multiple developers or AI agents through random ID generation and distributed traceability.

Key Features

  • Random Base36 IDs: 5-character IDs (e.g., a3bf2) prevent conflicts in parallel development
  • Distributed Traceability: Each document maintains its own Links section - no central tracking file
  • 5-Phase Workflow: Analysis → Requirements → ADR → Design → Plan & Execution
  • Document Templates: Standardized templates for all document types

When to Use This Skill

Use this skill when:

  • Starting a new project and want to establish traceability from the beginning
  • Improving existing projects to add or enhance traceability practices
  • Creating documentation (Analysis, Requirements, ADRs, Design, Plans)
  • Working in parallel with other developers or AI agents
  • Troubleshooting production issues and need to trace back to requirements/design
  • Conducting requirement analysis and tracking implementation coverage

Interactive Mode (Claude Code only)

When running in Claude Code and the user's intent is unclear, use AskUserQuestion tool to clarify:

Document Type (if not specified in the user's request):

  • Question: "What type of TDL document do you want to create?"
  • Header: "Doc Type"
  • Options:

- "Analysis (AN-)" - Problem exploration and discovery - "Requirement (FR/NFR-)" - Formal specification with acceptance criteria - "ADR (ADR-)" - Architecture/design decision record - "Task (T-)" - Implementation plan with design.md and plan.md

Requirement Type (when creating a requirement):

  • Question: "What type of requirement is this?"
  • Header: "Req Type"
  • Options:

- "FR - Functional Requirement (Recommended)" - Feature or behavior specification - "NFR - Non-Functional Requirement" - Performance, security, scalability, etc.

NFR Category (when creating a non-functional requirement):

  • Question: "What category does this NFR belong to?"
  • Header: "Category"
  • Options:

- "Performance" - Response time, throughput - "Security" - Authentication, authorization, data protection - "Scalability" - Load handling, growth capacity - "Reliability" - Availability, fault tolerance

  • If user needs a different category, they can specify via the "Other" option

ADR Template (when creating an ADR):

  • Question: "Which ADR template should be used?"
  • Header: "Template"
  • Options:

- "Full ADR (Recommended)" - Comprehensive template for significant decisions - "Lite ADR" - Simplified template for tactical decisions

TDL Workflow Phases

┌─────────────┐    ┌──────────────┐    ┌─────────┐    ┌────────┐    ┌──────────────────┐
│  Analysis   │───▶│ Requirements │───▶│   ADR   │───▶│ Design │───▶│ Plan & Execution │
│   (AN-)     │    │   (FR/NFR)   │    │ (ADR-)  │    │        │    │                  │
└─────────────┘    └──────────────┘    └─────────┘    └────────┘    └──────────────────┘
     │                    │                 │              │                  │
     │                    │                 │              │                  │
     ▼                    ▼                 ▼              ▼                  ▼
  Explore             Formalize         Document       Technical       Implementation
  problem             what/why          decisions       design           phases

Phase 1: Analysis (AN-xxxxx)

Purpose: Explore problem space and discover requirements

Output: docs/analysis/AN-xxxxx-topic.md

python scripts/create_analysis.py "User Authentication Flow"

Lifecycle: Draft → Active → Complete → Archived (after requirements formalized)

Phase 2: Requirements (FR-xxxxx / NFR-xxxxx)

Purpose: Formalize what needs to be built with measurable acceptance criteria

Output:

  • Functional: docs/requirements/FR-xxxxx-topic.md
  • Non-Functional: docs/requirements/NFR-xxxxx-topic.md
python scripts/create_requirement.py "User Authentication" --type FR
python scripts/create_requirement.py "API Response Time" --type NFR --category Performance

Lifecycle: Proposed → Accepted → Implemented → Verified → (Deprecated)

Phase 3: Architecture Decision Records (ADR-xxxxx)

Purpose: Document important design decisions and their rationale

Output: docs/adr/ADR-xxxxx-topic.md

python scripts/create_adr.py "Use PostgreSQL for data storage"
python scripts/create_adr.py "Minor API change" --lite  # For tactical decisions

Lifecycle: Proposed → Accepted | Rejected → (Deprecated | Superseded by ADR-xxxxx)

Phase 4 & 5: Design and Plan (T-xxxxx)

Purpose: Technical design and phased implementation plan

Output: docs/tasks/T-xxxxx-topic/

  • design.md: How to implement (technical design)
  • plan.md: What to do (phased implementation)
python scripts/create_task.py "implement-user-auth" --requirements FR-a1b2c,FR-d3e4f

Lifecycle: Not Started → Phase X In Progress → Blocked → Under Review → Completed

Random ID System

TDL uses 5-character Base36 random IDs instead of sequential numbers to prevent conflicts in parallel development.

Why Random IDs?

Sequential IDsRandom IDs
FR-001, FR-002FR-a3bf2, FR-b4cd8
Conflicts when parallel workNo conflicts
Requires coordinationIndependent generation
Central tracking fileDistributed traceability

ID Format

  • Characters: 0-9 and a-z (Base36)
  • Length: 5 characters
  • Combinations: ~60 million
  • Collision probability: ~1% at 1,100 documents

Generate IDs

# Generate a raw ID
python scripts/tdl_new_id.py

# Generate with prefix
python scripts/tdl_new_id.py --prefix FR
# Output: FR-a3bf2

Directory Structure

docs/
├── analysis/           # Problem exploration (AN-xxxxx)
│   ├── archive/        # Completed analyses
│   └── AN-a3bf2-topic.md
├── requirements/       # Formal requirements (FR/NFR-xxxxx)
│   ├── FR-b4cd8-topic.md
│   └── NFR-c5de9-topic.md
├── adr/               # Architecture decisions (ADR-xxxxx)
│   ├── archive/       # Deprecated/superseded ADRs
│   └── ADR-d6ef0-topic.md
├── tasks/             # Implementation tasks (T-xxxxx)
│   └── T-e7fa1-topic/
│       ├── design.md
│       └── plan.md
└── templates/         # Document templates

Distributed Traceability

Every TDL document has a Links section that maintains relationships to other documents:

## Links

- **Analysis**: [AN-a3bf2](../analysis/AN-a3bf2-topic.md)
- **Requirements**: [FR-b4cd8](../requirements/FR-b4cd8-topic.md)
- **Related ADRs**: N/A – First implementation
- **Issue**: #123
- **PR**: N/A – Not yet submitted

Rules for Links

  1. Always include all link categories - use N/A – <reason> if not applicable
  2. Use relative paths for internal links
  3. External references go in a separate section
  4. Update links when relationships change

Available Scripts

Initialize TDL Structure

python scripts/init_tdl_docs.py [path]

Creates the complete directory structure and README files.

Generate Random ID

python scripts/tdl_new_id.py [--prefix PREFIX]

Generates a unique 5-character Base36 ID with optional prefix.

Create Documents

# Analysis
python scripts/create_analysis.py "Topic Name"

# Requirements
python scripts/create_requirement.py "Title" --type FR|NFR [--category Category]

# ADR
python scripts/create_adr.py "Decision Title" [--lite]

# Task (with design.md and plan.md)
python scripts/create_task.py "task-name" [--requirements FR-xxxxx,NFR-xxxxx]

Analyze Traceability

# Show status summary
python scripts/trace_status.py

# Detailed report
python scripts/trace_status.py --verbose

# CI mode (exit 1 if gaps found)
python scripts/trace_status.py --check

# Markdown output
python scripts/trace_status.py --format markdown

Document Templates

Common Structure

All documents follow this structure:

# Title

## Metadata

- **ID**: [TYPE-xxxxx]
- **Type**: [Document Type]
- **Owner**: [Person or role]
- **Reviewers**: [List]
- **Status**: [Status]
- **Date**: YYYY-MM-DD

## Links

- **[Link Type]**: [ID or N/A – reason]
...

## [Content Sections]
...

## External References

- [External links]

Template Rules

  1. Language: All documents in English
  2. Date format: YYYY-MM-DD
  3. ID placement: In Metadata, not in title
  4. Links section: Required in all documents

Code Integration

In Commits

git commit -m "feat(auth): Implement JWT authentication

Implements FR-b4cd8 User Authentication
Related ADR: ADR-d6ef0

Closes: #123"

In Code Comments

class AuthMiddleware:
    """JWT authentication middleware.

    Implements: FR-b4cd8
    Design: docs/tasks/T-e7fa1-implement-auth/design.md
    """

In Logs

logger.info(
    "User authenticated",
    extra={
        "requirement": "FR-b4cd8",
        "user_id": user_id,
        "action": "auth.login.success"
    }
)

Best Practices

Document Management

  1. Create documents using scripts - ensures proper ID generation and structure
  2. Update Links immediately - when relationships are established
  3. Archive completed analyses - after requirements are formalized
  4. Update status regularly - reflect current state

Parallel Development

  1. Always use random IDs - never manually assign sequential numbers
  2. Check traceability before merging - python scripts/trace_status.py --check
  3. No central tracking file - rely on Links sections in documents
  4. Resolve conflicts in content, not IDs - IDs should never conflict

Quality Assurance

  1. Run traceability analysis - before releases and in CI
  2. Fill all gaps - orphan requirements need tasks, orphan tasks need requirements
  3. Review Links section - in code reviews

Quick Start

For New Projects

# 1. Initialize structure
python scripts/init_tdl_docs.py

# 2. Start with analysis
python scripts/create_analysis.py "Initial Project Analysis"

# 3. Create requirements from analysis
python scripts/create_requirement.py "Core Feature" --type FR

# 4. Document design decisions
python scripts/create_adr.py "Technology Stack Selection"

# 5. Create implementation task
python scripts/create_task.py "implement-core-feature" --requirements FR-xxxxx

For Existing Projects

# 1. Initialize structure (won't overwrite existing)
python scripts/init_tdl_docs.py

# 2. Check current traceability
python scripts/trace_status.py

# 3. Document existing architecture
python scripts/create_adr.py "Current Architecture Overview"

# 4. Gradually add traceability to new work

Reference Materials

The references/ directory contains:

  • adr-template.md - ADR writing guide with examples
  • commit-message-guide.md - Commit message standards
  • pr-template.md - Pull request templates
  • logging-patterns.md - Structured logging patterns
  • api_reference.md - Script API documentation

Troubleshooting

"ID collision detected"

The script automatically retries up to 10 times. If this persists:

  • Check if docs/ directory has an unusually large number of documents
  • Manually verify the generated ID doesn't exist

"Traceability gaps identified"

Run python scripts/trace_status.py --verbose to see:

  • Requirements without implementing tasks
  • Tasks without linked requirements

"Links section missing"

All documents must have a Links section. Use the creation scripts to ensure proper structure.

Summary

TDL provides a systematic approach to software development traceability:

ComponentPurpose
Random IDsPrevent parallel development conflicts
5 PhasesStructured workflow from analysis to execution
Links SectionDistributed traceability without central file
ScriptsAutomate document creation and analysis
TemplatesEnsure consistent documentation

Start small, use the provided scripts, and gradually build a culture of traceability.

平台分布

Claude Code

29.06%
按下载量换算27

OpenCode

24.82%
按下载量换算23

Codex

16.93%
按下载量换算16

Antigravity

13.7%
按下载量换算13

windsurf

9.26%
按下载量换算9

trae

3.44%
按下载量换算3

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。

继续浏览同类 Skills