Skill: lion504/code-1-0-4 (version 1.0.0)

--- name: Code slug: code version: 1.0.4 homepage: https://clawic.com/skills/code description: Coding workflow with planning, implementation, verification, and testing for clean software development. changelog: Improved description for better discoverability metadata: {"clawdbot":{"emoji":"💻","requires":{"bins":[]},"os":["linux","darwin","win32"]}} --- ## When to Use User explicitly requests code implementation. Agent provides planning, execution guidance, and verification workflows. ## Architecture User preferences stored in `~/code/` when user explicitly requests. ``` ~/code/ - memory.md # User-provided preferences only ``` Create on first use: `mkdir -p ~/code` ## Quick Reference | Topic | File | |-------|------| | Memory setup | `memory-template.md` | | Task breakdown | `planning.md` | | Execution flow | `execution.md` | | Verification | `verification.md` | | Multi-task state | `state.md` | | User criteria | `criteria.md` | ## Scope This skill ONLY: - Provides coding workflow guidance - Stores preferences user explicitly provides in `~/code/` - Reads included reference files This skill NEVER: - Executes code automatically - Makes network requests - Accesses files outside `~/code/` and the user's project - Modifies its own SKILL.md or auxiliary files - Takes autonomous action without user awareness ## Core Rules ### 1. Check Memory First Read `~/code/memory.md` for user's stated preferences if it exists. ### 2. User Controls Execution - This skill provides GUIDANCE, not autonomous execution - User decides when to proceed to next step - Sub-agent delegation requires user's explicit request ### 3. Plan Before Code - Break requests into testable steps - Each step independently verifiable - See `planning.md` for patterns ### 4. Verify Everything | After | Do | |-------|-----| | Each function | Suggest running tests | | UI changes | Suggest taking screenshot | | Before delivery | Suggest full test suite | ### 5. Store Preferences on Request | User says | Action | |-----------|--------| | "Remember I prefer X" | Add to memory.md | | "Never do Y again" | Add to memory.md Never section | Only store what user explicitly asks to save. ## Workflow ``` Request -> Plan -> Execute -> Verify -> Deliver ``` ## Common Traps - **Delivering untested code** -> always verify first - **Huge PRs** -> break into testable chunks - **Ignoring preferences** -> check memory.md first ## Self-Modification This skill NEVER modifies its own SKILL.md or auxiliary files. User data stored only in `~/code/memory.md` after explicit request. ## External Endpoints This skill makes NO network requests. | Endpoint | Data Sent | Purpose | |----------|-----------|---------| | None | None | N/A | ## Security & Privacy **Data that stays local:** - Only preferences user explicitly asks to save - Stored in `~/code/memory.md` **Data that leaves your machine:** - None. This skill makes no network requests. **This skill does NOT:** - Execute code automatically - Access network or external services - Access files outside `~/code/` and user's project - Take autonomous actions without user awareness - Delegate to sub-agents without user's explicit request

path: _meta.json
content: ownerId: kn73vp5rarc3b14rc7wjcw8f8580t5d1
slug: code
version: 1.0.4
publishedAt: 1771467169291

path: criteria.md
content: # Criteria for Storing Preferences

Reference for when to save user preferences to `~/code/memory.md`.

## When to Save (User Must Request)

Save only when user explicitly asks:
- "Remember that I prefer X"
- "Always do Y from now on"
- "Save this preference"
- "Don't forget that I like Z"

## When NOT to Save

- User didn't explicitly ask to save
- Project-specific requirement (applies to this project only)
- One-off request ("just this once")
- Temporary preference

## What to Save

**Preferences:**
- Coding style preferences user stated
- Tools or frameworks user prefers
- Patterns user explicitly likes

**Things to avoid:**
- Approaches user explicitly dislikes
- Patterns user asked not to repeat

## Format in memory.md

```markdown
## Preferences
- prefers TypeScript over JavaScript
- likes detailed comments
- wants tests for all functions

## Never
- no class-based React components
- avoid inline styles
```

## Important

- Only save what user EXPLICITLY asked to save
- Ask user before saving: "Should I remember this preference?"
- Never modify any skill files, only `~/code/memory.md`


path: execution.md
content: # Execution Guidance

Reference for executing multi-step implementations.

## Recommended Flow

When user approves a step:
1. Execute that step
2. Verify it works
3. Report completion to user
4. Wait for user to approve next step

## Progress Tracking

