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

tdd时差

Agent Skill

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

总安装

269

周安装

11

GitHub Stars

26

下载量

86
CodexClaudeCursorGemini CLI

安装说明

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

GitHub

来源数

3

许可证

MIT

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

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

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

命令行安装

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

skills.shnpx skills
npx skills add https://github.com/outfitter-dev/agents --skill tdd

简介

tdd 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。

  • 适用于测试驱动开发方法查询、实践案例或工具链研究等场景。
  • 通过关键词检索返回 TDD 流程、用例设计或自动化测试方案。
  • 安装命令为 npx skills add https://github.com/outfitter-dev/agents --skill tdd。
  • 使用前请确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写操作。

SKILL.md

Test-Driven Development

Write tests first, implement minimal code to pass, refactor systematically.

<when_to_use>

  • New features with TDD methodology
  • Complex business logic requiring coverage
  • Critical paths: auth, payments, data integrity
  • Bug fixes: reproduce with test, fix, verify
  • Refactoring: ensure behavior preservation
  • API design: tests define the interface

NOT for: exploratory coding, UI prototypes, static config, trivial glue code

</when_to_use>

Load the maintain-tasks skill for stage tracking. Advance through RED-GREEN-REFACTOR cycle.

StageTriggeractiveForm
RedSession start / cycle restart"Writing failing test"
GreenTest written and failing"Implementing code"
RefactorTests passing"Refactoring code"
VerifyRefactor complete"Verifying implementation"

Task format:

- Write failing test for { feature }
- Implement { feature } to pass tests
- Refactor { aspect }
- Verify { what's being checked }

Workflow:

  • Start: Create "Red" stage in_progress
  • Transition: Mark current completed, add next in_progress
  • After each stage: Run tests before advancing
  • Multiple cycles: Return to "Red" for next feature

Edge cases:

  • Good existing tests: Start at "Refactor" after confirming pass
  • Bug fix: Start at "Red" with failing test reproducing bug
  • No regression: Tests must continue passing through all stages
RED --> GREEN --> REFACTOR --> RED --> ...
 |       |          |
Test   Impl      Improve
Fails  Passes   Quality

Each cycle: 5-15 min. Longer = step too large, decompose.

Philosophy:

  • Red-Green-Refactor as primary workflow
  • Test quality over quantity - behavior, not implementation
  • Incremental progress - small focused cycles
  • Type safety throughout - tests as type-safe as production

<red_phase>

Write tests defining desired behavior before implementation exists.

Guidelines:

  • 3-5 related tests fully specifying one feature
  • Type system makes invalid states unrepresentable
  • Each test = one specific behavior
  • Run tests, verify fail for right reason
  • Descriptive names forming sentences

TypeScript:

import { describe, test, expect } from 'bun:test'

describe('UserAuthentication', () => {
  test('authenticates with valid credentials', async () => {
    const result = await authenticate({ email: 'user@example.com', password: 'SecurePass123!' })
    expect(result).toMatchObject({ type: 'success', user: expect.objectContaining({ email: 'user@example.com' }) })
  })

  test('rejects invalid credentials', async () => {
    const result = await authenticate({ email: 'wrong@example.com', password: 'wrong' })
    expect(result).toMatchObject({ type: 'error', code: 'INVALID_CREDENTIALS' })
  })

  test.todo('implements rate limiting after failed attempts')
})

Rust:

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn authenticates_with_valid_credentials() {
        let creds = Credentials { email: "user@example.com".into(), password: "SecurePass123!".into() };
        assert!(matches!(authenticate(&creds), Ok(AuthResult::Success { .. })));
    }

    #[test]
    fn rejects_invalid_credentials() {
        let creds = Credentials { email: "wrong@example.com".into(), password: "wrong".into() };
        assert!(matches!(authenticate(&creds), Err(AuthError::InvalidCredentials)));
    }
}

Commit: test: add failing tests for [feature]

Transition: Mark "Red" completed, create "Green" in_progress

</red_phase>

<green_phase>

Implement minimum code to make tests pass.

Guidelines:

  • Focus on passing tests, not perfect code
  • Explicit types where aids clarity
  • Straightforward solutions first
  • Hardcode if passes test - refactor generalizes
  • Run tests frequently

TypeScript:

type AuthResult = { type: 'success'; user: User } | { type: 'error'; code: string }

async function authenticate(creds: { email: string; password: string }): Promise<AuthResult> {
  if (!creds.password) return { type: 'error', code: 'MISSING_PASSWORD' }
  const user = await findUserByEmail(creds.email)
  if (!user) return { type: 'error', code: 'INVALID_CREDENTIALS' }
  const match = await comparePassword(creds.password, user.passwordHash)
  if (!match) return { type: 'error', code: 'INVALID_CREDENTIALS' }
  return { type: 'success', user }
}

Rust:

