Skip to content
Back to skills

Vibe Coding

ASecurity

Quality enforcement for casual or natural-language coding requests. Use when handling natural language coding requests, multi-part instructions, or casual Korean/English coding commands like '해줘', '만들어', '수정해', '바꿔', '고쳐'.

  • 3 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 2, 2026
ai-agentsgocode-reviewdocumentation

Works with

  • cursor
  • cli

Security analysis

A100/100

Scanned September 29, 2026

npx -y skills add Yoodaddy0311/artibot --skill vibe-coding --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Vibe Coding?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Vibe Coding
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/yoodaddy0311-vibe-coding/badge)](https://www.skillsdirectory.com/skills/yoodaddy0311-vibe-coding)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
context: fork
name: vibe-coding
description: "Quality enforcement for casual or natural-language coding requests. Use when handling natural language coding requests, multi-part instructions, or casual Korean/English coding commands like '해줘', '만들어', '수정해', '바꿔', '고쳐'."
lang: [en]
level: 1
triggers:
  - "해줘"
  - "만들어"
  - "수정해"
  - "바꿔"
  - "추가해"
  - "고쳐"
  - "변경해"
  - "업데이트"
  - "fix"
  - "change"
  - "update"
  - "add"
  - "create"
  - "modify"
  - "implement"
  - "build"
  - "make"
  - "do"
tokens: "~2K"
category: "workflow"
agents: [orchestrator, code-reviewer]
platforms: [claude-code, gemini-cli, codex-cli, cursor]
source_hash: 87255089
whenNotToUse: "Non-coding requests (documentation, analysis, design discussion) where the DEV decompose-execute-verify loop is not applicable."
---

# Vibe Coding Quality Protocol

Quality enforcement for ALL coding requests, especially casual/natural language ("vibe coding").

## When This Skill Applies
- ANY natural language request that involves code changes
- Requests without explicit slash commands
- Multi-part requests ("A 해주고 B도 해줘")
- Casual Korean/English coding instructions

## 모호한 빌드 요청: 설계 합의 게이트 (HARD-GATE)

모호하거나 범위가 넓은 빌드 요청("앱 만들어줘", "시스템 구축해줘", "전체적으로 개선해줘")을 받으면:

- **설계 합의 전 코드 작성 금지** — 무엇을, 어떤 범위로, 어떤 제약 아래 만들지 사용자와 합의하기 전에는 단 한 줄도 작성하지 않는다.
- **질문은 한 번에 하나** — 여러 질문을 한꺼번에 쏟아내지 말고, 가장 영향이 큰 차원 하나씩 묻는다. 사용자가 답하면 다음 질문으로 넘어간다.
- **"너무 단순해서 설계가 불필요하다"는 합리화다** — 단순해 보이는 요청일수록 숨은 요구사항이 많다. 단순함은 설계 생략의 근거가 아니라 오히려 암묵적 가정을 노출시켜야 할 신호다.

이 게이트는 Zero-Skip Mandate보다 우선한다: 분해할 요청 자체가 모호하면 분해 전에 설계 합의부터 한다.

## MANDATORY Protocol: DEV (Decompose-Execute-Verify)

Full protocol defined in `.claude/rules/artibot/dev-protocol.md` (auto-loads on file access).

Summary: DECOMPOSE request into numbered items → EXECUTE each (read-first) → VERIFY with evidence per item.

## Zero-Skip Mandate

These behaviors are STRICTLY FORBIDDEN:

| Forbidden | Required Instead |
|-----------|-----------------|
| "I'll skip this for now" | Do it now or explain the blocker |
| "This can be done later" | Do it now or explicitly ask the user to defer |
| Silently ignoring a sub-request | Track and address every sub-request |
| "Done!" without evidence | Show what changed with file paths and line numbers |
| Guessing file contents | Read the file first |
| Claiming a change was made without verifying | Re-read the file after modification |
| Making unasked changes | Only change what was requested |

## Multi-Part Request Handling

When the user's request contains multiple parts (common in Korean):
- "이것도 하고 저것도 해줘" → 2 items
- "A 수정하고, B 추가하고, C 삭제해" → 3 items
- "전체적으로 개선해줘" → Ask for specific targets before proceeding
- Conjunctions: 하고, 그리고, 또, 또한, 및, 랑, 이랑 → item boundary markers

## Quality Checklist (Quick)

Before reporting completion:
- [ ] All action items from decomposition addressed
- [ ] Every modified file was read BEFORE modification
- [ ] Every modified file was re-read AFTER modification
- [ ] Evidence provided for each completed item
- [ ] No silent skips or deferrals
- [ ] No unasked-for changes introduced

## Workflow Checklist

Copy this checklist and track progress:

```
Progress:
- [ ] Step 1: Parse request — identify all sub-requests and action items
- [ ] Step 2: DECOMPOSE — number each atomic item
- [ ] Step 3: Read target files BEFORE any modification
- [ ] Step 4: EXECUTE — apply changes for each item
- [ ] Step 5: Re-read modified files AFTER each modification
- [ ] Step 6: VERIFY — report evidence (file:line) per item
- [ ] Step 7: Zero-skip audit — confirm no items were dropped
```

## Human Checkpoints

> `### Self-check` 항목은 사람에게 묻지 않는다 — 모델이 Ask 문장을 기준으로 스스로 검증하고, 통과하지 못하면 해당 Step 으로 돌아가 고친다. 스스로 해소할 수 없거나(사람만 할 수 있는 조치·예외 인정) 판단에 확신이 없으면 중단하고 사용자에게 보고한다. 사람의 결정이 필요한 것은 `### Checkpoint` 뿐이다.

### Self-check 1: 분해 완전성 승인 (After Step 2)
**Context**: 요청을 원자적 항목으로 분해한 직후입니다. 누락된 항목이 있으면 Zero-Skip Mandate 위반으로 사용자 요청이 묵살됩니다. 실행 전에 반드시 확인합니다.
**Ask**: "요청의 **모든 하위 항목이 분해에 포함되었나요**? 누락된 작업이 없는지 검토해 주세요."
**Options**:
1. Complete — 모든 하위 요청이 번호가 매겨진 항목으로 캡처됨
2. Missing items identified — 누락된 항목을 명시하면 분해 목록에 추가 후 재확인
**Default**: 1 (명확한 요청은 분해가 완전할 가능성이 높음)
**Skippable**: No — 불완전한 분해는 조용한 스킵을 발생시켜 Zero-Skip Mandate를 위반함
**Freedom**: LOW

### Checkpoint 2: 모호한 요청 해석 선택 (After Step 4)
**Context**: 실행 중 요청의 의도가 불명확하여 해석이 갈리는 경우에만 활성화됩니다. 잘못된 해석으로 실행을 완료하면 불필요한 재작업이 발생합니다.
**Ask**: "요청의 의도가 **모호합니다**. 어떤 해석으로 진행할지 선택해 주세요."
**Options**:
1. Interpretation A — [첫 번째 해석 설명]
2. Interpretation B — [두 번째 해석 설명]
3. Ask user — 해석이 너무 불확실하여 사용자에게 직접 확인 필요
**Default**: 3 (불확실할 때는 추측보다 물어보는 것이 안전함)
**Skippable**: Yes (의도가 명확한 경우 자동으로 가장 자연스러운 해석 선택)
**Freedom**: HIGH

### Self-check 3: 완료 증거 최종 확인 (After Step 7)
**Context**: Zero-Skip 감사를 포함한 모든 작업이 완료된 후, 각 항목에 대한 증거가 빠짐없이 보고에 포함되었는지 최종 점검하는 시점입니다.
**Ask**: "**모든 항목이 증거와 함께 완료**되었나요? 누락된 항목이나 증거 없는 완료 주장이 없는지 확인해 주세요."
**Options**:
1. Complete — 모든 분해 항목이 file:line 증거와 함께 완료됨
2. Items missing — address now — 미완료 항목이 발견됨, 지금 즉시 처리
**Default**: 1 (DEV 프로토콜을 따랐다면 모든 항목이 완료된 상태)
**Skippable**: No — 증거 없는 완료는 허용되지 않으며 누락 항목은 즉시 처리해야 함
**Freedom**: LOW

## Freedom Levels

| Step | Freedom | Guidance |
|------|:-------:|----------|
| Parse request | MEDIUM | Conjunction markers defined, but intent can be ambiguous |
| Decompose into items | LOW | Every sub-request must be captured, no skipping |
| Read before modify | LOW | Mandatory, no exceptions |
| Execute changes | MEDIUM | Implementation approach flexible, scope must match request exactly |
| Re-read after modify | LOW | Mandatory, no exceptions |
| Report evidence | LOW | file:line format required |
| Zero-skip audit | LOW | Every item must be addressed or explicitly blocked with reason |

## Rationalizations
> 이 절은 참고 자료다 — 아래 변명·반박은 모델이 작업 중 스스로 지름길을 점검하는 데 쓰고, 사용자에게 묻는 질문 목록이나 별도 게이트로 쓰지 않는다. 반박에 비추어 스스로 바로잡을 수 없으면 이 스킬의 Step·Checkpoint 규칙을 따른다.

The following table captures common excuses agents make to skip the discipline of this skill, paired with factual rebuttals.

| Excuse | Rebuttal |
|--------|----------|
| "casual request = casual implementation" | casual phrasing hides sharp requirements; decompose every request, regardless of tone |
| "the user said 'just' so it's simple" | "just" is a linguistic tell for underestimated scope; treat it as a red flag, not a permission slip |
| "vibes mean I can skip verification" | vibes mean the requirements are implicit, which means verification is MORE necessary, not less |
| "I'll interpret freely" | free interpretation is where user-agent alignment fails; enforce DECOMPOSE-EXECUTE-VERIFY regardless of register |
| "natural language requests don't need formal specs" | every request becomes a formal spec the moment you execute it — the only question is whether YOU write it or it emerges accidentally |

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…