구현하고 싶은 것을 설명하세요. 팀이 검토하고 에이전트가 실행할 수 있는 명세를 생성합니다.
Reduce return processing from 5 days to same-day for eligible orders
As a customer, I can initiate a return from order history so that I get a refund without contacting support
As a warehouse operator, I can process returns with barcode scan so that throughput stays above 50/hour
Return after 30-day window
Item was a gift purchase
Partial refund on bundled items
Payment timeout → retry 3x with backoff, then queue
Inventory sync failure → alert ops, hold refund
Add a returns flow to the e-commerce app
Do gift recipients get the refund, or the original purchaser?
This determines the refund routing logic and notification flow
Should customers be able to return individual items from a bundle?
Partial returns on bundles require inventory reconciliation
프로세스
도메인별 확인 사항 — 선물 반품 라우팅, 번들 가격 로직, 사기 엣지 케이스. 짧은 답변도 괜찮습니다. AI가 나머지를 추론합니다.
일회성 생성기가 아닙니다
모든 편집을 버전 관리. 두 버전을 비교. 변경 메모 추가.
초안 → 검토 중 → 승인됨 → 개발 중 → 전달됨. 80%에서 승인 게이트.
링크를 공유하세요. 누구나 특정 섹션에 댓글 가능 — 가입 필요 없음.
GitHub 리포지토리를 연결하세요. ClearSpec이 파일 트리, 종속성, 최근 PR을 읽어 실제 코드를 참조하는 명세를 생성합니다. 소스 코드는 저장되지 않습니다.
컨텍스트 없이
“Create a new API endpoint for refunds”
GitHub 컨텍스트와 함께
“Add POST /api/refunds in src/routes/payments.ts using the existing StripeService from src/services/stripe.ts. The OrderV2 schema from PR #487 applies.”
기존 명세용
누락된 장애 상태, 보안 사각지대, 모호한 기준. 각 갭에 구체적이고 구현 가능한 수정안 제시.
Add rate limiting: max 5 returns per user per hour with exponential backoff
Flag accounts with >3 returns in 30 days for manual review
Add ARIA labels, keyboard navigation, and screen reader announcements
더 빠르게 시작
각 템플릿이 명세 유형에 맞게 AI의 확인 질문을 맞춤 설정.
작업이 이루어지는 곳으로 명세 푸시
19%
더 느려짐. AI를 사용한 개발자는 스스로 빨라졌다고 믿었지만, 측정 결과 더 느렸습니다.
91%
리뷰 시간 증가. PR 볼륨이 2배로. 검증이 병목이 됨.
30-50%
의 엔지니어링 시간이 요구사항 명확화에 소비. 모호한 명세로 인한 15-30% 재작업.
얼리 액세스 기간 무료.