claude-init is an archived project template for initializing Claude Code development environments, with Chinese-localized configuration and workflows. Developers on macOS or Linux use it to set up agents, skills, commands, rules, hooks, and development contexts for Claude Code. Its catalogue entries provide the included commands, agents, hooks, and skills.
Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/cfrs2005/claude-init/tdd-workflownpx skills add cfrs2005/claude-init --skill tdd-workflowgit clone --depth 1 https://github.com/cfrs2005/claude-initWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/cfrs2005/claude-init/tdd-workflow)<a href="https://agentmods.dev/skills/cfrs2005/claude-init/tdd-workflow"><img src="https://agentmods.dev/badge/skills/cfrs2005/claude-init/tdd-workflow.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00072 | $0.02786 |
| Opus 5 | $0.00036 | $0.01393 |
| Sonnet 5 | $0.00014 | $0.00557 |
| Haiku 4.5 | $0.00007 | $0.00279 |
Grade A, and why
tdd-workflow (测试驱动开发工作流) scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 5d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 411 lines — stays where its author put it; the contents beside it link to each section on GitHub.
测试驱动开发 (TDD) 工作流
本技能确保所有代码开发遵循 TDD 原则,并具有全面的测试覆盖率。
何时激活
- 编写新特性或功能
- 修复 Bug 或问题
- 重构现有代码
- 添加 API 端点
- 创建新组件
核心原则
1. 先写测试,再写代码 (Tests BEFORE Code)
始终先编写测试,然后实现代码以使测试通过。
2. 覆盖率要求
- 最低 80% 覆盖率 (单元 + 集成 + E2E)
- 覆盖所有边缘情况
- 测试错误场景
- 验证边界条件
3. 测试类型
单元测试 (Unit Tests)
- 独立函数和工具
- 组件逻辑
- 纯函数
- 辅助函数和工具
集成测试 (Integration Tests)
- API 端点
- 数据库操作
- 服务交互
- 外部 API 调用
E2E 测试 (Playwright)
- 关键用户流程
- 完整工作流
- 浏览器自动化
- UI 交互
TDD 工作流步骤
步骤 1: 编写用户旅程 (User Journeys)
作为 [角色],我想要 [行动],以便 [收益]
示例:
作为用户,我想要进行语义化的市场搜索,
以便即使没有确切的关键词也能找到相关的市场。
步骤 2: 生成测试用例
为每个用户旅程创建全面的测试用例:
describe('Semantic Search', () => {
it('returns relevant markets for query', async () => {
// 测试实现
})
it('handles empty query gracefully', async () => {
// 测试边缘情况
})
it('falls back to substring search when Redis unavailable', async () => {
// 测试回退行为
})
it('sorts results by similarity score', async () => {
// 测试排序逻辑
})
})
步骤 3: 运行测试 (应失败)
npm test
# 测试应失败 - 我们尚未实现
步骤 4: 实现代码
编写最少量的代码以使测试通过:
// 由测试引导的实现
export async function searchMarkets(query: string) {
// 在此实现
}
步骤 5: 再次运行测试
npm test
# 测试现在应通过
步骤 6: 重构
在保持测试通过的前提下提高代码质量:
- 消除重复
- 改进命名
- 优化性能
- 增强可读性
步骤 7: 验证覆盖率
npm run test:coverage
# 验证是否达到 80%+ 覆盖率
测试模式
单元测试模式 (Jest/Vitest)
import { render, screen, fireEvent } from '@testing-library/react'
import { Button } from './Button'
describe('Button Component', () => {
it('renders with correct text', () => {
render(<Button>Click me</Button>)
expect(screen.getByText('Click me')).toBeInTheDocument()
})
it('calls onClick when clicked', () => {
const handleClick = jest.fn()
render(<Button onClick={handleClick}>Click</Button>)
fireEvent.click(screen.getByRole('button'))
expect(handleClick).toHaveBeenCalledTimes(1)
})
it('is disabled when disabled prop is true', () => {
render(<Button disabled>Click</Button>)
expect(screen.getByRole('button')).toBeDisabled()
})
})
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 5d ago First seen · 411 lines · 72 tokens per session scan A 1231c7e7ef92
tdd-workflow (测试驱动开发工作流) is a skill published in the GitHub repository cfrs2005/claude-init (1,364 stars, last pushed 5mo ago), licensed MIT. It adds 72 tokens to every session and 2,786 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
mushi-integration
Full end-to-end Mushi Mushi integration smoke test: bug capture → AI triage → story mapping → TDD test generation → approval → execution → PDCA cycle. Use when "test mushi integration", "verify full pipeline", "mushi e2e check", "does mushi work end-to-end", "smoke test mushi", or after deploying changes.
mushi-test
Run, review, and improve Mushi Mushi TDD tests — story mapping, Playwright test generation, QA coverage, PDCA improvement loop, test approval workflow. Use when "run tdd tests", "generate tests for my stories", "check qa coverage", "improve failing tests", "test my app with mushi", "review generated tests", or any…
sdcorejs-test
Requirement-driven test executor for planning, authoring, running, TDD, UAT, test coverage analysis, authenticated browser testing, and verified UI evidence across existing project stacks. Use for direct test work; route product requirement/traceability coverage without test work to sdcorejs-product, debugging fixes…
swift-tdd-workflow
Use this skill when writing new features, fixing bugs, or refactoring code. Enforces test-driven development with XCTest including unit, integration, and XCUITest E2E tests.
Forge
Autonomous quality engineering swarm that forges production-ready code through continuous behavioral verification, exhaustive E2E testing, and self-healing fix loops. Combines DDD+ADR+TDD methodology with BDD/Gherkin specifications, 7 quality gates, defect prediction, chaos testing, and cross-context dependency…
step
Work in the smallest next step, staying in the loop. Browser-first RED, TDD, evidence, before/then. Handles refining a requirement, researching alternatives, or building — and switches between them as the task shifts. Keeps a tiny optional buffer. Output stays short and critical. Use when: step, let's build this, next…