Initial commit with translated description

This commit is contained in:
2026-03-29 09:49:09 +08:00
commit c822dca19b
8 changed files with 384 additions and 0 deletions

120
SKILL.md Normal file
View File

@@ -0,0 +1,120 @@
---
name: Code
slug: code
version: 1.0.4
homepage: https://clawic.com/skills/code
description: "具有规划、实施、验证和测试的编码工作流。"
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

6
_meta.json Normal file
View File

@@ -0,0 +1,6 @@
{
"ownerId": "kn73vp5rarc3b14rc7wjcw8f8580t5d1",
"slug": "code",
"version": "1.0.4",
"publishedAt": 1771467169291
}

48
criteria.md Normal file
View File

@@ -0,0 +1,48 @@
# 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`

42
execution.md Normal file
View File

@@ -0,0 +1,42 @@
# 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

38
memory-template.md Normal file
View File

@@ -0,0 +1,38 @@
# 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`

31
planning.md Normal file
View File

@@ -0,0 +1,31 @@
# 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

60
state.md Normal file
View File

@@ -0,0 +1,60 @@
# 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.

39
verification.md Normal file
View File

@@ -0,0 +1,39 @@
# 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"