Token导航 LogoToken导航

Agent Skill · 研究检索

sc-tdd(短时差)

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

sc-tdd 是研究检索类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为调用外部服务;许可证为 MIT,第三方扫描有提醒项,按安装量在研究检索类的 73,675 个 Skill 里排第 48,042。

总安装 706周安装 30GitHub Stars 17下载 247核验 2026-05-01

安装说明

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

安装方式

通过对话安装

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

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

命令行安装

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

skills.shnpx skills
npx skills add https://github.com/tony363/superclaude --skill sc-tdd

这个 Skill 是做什么的

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

sc-tdd 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中快速定位候选结果。适用于需要根据关键词或任务场景从来源线索中筛选信息的场景。通过 npx skills add 命令从指定 GitHub 仓库安装使用。

安装前建议确认权限范围、维护状态及是否触发联网或文件操作。可结合原始 README 进一步核验具体功能和使用方法。

来源仓库内路径:skills/sc-tdd

上手步骤

4 步
  1. 1

    确认自己的宿主工具

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

  2. 2

    拿到安装命令

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

  3. 3

    安装后重启宿主

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

  4. 4

    按最小权限试用

    它需要调用外部服务,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

sc-tdd 怎么安装?

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

sc-tdd 支持哪些 AI 工具?

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

sc-tdd 需要什么权限?

权限级别是调用外部服务。该 Skill 可能调用第三方服务、云服务或外部模型 API,使用前需要确认账号、额度、数据发送范围和服务条款。

sc-tdd 是免费的吗?

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

sc-tdd 用的人多吗?

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

sc-tdd 安全吗?

第三方扫描有提醒项,说明存在需要人工确认的行为。安装前请打开源码看清它读了什么、联网到哪里。

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

值得选的地方

  • 同时适配 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调用外部服务未明确有提醒
sc-tdd

短时差 · 本页

70617调用外部服务MIT有提醒

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

SKILL.md 原文

Test-Driven Development (TDD) Skill

Strict Red-Green-Refactor workflow enforcement with automated validation.

This skill acts as a TDD workflow state machine that enforces discipline through validators. It prevents common TDD anti-patterns and ensures proper test-first development.

Quick Start

# Start TDD for a new feature
/sc:tdd "add user password validation"

# TDD with specific framework
/sc:tdd payment-module --framework pytest

# Fast mode (skip full suite after green, run at end)
/sc:tdd api-endpoint --fast

# Allow snapshot tests
/sc:tdd ui-component --allow-snapshots

Behavioral Flow

This skill enforces a 7-step Red-Green-Refactor cycle:

  1. Initialize - Detect scope, framework, create state
  2. RED: Write Failing Test - Create test for missing functionality
  3. RED: Validate Failure - Run validator, confirm SEMANTIC failure (assertion, not compile error)
  4. GREEN: Implement Minimally - Write smallest code to pass test
  5. GREEN: Validate Passing - Run validators, confirm test passes + no regressions
  6. REFACTOR: Improve Design - Clean up with tests as safety net
  7. REFACTOR: Validate Stability - Re-run suite, confirm still green

State Machine

IDLE → RED_PENDING → RED_CONFIRMED → GREEN_PENDING →
GREEN_CONFIRMED → REFACTOR_PENDING → REFACTOR_COMPLETE → [cycle repeats]

Critical Rules:

  • Validator output is source of truth - If validator says blocked, you MUST stop
  • Exit codes matter: 0 = allowed, 2 = blocked, 3 = error (ask user for help)
  • No bypassing - Every phase transition requires validator approval

Phase 1: Initialize (IDLE → RED_PENDING)

When: User requests TDD workflow

Your Actions:

  1. Detect scope root:
python .claude/skills/sc-tdd/scripts/framework_detector.py \
  --detect-scope $(pwd) \
  --json
  1. Initialize state:
python .claude/skills/sc-tdd/scripts/tdd_state_machine.py \
  --scope-root <detected_scope> \
  --init \
  --json
  1. Transition to RED_PENDING:
python .claude/skills/sc-tdd/scripts/tdd_state_machine.py \
  --scope-root <scope> \
  --phase RED_PENDING \
  --evidence "User requested: <feature_description>" \
  --json

Output: Confirm initialization, explain RED phase rules to user

Phase 2: Write Failing Test (RED_PENDING)

Rules:

  • User writes test first
  • You MAY help write the test
  • You MAY add empty stubs/interfaces to make test compile (e.g., pass, raise NotImplementedError, empty functions)
  • You MUST NOT write production implementation yet

