flow - AI Collaboration tool

Read the comments on a Flow post or task in order, including reply previews. ## When to use 게시물/업무에 달린 **댓글을 페이지 단위로** 읽을 때. postId 만 알면 된다. `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건을 넘어설 때 쓴다. ## 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` 등은 **null 일 수 있다**(댓글 쪽은 아님). - `cursor` 는 직전 응답의 `lastCursor` 를 문자열로. 결과가 0건이면 `lastCursor` 는 -1.

flow_list_comments

Collect and summarize what everyone in a department did in Flow over a date range. ## When to use 한 부서(팀)의 멤버 전원이 기간 내 활동한 프로젝트·과제를 묶어 요약한다. "우리 팀 이번 주/이번 기간 뭐했나" 주간보고·현황 파악용. ## Input - `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".

flow_collect_dept_chain

Define or replace a Flow project's status options (workflow stages). ## When to use 프로젝트 보드가 쓸 **상태 목록 자체**를 정의·교체한다. "이 보드의 진행 단계를 A/B/C 로" 처럼 **선택지 집합**을 바꾸는 것이지, 어느 한 업무를 다른 상태로 옮기는 게 아니다. ## Do NOT use - **업무 하나의 상태를 바꾸는 것** → flow_update_task. 가장 흔한 혼동이다. 구분법: 대상이 **보드**(선택지 목록)면 여기, 대상이 **업무 한 건**이면 그쪽이다. ## Notes - **쓰기 작업** — 보드의 상태 컬럼 옵션이 주어진 목록으로 구성됨. - **프로젝트 관리자만 바꿀 수 있다.** 참여자로만 들어가 있으면 거부된다(`권한 거부 (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 중 하나 필수.

flow_set_statuses

Mark one of your Flow notifications as read. ## When to use 알림을 읽음 처리한다. 한 건이든 전부든 본 도구다: - `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.

flow_mark_alarm_read

Change a Flow task's status, assignees, priority, start date or due date. ⚠️ This tool modifies a real task. Confirm with the user before invoking. ## When to use 기존 업무의 상태/우선순위/담당자/시작일/종료일 변경. 여러 필드를 한 번에 지정 가능. - 대상이 **한 건**이면 `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_task)은 base 5상태만 받는다. 커스텀 상태로 만들어야 하면 **생성한 뒤 본 도구로 statusOptionSrno 를 지정**하거나, 처음부터 flow_create_tasks 로 만든다 (그쪽은 상태를 이름으로 주면 서버가 ID 를 해소한다). - 여러 필드 지정 시 status→priority→workers→startDate→endDate 순차 적용. 일부 실패해도 나머지는 적용되며 결과의 failed 에 사유가 담긴다. ## Common mistakes - 같은 status 로 호출 시 flow-api 400 (TASK_STATUS_DUPLICATE_ERROR). - workers 는 flow_find_employees 또는 flow_get_project(include:["participants"]) 로 id 를 먼저 해소. ## Examples - "첫 번째 업무 완료 처리" → flow_list_project_items 로 taskId 확보 후 projectId+taskId+status:"complete". - "2주차 업무 전부 계획됨으로" → `{ projectId, taskIds:["46143541","46143558",…], statusOptionSrno:"990931" }`

flow_update_task

