flow connects ChatGPT to your Flow (flow.team) workspace, the collaboration tool by Madrascheck. Find projects, tasks, calendar events, posts, comments, notifications, and wiki documents, and create or update work items — all scoped to the account you sign in with. Every batch write is previewed before it is applied, and irreversible changes require an explicit confirmation step.
dept(필수): 부서명(dvsn_nm) - since: 활동일 기준 시작일. 생략 시 최근 14일(프로젝트 체인과 달리 디폴트 있음). Output format=markdown(기본): 멤버 목록 + 프로젝트별 상태 통계 테이블 + 완료/신규/마감초과/상태변경 요약. format=structured: data에 프로젝트별 상태 통계 + 멤버 활동수 (JSON). 공통: counts/meta/orgTree. Common mistakes - 탐색은 "게시물 작성자 ∪ 업무 담당자" 기준 — 남의 글 밑에 업무만 만든 극소수 프로젝트는 누락될 수 있다. - 테스트/데모성 프로젝트(테스트/e2e/private 등)는 자동 제외된다. - 특정 프로젝트 한 개를 깊게 보려면 flow_collect_project_chain 을 쓴다. Examples - "AI사업개발실 이번 주 활동 정리" → dept:"AI사업개발실". 통계 JSON 으로 → format:"structured".link: flow 링크 또는 "project:<id>" / 순수 숫자 / 해시 - projectId: 프로젝트 전체 - postId: 특정 게시물 기준 상·하위 업무 트리(앵커 모드) 날짜 디폴트 없음 — since 줄 때만 그 이후 활동분으로 한정. statuses/assignees/priorities 필터 가능. Output format=markdown(기본): text에 마크다운 체인(~5만자 예산, 초과 시 압축/truncated). flow.team/l/ 링크는 3단계 재귀 확장. format=structured: data에 과제/게시물 배열(JSON) — 다운스트림에서 필터·정렬 가능. 값이 있는 사용자 커스텀 컬럼은 과제의 customColumns[{name,value}] 로 실린다(빈 값은 생략). 공통: counts/meta(상태·담당자 집계)/orgTree. Common mistakes - 부서 단위 요약은 이 도구가 아니라 flow_collect_dept_chain 을 쓴다. - 대형 프로젝트는 since 로 기간을 좁히면 빠르고 잘림 없이 받는다. 잘림이 걱정돼 이 도구 대신 flow_get_post 를 전건 순회하는 것은 더 나쁘다 — 호출이 수백~수천 배로 늘어 상류 호출량 제한에 걸리고, 그러면 아무것도 못 받는다. - companyId 는 인증 컨텍스트에서 자동 적용 — 입력으로 받지 않는다. Examples - "이 프로젝트 최근 진행상황" → projectId:"2910862" (또는 link). 구조화 → format:"structured".권한 거부 (403)). 남이 만든 오래된 방에서 자주 걸린다 — 재시도해도 같다. 방장에게 관리자 권한을 받거나, 새 프로젝트를 만들어 거기에 세운다. - type: option 이면 options 로 선택지를 준다(색은 자동 배정). Examples - 선택형: { projectId:"...", name:"우선분류", type:"option", options:["긴급","일반"] }. - 텍스트: { projectId:"...", name:"비고", type:"text" }. Common mistakes - type:"option" 인데 options 누락 — 선택지 없는 빈 옵션 컬럼이 됨. - 같은 이름 컬럼 중복 생성 — 추가 전 flow_get_project(include:["columns"]) 로 확인.projectId(colabo_srno) + postId(commt_srno) 둘 다 필요 — 검색/목록/체인 도구로 먼저 확보. - 답글은 replyToRemarkId(부모 댓글 ID) 지정. - 첨부: 일반 파일은 files, inline 이미지는 imageFiles (각각 여러 개). fileContents 는 base64. Examples - 댓글: { projectId:"2880254", postId:"78543642", content:"확인했습니다" }. - 파일 첨부: { ..., files:[{fileName:"보고서.pdf",fileContents:"<base64>"}] }. - 이미지 첨부: { ..., imageFiles:[{fileName:"shot.png",fileContents:"<base64>"}] }. - 답글: 위에 replyToRemarkId:"<부모 댓글 id>" 추가. Common mistakes - projectId(colabo_srno) 와 postId(commt_srno) 둘 다 필요. - fileContents 는 base64 문자열 — 일반 파일은 files, inline 이미지는 imageFiles 에 넣는다. - fileContents는 실제 파일 바이트를 읽어 base64로 변환한 값만 사용. 임의 생성·data URI prefix·줄바꿈 금지. - 이미지 fileName 확장자는 실제 이미지 형식과 일치시킨다. - 첨부 크기: 파일당 2MB(flow 정책), 요청 바디 합산 3MB 초과 시 413. 큰 이미지는 압축(UI 스샷=256색 양자화로 보통 ~60%↓) 후 첨부. base64 문자열을 직접 받아쓰지 말고 파일에서 읽어 넣을 것. Notes - 쓰기 작업 — 실제 flow에 댓글이 등록됨. - 결과의 commentId는 flow_list_comments 대댓글 조회에, remarkId는 flow_update_comment 수정에 그대로 쓴다. - 파일 업로드 포함 시 처리 시간이 더 걸릴 수 있음.= 패딩 포함). 임의 생성·data URI prefix 금지. - 이미지 fileName 확장자는 실제 이미지 형식과 일치시킨다. - botId 는 이메일 형식이어야 한다.projectId(colabo_srno)로 이어서 업무 추가(flow_create_tasks)·컬럼 추가 등을 수행. Notes - 쓰기 작업 — 실제 flow에 보드가 생성됨. - 현재는 빈 보드만 생성 — 업무/컬럼은 후속 도구로 추가. Examples - { title:"2026 분기 기획", description:"Q3 로드맵" } → projectId 반환. - 보드 세팅 흐름: create_project → flow_set_statuses → flow_create_column → flow_create_tasks.parentTaskId 있음 → 그 업무의 하위 업무를 프리뷰 후 승인·적용 (mode=subtask) - files/imageFiles/viewPermission/botId/customColumns 있음 → 단건 즉시 생성 (mode=single) - 그 외 → 프리뷰 후 적용 (mode=batch) Do NOT use - 새 보드(프로젝트) 자체를 만드는 것 → flow_create_project. 여기는 기존 보드에 업무를 넣는다. - 보드의 상태 체계(대기/진행/완료 단계 목록)를 정의·교체 → flow_set_statuses. - 이미 있는 업무의 상태·담당자·기한 변경 → flow_update_task. 프리뷰 → 적용 (mode=batch 또는 mode=subtask) 응답의 applied 를 먼저 본다. applied:true 면 이미 적용을 시도한 것이므로 created·failed 를 확인한다. 1. confirmToken 없이 호출 → 안 넣고 {applied:false, plan, confirmToken} 반환. 배치 plan 은 상태·커스텀 컬럼을 id로 해소한다. 하위 업무 plan 은 요청 내용과 상위 업무 ID이며 적용 성공 보장은 아니다. 2. 사용자 승인 후 받은 confirmToken 을 그대로 넣어 재호출 → 등록. - 입력이 바뀌면 토큰이 안 맞아 다시 프리뷰부터. 배치의 같은 토큰 재호출은 48시간 동안 저장된 결과를 돌려준다. - 하위 업무 토큰은 1회용이며 10분 후 만료된다. 사용자·기업·서비스와 입력에 묶이고, 적용 시도 전에 소진되어 실패 후에도 재사용할 수 없다. - 하위 업무는 preview:skip 으로 확인을 생략할 수 없다. 구 호출명 flow_create_subtask 도 토큰을 최상위에 넣어 같은 승인 절차를 따른다. - 첨부 단건 경로(mode=single)는 기존처럼 즉시 생성한다. 이미 생성된 요청을 다시 호출하지 않는다. 상태·커스텀 컬럼은 이름으로 - status:"검토중" · fields:{"분류":"개발"} 처럼 이름으로 주면 서버가 id 를 해소·검증한다. 별도 목록 조회가 필요 없고, 없는 이름이면 유효 목록과 함께 거부된다(잘못 들어가기 전에 차단). - 생성과 동시에 ID로 정확히 넣어야 하면 customColumns:[{columnId,value}] 를 쓴다. flow_get_project(include:["columns"])로 컬럼 ID와 OPTION/USER 값 ID를 먼저 확인한다. 단건만 가능하다. - ⚠️ 신규 업무는 기본이 대기(요청) — 시작 전이면 status 를 생략한다. 실제 착수한 것만 "진행". 안 시작한 일을 진행으로 넣으면 워크리스트·스탠드업 신호가 왜곡된다. - 우선순위는 사용자가 요청한 경우에만 priority 로 지정한다. 요청이 없으면 필드를 생략한다. 임의로 normal(보통)을 넣으면 우선순위를 지정하지 않은 업무까지 보통으로 기록된다. - 프로젝트가 자체 단계를 쓰면(예: "검토중") 어느 경로에서든 그 이름 그대로 주면 된다. 하위 업무·첨부 단건 경로는 생성 API 가 기본 5상태만 받으므로, 만든 뒤 그 상태로 옮긴다. 옮기기가 실패하면 업무는 남고 failed 에 사유가 적힌다 — 그때 업무는 대기 상태다. Examples - 한 건: { projectId:"2880254", tasks:[{ title:"기획안 검토", endDate:"20260610", priority:"high" }] } → plan + confirmToken 반환. 토큰을 다시 넣어 등록. - 여러 건: tasks:[{title:"A"},{title:"B",status:"진행"}] - 하위 업무: { projectId:"318821", parentTaskId:"319001", tasks:[{title:"API 문서 초안"}] } → 미리보기만 반환. 사용자 승인 후 같은 입력에 confirmToken을 추가해 1회 적용. - 요청 안에서 부모-자식: tasks:[{title:"부모",tempId:"p1"},{title:"자식",parentTempId:"p1"}] - 첨부: tasks:[{ title:"보고서", contents:"본문", status:"request", files:[{fileName:"a.pdf",fileContents:"<base64>"}] }] Common mistakes - parentTaskId 에 게시글 ID(postId)를 넣기 — 상위 업무 ID 다. 잘못 넣으면 412. - 첨부를 여러 건과 함께 주기 — 첨부 경로는 단건만 된다. 나눠서 호출한다. - 이미지 fileName 확장자는 실제 이미지 형식과 일치시킨다. - 첨부하면서 contents/status 를 빠뜨리기 — 그 경로는 둘 다 필수다. - 담당자 이름을 fields 에 넣기 — 담당자는 workers:[{workerId}] 다. userId 는 flow_find_employees 로 찾는다. - 실패분 재시도 시 성공분까지 다시 호출 — failed 의 것만 골라 넣는다(롤백 없음). Notes - 한 번에 최대 50건. 초과하면 나눠 호출한다. - 하위 업무 경로는 startDate/endDate/workers/첨부/fields 를 받지 않는다 — 주면 그 건만 failed 로 보고된다(조용히 버리지 않는다). - ⚠️ 본문의 `<단어>` 는 프리뷰 경로(mode=batch)에서 사라진다. 업스트림이 태그로 보고 지운다 — List<String> → List, <div>글</div> → 글. 오류도 경고도 없다(2026-08-09 실측). a < b · Map<K, V> · <open 처럼 태그로 안 보이는 것은 남는다. 하위 업무 경로는 평문이라 안 지운다. 살려야 하면 전각 꺾쇠(＜ ＞) 를 쓴다 — <(엔티티)는 디코드 후 지워져 더 나쁘고, 백틱도 못 막는다. - ⚠️ 프리뷰 plan 의 content 는 앞부분만 보여준다(실측 약 120자). 본문이 온전한지를 프리뷰로 판단하지 말 것 — 잘린 것은 표시일 뿐 저장은 전문이 들어간다. - ⚠️ 상위 업무 1건이 가질 수 있는 하위 업무는 50건까지다. 51번째부터 업스트림이 원인을 안 밝히는 오류만 돌려준다(재시도해도 같다) — 상위 업무를 나눠야 한다. 구성원 수만큼 하위 업무를 만드는 식이면 50을 넘기 쉽다. 넘을 것 같으면 계층을 포기하고 평면(1뎁스) + 커스텀 컬럼을 쓴다 — 하위 경로는 fields 를 못 받아 그룹을 컬럼으로 둘 수도 없으므로, 계층을 고른 순간 필터·집계를 함께 잃는다.{ projectId:"...", name:"담당자별", columns:["<담당자 columnId>","<기한 columnId>"], treeMode:true }. Common mistakes - columns 는 컬럼 이름이 아니라 columnId — flow_get_project(include:["columns"]) 로 먼저 확인. - 보드엔 기본 뷰가 이미 있음 — 꼭 필요할 때만 추가.confirmToken 없이 호출 → 아무것도 지우지 않고 {applied:false, plan, confirmToken} 반환. 2. plan.summary 를 사용자에게 그대로 보여주고 동의를 받는다. 3. 같은 인자에 받은 confirmToken 을 붙여 재호출 → 실행되고 {applied:true, result} 반환. 인자를 바꾸면 토큰이 무효다(다시 1번부터). 토큰은 10분·1회용. Examples - "12345 일정 삭제" → eventSrno:"12345". 반복 중 이 회차만 → repeatEditOption:"THIS".searchWord/dateFilter/searchTarget/limit → 조건 조회 (source=search) Do NOT use - 알림을 읽음 처리 → flow_mark_alarm_read. 본 도구는 조회 전용이다. - 마감 임박·지난 업무까지 함께 챙기려는 것 → flow_get_my_worklist. ★ 그 도구도 mentions 를 곁들여 주지만 최근 며칠치 부산물이다. 멘션·알림 자체를 묻는 질문은 여기다. Notes - mode:"UNREAD" 가 안 읽은 것만 거르는 축이고, alarmFilter 는 알림 종류 축이다(별개). - 여기서 얻은 alarmId 로 읽음 처리한다. Examples - "안 읽은 알림 뭐 있어?" → mode:"UNREAD". - "지난주 나를 멘션한 알림" → alarmFilter:["MENTION"], dateFilter:{startDate:"20260801"}.userId → 그 사람 단건 (mode=single) - searchWord/divisionCode 등 조건 → 조건 검색 (mode=search) - 아무 조건 없음 → 회사 전체 명단 첫 페이지 (mode=all) Do NOT use - 부서(조직) 목록 자체 → flow_list_divisions. - 내 정보 → flow_get_my_profile. - 프로젝트에 사람을 추가/초대 → flow_add_project_participants (본 도구는 조회 전용). Notes - 담당자 지정·멘션에 필요한 userId 를 얻는 출발점이다. - 호칭·직책("대표님"·"팀장님")으로 찾으면 여러 명이 올 수 있다(직책 서브스트링 매칭: "대표" → 부대표·대표이사). employees[0] 을 고르지 말고 `bestMatch` 를 쓴다 — 서버가 이름 일치 > 직책 일치(대표→대표이사 > 부대표)로 정한다. - pageSize/cursor 로 페이징. hasNext=true 면 lastCursor 를 다음 cursor 로 전달한다. Privacy 전화번호는 반환하지 않는다. 이메일·부서·직책만. Examples - "김철수 어느 부서야?" → searchWord:"김철수" (userId 를 알면 userId). - "대표님이 쓴 글" → searchWord:"대표님" → bestMatch.userId 를 flow_search registerFilter.ids 에. - "마케팅팀에 누구 있어?" → divisionCode(flow_list_divisions 로 확보) 또는 searchWord:"마케팅". - "회사 전체 명단" → (인자 없음).eventSrno → 그 일정 상세 (mode=single). 기간 불필요. - projectIds/userFilter/calendarFilter/dateFilter → 여러 일정 소스를 합쳐 조회 (mode=aggregate) - searchWord → 캘린더 이름 검색 (mode=search). 기간은 선택이며 생략하면 서버가 채운다. - 기간만 → 그 구간의 일정 목록 (mode=range) ⚠️ 수정·삭제에 쓸 수 있는 결과인지 확인한다 항목마다 editable/idKind 가 붙는다. - editable:true (idKind:"eventSrno") → flow_update_event / flow_delete_event 에 바로 쓴다. - editable:false (idKind:"postId") → 수정·삭제에 못 쓴다. 합산 경로가 프로젝트 일정 게시물·구독·반복 일정을 섞어 정규화한 결과라서다. 고쳐야 하면 searchWord+기간으로 다시 찾아 eventSrno 를 얻는다. Do NOT use - 캘린더 자체(내 캘린더 목록·기본 캘린더·구독) → flow_list_calendars. 여기는 캘린더가 아니라 그 안의 일정이다. - ★ 단 기간이 함께 언급되면 "캘린더" 라는 말이 나와도 여기다. 캘린더 목록에는 기간이 없으므로, 기간이 붙은 순간 묻는 대상은 일정이다. Notes - Aggregate filters use dateFilter for date boundaries. startDateTime/endDateTime cannot be combined with aggregate filters; exact time filtering is only supported by calendar query/search. - 시각은 timezone(기본 서버 존) 기준. 정확한 구간은 14자리 startDateTime/endDateTime 을 쓴다 — 8자리 dateFilter 는 백엔드 존의 하루 경계다. - timezone 이 적용되는 응답 시각은 일정 시작·종료, 등록 시각, 반복 종료뿐이다 — 화상회의(vcRecords)·알림(notifications) 시각은 백엔드 존 그대로다. - dateFilter 와 startDateTime/endDateTime 은 상호배타다. 둘 중 한 표현만 쓴다. - For my events, explicitly set userFilter:{type:"self"}. Use sortOrder:"asc" for chronological order. Use both absolute boundaries for a specified period, or startDate only for an after-date lookup. - Distinguish "within a period" from "after a date". A monthly count and the nearest event after a date can require different intervals. Do not reuse the count interval as an implied upper boundary for the nearest event. - To find the nearest event after a reference date, use dateFilter:{type:"absolute",startDate:"reference date YYYYMMDD"}, userFilter:{type:"self"} when asking about my events, and sortOrder:"asc". Use the first returned event and express its time relative to the reference date. If empty, extend the horizon or clearly report searchedRange; never conclude that no later event exists outside it. - For a count and nearest event explicitly within the same period, one query suffices. Check searchedRange before drawing conclusions from zero results. - userFilter:{type:"none"} 과 calendarFilter:{calendarType:"ALL"} 은 필터 생략과 같으며 searchWord 검색을 막지 않는다. - "이번 주" 같은 상대 기간은 dateFilter:{type:"relative",value:"CURRENT_WEEK"} 를 쓴다. With searchWord, use absolute dateFilter or 14-digit startDateTime/endDateTime. Either boundary may be omitted; searchedRange reports the bounded interval actually searched. - 프로젝트 안에서 이름으로 찾고 싶으면 searchWord 로 찾은 뒤 결과를 보거나, projectIds 로 기간 조회(mode=aggregate)를 한다. 둘을 한 번에 주면 검색어가 적용되지 않아 거부한다. - eventSrno·합산 조건이 모두 없으면 start/endDateTime 이 필수다. - 이름을 아는데 기간이 애매하면 넉넉한 구간 + searchWord 가 기간만 훑는 것보다 낫다. - aggregate의 truncated:true는 다음 cursor가 없다는 뜻이다. 같은 호출을 반복하지 말고 필터나 limit을 좁힌다. Examples - "오늘 일정 뭐 있어?" → 오늘 00:00:00~23:59:59 (mode=range). - "킥오프 미팅 언제였지?" → searchWord:"킥오프" + 넉넉한 기간 (mode=search). - "그 회의 누가 와?" → eventSrno (mode=single). - "두둠칫 프로젝트 이번 주 일정" → projectIds:["…"], dateFilter:{type:"relative",value:"CURRENT_WEEK"}. - "지정 기간의 내 일정 날짜순" → userFilter:{type:"self"}, dateFilter:{type:"absolute",startDate:"period start YYYYMMDD",endDate:"period end YYYYMMDD"}, sortOrder:"asc". - "김과장 오늘 일정" → userFilter:{type:"named",names:["김과장"]}, dateFilter:{type:"relative",value:"TODAY"}.keywords → 이름으로 검색 (mode=search) - 인자 없음 → 내가 참여 중인 프로젝트 전체 목록 (mode=all) Do NOT use - 공간 안의 글·업무를 키워드로 찾는 것 → flow_search. - 한 프로젝트 안의 항목을 키워드 없이 훑는 것 → flow_list_project_items. - 이미 projectId 를 알고 상세를 보는 것 → flow_get_project. Notes - mode=all 은 lastCursor(숫자), mode=search 는 nextCursor(문자열)로 페이징한다. - 타인이 참여한 프로젝트는 조회할 수 없다(공동 멤버십 추론 차단). 요청받으면 불가하다고 답한다. Examples - "내 프로젝트 목록 보여줘" → (인자 없음). - "마케팅 프로젝트 찾아줘" → keywords:["마케팅"].keywords (mode=search) - 특정 폴더 안을 본다 → parentId (mode=children) - 단서가 없고 위키 전체 구조가 궁금 → 입력 없음 (mode=root) Do NOT use - 프로젝트(공간·보드) 자체를 찾는 것 → flow_find_projects. 위키 문서와 프로젝트는 이름이 겹치기 쉽다 — 찾는 대상이 문서가 아니라 공간이면 그쪽이다. - 문서 본문을 읽을 때 → flow_get_wiki_document. 여기서는 제목·ID 만 나온다. - 업무·게시글·일정 검색 → flow_search. 본 도구는 위키 전용이다. Notes - 여기서 얻은 nodes[].id 가 flow_get_wiki_document / flow_update_wiki 의 docId 다. - 검색 결과의 hasMore:true면 nextPage를 그대로 다음 호출의 page로 사용한다. Examples - "위키에 뭐 있어?" → 입력 없음. - "위키에서 온보딩 찾아줘" → keywords:"온보딩". - "이 폴더 안에 뭐 있어?" → parentId:<앞서 얻은 id>.type: completed_task(완료) · started_task(시작) · created_task(내가 만들고 내가 맡음) · requested_task(만들어 남에게 요청, assignees 에 이름) · post(쓴 글) · comment(단 댓글) · confirmed_task(내 담당 아닌 업무를 완료 확인) - at 은 시각(YYYYMMDDHHmmss)이라 시간순으로 이야기를 만들 수 있다. - excerpt 는 글·댓글 본문 앞 100자. 업무 활동은 비어 있다. - counts 로 "완료 5건, 댓글 12건" 같은 요약이 바로 나온다. Notes - 범위는 내가 참여한 프로젝트로 한정된다. - 기간은 최대 31일. 넘으면 거부된다 — 참여 프로젝트 전체를 훑는 조회라 넓으면 느리다. - 항목은 at 오름차순이다. 기간이 넓을 때 (주·월) 한 달치는 수백 건이고 항목마다 제목·발췌·링크가 붙는다 — 그대로 받으면 응답이 아주 커진다. - 세기만 할 때 → format:"counts". 항목을 안 싣고 limit 도 안 걸어 잘린 숫자가 안 나온다. - 일부만 필요할 때 → types:["completed_task"] 처럼 좁힌다. 서버에서 거른다. - 기간 상한은 31일이다. 분기·연간이 필요하면 달 단위로 나눠 부른다. 잘렸을 때 (truncated:true) 마지막 항목의 `at` 을 그대로 `start` 로 넣어 다시 부른다. 그게 이어받기다. - 날짜만으로 다시 부르면 같은 날에 몰린 경우 같은 자리를 맴돈다 — 초까지 넣어야 진행한다. - 경계의 1건이 두 번 나올 수 있다(at 이 포함이라). postId+type 으로 중복을 지운다. Examples - "어제 한 일" → { start:"20260808", end:"20260808" } - "이번 주" → { start:"20260803", end:"20260809" } - "지난달 몇 건 했지" → { start:"20260701", end:"20260731", format:"counts" } - "지난주에 끝낸 것만" → { start:"20260727", end:"20260802", types:["completed_task"] } - 이어받기 → 앞 응답의 마지막 at:"20260805143000" 이면 { start:"20260805143000", end:"20260807" }rank 가 동작을 정한다: - 생략/false → 마감 임박·지난 업무·멘션을 나열 (mode=list) - rank: true → 점수·이유를 매겨 상위 N개만 (mode=focus). "뭐부터 할까"·"우선순위 잡아줘". Do NOT use - 멘션·알림 자체를 묻는 것("나 멘션된 거 있어?", "안 읽은 알림") → flow_find_alarms. 여기의 mentions 는 "지금 챙길 일" 을 판단하려고 곁들이는 최근 며칠치 부산물이다. - 특정 프로젝트 안의 업무·글 목록("여기 업무 뭐뭐 있어") → flow_list_project_items. 본 도구는 프로젝트를 가리지 않고 내 담당만 모은다. - 부서·팀원 현황 → flow_get_team_standup. "내가 지금 챙겨야 할 게 뭐야?" — 인증 사용자(본인) 기준으로 마감 임박/지난 업무 + 나를 멘션한 글을 한 번에. 데일리 스탠드업·업무 시작 시 개인 액션 점검용. Output - overdueActive: 마감 지났고 최근 활동 중인 = 진짜 밀리는 업무 (오래 방치된 좀비는 counts.overdueStale 로 카운트만) - imminent: 오늘~+N일 마감 임박 - mentions: 최근 나를 멘션한 글/댓글 - text: 위를 합친 마크다운 요약 (format=structured 면 생략, 배열만) - coverage (rank=true 일 때): truncated 면 배정이 너무 많아 생성 순 최신 `assignmentBudget` 건만 봤다는 뜻이다. 그 밖의 오래된 업무는 candidateCount·picks 에서 빠져 있다. format=structured 는 text 가 비어 있어 이 필드가 유일한 신호다. Notes - 대상은 기본 본인(인증). userId 로 같은 회사 내 타인 워크리스트도 조회 가능. - 담당(worker) 기준 + 공개(range_type=A) 업무만. 진행률 100% 제외. - 커스텀 상태로만 완료 처리된 일부 업무는 base 상태(대기/진행) 기준이라 드물게 섞일 수 있음. - 부서/프로젝트 단위 현황은 flow_collect_dept_chain / flow_collect_project_chain 을 쓴다. Examples - "나 지금 뭐 챙겨야 해?" → (인자 없음). 타인 → userId 지정. 배열만 필요하면 format:"structured".includeAttachmentText:true 로 부른다. attachmentTexts[] 에 파일별 text 가 온다 (문서는 본문 텍스트, 이미지는 안에 적힌 글자·표). 못 읽은 것은 status·reason(too_large·too_many_files·timeout)으로 온다. - 글 본문 첨부만 읽는다. 댓글 첨부는 목록만 온다. Notes - 검색(flow_search)의 type:"post" 결과나 프로젝트 글 목록에서 얻은 postId 로 호출. 한 건씩 읽는 도구다. - type:"chat" 결과의 chatId·roomChatSrno는 채팅 메시지 식별자다. 이 도구에 넘기지 말고 검색 결과의 message를 사용. 목록을 이미 받았다면 flow_list_project_items 응답에는 `content`(원문)·`htmlContent` 가 이미 들어 있다. 내용을 알기 위해서라면 목록의 글을 이 도구로 다시 열 필요는 없다. 이 도구가 더 주는 것은 읽기용으로 정규화된 outContent, 멘션·이미지 메타, 첨부/할일/일정/업무/투표 원본이다 — 그게 필요할 때만 쓴다. Do NOT loop 목록에서 얻은 postId 를 전건 순회하지 않는다. 프로젝트의 글·업무·댓글을 한 번에 읽어야 하면 flow_collect_project_chain 을 쓴다 — 한 번의 호출로 끝난다. (실측: 이 도구를 1분에 1,556회 부른 계정이 있었고, 상류 호출량 제한으로 전량 실패했다) Examples - "그 공지글 내용 보여줘" → postId:"78543642" (flow_search/flow_list_project_items 로 확보).include 로 필요한 부분만 덧붙인다: - participants — 참여자 명단(userId). 담당자 지정·멘션 전에 필요. - columns — 관리 항목(컬럼) 구성. "이 보드 컬럼 뭐 있어". - statuses — 업무 상태 선택지(대기/진행/완료 등). Do NOT use - 프로젝트를 찾는 것 → flow_find_projects. 여기는 projectId 를 이미 아는 경우다. - 프로젝트 안의 업무·글 목록 → flow_list_project_items. Notes - 참여자 수만 필요하면 include 없이 호출한다 — participantCount 가 기본 응답에 있다. - include 를 켜지 않으면 추가 API 호출도 하지 않는다(응답이 커지지 않는다). Examples - "이 프로젝트 정보 보여줘" → projectId:"2910862". - "이 프로젝트 멤버 누구야?" → include:["participants"]. - "업무 상태 어떤 거 고를 수 있어?" → include:["statuses"].members[]: 각 멤버의 imminent(오늘~+N 마감) + blocked(지났고 최근 활동 중) 업무 리스트 - 오래 방치된 overdue(좀비)는 staleCount 로만 (액션 리스트 오염 방지) - text: 멤버별 스탠드업 마크다운 (format=structured 면 배열만) - truncatedMembers: 배정이 너무 많아 생성 순 최신 일부만 본 멤버 이름. 그 멤버의 지난·방치 업무는 실제보다 적을 수 있다. format=structured 는 text 가 비어 있어 이 필드가 유일한 신호다. Notes - 담당(worker) 기준 + 진행률 100% 제외. companyId 는 AuthContext. - "어제 완료한 일"은 미포함 — base 상태(완료=2)가 커스텀상태 완료를 과소집계하고 성능 부담이라 제외. 포워드(임박/막힘) 중심. - 특정 개인은 flow_get_my_worklist, 프로젝트 서사는 flow_collect_dept_chain. Examples - "우리 팀 오늘 현황" → dept:"AI사업개발실". 배열만 → format:"structured".searchWord → 아직 구독하지 않은, 구독 가능한 캘린더 검색 (mode=subscribable) Do NOT use - 캘린더 안의 일정을 찾는 것 → flow_find_events. - ★ 기간이 언급되면 여기가 아니다. 캘린더 목록에는 기간 개념이 자체가 없다 — "이번 주/이번 달/오늘" 같은 말이 붙으면 그건 캘린더가 아니라 그 안의 일정을 묻는 것이다. 사용자가 "캘린더 보여줘" 라고 말해도 마찬가지다. Output - mode=mine: editableCalendars / viewOnlyCalendars / projectCalendars + defaultCalendarId + calendarSrno - mode=subscribable: subscribableCalendars (커서 페이지네이션) Notes - "일정은 어느 캘린더에 들어가?" 는 인자 없이 호출해 defaultCalendarId 를 본다. - 일정 쓰기로 이어갈 때는 같은 값을 담은 calendarSrno 를 그대로 전달한다. - 일정 생성은 editableCalendars 의 calendarSrno 만 가능(viewOnly 불가). Examples - "내 캘린더 뭐뭐 있어?" → (인자 없음). - "영업팀 공유 캘린더 찾아줘" → searchWord:"영업".flow_get_post 도 댓글(remarks)을 주지만 페이지네이션이 없어 전량 반환한다 — 댓글이 많은 글이거나 댓글만 필요하면 이 도구를 쓴다. Do NOT loop 여러 글의 댓글을 훑으려고 글마다 flow_get_post + 이 도구를 반복하지 않는다. 프로젝트 단위로 읽어야 하면 flow_collect_project_chain 이 글·업무·댓글을 한 번에 준다. Inputs - postId(commt_srno)만 필수. projectId 는 받지 않는다 — 서버가 postId 로 접근권한을 확인한다. - cursor/size 로 페이징(size 1~100, 서버 기본 100). - replyYn:'Y' 를 주면 각 댓글에 대댓글 미리보기가 최대 10건 따라온다. - `commentId` 를 주면 그 댓글의 대댓글 전량을 준다(mode=replies). 미리보기 10건을 넘어설 때 쓴다. - 댓글과 대댓글의 attachments 에 파일명·크기·다운로드 URL이 실린다. Examples - 댓글만: { postId:"78543642" } - 대댓글까지 한 번에: { postId:"78543642", replyYn:"Y" } - 다음 페이지: { postId:"78543642", cursor:"<직전 lastCursor>" } Common mistakes - replyYn 을 안 주면 응답에 replies/replyHasNext 키 자체가 없다(빈 배열 아님). 없다고 해서 대댓글이 없는 게 아니다. - 미리보기는 최대 10건이다. replyHasNext:true 면 나머지는 이 도구에 commentId 를 줘서 조회한다 (flow_list_replies 는 등록된 도구가 아니다 — alias 로만 남아 있다). - contents/registerName/registerCorpName/registerProfilePhoto 등은 댓글·대댓글 양쪽 다 null 일 수 있다. - cursor 는 직전 응답의 lastCursor 를 문자열로. 결과가 0건이면 lastCursor 는 -1.htmlContent, 그리고 remarkCount·taskStatus· 작성자·일시까지 담아 준다. 내용을 알기 위해 목록의 글을 하나씩 다시 열 필요는 없다. flow_get_post 를 추가로 부를 이유는 이 셋뿐이다 — - 읽기용으로 정규화된 평문/마크다운(outContent) 이 필요할 때(목록은 원문 그대로 준다) - 멘션·이미지 메타가 필요할 때 - 첨부/할일/일정/업무/투표 원본이 필요할 때 댓글은 목록에 없다. 댓글이 필요하면 flow_list_comments 를 쓴다(글은 다시 안 열어도 된다). Do NOT use - 찾는 항목의 제목·키워드를 아는 경우 → flow_search (+ projectIds 로 그 프로젝트 한정). 목록은 수백 건이 나와 요약 과정에서 정답이 밀려난다. - postId/taskId 한두 건만 아는 경우 → flow_get_post 등 단건 조회. - 하위 업무 목록 → flow_collect_project_chain(postId). 이 도구는 상위 업무만 돌려준다. Do NOT loop 이 도구의 결과 전건을 flow_get_post 로 하나씩 여는 것은 본문을 두 번 받는 낭비다(위 참고). 프로젝트의 글·업무·댓글을 한 번에 읽어야 하면 flow_collect_project_chain 을 쓴다. (실측: 한 계정이 이 패턴으로 1분에 flow_get_post 를 1,556회 불러 전량 실패했고, 같은 계정의 단건 조회 2.2만 회는 목록이 이미 준 본문을 다시 받은 것이었다) Difference from flow_search 입력 조건으로 갈린다 — 키워드를 알면 search, 단서 없이 전량이 필요하면 이 도구. Filters & Pagination - postId 로 단건 조회. hasNext=true 이면 lastCursor 를 다음 호출 cursor 로 전달. - 결과가 없으면 posts:[] · hasNext:false · lastCursor:-1 이다. - ⚠️ 하위 업무는 목록에 안 나온다(상위 업무만). 그래서 하위 업무의 postId 를 주면 posts:[] 다 — 없는 것이 아니라 이 목록의 대상이 아닌 것이다. 상·하위 트리는 flow_collect_project_chain(postId). Examples - "이 프로젝트 업무 목록" → projectId:"2910862", templateType:"task". 글 목록 → templateType:"post".alarmId → 그 알림 한 건 (scope=one) - all: true → 전체. projectId 를 주면 그 프로젝트 알림만 (scope=all) Do NOT use - 알림 목록을 보여달라는 요청 → flow_find_alarms. 본 도구는 상태를 바꾼다. Notes - "읽음 처리해줘" 뿐 아니라 "확인했어"·"봤어"·"처리했어" 처럼 완료를 선언하는 표현도 본 도구. - alarmId 는 flow_find_alarms 응답의 alarmId(숫자 문자열). 이미 읽은 알림 재호출은 무해(idempotent). Examples - "그 알림 읽음 처리" → alarmId:"1234567". - "알림 다 읽음으로 해줘" → all:true.sources:["file"] = 게시글에 첨부된 파일. 글·댓글과 함께 훑을 때. - sources:["drive"] = 파일 저장소. 내 드라이브 + (driveScope:"all" 이면) 협업방 파일함·글첨부. ★ 여기만 파일 본문까지 검색한다. "그 자료 어디 있더라" 는 이쪽이다. - drive 는 백엔드가 달라 다른 소스와 같이 못 쓴다(단독). 둘 다 필요하면 두 번 호출. - drive 는 페이지네이션이 없고 최대 50건이다. 커서를 찾지 말 것. Difference from flow_find_projects 본 도구는 게시물(콘텐츠) 검색. 프로젝트(공간) 자체 검색은 flow_find_projects. Pagination 응답 pagination.hasNext 가 true 이면 nextCursor 를 다음 호출의 nextCursor 로 전달. 사람·공간·기간 (flow-ai 내장 검색과 같은 해석 규칙) - 사람은 말한 그대로 personName 에("대표님"·"김과장"·"June Lee"). 서버가 호칭을 떼고 직책까지 대조해 한 명으로 푼다 (대표→대표이사, 부대표 아님). flow_find_employees 를 먼저 부르지 않는다. "내가/나의"는 registerFilter.includeSelf:true. personRole: 쓴/올린=author(기본), 담당/맡은=assignee. 작성자 필터를 걸면 그 사람 이름·호칭은 keywords 에서 뺀다. - 공간은 spaceName 에("<이름> 방/프로젝트/보드에서"). flow 의 "방"은 프로젝트 공간이기도 하다 — 채팅만 뒤지지 않는다. - 기간은 사용자가 말한 것만. 없으면 dateFilter 생략(SCORE). 계절·행사어(신년·연말·워크샵)는 작성일이 앞뒤로 퍼지니 좁히려면 넉넉히 — 신년/신년사 = 전년 12/1~당해 2/28. - 주제어가 없으면("대표님이 최근 쓴 글") keywords:[] + personName — 서버가 범용 검색어로 채운다. 0건·빗나감일 때 (서버는 재시도하지 않는다 — 한 번에 한 축만 바꿔 다시 부른다) 1. 키워드: 결과 제목에 실제로 쓰인 말로 바꾼다(동의어·상위어 하나). 작성자 필터가 있으면 사람 토큰은 절대 키워드에 넣지 않는다. 2. 기간: 추측해 좁힌 기간을 넓히거나 뺀다(사용자 명시 기간은 유지). 3. 사람 필터: 두 번째 재시도부터 personName/registerFilter 를 빼고 다른 사람이 쓴 관련 글도 본다. 4. 정렬: SCORE↔LATEST 를 바꾼다 — 같은 키워드라도 상위 N건이 통째로 달라진다. 5. quality 를 읽는다: unresolved=["personName"] 은 그 이름이 없다는 뜻(다른 이름), lookupFailed 는 조회 장애(이름을 바꿔도 소용없음), orderType 은 실제 적용 정렬. Examples - "결제 관련 업무 검색" → keywords:["결제"], templateType:"task". 타입 모르면 templateType:"all". - "대표님이 신년에 강조하신 키워드" → keywords:["신년"], personName:"대표님", dateFilter:{startDate:"20251201",endDate:"20260228"} (오늘이 2026년일 때). - "두둠칫 QA 방에서 결제 오류 재현 절차" → keywords:["결제","오류"], spaceName:"두둠칫 QA". - "장애 관련 댓글과 파일" → keywords:["장애"], sources:["comment","file"]. - "이 프로젝트 자료를 의미 기반 검색" → projectIds:["..."], keywords:["..."], sources:["rag"]. - "작년 보고서 파일 어디 있지?" → keywords:["보고서"], sources:["drive"], driveScope:"all". Notes - 프로젝트 이름만 알면 flow_find_projects로 projectId를 먼저 찾는다. - type:"chat" 결과의 chatId는 게시글 postId가 아님. data.message로 바로 답변하고 flow_get_post에 넘기지 않는다. - sources 확장 검색은 cursor 페이지네이션을 제공하지 않는다. - sources 확장 검색과 personName·spaceName 검색은 registerFilter·projectIds·dateFilter·orderType·size를 지원한다. workerFilter·participantFilter·nextCursor와 함께 쓰지 않는다. - 빈 keywords 검색(사람·기간만)은 projectIds 를 무시한다 — 함께 보내면 거절된다. 프로젝트의 업무를 기간으로 보려면 flow_query_tasks(projectIds+dateFilter), 게시글 목록은 flow_list_project_items. - 그 경로에서 templateType 은 적용되지 않는다 — 주더라도 거절하지 않고 응답 ignoredInputs:["templateType"] 로 알린다. 타입으로 좁히려면 sources 없이 다시 부른다. - drive 는 위 필터를 전부 무시하고 keywords·driveScope·size(≤50)만 본다.권한 거부 (403)). ⚠️ 아래 2단계의 미리보기는 통과하고 적용에서 막힌다 — plan 은 우리가 만들고 권한 검사는 실제 적용에서만 돈다. 될 것처럼 보인 뒤 거절되면 이것이다. - category 로 대기/진행/완료/보류 성격 지정(색은 자동). Examples - { projectId:"...", statuses:[{name:"대기",category:"request"},{name:"검토중",category:"progress"}, {name:"완료",category:"complete"}] }. 확인이 필요하다 (2단계) 1. confirmToken 없이 호출 → 아무것도 바꾸지 않고 {applied:false, plan, confirmToken} 반환. plan 에 사라지는 단계와 그 단계에 걸린 업무 수가 적혀 있다 — 그대로 사용자에게 보여준다. ⚠️ 이 도구는 업무를 옮기지 않는다. 사라지는 단계에 업무가 있으면 교체 후 그 업무들이 어느 단계에도 안 붙는다 — flow_update_task 의 taskIds 로 새 단계에 배정할 것. 2. 동의를 받으면 같은 인자에 받은 confirmToken 을 붙여 재호출 → {applied:true, result}. 인자를 바꾸거나 그 사이 단계가 변하면 토큰이 무효다(다시 1번부터). 토큰은 10분·1회용. Common mistakes - 전체 목록을 줘야 함(set=교체). 한 개만 주면 나머지 상태가 사라질 수 있음 → 원하는 전체를 나열. - category 빠뜨림 — request/progress/complete/hold 중 하나 필수.columnType·columnName 을 매번 요구한다. 설명만 바꿀 때도 현재 유형/이름을 같이 보낼 것. - columnDescription 을 생략하면 기존 설명이 지워진다. 유지하려면 현재 값을 그대로 실어야 한다. - 따라서 flow_get_project(include:["columns"]) 로 현재 값을 먼저 읽고 바꿀 필드만 교체해 보낸다. Inputs - columnId 는 flow_get_project(include:["columns"]) 응답의 columnId 값을 그대로 쓴다. - 상태 컬럼(기본 제공)은 이 도구로 수정할 수 없다 — columnType 이 지원 목록 밖이라 거부된다. Result 응답은 보낸 입력을 그대로 되돌려주는 형태라 반영을 보장하지 않는다. 확인이 필요하면 flow_get_project(include:["columns"]) 로 재조회할 것. Examples - "고객사 컬럼 이름을 거래처로" → flow_get_project(include:["columns"]) 로 columnId/유형/설명 확보 후 { projectId, columnId, columnType:"TEXT", columnName:"거래처", columnDescription:"<기존 설명>" }.projectId(colabo_srno) + postId(commt_srno) + remarkId(colabo_remark_srno) 모두 필요. - content 는 새 내용으로 덮어쓴다. - 첨부는 덮어쓰기 — files/imageFiles 로 준 set 이 최종 상태가 된다(미제공 = 첨부 제거). fileContents 는 base64. Examples - 내용만 수정: { projectId:"2880254", postId:"78543642", remarkId:"187042786", content:"수정된 내용" }. - 내용+이미지 교체: { ..., imageFiles:[{fileName:"new.png",fileContents:"<base64>"}] }. Common mistakes - remarkId 까지 셋 다 필요. - 첨부는 병합이 아니라 교체 — 기존 첨부를 유지하려면 다시 전달해야 한다. - fileContents는 실제 파일 바이트를 읽어 base64로 변환한 값만 사용. 임의 생성·data URI prefix·줄바꿈 금지. - 이미지 fileName 확장자는 실제 이미지 형식과 일치시킨다. - 첨부 크기: 파일당 2MB(flow 정책), 요청 바디 합산 3MB 초과 시 413. 큰 이미지는 압축 후 첨부. Notes - 쓰기 작업 — 실제 flow 댓글이 수정됨.taskId. - 대상이 여럿인데 바꿀 값은 같다면 taskIds (최대 50건). 상태 일괄 이동이 대표 용례다. ⚠️ 업무마다 이 도구를 반복 호출하지 말 것 — 중간에 끊기면 절반만 바뀐 보드가 남는다. Behavior - 지정한 필드만 변경(미지정 필드 유지). 최소 1개 필드 필수. - taskId 와 taskIds 는 둘 중 하나만. 둘 다 주면 거부한다. - 응답 모양이 대상 수에 따라 갈린다: 단건은 {updated, failed}, 복수는 {results:[{taskId, updated, failed}], summary:{total, ok, failed}}. - 복수는 순차 적용한다. 한 건이 실패해도 나머지는 계속하며, 실패한 건만 results 에서 골라 재시도하면 된다(성공분을 다시 밟으면 TASK_STATUS_DUPLICATE_ERROR 가 난다). - ⚠️ workers 는 전체 교체다. 배열에 없는 기존 담당자는 삭제된다(서버가 전원 삭제 후 재등록). "담당자 추가" 요청이면 기존 담당자를 먼저 조회해 함께 넣을 것 — 새 사람만 보내면 나머지가 사라진다. - 커스텀 상태로 바꿀 때는 `statusOptionSrno` — 프로젝트가 flow_set_statuses 로 자체 단계를 쓰면 base 5상태(request/progress/…)로는 그 단계로 못 옮긴다. ID 는 flow_get_project(include:["statuses"]). - 커스텀 상태로 만들 때는 flow_create_tasks 에 상태 이름을 그대로 준다 — 기본(배치) 경로는 서버가 이름을 해소해 생성 시점에 적용하고, 하위 업무·첨부 단건 경로만 생성 API 가 base 5상태만 받아 만든 뒤 옮긴다. 이미 있는 업무를 옮기는 것이 본 도구의 statusOptionSrno 다. - 여러 필드 지정 시 status→priority→workers→startDate→endDate 순차 적용. 일부 실패해도 나머지는 적용되며 결과의 failed 에 사유가 담긴다. - columnValues는 마지막에 순서대로 적용. OPTION/USER 값은 이름이 아니라 조회된 ID를 쓴다. Common mistakes - 같은 status 로 호출 시 flow-api 400 (TASK_STATUS_DUPLICATE_ERROR). - workers 는 flow_find_employees 또는 flow_get_project(include:["participants"]) 로 id 를 먼저 해소. - userId 가 <<email-N>> 처럼 가려져 오면 workers 에 넣지 말고 workerNames:[{name}] 로 이름을 준다. Examples - "첫 번째 업무 완료 처리" → flow_list_project_items 로 taskId 확보 후 projectId+taskId+status:"complete". - "2주차 업무 전부 계획됨으로" → { projectId, taskIds:["46143541","46143558",…], statusOptionSrno:"990931" }confirmToken 없이 호출 → 아무것도 안 바꾸고 {applied:false, plan, confirmToken} 반환. plan 에 기존 본문이 몇 자 사라지는지 적혀 있다 — 그대로 사용자에게 보여준다. 2. 동의를 받으면 같은 인자에 받은 confirmToken 을 붙여 재호출 → {applied:true, result}. 인자를 바꾸거나 그 사이 문서가 변하면 토큰이 무효다(다시 1번부터). 토큰은 10분·1회용. Common mistakes - contentJson 은 부분 수정이 아니라 전체 교체다. 먼저 flow_get_wiki_document 로 기존 본문을 읽고 고쳐서 넣는다. - docId 는 flow_find_wiki 로 먼저 찾는다. 제목만 알고 호출하면 실패한다. Output 필드별로 순차 반영하고 updated/failed 로 종합 보고한다 — 한쪽이 실패해도 다른 쪽은 반영된다.Click any prompt to copy it.
App Stats
39
Tools
3
Prompts
ChatGPT
Platforms
Category
Work ManagementWorks with
Data refreshed daily
