Token导航 LogoToken导航TokenDH.com
研究检索需要联网github未标认证来源可访问clear审计通过

tdlTDL 搜索

Agent Skill

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

总安装

294

周安装

12

GitHub Stars

公开资料未说明

下载量

94
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

3

许可证

MIT

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 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

简介

TDL 提供软件开发可追溯性的系统化方法,含五阶段工作流程。

  • 通过随机 ID 防冲突、脚本自动化与模板标准化提升文档一致性。
  • 适用于中大型项目需求追踪与分布式团队协作。适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。
  • 每周安装量较低,建议评估社区活跃度后再集成。
  • tdl 属于研究检索类 Skill,可作为该场景下的辅助能力补充。

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.

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

04

需要参考平台分布和安装热度时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

补充不同宿主或平台的使用分布数据

能力 5

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

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