Create tasks in a Flow project — one, many, or as subtasks of an existing task. ⚠️ This tool creates real work tasks. Confirm with the user before invoking. ## When to use 프로젝트에 업무를 만드는 **모든 경우**. 한 건이든 여러 건이든, 하위 업무든 여기다. 입력이 경로를 정한다: - `parentTaskId` 있음 → 그 업무의 **하위 업무**로 즉시 생성 (mode=subtask) - `files`/`imageFiles`/`viewPermission`/`botId` 있음 → 단건 즉시 생성 (mode=single) - 그 외 → **프리뷰 후 적용** (mode=batch) ## Do NOT use - 새 보드(프로젝트) 자체를 만드는 것 → flow_create_project. 여기는 기존 보드에 업무를 넣는다. - 보드의 **상태 체계**(대기/진행/완료 단계 목록)를 정의·교체 → flow_set_statuses. - 이미 있는 업무의 상태·담당자·기한 변경 → flow_update_task. ## 프리뷰 → 적용 (mode=batch 일 때만) 응답의 `mode` 를 먼저 본다. `single`/`subtask` 면 **이미 만들어진 것**이라 재호출하면 중복 생성된다. 1. `confirmToken` **없이** 호출 → 안 넣고 `{applied:false, plan, confirmToken}` 반환. `plan` 에 상태·커스텀 컬럼이 **id 로 해소된** 모습이 들어 있다 — 무엇이 들어갈지 확인한다. 2. 사용자 승인 후 받은 `confirmToken` 을 그대로 넣어 재호출 → 등록. - 입력이 바뀌면 토큰이 안 맞아 다시 프리뷰부터. 같은 토큰 재호출은 48시간 동안 저장된 결과를 돌려주며 중복 생성하지 않는다. - `parentTaskId`/첨부 경로는 프리뷰 없이 바로 들어간다(`applied:true`). ## 상태·커스텀 컬럼은 이름으로 - `status:"검토중"` · `fields:{"분류":"개발"}` 처럼 **이름으로 주면 서버가 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 문서 초안"}] }` - 요청 안에서 부모-자식: `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. - 첨부를 여러 건과 함께 주기 — 첨부 경로는 **단건만** 된다. 나눠서 호출한다. - 첨부하면서 `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` 처럼 태그로 안 보이는 것은 남는다. 하위 업무 경로는 평문이라 안 지운다. 살려야 하면 **전각 꺾쇠(＜ ＞)** 를 쓴다 — `&lt;`(엔티티)는 디코드 후 지워져 더 나쁘고, 백틱도 못 막는다. - ⚠️ 프리뷰 `plan` 의 `content` 는 **앞부분만 보여준다**(실측 약 120자). 본문이 온전한지를 프리뷰로 판단하지 말 것 — 잘린 것은 표시일 뿐 저장은 전문이 들어간다. - ⚠️ **상위 업무 1건이 가질 수 있는 하위 업무는 50건까지다.** 51번째부터 업스트림이 원인을 안 밝히는 오류만 돌려준다(재시도해도 같다) — 상위 업무를 나눠야 한다. 구성원 수만큼 하위 업무를 만드는 식이면 50을 넘기 쉽다. 넘을 것 같으면 계층을 포기하고 **평면(1뎁스) + 커스텀 컬럼**을 쓴다 — 하위 경로는 `fields` 를 못 받아 그룹을 컬럼으로 둘 수도 없으므로, 계층을 고른 순간 필터·집계를 함께 잃는다.

flow_create_tasks

Filter Flow tasks by status, assignee and due date. ## When to use 상태·우선순위·담당자·날짜를 조합해 업무를 조회. 프로젝트명만 알면 flow_find_projects로 ID를 먼저 찾은 뒤 projectIds에 전달. ## Difference from flow_list_project_items list_project_items는 프로젝트 한 곳의 단순 목록. 이 도구는 여러 프로젝트와 복합 조건 조회. ## Examples - "두둠칫 프로젝트의 진행중 업무" → flow_find_projects → projectIds:[검색된 projectId], statuses:["IN_PROGRESS"] - "내 지연 업무" → assigneeFilter:{type:"self"}, dateFilter:{type:"relative",value:"DELAY",target:"END_DT"} - "김과장이 만든 긴급 업무" → assigneeFilter:{type:"named",names:["김과장"],role:"author"}, priority:["URGENT"] ## Notes - 날짜는 YYYYMMDD. DELAY는 마감이 지났고 미완료인 업무. - 프로젝트를 이름으로 지정했으면 전체 목록을 가져오지 말고 flow_find_projects를 사용. - hasMore:true면 결과가 limit에서 잘린 것. projectIds·statuses·dateFilter 등 조건을 좁혀 재조회.

