write

Use when starting a substantial written artifact that will be read by others. Triggers on: "문서 같이 써줘", "PRD 작성", "design doc", "RFC 초안", "제안서 써야 해", "technical spec", "decision doc", "write a doc", "문서 작성 도와줘", "spec 써줘". Best for: PRDs, design docs, decision docs, technical specs, RFCs, proposals. Not for: short single-paragraph writes or casual emails — use writer-verification for existing drafts.

Use when giving feedback to a colleague and the wording feels judgmental, vague, or accusatory. Triggers on: "피드백 어떻게 말해?", "feedback 써줘", "SBI", "동료한테 어떻게 말해야 해?", "칭찬 어떻게 해?", "건설적 피드백", "peer review 써야 해", "이 말이 너무 공격적인 것 같아". Best for: constructive feedback, peer reviews, positive recognition, upward feedback. Not for: general performance reviews or disciplinary documentation.

Use when writing a technical blog post about something built, fixed, or learned. Triggers on: "기술 블로그 써줘", "개발 블로그", "technical blog", "글 쓰고 싶은데 어떻게 시작해?", "이 경험 블로그로 쓰고 싶어", "engineering post", "회고 글", "튜토리얼 써줘", "개발 경험 공유". Best for: incident post-mortems, feature deep dives, lessons from production, tutorials. Not for: marketing copy, non-technical writing, or documentation (use doc-coauthoring).

Use when existing writing needs reviewing, proofreading, or improvement. Triggers on: "글 검토해줘", "맞춤법 확인", "proofread", "이 문장 자연스러워?", "글 다듬어줘", "review my writing", "출판 전에 확인해줘", "표현이 어색한 것 같아", "문법 맞아?", "글 퀄리티 봐줘". Best for: blog posts, emails, documents, reports, marketing copy in Korean or English. Not for: writing new content from scratch (use technical-blog-writer or doc-coauthoring).

Use when a task is large enough that diving in without a plan leads to rework. Triggers on: "구현 계획 써줘", "implementation plan", "코딩 전에 계획 잡아줘", "migration plan", "이 기능 어떻게 나눠서 구현해?", "plan before coding", "스텝별로 정리해줘", "리팩토링 계획". Best for: multi-part features, migrations, refactors with dependencies, anything with 3+ moving parts. Not for: single-step tasks or already-planned work ready to execute (use executing-plans).