Code

Code Feature Implementation Skill

Purpose

Execute the implementation plan and write code following project-specific patterns.

Usage

/code

(Must be run after /branch)

Re-running after plan updates: If you update the implementation plan via /review after /code has already run, you can re-run /code to implement the updated plan. The skill will read the latest implementation-plan.md and apply the changes.

What This Skill Does

1. Load Current JIRA Issue: Reads JIRA issue details from current-issue.md
2. Load Implementation Plan: Reads detailed plan from implementation-plan.md
3. Apply Project-specific Patterns: Follows Project-specific coding standards, naming conventions, design patterns
4. Implement Changes: Creates new files and modifies existing files
5. Log Changes: Records all modifications to implementation-log.md

JIRA Issue Context

The JIRA issue details should be located in the most recent directory under workflow/jira-to-github/*/current-issue.md. You will need to find and read this file in Step 1.

Implementation Plan Context

The implementation plan should be located in the most recent directory under workflow/jira-to-github/*/implementation-plan.md. You will need to find and read this file in Step 1.

Instructions

You are coordinating the code implementation for a JIRA issue. This skill spawns a sub-agent to execute the implementation plan autonomously following implementing with project-specific patterns.

CRITICAL: Your ONLY job is to:

1. Code the implementation plan for a JIRA issue
2. Spawn a 'general-purpose' sub-agent using the Task tool
3. Report the agent's results to the user

DO NOT:

• Fetch JIRA data yourself
• change implementation plan
• push code to github
• write unit tests (that's /test's job)
• If the sub-agent fails, DO NOT retry the work yourself - report the failure to the user

Step 1: Validate Prerequisites

Verify that prerequisites are met:

# Verify JIRA issue details exists
JIRA_DIR=$(ls -td workflow/jira-to-github/*/ 2>/dev/null | head -1)
if [ ! -f "$JIRA_DIR/current-issue.md" ]; then
  echo "❌ No JIRA Issue found. Run /pull first."
  exit 1
fi

# Verify implementation plan exists
JIRA_DIR=$(ls -td workflow/jira-to-github/*/ 2>/dev/null | head -1)
if [ ! -f "$JIRA_DIR/implementation-plan.md" ]; then
  echo "❌ No implementation plan found. Run /plan first."
  exit 1
fi

Step 2: Spawn Code Implementation Agent

Use the Task tool to spawn a general-purpose agent to execute the implementation plan autonomously:

Agent Prompt:

Implement the code changes for the JIRA issue based on the implementation plan.

CONTEXT FILES LOADED:
- Target repo: workflow/jira-to-github/*/target-repo.md
- Current issue: workflow/jira-to-github/*/current-issue.md
- Implementation plan: workflow/jira-to-github/*/implementation-plan.md
- Previous implementation log (if exists): workflow/jira-to-github/*/implementation-log.md

REPO CONTEXT LOADING:
Before implementing, load repo-specific coding patterns:
1. Read `target-repo.md` to find the repo path and profile path
2. Read the repo profile (e.g., `context/repos/esperanto.md`) to get `Context Files` pointers
3. Read the repo's own CLAUDE.md at `<repo-path>/CLAUDE.md` for coding patterns, conventions, and rules
4. Read the module context file at `<repo-path>/<primary-module-path>` (as specified in profile) for module-specific structure, key files, and patterns
5. Apply these patterns throughout implementation (coding style, imports, naming, file organization)
6. If `target-repo.md` is not found, fall back to patterns described in the implementation plan

Tasks:

1. Check for previous implementation:
   - Check if implementation-log.md exists in the workflow directory
   - If it exists, this is a RE-IMPLEMENTATION after plan updates:
     * Read the previous implementation log to understand what was already done
     * Read the current implementation plan to see the updated requirements
     * Identify what changed in the plan compared to previous implementation
     * Apply incremental changes based on plan updates
     * Append to implementation log noting this is a revision
   - If it doesn't exist, this is a FIRST-TIME implementation:
     * Proceed with full implementation as planned

2. Read and understand the implementation plan:
   - Files to create (with purposes)
   - Files to modify (with specific changes)
   - project-specific patterns to follow

   NOTE: You are implementing code ONLY. Do NOT write unit tests - the /test skill handles that.

   OPTIMIZATION REQUIREMENTS:
   - Use tables for file changes (more token-efficient than paragraphs)
   - Do NOT include specific line numbers in the log
   - Reference the implementation plan for patterns instead of repeating them
   - Keep descriptions concise and actionable
   - For revisions, use changelog format instead of repeating full implementation details

3. Apply repo-specific patterns (from repo CLAUDE.md and module context file):
  - Follow TypeScript/React naming conventions from repo context
  - Follow repo-specific coding rules (e.g., strict mode, import style, hooks-only)
  - Follow repo-specific design patterns (e.g., state management, error handling)
  - Follow module-specific file organization and integration points

