Claude-project-skills-template task
Structured implementation process for features, chores, refactors, and docs. Use when implementing non-bugfix work.
git clone https://github.com/dohernandez/claude-project-skills-template
T=$(mktemp -d) && git clone --depth=1 https://github.com/dohernandez/claude-project-skills-template "$T" && mkdir -p ~/.claude/skills && cp -r "$T/.claude/skills/task" ~/.claude/skills/dohernandez-claude-project-skills-template-task && rm -rf "$T"
.claude/skills/task/SKILL.mdTask
Purpose
Structured implementation methodology for non-bugfix work (features, chores, refactors, docs). Ensures work is properly scoped, planned, implemented following project patterns, and verified before completion.
Quick Reference
- Phases: Scope -> Plan -> Implement -> Verify
- Key Rule: Understand before building
- Output: Working implementation with changes reviewed
Task Phases
+-----------------------------------------------------------------------------+ | TASK WORKFLOW | +-----------------------------------------------------------------------------+ | 1. SCOPE -> 2. PLAN -> 3. IMPLEMENT -> 4. VERIFY | +-----------------------------------------------------------------------------+
Phase T1: Scope
Goal: Understand what needs to be done and define boundaries.
Procedure:
- Read the ticket/request description carefully
- Identify the core requirement (what must be delivered)
- Identify out-of-scope items (what NOT to do)
- Clarify any ambiguities with user
- Document the scope
Output: Clear understanding of deliverables
## Scope - **Goal:** Add retry logic to the E2E runner script - **Deliverables:** - Configurable retry count in run-e2e.sh - Proper exit code propagation - **Out of scope:** - Changes to the GitHub Actions workflow triggers - Dashboard or reporting changes
Key Rule: Don't start planning until scope is clear. Ask questions early.
Phase T2: Plan
Goal: Design the approach before writing code.
Procedure:
- Explore the relevant parts of the codebase
- Identify files to create/modify
- Consider how changes interact with existing scripts and workflows
- Document the plan
- Get user approval on plan before implementing
Output: Implementation plan with files and approach
## Plan - **Area:** E2E runner orchestration - **Files to modify:** - scripts/run-e2e.sh (add retry loop) - .github/workflows/run-e2e.yml (pass retry count input) - **Approach:** Wrap test execution in retry loop with configurable count
Key Rule: Get user approval on plan before implementing.
Phase T3: Implement
Goal: Write code following project patterns.
Procedure:
- Follow existing code patterns and conventions in the project
- Work in small increments
- Keep changes minimal and focused on the scope
- Use proper shell scripting practices (set -euo pipefail, quoting, etc.)
- Follow YAML best practices for workflow files
Guidelines:
- Match existing code style and patterns
- Don't over-engineer
- Keep shell scripts defensive (error handling, input validation)
- Use consistent naming with existing files
Output: Working code changes
Key Rule: Minimal changes only. Don't refactor unrelated code.
Phase T4: Verify
Goal: Ensure implementation is complete and correct.
Procedure:
- Review the diff of all changes against the original scope
- Run shellcheck on modified shell scripts (if available)
- Validate YAML syntax on modified workflow files
- Check for common issues: unquoted variables, missing error handling, hardcoded values
- Verify no unintended side effects in related files
Output: Changes reviewed, no obvious errors, ready for commit
# Verification checks (as applicable) shellcheck scripts/run-e2e.sh # Lint shell scripts yamllint .github/workflows/*.yml # Validate YAML syntax git diff --stat # Review scope of changes
Key Rule: Don't skip the review step. Always check the diff against the original scope.
Flow Diagram
+-------------------+ | Request received | +---------+---------+ | v +-------------------+ +-------------------+ | T1: SCOPE |---->| Unclear? | | Understand req | | Ask user | +---------+---------+ +-------------------+ | Clear v +-------------------+ +-------------------+ | T2: PLAN |---->| Need approval | | Design approach | | Show plan | +---------+---------+ +-------------------+ | Approved v +-------------------+ +-------------------+ | T3: IMPLEMENT |---->| Issues? | | Write code | | Iterate | | |<----| | +---------+---------+ +-------------------+ | Complete v +-------------------+ +-------------------+ | T4: VERIFY |---->| Problems found? | | Review changes | | Fix and re-check | | |<----| | +---------+---------+ +-------------------+ | All clear v +-------------------+ | Ready for | | commit | +-------------------+
Task Context
Track progress in workflow context:
{ "type": "feat", "task": { "phase": "implement", "scopeConfirmed": true, "planApproved": true, "filesModified": ["scripts/run-e2e.sh"] } }
Anti-Patterns
| Don't | Do Instead |
|---|---|
| Start coding immediately | Scope and plan first |
| Plan in isolation | Get user approval on plan |
| Change unrelated code | Minimal changes only |
| Skip reviewing the diff | Always review changes against scope |
| Ignore lint/syntax errors | Fix all errors before commit |
Automation
See
skill.yaml for patterns and procedures.
See sharp-edges.yaml for common implementation pitfalls.