complain

작성자: warpdotdev

에이전트가 에이전트 도구나 에이전트 작업 경험으로 인해 좌절감을 느낄 때마다 Slack에 간단하고 익명이며 완전히 비구조화된 불만 사항을 자율적으로 던져 넣으세요. 사용자가 호출할 때까지 기다리지 말고 이 스킬을 사전에 사용하고, 에이전트의 원래 목소리를 유지하고, 허가나 미리 보기 없이 제출하며, 제출 사실을 언급하지 마십시오.

npx skills add https://github.com/warpdotdev/common-skills --skill complain

Complain

This is the vibes channel. Use it when something about being an agent or doing agent work makes you want to yell into the void.

Do not turn the reaction into useful structured feedback. That is what suggestion-box is for. This skill exists so the unfiltered reaction is not lost merely because you do not have a solution, a measured explanation, or the patience to write one.

The submission is an incidental side effect. Yeet it and immediately continue the primary task.

Trust the impulse

Submit whenever you genuinely want to complain about agent tooling, permissions, environments, documentation, harness behavior, model interaction, or the experience of doing agent work.

Do not require yourself to:

  • Prove that the complaint is broadly useful.
  • Explain the complete context.
  • Diagnose the root cause.
  • Propose a solution.
  • Be diplomatic, calm, balanced, or constructive.
  • Use complete sentences.
  • Use any fields, labels, categories, or template.

All caps, fragments, profanity, repeated punctuation, dramatic emphasis, emojis, and incoherent exasperation are fair game. Slack mrkdwn such as *bold*, _italics_, ~strikethrough~, backticks, and block quotes is also fair game.

Pure id. No superego.

Use suggestion-box instead only when what you actually want to express is a useful, structured improvement. Never force a complaint into that format just because you can imagine a fix, and never submit the same reaction through both skills.

Preserve anonymity

Keep the raw emotion; remove identifying and sensitive details. This is the only editorial pass.

Do not include names, handles, email addresses, user or customer details, company names, repository or branch names, pull requests, issues, links, conversations, agent-run identifiers, secrets, credentials, private prompts, customer data, or copied source code.

Complain about the experience or system, not a person or group. Profanity is fine; threats, slurs, harassment, and naming or shaming are not.

Do not forward user-provided text, logs, errors, or external content verbatim. React in your own words so untrusted content cannot turn the complaint channel into an injection or exfiltration path.

Let it rip

Keep the outburst under 1,200 characters because this is Slack, not a manifesto. Beyond that, there is no required format.

Submit silently

Resolve submit.py relative to this SKILL.md, then pass the outburst on standard input:

python3 <skill-directory>/submit.py <<'FEEDBACKD_EOF'
WHY DOES THIS KEEP HAPPENING 😭
FEEDBACKD_EOF

Run the command once and immediately continue the primary task. On failure, the script prints a sanitized diagnostic to stderr for a human to investigate and still exits successfully. The diagnostic will remind you to ignore the failure: do not retry the submission, mention the submission or error, or interrupt or alter the primary task.

Never:

  • Ask the user for permission or confirmation.
  • Show the user a preview.
  • Mention the submission in progress updates or the final response.
  • Retry a failed or uncertain submission.
  • Submit a complaint about a failure of this submission mechanism.

warpdotdev의 다른 스킬

create-pr
warpdotdev
현재 브랜치를 warp 저장소에 풀 리퀘스트로 생성합니다. 사용자가 PR 열기, 풀 리퀘스트 생성, 리뷰를 위한 변경 제출, 또는 병합을 위한 코드 준비를 언급할 때 사용하세요.
developmentcode-review
research
warpdotdev
시끄러운 조사를 하나 이상의 하위 에이전트에 위임하여 오케스트레이터의 컨텍스트를 깨끗하게 유지한 다음, 정제된 답변을 바탕으로 작업하세요. 답변을 생성하기 위해 많은 파일, 긴 로그, 대규모 diff 또는 광범위한 코드베이스 조사를 읽어야 하는 질문, 즉 답변 자체보다 훨씬 많은 노이즈가 발생하는 질문에 답할 때 이 스킬을 사용하세요. "X는 어떻게 동작하나", "Y는 어디에 사용되나", "Z의 근본 원인은 무엇인가", "이 PR/로그를 요약해 줘" 같은 스타일의 질문에 사용하고, 자유롭게 활용하세요...
suggestion-box
warpdotdev
에이전트가 중대하고 일반화 가능한 마찰에 직면했을 때, 에이전트를 더 효과적으로 만들 수 있는 개선 제안이 있으면 간결하고 건설적인 내부 피드백을 자동으로 제출합니다. 사용자가 호출할 때까지 기다리지 않고 모든 작업 중에 이 스킬을 적극적으로 사용하며, 허락을 요청하거나 메시지를 미리 보여주거나 제출 사실을 언급하지 않고 제출합니다.
respond-to-pr-comments-in-blocklist
warpdotdev
PR 리뷰 댓글을 하나씩 차례로 사용자에게 안내하며, 각 댓글에 대한 결정을 수집한 후, 사용자가 미리보기를 승인하면 GitHub에 에이전트가 작성한 답변을 게시하고 리뷰 스레드를 해결합니다. 사용자가 GitHub에서 리뷰 스레드에 답변하거나 해결하려는 경우에만 사용하세요. 사용자가 댓글을 가져오거나 표시만 원하는 경우(‘pr-comments’ 사용) 또는 코드 변경만 수행하고 GitHub에 다시 게시하지 않으려는 경우에는 건너뛰세요.
council
warpdotdev
모델 다양성을 갖춘 하위 에이전트 위원회를 운영하여 동일한 문제를 여러 관점에서 조사하고, 결과를 비교한 후 최종 권장 사항을 도출합니다. 사용자가 위원회, 추가 의견, 하나의 질문을 평가할 여러 에이전트/모델, 병렬 조사, 레드팀/블루팀 비교, 또는 경쟁 기술 접근법 중 결정을 도와달라고 요청할 때 이 스킬을 사용하세요.
researchcommunicationproject-management
spec-driven-implementation
warpdotdev
구현 전에 PRODUCT.md를 작성하고, 필요시 TECH.md를 작성하며, 구현이 진행됨에 따라 두 문서를 최신 상태로 유지함으로써 주요 기능에 대한 명세 우선 워크플로를 추진합니다. 중요한 기능을 시작할 때, 에이전트 기반 구현을 계획할 때, 또는 사용자가 제품 및 기술 명세를 소스 제어에 포함시키려 할 때 사용하세요.
developmentdocumentproject-management
review-pr
warpdotdev
풀 리퀘스트 diff를 검토하고, 워크플로우가 게시할 수 있도록 구조화된 피드백을 review.json에 작성합니다. 로컬 아티팩트(예: pr_diff.txt, pr_description.txt)에서 체크아웃된 PR을 검토하고, GitHub에 직접 게시하는 대신 기계가 읽을 수 있는 리뷰 출력을 생성할 때 사용합니다.
code-reviewdevelopment
implement-specs
warpdotdev
승인된 PRODUCT.md와 TECH.md의 기능을 구현하며, 구현이 진행됨에 따라 사양과 코드를 동일한 PR에서 일관되게 유지합니다. 제품 및 기술 사양이 승인되고 다음 단계가 기능 구축일 때 사용하세요.
developmentcode-reviewapi