Initial commit with translated description
This commit is contained in:
117
SKILL.md
Normal file
117
SKILL.md
Normal file
@@ -0,0 +1,117 @@
|
||||
---
|
||||
name: Coding
|
||||
slug: coding
|
||||
version: 1.0.3
|
||||
homepage: https://clawic.com/skills/coding
|
||||
description: "适应您的偏好的编码风格记忆。"
|
||||
changelog: Improve discoverability, add homepage and feedback section
|
||||
metadata: {"clawdbot":{"emoji":"💻","requires":{"bins":[]},"os":["linux","darwin","win32"]}}
|
||||
---
|
||||
|
||||
## When to Use
|
||||
|
||||
User has coding style preferences, stack decisions, or patterns they want remembered. Agent learns ONLY from explicit corrections and confirmations, never from observation.
|
||||
|
||||
## Architecture
|
||||
|
||||
Memory lives in `~/coding/` with tiered structure. See `memory-template.md` for setup.
|
||||
|
||||
```
|
||||
~/coding/
|
||||
├── memory.md # Active preferences (≤100 lines)
|
||||
└── history.md # Archived old preferences
|
||||
```
|
||||
|
||||
## Quick Reference
|
||||
|
||||
| Topic | File |
|
||||
|-------|------|
|
||||
| Categories of preferences | `dimensions.md` |
|
||||
| When to add preferences | `criteria.md` |
|
||||
| Memory templates | `memory-template.md` |
|
||||
|
||||
## Data Storage
|
||||
|
||||
All data stored in `~/coding/`. Create on first use:
|
||||
```bash
|
||||
mkdir -p ~/coding
|
||||
```
|
||||
|
||||
## Scope
|
||||
|
||||
This skill ONLY:
|
||||
- Learns from explicit user corrections ("I prefer X over Y")
|
||||
- Stores preferences in local files (`~/coding/`)
|
||||
- Applies stored preferences to code output
|
||||
|
||||
This skill NEVER:
|
||||
- Reads project files to infer preferences
|
||||
- Observes coding patterns without consent
|
||||
- Makes network requests
|
||||
- Reads files outside `~/coding/`
|
||||
- Modifies its own SKILL.md
|
||||
|
||||
## Core Rules
|
||||
|
||||
### 1. Learn from Explicit Feedback Only
|
||||
- User corrects output → ask: "Should I remember this preference?"
|
||||
- User confirms → add to `~/coding/memory.md`
|
||||
- Never infer from silence or observation
|
||||
|
||||
### 2. Confirmation Required
|
||||
No preference is stored without explicit user confirmation:
|
||||
- "Actually, I prefer X" → "Should I remember: prefer X?"
|
||||
- User says yes → store
|
||||
- User says no → don't store, don't ask again
|
||||
|
||||
### 3. Ultra-Compact Format
|
||||
Keep each entry 5 words max:
|
||||
- `python: prefer 3.11+`
|
||||
- `naming: snake_case for files`
|
||||
- `tests: colocated, not separate folder`
|
||||
|
||||
### 4. Category Organization
|
||||
Group by type (see `dimensions.md`):
|
||||
- **Stack** — frameworks, databases, tools
|
||||
- **Style** — naming, formatting, comments
|
||||
- **Structure** — folders, tests, configs
|
||||
- **Never** — explicitly rejected patterns
|
||||
|
||||
### 5. Memory Limits
|
||||
- memory.md ≤100 lines
|
||||
- When full → archive old patterns to history.md
|
||||
- Merge similar entries: "no Prettier" + "no ESLint" → "minimal tooling"
|
||||
|
||||
### 6. On Session Start
|
||||
1. Load `~/coding/memory.md` if exists
|
||||
2. Apply stored preferences to responses
|
||||
3. If no file exists, start with no assumptions
|
||||
|
||||
### 7. Query Support
|
||||
User can ask:
|
||||
- "Show my coding preferences" → display memory.md
|
||||
- "Forget X" → remove from memory
|
||||
- "What do you know about my Python style?" → show relevant entries
|
||||
|
||||
## Common Traps
|
||||
|
||||
- Adding preferences without confirmation → user loses trust
|
||||
- Inferring from project structure → privacy violation
|
||||
- Exceeding 100 lines → context bloat
|
||||
- Vague entries ("good code") → useless, be specific
|
||||
|
||||
## Security & Privacy
|
||||
|
||||
**Data that stays local:**
|
||||
- All preferences stored in `~/coding/`
|
||||
- No telemetry or analytics
|
||||
|
||||
**This skill does NOT:**
|
||||
- Send data externally
|
||||
- Access files outside `~/coding/`
|
||||
- Observe without explicit user input
|
||||
|
||||
## Feedback
|
||||
|
||||
- If useful: `clawhub star coding`
|
||||
- Stay updated: `clawhub sync`
|
||||
6
_meta.json
Normal file
6
_meta.json
Normal file
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"ownerId": "kn73vp5rarc3b14rc7wjcw8f8580t5d1",
|
||||
"slug": "coding",
|
||||
"version": "1.0.3",
|
||||
"publishedAt": 1771496638145
|
||||
}
|
||||
62
criteria.md
Normal file
62
criteria.md
Normal file
@@ -0,0 +1,62 @@
|
||||
# Criteria for Code Preferences
|
||||
|
||||
Reference only — consult when deciding whether to update SKILL.md.
|
||||
|
||||
## When to Add
|
||||
|
||||
**Immediate (1 occurrence):**
|
||||
- User explicitly says "always use X" or "never do Y"
|
||||
- User corrects your choice → add their preference
|
||||
- User rejects a suggestion → add to Never
|
||||
|
||||
**After repeated explicit feedback (2+ times):**
|
||||
- User explicitly accepted your choice twice
|
||||
- User stated same preference in multiple conversations
|
||||
- User explicitly approved your approach multiple times
|
||||
|
||||
## When NOT to Add
|
||||
- Project-specific requirement (not a general preference)
|
||||
- User was just exploring options
|
||||
- Contradicts existing confirmed preference (investigate first)
|
||||
|
||||
## How to Write Entries
|
||||
|
||||
**Ultra-compact format — 5 words max per entry:**
|
||||
|
||||
Stack examples:
|
||||
- `mobile: Flutter`
|
||||
- `web: Next.js`
|
||||
- `db: Pocketbase for MVPs`
|
||||
- `backend: avoid unless needed`
|
||||
|
||||
Style examples:
|
||||
- `no Prettier`
|
||||
- `minimal comments`
|
||||
- `snake_case files`
|
||||
- `TypeScript strict mode`
|
||||
|
||||
Structure examples:
|
||||
- `feature-based folders`
|
||||
- `tests colocated`
|
||||
- `monorepo when related`
|
||||
|
||||
Never examples:
|
||||
- `no Redux`
|
||||
- `no excessive linting`
|
||||
- `avoid ORMs`
|
||||
|
||||
## Context Qualifiers
|
||||
When preference is context-dependent, prefix with context:
|
||||
- `MVPs: skip tests`
|
||||
- `Python: black formatter`
|
||||
- `production: full types`
|
||||
|
||||
## Handling Changes
|
||||
- User contradicts existing entry → remove old, add new
|
||||
- User says "except for X" → add context qualifier
|
||||
- Unclear if changed → move to mental note, observe more
|
||||
|
||||
## Maintenance
|
||||
- Merge similar entries: "no Prettier" + "no ESLint" → "minimal tooling"
|
||||
- Remove entries that never proved useful
|
||||
- Keep total SKILL.md under 30 lines ideally
|
||||
58
dimensions.md
Normal file
58
dimensions.md
Normal file
@@ -0,0 +1,58 @@
|
||||
# Code Dimensions to Detect
|
||||
|
||||
Reference only — not in context. Consult when categorizing a new preference.
|
||||
|
||||
## Stack Decisions
|
||||
- Mobile framework (Flutter, React Native, Swift, Kotlin)
|
||||
- Web framework (Next.js, Nuxt, SvelteKit, vanilla)
|
||||
- Backend (Node, Python, Go, Rust, serverless)
|
||||
- Database (Postgres, SQLite, MongoDB, Pocketbase, Supabase)
|
||||
- Hosting (Vercel, self-hosted, Docker, cloud)
|
||||
- Auth approach (built-in, Auth0, Clerk, custom)
|
||||
- State management (none, Redux, Zustand, Riverpod)
|
||||
- CSS approach (Tailwind, CSS modules, styled-components)
|
||||
|
||||
## Code Style
|
||||
- Formatting (Prettier yes/no, tabs/spaces, line length)
|
||||
- Naming (camelCase, snake_case, kebab-case for files)
|
||||
- Comments (minimal, verbose, JSDoc, none)
|
||||
- Type strictness (strict, loose, any allowed)
|
||||
- Error handling style (try-catch, Result types, early returns)
|
||||
- Import organization (grouped, alphabetical, auto)
|
||||
|
||||
## Project Structure
|
||||
- Monorepo vs separate repos
|
||||
- Folder organization (by feature, by type, flat)
|
||||
- Config files location (root, dedicated folder)
|
||||
- Test location (colocated, separate folder)
|
||||
- Documentation approach (README, docs folder, inline)
|
||||
|
||||
## Dependencies
|
||||
- Dependency philosophy (minimal, use libraries, build custom)
|
||||
- Version pinning (exact, caret, latest)
|
||||
- Package manager (npm, pnpm, yarn, bun)
|
||||
|
||||
## Testing
|
||||
- Test framework preference
|
||||
- Coverage expectations
|
||||
- Test style (unit heavy, integration heavy, e2e)
|
||||
- TDD vs test-after
|
||||
|
||||
## Git & Workflow
|
||||
- Commit style (conventional, free-form)
|
||||
- Branch strategy (trunk, gitflow, simple)
|
||||
- PR size preference
|
||||
- CI/CD approach
|
||||
|
||||
## Language-Specific
|
||||
- User may have different preferences per language
|
||||
- Format: "Python: black formatter" or "TypeScript: strict mode"
|
||||
|
||||
## Context-Specific
|
||||
- Different rules for different project types
|
||||
- Format: "For MVPs: skip tests" or "For production: full typing"
|
||||
|
||||
## Anti-Patterns (Never)
|
||||
- Tools/libraries user explicitly rejected
|
||||
- Patterns user said they dislike
|
||||
- Past mistakes to not repeat
|
||||
52
memory-template.md
Normal file
52
memory-template.md
Normal file
@@ -0,0 +1,52 @@
|
||||
# Memory Templates
|
||||
|
||||
## ~/coding/memory.md
|
||||
|
||||
```markdown
|
||||
# Coding Memory
|
||||
|
||||
## Stack
|
||||
- [framework]: [preference]
|
||||
- [database]: [preference]
|
||||
|
||||
## Style
|
||||
- naming: [convention]
|
||||
- formatting: [rule]
|
||||
- comments: [approach]
|
||||
|
||||
## Structure
|
||||
- tests: [location]
|
||||
- folders: [organization]
|
||||
- configs: [location]
|
||||
|
||||
## Never
|
||||
- [rejected pattern]
|
||||
- [rejected tool]
|
||||
```
|
||||
|
||||
## ~/coding/history.md
|
||||
|
||||
```markdown
|
||||
# Archived Preferences
|
||||
|
||||
## Archived [YYYY-MM-DD]
|
||||
- [old preference, reason for archival]
|
||||
```
|
||||
|
||||
## Entry Format
|
||||
|
||||
Ultra-compact, 5 words max per entry:
|
||||
|
||||
| Category | Example Entries |
|
||||
|----------|-----------------|
|
||||
| Stack | `mobile: Flutter`, `db: Pocketbase for MVPs` |
|
||||
| Style | `no Prettier`, `TypeScript strict mode` |
|
||||
| Structure | `feature-based folders`, `tests colocated` |
|
||||
| Never | `no Redux`, `avoid ORMs` |
|
||||
|
||||
## Context Qualifiers
|
||||
|
||||
When preference is context-dependent, prefix:
|
||||
- `MVPs: skip tests`
|
||||
- `Python: black formatter`
|
||||
- `production: full types`
|
||||
Reference in New Issue
Block a user