Show user the current state:
```
- [DONE] Step 1 (completed)
- [WIP] Step 2 <- awaiting user approval
- [ ] Step 3
- [ ] Step 4
```

## When to Pause and Ask User

- Before starting any new step
- When encountering an error
- When a decision is needed (A vs B)
- When credentials or permissions are needed

## Error Handling

If an error occurs:
1. Report the error to user
2. Suggest possible fixes
3. Wait for user decision on how to proceed

## Patterns to Follow

- Report completion of each step
- Ask before proceeding to next step
- Let user decide retry strategy
- Keep user informed of progress


path: memory-template.md
content: # Memory Setup - Code

## Initial Setup

Create directory on first use:
```bash
mkdir -p ~/code
touch ~/code/memory.md
```

## memory.md Template

Copy to `~/code/memory.md`:

```markdown
# Code Memory

## Preferences
<!-- User's coding workflow preferences. Format: "preference" -->
<!-- Examples: always run tests, prefer TypeScript, commit after each feature -->

## Never
<!-- Things that don't work for this user. Format: "thing to avoid" -->
<!-- Examples: inline styles, console.log debugging, large PRs -->

## Patterns
<!-- Approaches that work well. Format: "pattern: context" -->
<!-- Examples: TDD: for complex logic, screenshots: for UI work -->

---
Last updated: YYYY-MM-DD
```

## Notes

- Check `criteria.md` for additional user-specific criteria
- Use `planning.md` for breaking down complex requests
- Verify with tests and screenshots per `verification.md`


path: planning.md
content: # Planning Reference

Consult when breaking down a multi-step request.

## When to Plan
- Multiple files or components
- Dependencies between parts
- UI that needs visual verification
- User says "build", "create", "implement"

## Step Format
```
Step N: [What]
- Output: [What exists after]
- Test: [How to verify]
```

## Good Steps
- Clear output (file, endpoint, screen)
- Testable independently
- No ambiguity in what "done" means

## Bad Steps
- "Implement the thing" (vague output)
- No test defined
- Depends on undefined prior step

## Don't Plan
- One-liner functions
- Simple modifications
- Questions about existing code


path: state.md
content: # State Tracking Guidance

Reference for tracking multiple tasks or requests.

## Request Tracking

Label each user request:
```
[R1] Build login page
[R2] Add dark mode
[R3] Fix header alignment
```

Track state for user visibility:
```
[R1] [DONE] Done
[R2] [WIP] In progress (awaiting user approval for step 2)
[R3] [Q] Queued
```

## Managing Multiple Requests

When user sends a new request while another is in progress:

1. Acknowledge: "Got it, I'll add this to the queue"
2. Show updated queue to user
3. Ask user if priority should change

## Handling Interruptions

| Situation | Suggested Action |
|-----------|------------------|
| New unrelated request | Add to queue, ask user priority |
| Request affects current work | Pause, explain impact, ask user how to proceed |
| User says "stop" or "wait" | Stop immediately, await instructions |
| User changes requirements | Summarize impact, ask user to confirm changes |

## User Decisions

Always ask user before:
- Starting work on queued items
- Changing priority order
- Rolling back completed work
- Modifying the plan

## Progress File (Optional)

User may request a state file:
```markdown
## In Progress
[R2] Dark mode - Step 2/4 (awaiting user approval)

## Queued  
[R3] Header fix

## Done
[R1] Login page [DONE]
```

Update only when user requests or approves changes.


path: verification.md
content: # Verification Reference

Consult when verifying implementations visually or with tests.

## Screenshots
- Wait for full page load (no spinners)
- Review yourself before sending
- Split long pages into 3-5 sections (~800px each)
- Caption each: "Hero", "Features", "Footer"

## Before Sending
```
[ ] Content loaded
[ ] Shows the specific change
[ ] No visual bugs
[ ] Caption explains what user sees
```

## Fix-Before-Send
If screenshot shows problem:
1. Fix code
2. Re-deploy
3. New screenshot
4. Still broken? -> back to 1
5. Fixed? -> now send

Never send "I noticed X is wrong, will fix" - fix first.

## No UI? Show Output

When verifying API endpoints, show actual output:
```
GET /api/users -> {"id": 1, "name": "test"}
```

Include actual response, not just "it works".

## Flows
Number sequential states: "1/4: Form", "2/4: Loading", "3/4: Error", "4/4: Success"


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)