flow_query_tasks

Create a new document in the Flow wiki. ⚠️ This tool creates a real wiki document. Confirm with the user before invoking. ## When to use 공개(PUBLIC) 또는 개인(PRIVATE) 위키에 새 문서를 생성합니다. ## Input - folderType: "PUBLIC"(공개) 또는 "PRIVATE"(개인). 필수. - title: 문서 제목. 선택. - parentId: 부모 폴더/문서 ID. 미지정 시 루트에 생성. flow_find_wiki 응답의 nodes[].id 사용. - contentJson: ProseMirror/Tiptap 형식 초기 내용. 선택. ## Output 생성된 문서의 docId, folderType, title, parentId 반환.

flow_create_wiki_document

Replace the title or the body of an existing Flow wiki document. ⚠️ This tool overwrites a real wiki document. Confirm with the user before invoking. ## When to use 기존 위키 문서의 제목·본문을 바꾼다. 둘을 한 번에 줘도 된다. ## Do NOT use - 새 문서를 만들 때 → flow_create_wiki_document. ## 확인이 필요하다 (2단계) 1. `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` 로 종합 보고한다 — 한쪽이 실패해도 다른 쪽은 반영된다.

flow_update_wiki

Read the contents of one Flow wiki document. ## When to use 위키 문서의 전체 내용(contentJson)을 조회합니다. ## Input docId: 위키 문서 ID (flow_find_wiki 응답의 nodes[].id). ## Output contentJson: ProseMirror/Tiptap 형식의 문서 JSON. raw 객체 그대로 반환됩니다.

flow_get_wiki_document

Find documents and folders in the Flow wiki — browse the tree or search by keyword. ## When to use 위키에서 폴더·문서를 찾는 모든 경우. 입력이 경로를 정한다: ★ **발화에 위키를 가리키는 단서가 있어야 한다** — "위키/문서/페이지/가이드/정책" 같은 말. 단서 없이 주제어만 있으면(그 주제가 문서로 있을 법해도) 여기가 아닐 가능성이 높다. - 키워드를 안다 → `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>.

flow_find_wiki

Delete a Flow calendar event; for a recurring event you choose the scope. ⚠️ This tool permanently deletes a calendar event. Confirm with the user before invoking. ## When to use 캘린더 일정 삭제. eventSrno 필요. ## Common mistakes - 반복 일정은 repeatEditOption 으로 범위 지정: THIS(이 인스턴스만) / AFTER(이후 모두) / ALL(전체). - 반복 인스턴스 삭제 시 repeatInstanceId 동반 가능. ## 확인이 필요하다 (2단계) 1. `confirmToken` **없이** 호출 → 아무것도 지우지 않고 `{applied:false, plan, confirmToken}` 반환. 2. `plan.summary` 를 사용자에게 그대로 보여주고 동의를 받는다. 3. **같은 인자**에 받은 `confirmToken` 을 붙여 재호출 → 실행되고 `{applied:true, result}` 반환. 인자를 바꾸면 토큰이 무효다(다시 1번부터). 토큰은 10분·1회용. ## Examples - "12345 일정 삭제" → eventSrno:"12345". 반복 중 이 회차만 → repeatEditOption:"THIS".

flow_delete_event

Create a new event on a Flow calendar, with attendees, reminders and recurrence. ⚠️ This tool creates a real calendar event. Confirm with the user before invoking. ## When to use 사용자 의 새 일정을 캘린더에 생성. 참석자/알림/반복 지원. ## Common mistakes - timestamp 형식: YYYYMMDDHHmmss (14자리). ISO reject. - gmtTime 예: "GMT+09:00" (서버가 GMT 접두어 형태를 요구; "+09:00" 으로 줘도 내부 보정). - allDayYn / publicYn / publicNameYn: "Y" 또는 "N" 만. ## Examples - "내일 10~11시 '팀 스탠드업'" → calendarSrno(flow_list_calendars 로 확보), eventName:"팀 스탠드업", eventStartTimestamp:"20260621100000", eventFinishTimestamp:"20260621110000", allDayYn:"N", gmtTime:"GMT+09:00", publicYn:"N", publicNameYn:"N".

