PaulShin

Charge up and use a deep prompt, just like when using an ultimate ability in a game.

Google is falling behind in this competition.

I believe that all light and darkness coexist.

Wow,, your comment really resonated with me. There’s a lot of insight in how you framed it.

I’ve actually been thinking about this as primarily a technology problem and, somewhat embarrassingly, I’m building something to try to address it.

When teams talk constantly across chat, calls, and meetings, a lot of the real work gets buried in the noise. Decisions are made. Tasks are implied. Commitments are spoken out loud and then they dissipate.

What we’re building is a system that extracts only the actionable parts from those conversations, turns them into tickets, assigns them automatically, and in some cases even lets AI execute the task directly. Humans do what only humans should do. AI handles what can be automated.

Recording conversations is important but motion is what creates value. If nothing moves, nothing compounds.

I don’t think adding another storage location solves the problem. Understanding relationships and triggering execution might.

Would genuinely love your thoughts on whether that’s directionally correct or if I’m still treating a wetware problem as software.

I got this

LoL

Seen from that perspective, it makes sense to shift toward a more modern, familiar look

Yes, I agree

Exactly. they're not visiting the site for an artistic experience. Thank you for the clarification.

You're right. Rather than trying to stand out in a unique way, it's better to look like something already trusted and established. Thanks for the insight!

True, but what if the pen wrote everything for you and even turned your notes into tasks that got done automatically?

Good job bro

Thank you, this is incredibly valuable feedback. You've hit on a critical point about trust and privacy, and I want to be very clear that we agree with you completely.

If my description made it sound like a "Big Brother" tool that monitors conversations, that's a total failure of my explanation, and I'd like to clarify.

The "automatic extraction" is not a secret surveillance process. The AI assistant is designed to act like a helpful teammate, not a spy. It operates openly in-channel and essentially asks, "Hey, that sounds like a to-do item. Should I create a ticket for you?"

The key is that

the user is always in control. Nothing gets turned into a formal to-do item without a user's explicit confirmation or manual click.

So the goal isn't to monitor the "real" chats, but to help the team capture the action items they've already publicly agreed to, acting more like a personal assistant for the team members themselves, not for management.

You are absolutely right about the human nature to CYA in team environments, and our design philosophy must respect that.

This feedback is a gift because it shows our messaging is causing the exact wrong impression. Thank you again. With this clarification, does the concept feel less like surveillance and more like a potentially useful tool?

Hi HN,

We're building a simple app that lets you automatically extract and manage to-do tickets right from your team's conversations.

I'm building this because my team and I constantly face a problem: actionable items get lost in the stream of our chat app (Slack, Teams, etc.), or we waste time manually moving them to a separate task manager like Jira or Notion. This manual copy-pasting is our biggest friction. When you move a task, you lose the original context of

why that task was created in the first place. This context-switching kills our productivity.

Our solution makes this process seamless. Here’s how it works:

You chat with your team, yourself, or an integrated AI assistant.

The AI understands the dialogue (e.g., "Could you fix the deployment bug by Friday?") and automatically suggests creating a to-do ticket from that message.

Of course, you can also manually turn any message into a ticket with a single click.

Each ticket is intrinsically linked to the conversation thread, so the full context is always preserved. These tickets can then be managed on a Kanban board or a calendar without ever leaving the app.

Essentially, our goal is to eliminate the 'collaboration tax' by merging the place of discussion with the place of action.

My questions for HN are:

Would you or your team use a tool like this?

What are your biggest frustrations with your current chat + task management workflow?

Does the "automatic task extraction" sound genuinely useful, or does it feel like a gimmick that might get annoying?

For this to be a "must-have" product for you, what feature would it absolutely need to get right?

Thanks for your feedback!

I'm DongYoon, founder of Markhub (https://markhub.ink).

We're building a chat app that automatically creates and manages your to-do list right from your conversations.

I started this for a simple reason: I was tired of the soul-crushing 'copy-paste' work of moving decisions from Slack over to Notion or Jira. So much context gets lost in that process, and it just creates more "work about work."

Our core idea is simple: a chat message and a to-do item shouldn't be two separate things you have to keep in sync. In Markhub, the conversation is the task. It's not a copy; the conversation itself becomes the to-do, and all the context is automatically preserved.

