You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Task Stack is a local, LIFO task-stack tray application. Today every task is created manually through the UI: the only creation surface is the stack store (push / push_next / push_last in python/src/task_stack/stack.py), wired to the Tk entry widget in python/src/task_stack/window.py. There is no external integration, no networking dependency, and no AI/summarization feature in either the Python or Go implementation.
A lot of actionable work originates in Slack discussions (threads, channels, DMs). Manually re-reading those conversations and transcribing follow-ups into tasks is tedious and error-prone, and items get lost. This feature would let Task Stack ingest relevant Slack discussions, summarize them into concise, actionable task text, and add them to the stack automatically, so the user does not have to context-switch and re-type.
Ideally this runs as a background job that checks Slack regularly (on a configurable interval) to keep the stack up to date, rather than a one-off manual fetch. The poller should run off the Tk main thread, deliver results through the existing AppCoordinator queue pattern (app.py), persist its checkpoint/cursor so it only processes new activity since the last run, and back off on errors and rate limits.
This would be the project's first external integration and first AI/LLM feature. There is no existing scaffolding to extend, so it requires net-new networking and summarization code plus a new configuration surface.
A configurable Slack source (token, channels and/or threads to monitor) can be set up, with config stored alongside existing settings (~/.task-stack.settings.yaml via settings.py)
A background job polls Slack on a configurable interval to keep the stack up to date, and can be enabled/disabled by the user
The poller persists a checkpoint/cursor so each run only processes Slack activity that is new since the last successful poll (no full re-scan, no missed messages)
The background job runs off the Tk main thread and delivers results through the existing AppCoordinator queue pattern (app.py), keeping the UI responsive, and shuts down cleanly when the app exits
The app can fetch new/unread Slack discussions from the configured sources
Fetched discussions are summarized into concise, actionable task text
Summarized items are added to the stack via the existing creation API (push / push_next / push_last in stack.py), with a sensible default position
Duplicate ingestion is avoided so the same discussion is not turned into a task more than once, even across repeated polls
Failures (auth errors, network errors, rate limits, summarization errors) are handled gracefully with backoff, do not crash the app, and are surfaced to the user
Secrets (Slack token, any LLM API key) are not logged and are stored securely
The feature is documented (user guide for setup/usage, and a spec doc under spec/ consistent with the existing per-feature specs)
Green-path automated tests cover the poll loop, fetch, summarize, and add-to-stack, with external services mocked
Background
Task Stack is a local, LIFO task-stack tray application. Today every task is created manually through the UI: the only creation surface is the stack store (push / push_next / push_last in python/src/task_stack/stack.py), wired to the Tk entry widget in python/src/task_stack/window.py. There is no external integration, no networking dependency, and no AI/summarization feature in either the Python or Go implementation.
A lot of actionable work originates in Slack discussions (threads, channels, DMs). Manually re-reading those conversations and transcribing follow-ups into tasks is tedious and error-prone, and items get lost. This feature would let Task Stack ingest relevant Slack discussions, summarize them into concise, actionable task text, and add them to the stack automatically, so the user does not have to context-switch and re-type.
Ideally this runs as a background job that checks Slack regularly (on a configurable interval) to keep the stack up to date, rather than a one-off manual fetch. The poller should run off the Tk main thread, deliver results through the existing AppCoordinator queue pattern (app.py), persist its checkpoint/cursor so it only processes new activity since the last run, and back off on errors and rate limits.
This would be the project's first external integration and first AI/LLM feature. There is no existing scaffolding to extend, so it requires net-new networking and summarization code plus a new configuration surface.
Version
64389c6
Acceptance Criteria
Created with create-issue (
053e9fd)