Help us improve
Share bugs, ideas, or general feedback.
From devstefancho-skills
Implements a task as production code plus tests, auto-detecting test frameworks (jest, vitest, pytest, go test, cargo test) and following existing project patterns.
npx claudepluginhub devstefancho/skillsHow this skill is triggered — by the user, by Claude, or both
Slash command
/devstefancho-skills:implement-with-testgeneral-purposeThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Turn a task into production code plus tests that fit naturally into the existing codebase.
Implement code with tests from a spec file or direct request. Auto-detects test framework (jest, vitest, pytest, go test, cargo test) and follows existing project patterns. Use when user asks to implement a spec, build a feature with tests, code from a spec, or says "implement", "구현", "구현해줘", "테스트와 함께 구현", "스펙 구현", "implement this spec". Proactively trigger whenever the user wants to turn a specification or requirement into working code with tests.
Test-first implementation workflow with TDD guardrails. Runs in normal mode (plan + task) or quick mode (direct instruction). Generates tests, implements, refactors, checks coverage and quality.
Implements task specs via TDD (RED-GREEN-REFACTOR cycle), one test at a time from PLAN-*.md files. Collaborative mode pauses per step; auto mode runs autonomously.
Share bugs, ideas, or general feedback.
Turn a task into production code plus tests that fit naturally into the existing codebase.
Exactly two sources:
specs/*.md, tasks/*.md, any task .md → Read and parse) or a direct natural-language description (parse in place).Extract into: Purpose (1-2 sentences) · Requirements (3-5 bullets) · Approach (2-5 sentences) · Verification (2-5 testable bullets). Display the summary.
package.json, tsconfig.json, pyproject.toml, go.mod, Cargo.toml, pom.xml; read the relevant config.AskUserQuestion.Glob **/*.test.* **/*.spec.* **/test_* **/*_test.* **/__tests__/**, read 1-2 test files: import style, assertion library, structure, setup/teardown, mocking approach, file naming convention, file location (colocated / __tests__/ / tests/).List production files to create/modify (with brief descriptions), test files (detected naming + location), and the Verification → test mapping. Show as an informational summary — no confirmation needed, just transparency.
Follow the Approach for architecture. Match existing import/naming/error-handling patterns. Handle edge cases from Requirements. Keep functions focused. Export only what testability requires.
Bash (per-language commands in reference.md).Only when the Phase 1 argument was a file path; skip for description- or conversation-sourced tasks.
Status mapping (writing-tasks compatible): all Verification tests pass → done · partial pass after 3 attempts → review · all fail → blocked.
Surgical edits only — update status / completed_at / passed checklist items, touch nothing else. Exact frontmatter and checklist rules: reference.md.
WRONG: "modernize" unfamiliar or old-style test patterns while adding new tests. RIGHT: mirror the existing patterns as-is.
WRONG: report success with "just one flaky test left" after 3 failed fix attempts.
RIGHT: status review, failures listed in the 테스트 section with error details, follow-ups under 다음 단계.
Error-handling table and defaults for when AskUserQuestion is unavailable: reference.md.