Our bigger vision is to do for collaboration what GitHub did for Git. We’re not reinventing chat or kanban boards; we’re building the seamless 'workflow layer' on top that finally makes them work together.

We're currently in a private beta and would love to hear from HN users who feel this same pain. We’ve been fortunate to get early traction with large enterprise clients (including a ~$200k on-premise deal), but now we're looking for feedback from smaller, agile teams.

Any and all feedback is a gift. Thanks!

That's an even more precise and insightful framing. You're absolutely right—the catalyst was licensing, and the technical problem of SCM was, in a sense, already "solved." Thank you for sharpening the point further.

You've actually given me the perfect "Part 2" of the analogy "the relationship between Git and GitHub."

Yeah, Git is the powerful, low-level engine. Technically brilliant, but with a notoriously steep learning curve. The real explosion in adoption came when GitHub wrapped it in a user-friendly product with a clear workflow (pull requests, issues, etc.). GitHub didn't reinvent SCM; it reinvented the collaboration workflow on top of it.

That's exactly how we see the problem we're tackling. The "protocols" of modern work already exist: real time chat, task lists, documents. But they exist as separate, low-level primitives, like Git commands. The "collaboration tax" comes from users having to manually act as the interface between them.

Our goal is to be the "GitHub for general collaboration." To take those existing primitives and build a seamless, opinionated workflow on top where the connections are automated. The user shouldn't have to think about the "protocol"; they should just be able to work.

So, your point is well taken and helps clarify our position. We're not trying to build the "Git" (the core primitive). We're trying to build the "GitHub" (the intuitive workflow layer that makes the primitives powerful for everyone).

And that philosophy is baked right into our name. The reason we're called Markhub is because we're building a central "Hub" where every "Mark" a team makes a message, a decision, a task, a document can live together in a single, seamless flow.

Haha, touché. You're sharp.

But they left some of the palantíri behind for the new age to communicate. We're just trying to build a less treacherous version.

Haha, wise words indeed. We’re definitely aiming to be the Council of Elrond, not Sauron. The goal is alignment, not domination.

You've absolutely nailed the history and ethos of Git, and it's a crucial distinction. Thank you for the clarification. You're right, it wasn't a "product" in the modern sense.

My analogy wasn't intended to be about the UI or its 'one thing well' philosophy, but about the category of friction it eliminated.

Before Git, the coordination overhead for code was immense think manual patches and diffs. Git didn't write the code for anyone, but it automated away that specific, painful "collaboration tax," freeing developers to focus on the actual programming.

I see a parallel today, but the "collaboration tax" has moved. It's now the manual, repetitive work of translating team conversations into structured tasks. We believe that specific friction can also be automated away, freeing teams to focus on the actual execution.

So, you've helped me refine the analogy: It's not about building a product like Git, but about tackling a problem in the same way Git did by automating a specific, painful type of coordination overhead.

Multiple monitors definitely make window switching easier—totally agree. The snag we keep hitting isn’t the physical hop, but the cognitive hop:

- A decision lives in Slack, - its rationale hides in Notion, - the actual task ends up in Jira.

Even with three screens, someone still has to copy-paste and re-explain. That’s the part we’re trying to erase: let a Slack message turn itself into a task/doc record without leaving the thread.

If that hand-off were automatic, would you still feel the need for so much screen real-estate, or is multi-monitor workflow a must for you regardless?

Side note We’re prototyping this idea right now. If you’re curious and willing to give feedback, drop me a note at ([email protected]) and I’ll send over a private link.

Appreciate your take!

Fair point no tool can manufacture intrinsic motivation. At the same time, even highly motivated people hit friction: digging through chat history, duplicating context, or chasing down “who owns this.”

The goal of what we’re building isn’t to make someone work; it’s to strip away the overhead that slows down people who already want to.

Think of it like version control: Git doesn’t write code for you, but it removes enough coordination pain that good engineers ship more often. We’re aiming for the same effect between conversation and execution—same motivation, less drag.

From our side, the north-star is a radically simple answer: let a single chat thread end all that visible complexity. One place, one flow, nothing to copy or sync. That’s the product we’re building toward.

