Antigravity Agent
f8b21af4be
10_Wiki/Topics 대규모 정리: - 오류 캡처/미완성 stub 문서 227개 제거 - 교차폴더 중복 43클러스터 병합 (63파일 → redirect) - 링크명 정규화: 깨진 링크 수정·redirect 직결·개념 매핑 ~2,400건 - 카테고리 MOC 6개 신규 생성 - Graph 섹션 미해결 related-keyword 링크 10,058건 제거 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
276 lines
7.0 KiB
Markdown
276 lines
7.0 KiB
Markdown
---
|
|
id: wiki-2026-0508-be-detailed
|
|
title: Be Detailed (Specificity Principle)
|
|
category: 10_Wiki/Topics
|
|
status: verified
|
|
canonical_id: self
|
|
aliases: [구체화, specificity, prompt detail, requirement specification, edge case enumeration]
|
|
duplicate_of: none
|
|
source_trust_level: B
|
|
confidence_score: 0.85
|
|
verification_status: applied
|
|
tags: [communication, prompt-engineering, requirements, spec, detail, edge-case, anti-vague]
|
|
raw_sources: []
|
|
last_reinforced: 2026-05-10
|
|
github_commit: pending
|
|
tech_stack:
|
|
language: communication / spec
|
|
applicable_to: [Prompt Engineering, RFC, Spec Writing, Bug Reports]
|
|
---
|
|
|
|
# Be Detailed (Specificity Principle)
|
|
|
|
## 📌 한 줄 통찰
|
|
> **"매 devil 의 detail"**. 매 abstraction 의 hide X — 매 number, 매 context, 매 edge. 매 prompt engineering 의 single biggest lever — 매 vague "make it good" → 매 hallucination, 매 specific "max 50 words, 매 active voice" → 매 reliable.
|
|
|
|
## 📖 핵심
|
|
|
|
### 매 specificity tool
|
|
|
|
#### 1. Quantification
|
|
- ❌ "매우 빠름"
|
|
- ✅ "p99 < 100ms"
|
|
- ❌ "큰 file"
|
|
- ✅ "100MB 이상"
|
|
|
|
#### 2. Contextualization
|
|
- ❌ "login button"
|
|
- ✅ "centered modal with email + password + social OAuth (Google, Apple), max-width 400px"
|
|
|
|
#### 3. Edge case enumeration
|
|
- 매 happy path 의 X.
|
|
- 매 empty / null / overflow / unicode / negative / boundary.
|
|
- 매 concurrent / partial failure / network split.
|
|
|
|
#### 4. Negative spec
|
|
- "should NOT" 의 explicit.
|
|
- 매 boundary 의 clarify.
|
|
|
|
#### 5. Acceptance criteria
|
|
- 매 verifiable.
|
|
- 매 Given-When-Then.
|
|
|
|
### 매 spec hierarchy
|
|
|
|
#### Vague → Specific
|
|
1. "Make it user-friendly"
|
|
2. "Reduce form fields"
|
|
3. "Reduce checkout from 6 fields to 2 (email, payment)"
|
|
4. "Reduce checkout from 6 fields to 2 (email, payment), keep address auto-fill via Stripe Address Element, A/B test 50/50 for 2 weeks"
|
|
|
|
→ 매 step 4 만 의 actionable.
|
|
|
|
### 매 prompt engineering 의 detail
|
|
|
|
#### 매 vague (bad)
|
|
> "Write me a poem"
|
|
|
|
#### 매 specific (good)
|
|
> "Write a 4-line haiku about autumn leaves.
|
|
> Format: 5-7-5 syllables.
|
|
> Tone: melancholic.
|
|
> No rhyming required.
|
|
> Output: poem only, no explanation."
|
|
|
|
→ 매 hallucination ↓, 매 reliability ↑.
|
|
|
|
### 매 RFC / spec format
|
|
1. **Motivation**: 매 why.
|
|
2. **Detailed design**: 매 how.
|
|
3. **Drawbacks**: 매 cost.
|
|
4. **Alternatives**: 매 other approaches.
|
|
5. **Unresolved questions**: 매 known gap.
|
|
6. **Future work**: 매 next.
|
|
|
|
### 매 bug report (specific)
|
|
- 매 reproducer (minimum case).
|
|
- 매 expected vs actual.
|
|
- 매 environment (OS, browser, version).
|
|
- 매 logs / stack trace.
|
|
- 매 frequency (always / 50% / random).
|
|
- 매 impact.
|
|
|
|
### 매 over-detail risk
|
|
- 매 over-spec: 매 implementation 의 lock-in.
|
|
- 매 micro-management: 매 creativity X.
|
|
- 매 outdated detail: 매 maintenance.
|
|
- 매 reader 의 cognitive overload.
|
|
|
|
→ 매 right level 의 abstraction.
|
|
|
|
### 매 progressive disclosure
|
|
- 매 summary first.
|
|
- 매 detail on demand.
|
|
- 매 README → 매 ADR → 매 code.
|
|
|
|
## 💻 패턴
|
|
|
|
### Specific prompt template
|
|
```
|
|
ROLE: Senior backend engineer.
|
|
TASK: Refactor function X.
|
|
CONTEXT:
|
|
- Current: throws on error.
|
|
- Codebase: TypeScript, neverthrow library.
|
|
|
|
CONSTRAINTS:
|
|
- Keep public signature unchanged.
|
|
- Return Result<T, E>.
|
|
- Add unit test for both branches.
|
|
|
|
OUTPUT FORMAT:
|
|
- Code only, no explanation.
|
|
- TypeScript with neverthrow.
|
|
|
|
EXAMPLE OUTPUT (for similar task):
|
|
[paste example]
|
|
|
|
INPUT:
|
|
[code]
|
|
```
|
|
|
|
### Acceptance criteria (Given-When-Then)
|
|
```gherkin
|
|
Feature: Login
|
|
Scenario: Valid credentials
|
|
Given a registered user with email "user@example.com"
|
|
And password "Pass123!"
|
|
When they submit the login form
|
|
Then they are redirected to /dashboard
|
|
And a session cookie "sid" is set with HttpOnly and Secure flags
|
|
|
|
Scenario: Invalid password
|
|
Given a registered user
|
|
When they submit invalid password 5 times in 1 minute
|
|
Then they are rate-limited for 15 minutes
|
|
And a 429 status is returned
|
|
```
|
|
|
|
### Bug report template
|
|
```markdown
|
|
## Reproducer
|
|
1. Login as user@example.com
|
|
2. Click "Export CSV" on /reports/123
|
|
3. CSV downloads but contains BOM + wrong encoding
|
|
|
|
## Expected
|
|
UTF-8 without BOM (matches docs).
|
|
|
|
## Actual
|
|
UTF-16 with BOM. Excel opens it but Numbers crashes.
|
|
|
|
## Environment
|
|
- macOS 15.2
|
|
- Chrome 130.0.6723
|
|
- App version 1.42.3 (commit abc123)
|
|
|
|
## Frequency
|
|
100% — every export since deploy on 2026-05-08.
|
|
|
|
## Impact
|
|
~200 users daily affected. Workaround: open in Excel.
|
|
|
|
## Logs
|
|
[paste]
|
|
```
|
|
|
|
### RFC template (short)
|
|
```markdown
|
|
# RFC-0042: Adopt Kafka for events
|
|
|
|
## Motivation
|
|
3 services need async coordination. Sync HTTP causes cascade.
|
|
|
|
## Detailed design
|
|
- Events: Avro schema.
|
|
- Topic: domain.event_type.v{version}.
|
|
- Retention: 7 days.
|
|
- Consumer group per service.
|
|
|
|
## Drawbacks
|
|
- Operational complexity (Kafka cluster).
|
|
- Async debugging harder.
|
|
|
|
## Alternatives
|
|
1. RabbitMQ — simpler, less throughput.
|
|
2. SQS — vendor lock-in, less ordering.
|
|
|
|
## Unresolved
|
|
- Schema registry choice.
|
|
- DLQ strategy.
|
|
|
|
## Future
|
|
- Stream processing (Flink).
|
|
```
|
|
|
|
### Edge case checklist (function spec)
|
|
```
|
|
For function process(input):
|
|
|
|
Empty:
|
|
[ ] input = null
|
|
[ ] input = undefined
|
|
[ ] input = ''
|
|
[ ] input = []
|
|
[ ] input = {}
|
|
|
|
Boundary:
|
|
[ ] input.length = 0
|
|
[ ] input.length = 1
|
|
[ ] input.length = MAX_INT
|
|
[ ] input.length = MAX_INT + 1
|
|
|
|
Type:
|
|
[ ] input = number (expected string)
|
|
[ ] input = string (expected number)
|
|
[ ] input = function
|
|
|
|
Special:
|
|
[ ] Unicode (emoji, RTL, combining)
|
|
[ ] Negative numbers
|
|
[ ] NaN, Infinity
|
|
[ ] Concurrent calls
|
|
[ ] Network failure mid-call
|
|
```
|
|
|
|
## 🤔 결정 기준
|
|
| 상황 | Detail level |
|
|
|---|---|
|
|
| Prompt to LLM | Maximum (constraint + example + format) |
|
|
| Spec / RFC | High (motivation + design + alternatives) |
|
|
| Bug report | High (repro + env + frequency) |
|
|
| README | Medium (BLUF + 30s pitch) |
|
|
| Slack message | Low (concise) |
|
|
| Architecture diagram | Layered (C4) |
|
|
|
|
**기본값**: 매 audience + 매 task 의 calibrate. 매 vague 의 default 의 X.
|
|
|
|
## 🔗 Graph
|
|
- 부모: [[Articulateness]]
|
|
- 변형: [[Edge-Case-Enumeration]]
|
|
- 응용: [[Prompt_Engineering|Prompt-Engineering]] · [[RFC]]
|
|
- Adjacent: [[Progressive-Disclosure]] · [[ADR]]
|
|
|
|
## 🤖 LLM 활용
|
|
**언제**: 매 LLM prompt. 매 spec 작성. 매 bug report. 매 design review.
|
|
**언제 X**: 매 brainstorm (premature specificity). 매 creative explore.
|
|
|
|
## ❌ 안티패턴
|
|
- **"매 user-friendly"** without metric: 매 unmeasurable.
|
|
- **No edge case**: 매 production crash.
|
|
- **Over-spec**: 매 implementation lock-in.
|
|
- **No reproducer in bug**: 매 wasted reviewer time.
|
|
- **No acceptance criteria**: 매 "done?" 의 ambiguous.
|
|
- **No example in prompt**: 매 LLM 의 guess.
|
|
|
|
## 🧪 검증 / 중복
|
|
- Verified (Pragmatic Programmer, RFC tradition, prompt engineering best practice).
|
|
- 신뢰도 B.
|
|
- Related: [[Articulateness]] · [[Prompt_Engineering|Prompt-Engineering]] · [[Spec-Writing]] · [[Edge-Case]].
|
|
|
|
## 🕓 Changelog
|
|
| 날짜 | 변경 |
|
|
|---|---|
|
|
| 2026-05-08 | Phase 1 |
|
|
| 2026-05-10 | Manual cleanup — specificity tool + prompt template + bug report + RFC + edge case checklist |
|