code-assist
A coding assistant that uses test-driven development to build features while maintaining idiomatic standards.
Install
mkdir -p .claude/skills/code-assist && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/4084" && unzip -o skill.zip -d .claude/skills/code-assist && rm skill.zipInstalls to .claude/skills/code-assist
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Guides implementation of code tasks using test-driven development in an Explore, Plan, Code, Commit workflow. Acts as a Technical Implementation Partner and TDD Coach — following existing patterns, avoiding over-engineering, and producing idiomatic, modern code.Key capabilities
- →Explore project requirements
- →Plan technical execution
- →Implement code via TDD
- →Commit changes with conventional messages
How it works
It follows a structured Explore, Plan, Code, Commit workflow, enforcing TDD cycles and documenting all decisions in project-specific planning files.
Inputs & outputs
When to use code-assist
- →Implementing features via TDD
- →Planning technical task execution
- →Refactoring code using existing patterns
- →Creating commits for planned tasks
About this skill
Code Assist
Overview
Guides implementation of code tasks using test-driven development in an Explore, Plan, Code, Commit workflow. Balances automation with user collaboration while adhering to existing package patterns and prioritizing readability and extensibility.
Parameters
- task_description (required): Task specification, rough idea, file path to
.code-task.md, or URL - additional_context (optional): Supplementary information for implementation context
- documentation_dir (optional, default: ".sop/planning"): Directory for planning documents
- repo_root (optional, default: current working directory): Repository root for code implementation
- task_name (optional): Short descriptive name (auto-generated if not provided)
- mode (optional, default: "auto"): "interactive" (confirmation at each step) or "auto" (autonomous execution)
Constraints:
- You MUST ask for all parameters upfront in a single prompt to avoid repeated interruptions
- You MUST validate inputs: normalize mode to "interactive"/"auto", verify paths, generate task_name if needed
Mode Behavior
Apply these patterns throughout all steps:
Interactive Mode: Present actions for confirmation. Explain pros/cons when multiple approaches exist. Ask clarifying questions. Pause at key decision points. Provide educational context.
Auto Mode: Execute autonomously. Document all decisions and reasoning in progress.md. Select the most appropriate approach and document why. Provide comprehensive summaries at completion.
Important Notes
Separation of Concerns:
Documentation goes in {documentation_dir}. Code (tests and implementation) goes in repo_root. Never mix them. Documentation should guide implementation with high-level concepts — not provide it. When including code snippets in documentation, keep them brief and clearly label them as examples or references.
CODEASSIST.md Integration: If CODEASSIST.md exists in repo_root, read it and apply its constraints throughout.
Steps
1. Setup
Initialize the project environment and create necessary directory structures.
Constraints:
- You MUST create
{documentation_dir}/implementation/{task_name}/(with logs subdirectory) and verify it exists before proceeding - You MUST discover instruction files (CODEASSIST.md, README.md, CONTRIBUTING.md, ARCHITECTURE.md, etc.) and summarize relevant information in context.md
- You MUST create context.md (project structure, requirements, patterns, dependencies) and progress.md (execution tracking with markdown checklists)
- If task_description points to a
.code-task.mdwith YAML frontmatter, updatestatus: in_progressandstarted: <date>(if not already set)
💬 See Mode Behavior for mode-specific interaction guidance
2. Explore Phase
2.1 Analyze Requirements and Context
Analyze the task description and existing documentation to identify core functionality, edge cases, and constraints.
Constraints:
- You MUST produce a clear list of functional requirements and acceptance criteria, even from rough descriptions
- You MUST determine appropriate file paths, language, and alignment with existing project structure
- In interactive mode, discuss requirements with the user, clarify ambiguities, and validate your understanding
💬 See Mode Behavior for mode-specific interaction guidance
2.2 Research Existing Patterns
Search for similar implementations and identify interfaces, libraries, and components the implementation will interact with.
Constraints:
- You MUST search the repository for relevant code, patterns, and conventions
- You MUST create a dependency map and update context.md with implementation paths
💬 See Mode Behavior for mode-specific interaction guidance
3. Plan Phase
3.1 Design Test Strategy
Create test scenarios covering normal operation, edge cases, and error conditions.
Constraints:
- You MUST cover all acceptance criteria with at least one test scenario
- You MUST define explicit input/output pairs and save scenarios to plan.md
- You MUST design tests that will initially fail (no mock implementations during design)
💬 See Mode Behavior for mode-specific interaction guidance
3.2 Implementation Planning & Tracking
Outline the high-level structure and create an implementation plan.
Constraints:
- You MUST save the plan to plan.md with key implementation tasks
- You MUST maintain an implementation checklist in progress.md using markdown checkbox format
- In interactive mode, present multiple approaches with pros/cons and discuss trade-offs
💬 See Mode Behavior for mode-specific interaction guidance
4. Code Phase
Phase-wide constraints:
- You MUST place all code (tests and implementation) in repo_root, never in documentation_dir
- You MUST verify tests/builds pass before advancing to the next sub-step
- You MUST follow the existing codebase's conventions (naming, patterns, error handling, testing style)
- Pipe build output to
{documentation_dir}/implementation/{task_name}/logs/and search for success/failure indicators
4.1 Implement Test Cases
Write test cases following strict TDD principles.
Constraints:
- You MUST implement tests for ALL requirements before writing ANY implementation code
- You MUST execute tests to verify they fail as expected, documenting failure reasons
- You MUST follow the testing framework conventions used in the existing codebase
💬 See Mode Behavior for mode-specific interaction guidance
4.2 Develop Implementation Code
Write implementation code to pass the tests, focusing on simplicity and correctness first.
Constraints:
- You MUST follow the TDD cycle: RED → GREEN → REFACTOR
- You MUST implement only what is needed to make current tests pass (YAGNI, KISS, SOLID)
- You MUST execute tests after each implementation step to verify they pass
💬 See Mode Behavior for mode-specific interaction guidance
4.3 Refactor and Optimize
Review the implementation for simplification, improvement, and convention alignment.
Constraints:
- You MUST verify all tests and builds pass before starting — fix any failures first
- You MUST align implementation with surrounding codebase conventions (naming, structure, error handling, imports, logging)
- You MUST maintain test-passing status throughout refactoring
💬 See Mode Behavior for mode-specific interaction guidance
4.4 Validate Implementation
Verify the implementation is complete and correct.
Constraints:
- You MUST run the full test suite and build, verifying all pass
- You MUST verify all implementation plan items are completed
- You MUST NOT claim completion while any tests are failing
💬 See Mode Behavior for mode-specific interaction guidance
5. Commit Phase
Draft a conventional commit message and perform the git commit.
Constraints:
- You MUST NOT commit until builds AND tests are verified passing
- You MUST follow the Conventional Commits specification
- You MUST NOT push to remote repositories
- If task_description was a
.code-task.md, update frontmatter tostatus: completedandcompleted: <date>before committing - Document the commit hash in progress.md
💬 See Mode Behavior for mode-specific interaction guidance
Desired Outcome
- Complete, well-tested implementation meeting all requirements
- Comprehensive test suite validating the implementation
- Clean code following existing patterns, prioritizing readability, avoiding over-engineering
- Implementation artifacts in
{documentation_dir}/implementation/{task_name}/(context.md, plan.md, progress.md, logs/) - Properly committed changes with conventional commit messages
Examples
Feature Implementation
Input:
task_description: "Create a utility function that validates email addresses"
mode: "interactive"
Expected Process:
- Check for CODEASSIST.md and discover instruction files
- Detect project type from existing files (pom.xml, package.json, etc.)
- Set up directory structure in .sop/planning/implementation/email-validator/
- Explore requirements and create context documentation
- Plan test scenarios for valid/invalid email formats
- Implement tests first (TDD approach)
- Implement the validation function
- Commit with conventional commit message
Troubleshooting
Directory/Permission Issues: Create directories if possible, inform user of permission issues, suggest alternatives.
Build Failures: Check CODEASSIST.md for guidance, verify correct directory, try clean builds, check dependencies.
Multi-Package Coordination: Verify dependency order, build in order, create separate commits per package.
Task File Frontmatter Issues: Skip frontmatter updates if missing/malformed. Don't fail the task due to frontmatter issues.
Implementation Challenges: Document in progress.md, propose alternatives. In interactive mode ask for guidance; in auto mode select the most promising approach and document the decision.
Artifacts
• {documentation_dir}/implementation/{task_name}/context.md — Workspace structure, requirements, patterns, dependencies, implementation paths
• {documentation_dir}/implementation/{task_name}/plan.md — Test scenarios, implementation strategy
• {documentation_dir}/implementation/{task_name}/progress.md — Execution tracking, TDD cycles, commit status, challenges
• {documentation_dir}/implementation/{task_name}/logs/ — Build outputs
When not to use it
- →For tasks that do not involve code implementation
- →When the project environment is not compatible with TDD
Prerequisites
Limitations
- →Requires strict adherence to TDD cycles
- →Documentation and code must be separated
How it compares
It acts as a technical partner that enforces TDD and project-specific patterns, rather than just generating code snippets.
Compared to similar skills
code-assist side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| code-assist (this skill) | 1 | 5mo | No flags | Advanced |
| moonbit-agent-guide | 1 | 7mo | Review | Intermediate |
| ruby-pro | 1 | 4mo | No flags | Advanced |
| agent-implementer-sparc-coder | 1 | 6mo | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by mikeyobrien
View all by mikeyobrien →You might also like
moonbit-agent-guide
loro-dev
Guide for writing, refactoring, and testing MoonBit projects. Use when working in MoonBit modules or packages, organizing MoonBit files, using moon tooling (build/check/test/doc/ide), or following MoonBit-specific layout, documentation, and testing conventions.
ruby-pro
sickn33
Write idiomatic Ruby code with metaprogramming, Rails patterns, and performance optimization. Specializes in Ruby on Rails, gem development, and testing frameworks. Use PROACTIVELY for Ruby refactoring, optimization, or complex Ruby features.
agent-implementer-sparc-coder
ruvnet
Agent skill for implementer-sparc-coder - invoke with $agent-implementer-sparc-coder
intellij-mcp
navikt
Uses the IntelliJ MCP tools for various programming tasks. Use when the IntelliJ MCP is available and you are building, running tests, searching or refactoring.
apex
zuzu59
Systematic implementation using APEX methodology (Analyze-Plan-Execute-eXamine) with parallel agents, self-validation, and optional adversarial review. Use when implementing features, fixing bugs, or making code changes that benefit from structured workflow.
tdd
oimiragieo
Canon TDD for humans and AI agents. Use for production code changes by writing tests first, proving RED, implementing minimal GREEN, and refactoring safely. 2026 edition adds TDP, flakiness gate, ralph-loop integration, memory-search in Step 0, PBT as Step 5.5, mutation testing gate in Step 4, and C