Curious have you seen lightweight workflows that actually cut this friction without adding new layers?

Thanks for the links—Brooks and Zawinski are exactly the guard-rails we keep taped to the monitor.

No Silver Bullet: We’re not chasing a “one tool to rule them all.” The essential complexity—humans aligning on what to do can’t be deleted; we’re only trying to strip away the accidental part (manual copy-pasting).

Zawinski’s Law: Instead of cramming every feature into one bloated app, we’re limiting scope to a single object model:

A message, a task, and a doc are the same object, just rendered in different views.

Chat ≠ Task Manager ≠ Wiki, but they sit on the same data layer, so hand-offs happen automatically rather than by re-typing.

Anything beyond that (CRM, billing, email) stays as integrations no temptation to rebuild an Outlook clone.

So the direction is “context cohesion without feature creep.” If we can kill the copy-paste tax and still keep each tool honest to its purpose, we think that’s the sweet spot.

Curious where you’ve seen this approach succeed or crash and burn in real teams.

Great point context switching hurts more than app switching when the tools don’t enforce a single source of truth.

Role clarity: Slack = capture, Notion = synthesize, Jira = track.

Reality: Decisions still leak out of channels, tasks lose owners, docs go stale.

Unifying everything in one mega-app can create new clutter, unless the app itself preserves context automatically. That’s the angle we’re exploring: keep roles clear, but let the hand-off happen inside the flow so people don’t have to think about it.

Curious how does your team make sure a Slack decision doesn’t die before it reaches Jira? Any workflow tricks that actually stick?

P.S. We’re prototyping a tool that tries this “context-in one flow” idea (still private beta). If anyone’s curious—or has horror stories about chat→task hand-offs—happy to swap notes. DM or reply here.

This is a fascinating model, thanks for sharing. The classic "engineering as the bottleneck" problem is something every product engineer feels, so I deeply appreciate the desire to solve it.

I'm intrigued by this API-first approach, and it's left me with a few questions from my perspective as an engineer who builds product features:

How do you handle features with complex UI/UX? While a push notification is a perfect fit, how would a non-eng person build, say, a new analytics dashboard with interactive charts or a multi-step modal view? Is there a clear line where a feature's complexity means it has to go back to the engineering team?

Who owns the holistic user experience? With different people building features decentrally, how do you ensure the product feels cohesive and not just a collection of disconnected Zapier flows? I imagine maintaining a consistent design system and user journey could be a challenge.

You mentioned the "duct-tape logic" problem. This is the part that resonates—and worries—me most. Do you have a formal process for refactoring or "graduating" a successful duct-tape solution into a core, robust, engineer-built API? How do you manage that accumulating technical debt?

As an engineer, the idea of focusing solely on clean, scalable APIs is incredibly appealing. At the same time, there's a certain joy in crafting and shipping a polished feature directly to users. It's a really interesting trade-off you've presented.

Thanks again for the thought-provoking post.

Great question. As a founder also working on my next project, the fear of "solving fake problems" is something I think about every day. Thanks for asking it.

For me, the single most frustrating part of any data-related task isn't the data itself. It's the "work about the work" – the soul-crushing feeling that I'm doing the same thing two or three times in different windows.

The biggest irony is that this is often caused by the very "smart work" tools that are supposed to make us more productive.

My typical workflow looks like this:

A request for data comes in on Slack. I pull the data, analyze it, and share a conclusion in the Slack thread. Then, I have to go to Jira to create a ticket that summarizes what I just said on Slack. Finally, I have to open Notion to write a brief document explaining the findings for the record. The context is constantly being copied, pasted, and fragmented. It's exhausting and feels like a waste of human potential.

This isn't a pitch, but this exact frustration is the only thing I'm focused on solving right now. My entire thesis is that the endless context switching between our communication layer (chat) and our execution layer (tasks, docs) is the biggest source of "fake work" in modern companies.

I'm building a tool where that entire "copy/paste the context" cycle is eliminated. A place where the conversation is the task, is the doc, is the context—all in one single flow.

I'm just a founder who is sincerely obsessed with this problem, and it's validating to see I'm not the one who feels this pain.