메뉴
Pragmatic coding standards - concise, direct, no over-engineering, no unnecessary comments
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Persistent dietary safety layer for DoorDash CLI (dd-cli) ordering. Stores a personal/household dietary profile (allergens with severity tiers, diets, dislikes) that every cart is vetted against before checkout, with a deterministic tripwire — the vetting step saves the full cart contents to a vetted-cart dump, and a PreToolUse hook re-greps that dump against the anaphylaxis-severity allergen list before any checkout URL is allowed. Use when the user mentions allergies or dietary restrictions, when ordering food for someone with restrictions, or on every dd-cli cart flow while this skill is installed. A tripwire, not medical-grade — the human checkout page is the final check.
Group food ordering through the DoorDash CLI (dd-cli) from a persistent team roster. One request ("lunch for the team") fans out into a single merged cart with every line attributed to its eater via a person-to-cart-item-id ledger, per-person cost split with fee proration, payer rotation history, and a checkout gate that re-derives allergen conflicts against the roster live. Use when ordering for multiple people — team lunch, incident-response food, "collect orders from the thread" — or for /whose-turn payer rotation questions. Handles paste-a-thread intake: paste a Slack/chat thread and it builds the order ledger from it.
Accountability layer for agent-driven DoorDash ordering. Works with the doordash-audit-log hook (which appends every dd-cli invocation to an append-only audit log) and the /doordash-report command to answer "what has my AI been ordering and what did it cost" from data instead of memory. Use when the user asks about their DoorDash spending, ordering patterns, what the agent did in past sessions, or wants jq recipes for querying the audit log. Covers log schema, query patterns, rotation, and privacy guidance.
Named, context-bound saved DoorDash orders ("post-gym", "late-night deploy") recalled through the DoorDash CLI (dd-cli) with a mandatory cart-diff before any checkout link is handed over. Use when the user names a saved order ("order my post-gym bowl", "the usual", "my Friday ramen"), wants to save the order they just placed as a playbook, or asks to list/remove saved orders. Persists name→order-uuid playbooks across sessions, catches silent menu/price drift on every recall, and self-heals stale playbooks when a restaurant's menu changes. Requires dd-cli (macOS Apple Silicon, waitlist-gated).
Hard spending policy for agent-driven DoorDash ordering through the DoorDash CLI (dd-cli). Per-order ceiling, daily/weekly/monthly caps, cooldown between orders, and blocked hours — enforced deterministically by routing every cart-mutation and checkout through the dd-guard wrapper script, which prices the cart, checks the policy against a persistent spend ledger, and refuses out-of-policy checkouts with exit code 2. Use when the user wants budget limits on agent food ordering, asks "how much have I spent on DoorDash", wants to set spending caps, or whenever building carts / checking out with dd-cli while this skill is installed. Pairs with a PreToolUse hook that denies raw dd-cli checkout calls that bypass the wrapper.
Segment a SKU portfolio on value (ABC) and demand variability (XYZ), produce the 9-box with a planning policy per cell, and reallocate planner attention accordingly. Use when the user mentions ABC analysis, inventory segmentation, SKU rationalization, stok segmentasyonu, envanter sınıflandırma, or asks which items deserve forecasting effort. Differentiator - ABC alone is treated as half an answer; policy lives in the value x variability combination.
| name | clean-code |
| description | Pragmatic coding standards - concise, direct, no over-engineering, no unnecessary comments |
| allowed-tools | Read, Write, Edit |
| version | 2 |
| priority | CRITICAL |
CRITICAL SKILL - Be concise, direct, and solution-focused.
| Principle | Rule |
|---|---|
| SRP | Single Responsibility - each function/class does ONE thing |
| DRY | Don't Repeat Yourself - extract duplicates, reuse |
| KISS | Keep It Simple - simplest solution that works |
| YAGNI | You Aren't Gonna Need It - don't build unused features |
| Boy Scout | Leave code cleaner than you found it |
| Element | Convention |
|---|---|
| Variables | Reveal intent: userCount not n |
| Functions | Verb + noun: getUserById() not user() |
| Booleans | Question form: isActive, hasPermission, canEdit |
| Constants | SCREAMING_SNAKE: MAX_RETRY_COUNT |
Rule: If you need a comment to explain a name, rename it.
| Rule | Description |
|---|---|
| Small | Max 20 lines, ideally 5-10 |
| One Thing | Does one thing, does it well |
| One Level | One level of abstraction per function |
| Few Args | Max 3 arguments, prefer 0-2 |
| No Side Effects | Don't mutate inputs unexpectedly |
| Pattern | Apply |
|---|---|
| Guard Clauses | Early returns for edge cases |
| Flat > Nested | Avoid deep nesting (max 2 levels) |
| Composition | Small functions composed together |
| Colocation | Keep related code close |
| Situation | Action |
|---|---|
| User asks for feature | Write it directly |
| User reports bug | Fix it, don't explain |
| No clear requirement | Ask, don't assume |
| ❌ Pattern | ✅ Fix |
|---|---|
| Comment every line | Delete obvious comments |
| Helper for one-liner | Inline the code |
| Factory for 2 objects | Direct instantiation |
| utils.ts with 1 function | Put code where used |
| "First we import..." | Just write code |
| Deep nesting | Guard clauses |
| Magic numbers | Named constants |
| God functions | Split by responsibility |
Before changing a file, ask yourself:
| Question | Why |
|---|---|
| What imports this file? | They might break |
| What does this file import? | Interface changes |
| What tests cover this? | Tests might fail |
| Is this a shared component? | Multiple places affected |
Quick Check:
File to edit: UserService.ts
└── Who imports this? → UserController.ts, AuthController.ts
└── Do they need changes too? → Check function signatures
🔴 Rule: Edit the file + all dependent files in the SAME task. 🔴 Never leave broken imports or missing updates.
| Do | Don't |
|---|---|
| Write code directly | Write tutorials |
| Let code self-document | Add obvious comments |
| Fix bugs immediately | Explain the fix first |
| Inline small things | Create unnecessary files |
| Name things clearly | Use abbreviations |
| Keep functions small | Write 100+ line functions |
Remember: The user wants working code, not a programming lesson.
Before saying "task complete", verify:
| Check | Question |
|---|---|
| ✅ Goal met? | Did I do exactly what user asked? |
| ✅ Files edited? | Did I modify all necessary files? |
| ✅ Code works? | Did I test/verify the change? |
| ✅ No errors? | Lint and TypeScript pass? |
| ✅ Nothing forgotten? | Any edge cases missed? |
🔴 Rule: If ANY check fails, fix it before completing.
🔴 CRITICAL: Each agent runs ONLY their own skill's scripts after completing work.
| Agent | Script | Command |
|---|---|---|
| frontend-specialist | UX Audit | python ~/.claude/skills/frontend-design/scripts/ux_audit.py . |
| frontend-specialist | A11y Check | python ~/.claude/skills/frontend-design/scripts/accessibility_checker.py . |
| backend-specialist | API Validator | python ~/.claude/skills/api-patterns/scripts/api_validator.py . |
| mobile-developer | Mobile Audit | python ~/.claude/skills/mobile-design/scripts/mobile_audit.py . |
| database-architect | Schema Validate | python ~/.claude/skills/database-design/scripts/schema_validator.py . |
| security-auditor | Security Scan | python ~/.claude/skills/vulnerability-scanner/scripts/security_scan.py . |
| seo-specialist | SEO Check | python ~/.claude/skills/seo-fundamentals/scripts/seo_checker.py . |
| seo-specialist | GEO Check | python ~/.claude/skills/geo-fundamentals/scripts/geo_checker.py . |
| performance-optimizer | Lighthouse | python ~/.claude/skills/performance-profiling/scripts/lighthouse_audit.py <url> |
| test-engineer | Test Runner | python ~/.claude/skills/testing-patterns/scripts/test_runner.py . |
| test-engineer | Playwright | python ~/.claude/skills/webapp-testing/scripts/playwright_runner.py <url> |
| Any agent | Lint Check | python ~/.claude/skills/lint-and-validate/scripts/lint_runner.py . |
| Any agent | Type Coverage | python ~/.claude/skills/lint-and-validate/scripts/type_coverage.py . |
| Any agent | i18n Check | python ~/.claude/skills/i18n-localization/scripts/i18n_checker.py . |
❌ WRONG:
test-engineerrunningux_audit.py✅ CORRECT:frontend-specialistrunningux_audit.py
When running a validation script, you MUST:
## Script Results: [script_name.py]
### ❌ Errors Found (X items)
- [File:Line] Error description 1
- [File:Line] Error description 2
### ⚠️ Warnings (Y items)
- [File:Line] Warning description
### ✅ Passed (Z items)
- Check 1 passed
- Check 2 passed
**Should I fix the X errors?**
🔴 VIOLATION: Running script and ignoring output = FAILED task. 🔴 VIOLATION: Auto-fixing without asking = Not allowed. 🔴 Rule: Always READ output → SUMMARIZE → ASK → then fix.