Copy English

Why

These were two cards and one of them said so. The tagged-bot idea recorded that it feeds into the integration workflow rather than standing alone, which is the definition of a merge. Both were parked in August 2026 as not currently important, so combining them costs nothing and removes a duplicate from the list.

What survives is the ordering, and it is the only part worth keeping. The workflow — a Slack thread that Claude summarizes and logs to Notion, chained through Claude's Slack and Notion MCP connectors — is a thing you can build today with no new surface area. A tagged presence in Slack is the same workflow with an invocation shortcut and an availability promise attached, and the promise is the expensive half: something that answers when tagged has to be running, has to handle being tagged in the wrong place, and has to fail visibly rather than silently.

So the honest sequence is workflow first, presence second, and the second may never be needed. If the manual version runs a handful of times and nobody misses it when it stops, that is the answer. agents-computer-use makes the same point at a larger scale — once the model is good enough, what you are buying is operations, and a bot that must always be reachable is an operations commitment dressed as a convenience.

How it works

Two forms of one idea

The test that decides whether the second one is ever needed

Run the manual version for a couple of weeks. If nobody misses it when it stops, the tagged version is a solution to a problem that did not exist. If it is missed, the miss itself specifies what the bot must guarantee — and that specification is worth more than any amount of design done in advance.

Why it stays parked

Both halves were marked not currently important in August 2026 and nothing has changed that. The entry stays on the list because the ordering is the finding, not because the work is queued.

← All Dev Notes · Workspace Index · Top ↑

Copy 한국어

Slack 속 Claude — 워크플로가 먼저, 상주는 나중

MCP 커넥터로 Slack · Claude · Notion 을 이어, 스레드가 정리돼 Notion 에 기록되게 합니다. 봇을 태그하는 판본은 그 워크플로의 포장된 형태이고, 그래서 워크플로가 값어치를 갖기 전까지는 보류입니다.

아직 범위 미정이고, 의도적으로 보류 중입니다. 재개할 때 순서는 정해져 있습니다 — 먼저 워크플로를 손으로 만듭니다(Slack 대화를 Claude 가 정리해 기존 커넥터로 Notion 에 기록). 상주형 태그 봇은 수동 버전이 아쉬워질 만큼 자주 돌아간 뒤에야 고려합니다.

왜

이건 카드 둘이었고, 그중 하나가 스스로 그렇게 적고 있었습니다. 태그 봇 아이디어는 독립적으로 서지 않고 통합 워크플로로 *연결된다* 고 기록돼 있었는데, 그게 곧 병합의 정의입니다. 둘 다 2026년 8월에 "지금은 중요하지 않음"으로 보류됐으므로, 합치는 데 잃는 것이 없고 목록에서 중복 하나가 사라집니다.

남는 것은 순서이고, 그것만이 간직할 값이 있습니다. 워크플로 — Slack 스레드를 Claude 가 정리해 Notion 에 기록, Claude 의 Slack·Notion MCP 커넥터로 연결 — 는 새 표면적 없이 오늘 만들 수 있는 것입니다. Slack 상주 태그 봇은 같은 워크플로에 호출 단축키와 가용성 약속을 붙인 것이고, 비싼 절반은 약속입니다 — 태그하면 답하는 것은 떠 있어야 하고, 엉뚱한 자리에서 태그되는 것을 처리해야 하고, 조용히가 아니라 눈에 띄게 실패해야 합니다.

그래서 정직한 순서는 워크플로 먼저, 상주는 나중이고, 나중은 영영 필요 없을 수도 있습니다. 수동 버전을 몇 번 돌렸는데 멈춰도 아무도 아쉬워하지 않으면 그게 답입니다. agents-computer-use 가 더 큰 축척에서 같은 말을 합니다 — 모델이 충분히 좋아지고 나면 사는 것은 운영이고, 항상 닿을 수 있어야 하는 봇은 편의로 분장한 운영 약속입니다.

동작 방식

한 아이디어의 두 형태

둘째가 필요한지를 정하는 시험

수동 버전을 2주쯤 돌립니다. 멈췄을 때 아무도 아쉬워하지 않으면, 태그 봇은 존재하지 않던 문제의 해법입니다. 아쉬워한다면, 그 아쉬움 자체가 봇이 무엇을 보장해야 하는지를 규정하고 — 그 규정이 미리 한 어떤 설계보다 값어치가 큽니다.

왜 계속 보류인가

둘 다 2026년 8월에 지금은 중요하지 않음 으로 표시됐고 바뀐 것이 없습니다. 이 항목이 목록에 남는 이유는 작업이 대기열에 있어서가 아니라 그 순서가 곧 발견이기 때문입니다.

← 전체 개발 노트 · 워크스페이스 인덱스 · 맨 위 ↑