Your Actions:

  1. Help user write test file
  2. Explain test must fail with assertion (not compile error)
  3. When test is written, proceed to validation

Phase 3: Validate Red (RED_PENDING → RED_CONFIRMED)

CRITICAL: You MUST run this validator before proceeding.

Command:

python .claude/skills/sc-tdd/scripts/validate_red.py \
  --scope-root <scope> \
  --json

Interpretation:

  • Exit code 0 + "allowed": true → Proceed to RED_CONFIRMED
  • Exit code 2 + "allowed": false → STOP, show user reasons, ask them to fix

Common Blocking Reasons:

  • "Test failed but NOT with semantic assertion" - Compile error, need to fix test
  • "Test PASSED (expected failure)" - Test not actually testing the feature
  • "No changed test files found" - Forgot to write test

If Blocked: Show user the reasons array, artifacts.test_output, and ask them to address the issue. DO NOT propose production code until validator allows.

If Allowed: Store artifacts.intent_test information, transition state, proceed to GREEN phase.

Phase 4: Implement Minimally (RED_CONFIRMED → GREEN_PENDING)

Rules:

  • Write MINIMAL implementation to pass the test
  • Focus on making test pass, not perfection
  • NO premature optimization
  • NO extra features beyond test requirements

Your Actions:

  1. Confirm current state is RED_CONFIRMED
  2. Implement minimal production code
  3. Explain your implementation approach
  4. Transition to GREEN_PENDING:
python .claude/skills/sc-tdd/scripts/tdd_state_machine.py \
  --scope-root <scope> \
  --phase GREEN_PENDING \
  --evidence "Implemented: <description>" \
  --json
  1. Proceed to validation

Phase 5: Validate Green (GREEN_PENDING → GREEN_CONFIRMED)

CRITICAL: You MUST run this validator before claiming success.

Command (standard):

python .claude/skills/sc-tdd/scripts/validate_green.py \
  --scope-root <scope> \
  --json

Command (fast mode, skips full suite):

python .claude/skills/sc-tdd/scripts/validate_green.py \
  --scope-root <scope> \
  --skip-full-suite \
  --json

Interpretation:

  • Exit code 0 + "allowed": true → GREEN_CONFIRMED, proceed to refactor
  • Exit code 2 + "allowed": false → STOP, implementation insufficient

Common Blocking Reasons:

  • "Intent test still FAILING" - Implementation didn't make test pass
  • "Full test suite FAILED - REGRESSION DETECTED" - Broke existing tests

If Blocked: Show user the failure details, fix implementation, re-validate.

If Allowed: Celebrate! Test passes, no regressions. Ask user if they want to refactor or complete cycle.

Phase 6: Refactor (Optional, GREEN_CONFIRMED → REFACTOR_PENDING)

Rules:

  • Improve code quality WITHOUT changing behavior
  • Tests must continue passing
  • Allowed changes: extract methods, rename variables, improve clarity, remove duplication
  • NOT allowed: add features, change test expectations, weaken tests

Your Actions:

  1. Ask user if they want to refactor
  2. If yes, transition to REFACTOR_PENDING
  3. Propose refactorings
  4. Apply changes
  5. Re-run tests to confirm stability

Phase 7: Validate Refactor (REFACTOR_PENDING → REFACTOR_COMPLETE)

Command:

python .claude/skills/sc-tdd/scripts/validate_green.py \
  --scope-root <scope> \
  --json

(Same validator, ensures tests still pass)

If Allowed: Cycle complete! Ask user:

  • Continue with next test? (start new RED cycle)
  • Feature complete?

Flags

FlagTypeDefaultDescription
--frameworkstringautoTest framework: auto, pytest, jest, vitest, go, cargo
--fastboolfalseSkip full suite in GREEN, run only at feature completion
--allow-snapshotsboolfalseAllow snapshot tests as semantic failures
--strictboolfalseNo stubs allowed in RED (must be pure test-first)

Personas Activated

  • agent-test-automator - Test design expertise
  • guardian - Test quality validation
  • agent-python-pro / agent-typescript-react-expert - Language-specific implementation
  • architect - Architecture guidance

MCP Integration

  • PAL MCP

- mcp__pal__codereview - Review test quality and implementation - mcp__pal__debug - Investigate unexpected test failures

Anti-Patterns Detected & Blocked

Blocked by validators:

  • Production code before failing test
  • Compile errors counted as "red" (must be runtime assertion)
  • Test passing when it should fail
  • Weakened assertions during GREEN phase
  • Regressions in full suite

