TDD implementation following Keller Solutions principles. Takes a ticket from story to working code with tests, proper commits, and quality gates. Works standalone or as part of /ks-feature or /ks-ticket workflow.
How this skill is triggered — by the user, by Claude, or both
Slash command
/keller-solutions-core:produce <ticket number or 'current'><ticket number or 'current'>The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Implement features using Test-Driven Development, following the Keller Solutions guiding principles.
Implement features using Test-Driven Development, following the Keller Solutions guiding principles.
Write the test first. Make it pass. Refactor. Repeat.
Every acceptance criterion becomes a test before it becomes code. This ensures we build only what's needed and can prove it works.
Confirm the environment is ready:
# Check we're on a feature branch (not main/develop)
CURRENT_BRANCH=$(git branch --show-current)
if [[ "$CURRENT_BRANCH" == "main" || "$CURRENT_BRANCH" == "develop" ]]; then
echo "ERROR: On '$CURRENT_BRANCH' (not a feature branch). Run /ks-prep first."
exit 1
fi
Retrieve the ticket to implement:
# If ticket number provided
gh issue view [TICKET_NUMBER] --json title,body,labels
# If "current" or no argument, check branch name for ticket reference
# Or ask user for ticket number
Move the ticket to "In Progress" to signal work has started. See managing-tickets for tool-specific commands.
Quick reference:
# GitHub
gh issue edit [TICKET_NUMBER] --add-label "status:in-progress"
# Jira
jira issue move [TICKET_KEY] "In Progress"
# ClickUp - see managing-tickets skill for full setup
curl -X PUT "https://api.clickup.com/api/v2/task/[TASK_ID]" \
-H "Authorization: ${CLICKUP_API_TOKEN}" \
-H "Content-Type: application/json" \
-d '{"status": "in progress"}'
Note: Update the ticket status at each major milestone:
/ks-present)Check project preference (detected during prep):
Co-Authored-By in commitsIf not already on a feature branch:
git checkout develop
git pull origin develop
git checkout -b feature/[descriptive-name]
Branch naming:
feature/user-dashboard - New featuresbugfix/filter-pagination - Bug fixeshotfix/critical-security-fix - Urgent production fixesExtract each acceptance criterion from the ticket. Each criterion will become at least one test.
Before implementing, search for related code:
# Find similar components/features
grep -r "similar_pattern" app/
Reference existing patterns rather than creating new ones.
Review relevant Architecture Decision Records:
ls docs/adr/*.md
If making an architectural decision, create an ADR first (see templates/ADR-template.md).
Use /workflows:plan or create manually:
## Execution Plan
### Ticket: #[NUMBER] - [TITLE]
**Criteria to implement:**
1. [Criterion 1] → Test: [test description]
2. [Criterion 2] → Test: [test description]
3. [Criterion 3] → Test: [test description]
**Patterns to follow:**
- [Reference to existing code/patterns]
**Files to create/modify:**
- [file1.rb]
- [file2.rb]
- [test/file1_test.rb]
Optionally use /compound-engineering:deepen-plan for additional research.
For each acceptance criterion:
Write a test that describes the expected behavior:
Rails Example:
# test/models/project_test.rb
test "projects are sorted by last activity" do
old_project = projects(:old)
new_project = projects(:new)
old_project.update!(updated_at: 1.week.ago)
new_project.update!(updated_at: 1.hour.ago)
sorted = Project.by_recent_activity
assert_equal new_project, sorted.first
assert_equal old_project, sorted.last
end
React/TypeScript Example:
// src/components/ProjectList.test.tsx
test('displays projects sorted by last activity', () => {
const projects = [
{ id: 1, name: 'Old', updatedAt: '2024-01-01' },
{ id: 2, name: 'New', updatedAt: '2024-01-15' }
];
render(<ProjectList projects={projects} />);
const items = screen.getAllByRole('listitem');
expect(items[0]).toHaveTextContent('New');
expect(items[1]).toHaveTextContent('Old');
});
Run the test to confirm it fails:
# Rails
bin/rails test test/models/project_test.rb
# JavaScript
npm test -- --testPathPattern=ProjectList
Write the minimum code to make the test pass:
Rails Example:
# app/models/project.rb
class Project < ApplicationRecord
scope :by_recent_activity, -> { order(updated_at: :desc) }
end
Run the test to confirm it passes:
bin/rails test test/models/project_test.rb
Clean up the code while keeping tests green:
Run full test suite after refactoring:
bin/rails test
After each criterion is implemented and tests pass:
git add .
git commit -m "$(cat <<'EOF'
feat(projects): add recent activity sorting
Projects can now be sorted by last activity using the
by_recent_activity scope.
Refs #123
Co-Authored-By: Claude Opus 4.5 <[email protected]>
EOF
)"
git push
Commit rules:
console.log, binding.pry, puts)Refs #123Continue the Red-Green-Refactor cycle until all acceptance criteria are implemented.
When implementing user-facing UI components, invoke /frontend-design. Use it for new pages, components, or any work where aesthetics matter.
Integration with TDD: Write the test for behavior first, then use frontend-design for implementation. The test verifies what the UI does; frontend-design ensures it looks exceptional.
Build only this story's slice of the design. A wireframe or comp shows the finished page; this story's acceptance criteria define which elements exist today. Do not add placeholder nav items, buttons, or links to # for elements that belong to later stories—an element appears only when the story that makes it work ships (Guiding Principle #3: Avoid Pre-Optimization). If the design shows an element no criterion covers, leave it out; if a criterion seems to need an element no story delivers, raise it with the user rather than stubbing it.
# Rails
bin/rails test
# JavaScript
npm test
# System tests (if applicable)
bin/rails test:system
All tests must pass.
# All linters (project-specific)
bin/lint
# Or individually:
bin/rubocop # Ruby
npm run lint # JavaScript
bin/brakeman # Security scan
Fix any issues immediately.
Verify test coverage meets standards (100%):
# Coverage report is typically generated with test run
open coverage/index.html
Before proceeding to Present:
# View all changes
git diff develop...HEAD
# List modified files
git diff --name-only develop...HEAD
Check:
Document changes in Keep a Changelog format before creating PR.
## [Unreleased]
### Added
- New feature X for ticket #123
### Changed
- Updated behavior Y for ticket #123
Categories: Added, Changed, Deprecated, Removed, Fixed, Security
# Find changelog file (CHANGELOG.md is most common)
CHANGELOG_FILE=$(ls CHANGELOG.md CHANGELOG HISTORY.md CHANGES.md 2>/dev/null | head -1)
# Check structure
grep -E "^## \[" "$CHANGELOG_FILE" | head -3
# Commit update
git add "$CHANGELOG_FILE" && git commit -m "docs(changelog): document changes for #[TICKET]" && git push
Output implementation summary:
## Implementation Complete
**Ticket**: #[NUMBER] - [TITLE]
**Branch**: [BRANCH_NAME]
### Criteria Implemented
- [x] [Criterion 1] - implemented in [commit]
- [x] [Criterion 2] - implemented in [commit]
- [x] [Criterion 3] - implemented in [commit]
### Quality Gates
- [x] All tests passing ([count] tests)
- [x] Linters passing
- [x] Coverage at [X]%
### Files Changed
- [file1.rb] - [brief description]
- [file2.rb] - [brief description]
- [test/file1_test.rb] - [brief description]
Ready to proceed with `/ks-present` to create PR and handle review.
When invoked directly (/ks-produce <ticket>):
When invoked as part of /ks-feature or /ks-ticket:
/ks-presentApply these principles with every commit. See Guiding Principles for details.
Never put yourself in a position where you have to force push. Push after each commit. No rebasing, amending, or squashing pushed commits. See Git Integrity for details.
Every feature should preserve the F5 principle: clone, setup, run. See The F5 Principle for full details.
Before completing a feature, verify:
.env.exampleThe test: Can a new developer run bin/setup && bin/dev without additional steps?
This skill integrates with commands from dependent plugins:
/workflows:plan - Detailed execution planning/compound-engineering:deepen-plan - Research and best practices/workflows:work - TDD implementation assistance/workflows:review - Self-review before PR/compound-engineering:resolve_todo_parallel - Address review findings/compound-engineering:lint - Run all linters/frontend-design - Create distinctive, production-grade UI componentsUse frontend-design whenever implementing visual interfaces. It prevents generic "AI slop" aesthetics and produces memorable, polished designs with intentional typography, color, and motion.
npx claudepluginhub keller-solutions/kslabs-marketplace --plugin keller-solutions-coreGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.