flow_create_event

Change the time, contents or attendees of an existing Flow calendar event. ⚠️ This tool modifies an existing calendar event. Confirm with the user before invoking. ## When to use 기존 일정의 시간/내용/참석자/반복 수정. ## Common mistakes - 반복 일정 수정 시 repeatEditOption 필수: THIS (이 인스턴스만) / AFTER (이후 모두) / ALL (전체). - 필수 필드 (eventStartTimestamp, eventFinishTimestamp, allDayYn, gmtTime, publicYn, publicNameYn) 매번 전달. - gmtTime 예: "GMT+09:00" (서버가 GMT 접두어 형태를 요구; "+09:00" 으로 줘도 내부 보정). ## Examples - "그 회의 4시로 미뤄줘" → eventSrno(flow_find_events 로 확보) + eventStartTimestamp/eventFinishTimestamp 변경, 필수 필드 동반.

flow_update_event

Find Flow calendar events — by date range, by search word, or one event by id. ## When to use 일정을 찾는 **모든 조회**. 기간으로 훑든, 이름으로 찾든, 사람·프로젝트로 좁히든, 한 건의 상세(참석자·장소·반복)를 보든 본 도구 하나다. 입력이 동작을 정한다: - `eventSrno` → 그 일정 상세 (mode=single). 기간 불필요. - `projectIds`/`userFilter`/`calendarFilter`/`dateFilter` → 여러 일정 소스를 합쳐 조회 (mode=aggregate) - `searchWord` + absolute dateFilter 또는 start/endDateTime → 캘린더 이름 검색 (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 - `dateFilter` 와 `startDateTime/endDateTime` 은 상호배타다. 둘 중 한 표현만 쓴다. - "이번 주" 같은 상대 기간은 `dateFilter:{type:"relative",value:"CURRENT_WEEK"}` 를 쓴다. 단 searchWord 검색은 absolute dateFilter 또는 14자리 start/endDateTime 쌍을 쓴다. - 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:"named",names:["김과장"]}, dateFilter:{type:"relative",value:"TODAY"}.

flow_find_events

List your company's department (organization) structure in Flow. ## When to use 회사 부서(divisionCode, divisionName, 상위부서) 목록 조회. ## Examples - "우리 회사 부서 뭐 있어?" → (인자 없음). ## Notes - 인자 불필요. 여기서 얻은 divisionCode 는 flow_find_employees 의 부서 필터에 사용.

flow_list_divisions

List the Flow calendars you can access and your default one; with a search word, list calendars you could subscribe to. ## When to use **캘린더 자체**에 대한 조회. 입력이 동작을 정한다: - 인자 없음 → 내가 접근 가능한 캘린더 + **기본 캘린더 ID** (mode=mine) - `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_list_calendars

Create a saved custom view on a Flow project board. ## When to use 프로젝트 보드에 **새 보기(화면·뷰)** 를 추가한다. 어떤 컬럼을 어떤 순서로 볼지 구성하는 것. "…기준으로 보는 화면/보기 만들어줘" 류가 여기다. 컬럼 ID 는 flow_get_project(include:["columns"]) 로 확인. ## Do NOT use - **내 할 일을 정렬해서 보여주는 것** → flow_get_my_worklist. 그건 화면을 만드는 게 아니라 조회다. - 일정·업무를 조건으로 **찾는** 것 → flow_find_events / flow_query_tasks. - 이 도구는 **보드 설정을 바꾸는 쓰기**다 — 조회 의도라면 여기가 아니다. ## Notes - **쓰기 작업** — 보드에 새 뷰가 추가됨. (보드엔 기본 뷰가 이미 있어 선택적) - 섹션 그룹·필터는 현재 미지원(기본 그리드 뷰). ## Examples - `{ projectId:"...", name:"담당자별", columns:["<담당자 columnId>","<기한 columnId>"], treeMode:true }`. ## Common mistakes - `columns` 는 컬럼 **이름이 아니라 columnId** — flow_get_project(include:["columns"]) 로 먼저 확인. - 보드엔 기본 뷰가 이미 있음 — 꼭 필요할 때만 추가.