Warned by validators:

  • Snapshot tests (blocked unless --allow-snapshots)
  • Flaky patterns: sleep, network, random without mocking
  • Assertionless tests
  • Tests that always pass

Tool Coordination

  • Read - Read existing test files, implementation code, framework configs
  • Write - Create new test files, state files
  • Edit - Modify tests and implementation incrementally
  • Bash - Execute validator scripts (NON-NEGOTIABLE, always run validators)
  • Glob - Find test files, manifest files, CI configs
  • Grep - Search for test patterns, framework usage

Quality Dimensions

Evaluated on:

  • Correctness (30%) - Tests pass, implementation works as specified
  • Completeness (20%) - All test scenarios covered, edge cases handled
  • Testability (20%) - Tests are clear, maintainable, fast, deterministic
  • Maintainability (15%) - Code is clean, well-structured, no duplication
  • Discipline (15%) - Followed TDD process, no shortcuts, proper Red-Green-Refactor

Threshold: 70+ score required to mark feature complete

Examples

Example 1: Feature Development

/sc:tdd "add password validation: minimum 8 characters"

# Workflow enforced:
# 1. Initialize state for current directory scope
# 2. User/Claude writes test_password_validation.py:
#    def test_password_min_length():
#        assert validate_password("short") == False
#        assert validate_password("longenough") == True
# 3. Run validate_red.py → confirms test FAILS with AssertionError (no validate_password function)
# 4. Claude implements:
#    def validate_password(password: str) -> bool:
#        return len(password) >= 8
# 5. Run validate_green.py → confirms test PASSES, full suite GREEN
# 6. Ask user about refactoring
# 7. Feature complete or next cycle

Example 2: Bug Fix with TDD

/sc:tdd "fix: user deletion doesn't cascade to posts" --framework pytest

# Workflow:
# 1. Write test exposing bug (test fails showing cascade doesn't work)
# 2. Validate RED (confirms bug exists)
# 3. Fix cascade behavior
# 4. Validate GREEN (confirms bug fixed, no regressions)

Example 3: Monorepo Package

cd backend/user-service
/sc:tdd "add email validation"

# Auto-detects:
# - scope_root: backend/user-service (nearest package.json)
# - framework: jest (from package.json devDependencies)
# - Runs tests only in this package scope

Troubleshooting

"No testing framework detected"

Solution:

  1. Check if test framework is installed
  2. Specify manually: --framework pytest
  3. Ensure framework config exists (pytest.ini, jest.config.js, etc.)

"Test failed but NOT with semantic assertion"

Cause: Compile error, import error, syntax error

Solution:

  1. Fix test to compile and run
  2. Add empty stub if needed: def my_function(): raise NotImplementedError
  3. Re-run validate_red.py

"Full test suite timed out"

Solution:

  1. Use --fast mode for faster cycles
  2. Run full suite only at feature completion
  3. Investigate slow tests

"Multiple test files changed"

Cause: More than one test file modified (TDD requires focus)

Solution:

  1. Commit/stash other changes
  2. Work on one test at a time
  3. Use multiple micro-cycles

State Recovery

If state file is lost or corrupted:

  1. Validator will attempt recovery from git diff + current test results
  2. You can manually re-initialize: python tdd_state_machine.py --init --scope-root <path>
  3. State is per-scope, so multiple packages can have independent TDD states

Important Reminders

  1. ALWAYS run validators before phase transitions - This is non-negotiable
  2. Trust validator output over assumptions - If validator says blocked, stop
  3. Exit codes matter: Check both exit code AND "allowed" field in JSON
  4. One test at a time - TDD is about smallest increments
  5. Semantic failures only - Compile errors don't count as proper "red"
  6. Full suite matters - Don't skip unless using --fast mode explicitly

Version: 1.0.0 Last Updated: 2025-01-09 Maintainer: SuperClaude Framework

平台分布

Codex

26.53%
按下载量换算66

Claude Code

24.83%
按下载量换算61

windsurf

19.29%
按下载量换算48

trae

13.52%
按下载量换算33

OpenCode

7.35%
按下载量换算18

Cursor

3.35%
按下载量换算8

安全审计

Gen Agent Trust Hub

通过

Socket

可疑

Snyk

通过

权限和风险

调用外部服务

该 Skill 可能调用第三方服务、云服务或外部模型 API,使用前需要确认账号、额度、数据发送范围和服务条款。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在提醒或未通过项,安装前请自行复核。

继续浏览同类 Skills