4. Implement code changes for each file in the plan:

   **Creating New Files**:
   - Use Bash to create directories if needed: mkdir -p path/to/directory
   - Use Write tool to create new files with proper content
   - Do NOT add file header comments or JIRA references
   - Let the code be self-documenting
   - Only add comments for complex logic that isn't self-evident

   **Modifying Existing Files**:
   - Use Read tool to read existing files first
   - Use Edit tool for precise changes
   - Match existing code style
   - Preserve imports order
   - Follow ESLint rules
   - Use existing utility functions
   - Don't over-engineer
   - Add comments ONLY for complex logic that isn't self-explanatory
   - Do NOT add: file headers, JIRA references, function descriptions for obvious functions
   - Prefer self-documenting code over comments

5. Create or update implementation log with all changes:

   **For first-time implementation**:
   ```markdown
   # Implementation Log: <JIRA-KEY>

   ## Summary
   <Brief 1-2 sentence summary of what was implemented>

   ## Changes Made

   ### New Files Created
   | File | Purpose | Key Features |
   |------|---------|--------------|
   | path/to/new-file.ts | <description> | <key features/patterns used> |

   ### Files Modified
   | File | Modifications | Status |
   |------|---------------|--------|
   | path/to/file.ts | Added <feature>, Updated <component> | ✓ Complete |

   ## Project Patterns Applied
   See "Project-Specific Patterns" in implementation-plan.md

   ## Code Review Checklist
   - [ ] TypeScript types defined
   - [ ] ESLint passing
   - [ ] No console.log statements
   - [ ] Error handling implemented
   - [ ] Security considerations addressed
   - [ ] Team patterns followed
   - [ ] Comments added for complex logic

   ## Next Steps
   - Run /test to write unit tests
   - Manual testing: <specific scenarios>

   ---
   *Implementation completed: <timestamp>*

For re-implementation after plan updates (APPEND this to existing file):

---

## Revision: <YYYY-MM-DD>

### Changes from Plan Update
- <brief bullet point of what changed in the plan>
- <brief bullet point of what changed in the plan>

### Files Affected
| File | Change Type | Description |
|------|-------------|-------------|
| path/to/file.ts | Modified | <brief change description> |
| path/to/removed.ts | Removed | <brief reason> |
| path/to/new-file.ts | Created | <brief purpose> |

### Impact
<1-2 sentences describing the overall impact of this revision>

---
*Revision completed: <timestamp>*

IMPORTANT for revisions:

• Keep original "Changes Made" and "Code Review Checklist" sections intact
• Only APPEND the revision section above
• Do NOT duplicate the entire log structure
• Use concise tables and bullet points
• Focus on WHAT changed, not detailed implementation

6. Save implementation log to: workflow/jira-to-github//implementation-log.md

   • For first-time: Create new file with complete structure
   • For revisions: APPEND ONLY the revision section to existing file
     • Do NOT rewrite or duplicate existing content
     • Keep original implementation details intact
     • Add new revision section at the end

7. Display summary to user showing:

   • Count of files created
   • Count of files modified
   • Count of lines changed
   • Summary of team patterns applied
   • Implementation log file location
   • Next step: Run /test to write unit tests

SECURITY REQUIREMENTS:

• NEVER commit: API keys, secrets, PII, full credit card numbers, passwords, tokens
• For eProtect: Never log card data, use tokenization, validate CVV without storing
• Follow PCI DSS guidelines

ERROR HANDLING:

• If file not found: Verify paths in implementation plan, log error
• If syntax errors: Fix TypeScript/ESLint errors before completing
• If merge conflicts: Resolve conflicts before continuing
• Log all errors to: workflow/jira-to-github//errors.log

### Step 3: Monitor Agent Progress

The agent will run autonomously. When complete, it will have:
- Read and understood the JIRA issue details
- Read and understood the implementation plan
- Created all new files following project specific patterns
- Modified existing files with targeted changes
- Applied project specific conventions
- Created comprehensive implementation log in workflow/jira-to-github/<JIRA-NUMBER>/implementation-log.md
- Displayed summary to user

## Error Handling

If errors occur:
1. Log error to `workflow/jira-to-github/<JIRA-NUMBER>/errors.log`
2. Display user-friendly message
3. Do NOT commit changes if errors occurred

Common errors:
- **File not found**: Verify paths in implementation plan
- **Syntax errors**: Fix TypeScript/ESLint errors before proceeding
- **Merge conflicts**: Resolve conflicts before continuing
- **Permission errors**: Check file permissions

## Security Considerations

**Never commit**:
- API keys or secrets
- PII (Personally Identifiable Information)
- Full credit card numbers
- Passwords or tokens

**eProtect specific**:
- Never log card data
- Use tokenization for storage
- Validate CVV without storing
- Follow PCI DSS guidelines

## Examples

Example 1: Re-implementation after plan update
```bash
# Initial workflow
/pull DRT-17270
/plan
/review  # User approves
/branch
/code         # Initial implementation

# User realizes plan needs changes
/review "Add retry logic for network failures"
# Plan is revised based on feedback

# Re-run code to implement updated plan
/code         # Reads updated plan, applies incremental changes
# Implementation log shows revision with changes