pub fn authenticate(creds: &Credentials) -> Result<AuthResult, AuthError> {
    if creds.password.is_empty() { return Err(AuthError::MissingPassword); }
    let user = find_user_by_email(&creds.email).ok_or(AuthError::InvalidCredentials)?;
    if !compare_password(&creds.password, &user.password_hash) {
        return Err(AuthError::InvalidCredentials);
    }
    Ok(AuthResult::Success { user })
}

Verify: bun test / cargo test

Commit: feat: implement [feature] to pass tests

Transition: Mark "Green" completed, create "Refactor" in_progress

</green_phase>

<refactor_phase>

Enhance code quality without changing behavior. Tests must continue passing.

Guidelines:

  • Extract common patterns into well-named functions
  • Apply SOLID principles where appropriate
  • Improve types: discriminated unions, branded types
  • No test behavior changes
  • Run tests after each step

TypeScript:

// Extract validation
function validateCredentials(creds: { email: string; password: string }): AuthResult | null {
  if (!creds.password) return { type: 'error', code: 'MISSING_PASSWORD' }
  if (!isValidEmail(creds.email)) return { type: 'error', code: 'INVALID_EMAIL' }
  return null
}

// Branded types for safety
type Email = string & { readonly __brand: 'Email' }

Rust:

// Extract validation
fn validate_credentials(creds: &Credentials) -> Result<(), AuthError> {
    if creds.password.is_empty() { return Err(AuthError::MissingPassword); }
    if !is_valid_email(&creds.email) { return Err(AuthError::InvalidEmail); }
    Ok(())
}

// Newtype for safety
pub struct Email(String);

Verify: bun test / cargo test

Commit: refactor: [improvement description]

Transition: Mark "Refactor" completed, create "Verify" in_progress

Final: Run full suite. Mark "Verify" completed when all checks pass.

</refactor_phase>

Follow project conventions, defaulting to:

TypeScript/Bun:

src/{module}/{name}.ts          # Implementation
src/{module}/{name}.test.ts     # Unit tests colocated
src/{module}/__fixtures__/      # Test data
tests/integration/              # Integration tests
tests/e2e/                      # End-to-end tests

Rust:

src/{module}/mod.rs             # #[cfg(test)] mod tests { ... }
tests/integration/              # Integration tests
tests/fixtures/                 # Test data
MetricTarget
Line coverage>=80% (90% critical paths)
Mutation score>=75%
Unit test time<5s

Test characteristics:

  • Single clear assertion per test
  • No execution order dependencies
  • Descriptive names forming sentences
  • Behavior focus, not implementation

Smells to avoid:

  • Setup longer than test
  • Multiple unrelated assertions
  • Coupling to implementation details
  • Flaky tests

See quality-metrics.md for coverage and mutation testing details.

<bug_fixes>

TDD workflow for bugs:

  1. Write failing test reproducing bug (Start "Red" in_progress)
  2. Verify fails for right reason
  3. Fix with minimal code (Transition to "Green")
  4. Verify passes, all others still pass
  5. Refactor if needed (Transition to "Refactor" or skip to "Verify")
  6. Commit: fix: [bug description] with test coverage

Example:

// 1. Failing test
test('handles division by zero gracefully', () => {
  expect(divide(10, 0)).toMatchObject({ type: 'error', code: 'DIVISION_BY_ZERO' })
})

// 3. Fix
function divide(a: number, b: number): Result {
  if (b === 0) return { type: 'error', code: 'DIVISION_BY_ZERO' }
  return { type: 'success', value: a / b }
}

</bug_fixes>

ALWAYS:

  • Track progress with Tasks (load maintain-tasks skill)
  • Write tests before implementation (RED first)
  • Run tests after each stage
  • Verify tests fail for right reason in RED
  • Keep cycles 5-15 min max
  • Descriptive test names forming sentences
  • Test behavior, not implementation
  • Each test = one reason to fail

NEVER:

  • Skip to implementation without tests
  • Change test behavior during refactoring
  • Test implementation details or private methods
  • Allow tests to depend on execution order
  • Write flaky tests
  • Mark stage complete without running tests
  • Multiple unrelated assertions per test

<quick_reference>

# TypeScript/Bun
bun test                    # Run all tests
bun test --watch            # Watch mode
bun test --coverage         # Coverage report
bun test --only             # Run only .only tests
bun x stryker run           # Mutation testing

# Rust
cargo test                  # Run all tests
cargo test --test NAME      # Specific integration test
cargo tarpaulin             # Coverage report
cargo mutants               # Mutation testing
cargo test -- --nocapture   # Show println! output

</quick_reference>

适合场景

01

用户想查找某类 Agent Skill 时

02

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

03

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

04

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

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

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

能力 4

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

能力 5

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

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

平台分布

github-copilot

24.85%
按下载量换算21

kilo

24.73%
按下载量换算21

windsurf

18.08%
按下载量换算16

zencoder

11.8%
按下载量换算10

amp

7.55%
按下载量换算6

cline

3%
按下载量换算3

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

需要联网

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

安装前确认

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

来源信息

继续浏览同类 Skills