flow_create_view

Rename a custom column on a Flow project board or change its type. ⚠️ This tool modifies a real project column. Confirm with the user before invoking. ## When to use 기존 커스텀 컬럼의 이름·유형·설명 변경. 컬럼 추가는 flow_create_column. ## ⚠️ 부분 수정이 아니다 - 서버가 `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:"<기존 설명>" }`.

flow_update_column

Add a new custom column to a Flow project board. ## When to use 기존 프로젝트에 커스텀 컬럼(필드)을 추가. 현 컬럼 구조는 flow_get_project(include:["columns"]) 로 먼저 확인 권장. ## Notes - **쓰기 작업** — 실제 flow 보드에 컬럼이 추가됨. - **프로젝트 관리자만 추가할 수 있다.** 참여자로만 들어가 있는 방은 거부된다 (`권한 거부 (403)`). 남이 만든 오래된 방에서 자주 걸린다 — 재시도해도 같다. 방장에게 관리자 권한을 받거나, 새 프로젝트를 만들어 거기에 세운다. - `type: option` 이면 `options` 로 선택지를 준다(색은 자동 배정). ## Examples - 선택형: `{ projectId:"...", name:"우선분류", type:"option", options:["긴급","일반"] }`. - 텍스트: `{ projectId:"...", name:"비고", type:"text" }`. ## Common mistakes - `type:"option"` 인데 `options` 누락 — 선택지 없는 빈 옵션 컬럼이 됨. - 같은 이름 컬럼 중복 생성 — 추가 전 flow_get_project(include:["columns"]) 로 확인.

flow_create_column

Search across Flow — posts, tasks, schedules, todos, votes and drive files. ## When to use Flow 콘텐츠를 키워드로 검색. 게시물 종류는 templateType, 댓글·파일·채팅·RAG는 sources로 지정. - post=글, task=업무, schedule=일정, todo=할일, vote=투표, all=전체(타입 모를 때). - sources: post/comment/file/chat/chat_file/integrated/rag/drive. 생략하면 기본 게시물 검색. ## 파일을 찾을 때 — file 과 drive 는 다른 것을 본다 - `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·빈 keywords 검색은 registerFilter·projectIds·dateFilter·orderType·size를 지원한다. templateType·workerFilter·participantFilter·nextCursor와 함께 쓰지 않는다. - drive 는 위 필터를 전부 무시하고 keywords·driveScope·size(≤50)만 본다.

flow_search

Read your team's current work in Flow — what each member has due and what is stuck. ## When to use 부서원 각자가 "오늘 할 것(마감 임박) + 막힌 것(마감 지남·최근 활동)"을 한 화면에. 데일리 스탠드업·주간 점검 시 팀 현황을 사람별로 자동 브리핑 (수기 입력 불필요). - "스탠드업" · "팀 현황" · "누가 뭐 하고 있나" 는 전부 여기다. 부서명만 주면 된다. ## Do NOT use - 스탠드업 **글을 써 주거나 올리는 것** → 이 도구는 조회 전용이다. 작성은 flow_create_post. ("스탠드업" 은 읽기 요청으로 읽는다 — 팀의 현재 상태를 가져오는 것이지 문구를 짓는 게 아니다.) - 한 사람의 일만 → flow_get_my_worklist. 프로젝트 단위 서사 → flow_collect_dept_chain. ## Output - `members[]`: 각 멤버의 `imminent`(오늘~+N 마감) + `blocked`(지났고 최근 활동 중) 업무 리스트 - 오래 방치된 overdue(좀비)는 `staleCount` 로만 (액션 리스트 오염 방지) - `text`: 멤버별 스탠드업 마크다운 (format=structured 면 배열만) ## Notes - 담당(worker) 기준 + 진행률 100% 제외. companyId 는 AuthContext. - **"어제 완료한 일"은 미포함** — base 상태(완료=2)가 커스텀상태 완료를 과소집계하고 성능 부담이라 제외. 포워드(임박/막힘) 중심. - 특정 개인은 flow_get_my_worklist, 프로젝트 서사는 flow_collect_dept_chain. ## Examples - "우리 팀 오늘 현황" → dept:"AI사업개발실". 배열만 → format:"structured".

flow_get_team_standup

Read one Flow project — optionally with its participants, columns and status options. ## When to use 한 프로젝트에 대한 조회. 기본은 제목/설명/참여자수/공개여부/등록자. `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"].

flow_get_project

Create a schedule post inside a Flow project. ⚠️ This tool creates a real schedule. Confirm with the user before invoking. ## When to use 프로젝트에 **시작·종료 시각이 있는** 항목을 올린다(게시물형 일정). 워크숍·회의·행사처럼 "언제" 가 본문의 핵심인 것. 캘린더 이벤트(flow_create_event)와 별개 — 이건 프로젝트 게시물이다. ## Do NOT use - 시각이 없는 **공지·메시지** → flow_create_post. 판별자는 시작/종료 시각의 유무다. - 개인·구독 캘린더에 잡는 약속 → flow_create_event. 여기는 프로젝트 안에 남는 글이다. ## Common mistakes - startDateTime/endDateTime 은 YYYYMMDDHHmmss 14자리, start ≤ end (뒤집히면 호출 전에 거부된다). - 등록자는 자동으로 본인(호출자). ## Output {projectId, postId, taskId?, tinyUrl?} — 전 필드 optional. 일정은 postId 가 비어 돌아올 수 있다(정상). 단 projectId 까지 비어 오면 생성 결과를 확인할 수 없는 상태다 — 성공으로 단정하지 말 것. ## Examples - "킥오프 일정 글 만들어줘" → projectId, title:"킥오프", startDateTime/endDateTime(YYYYMMDDHHmmss), isAllDay:false.

flow_create_schedule

Invite or add members to an existing Flow project. ⚠️ This tool adds participants to a project. Confirm with the user before invoking. ## When to use 프로젝트에 구성원(참여자)을 추가. projectId + 추가할 participantIds 목록. ## Note participantIds 는 flow_find_employees / flow_find_employees 로 얻은 userId 들. ## Examples - "김대리 이 프로젝트에 추가" → projectId:"2910862", participantIds:["kimdr"].

flow_add_project_participants

Find the Flow projects you participate in — the full list, or by keyword search. ## When to use 프로젝트(공간)를 찾는 모든 경우. projectId 를 얻는 출발점이다. - `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:["마케팅"].

flow_find_projects

List the items in a Flow project — posts, tasks, schedules, todos and votes. ## When to use **프로젝트 안을 통째로 훑을 때.** 예: "그 프로젝트 업무 전부 보여줘", 최근 순으로 쭉 확인. templateType 으로 대상 타입 지정. ## 응답에 본문이 함께 온다 각 항목은 제목·ID 만이 아니라 **`content`(원문)** 와 `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".

flow_list_project_items

Create a new Flow project (board). ## When to use 새 프로젝트(협업 보드)를 만든다. 인증 사용자 명의로 생성되며 본인이 관리자. 반환된 `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.

flow_create_project

Collect one Flow project's tasks, posts and comments to summarize recent progress. ## When to use 특정 flow 프로젝트 또는 게시물의 과제·게시물·댓글을 하나의 트리로 수집한다. "이 프로젝트/이 게시물에서 무슨 일이 있었나"를 깊게 볼 때. ## Input (택1 필수) - `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".

flow_collect_project_chain