Browse Ship docs
Ship docs
Ship docsChat as the entry point

Chat as the entry point

The window where most of your work happens

You'll spend more time in the chat than anywhere else in Ship. It sits next to you while you think out loud about the product, and it turns the thinking into actions you can defend. Ideas, ticket drafts, "what was that thing we decided last month," "park that for now," "show me everything on my plate today" — all of it lives in the same conversation.

It is not a chatbot bolted onto a project tool. It is the primary surface. The dashboard, the Inbox, the knowledge catalog — they're all real screens you'll use, but the path you'll keep returning to is the one where you sit and talk to the workspace.

What you can actually do here

Four things, day to day.

Plan. You describe an initiative. The conversation lands as a project description on your tracker — motivation, scope, constraints, and decisions in one body of text. Child tickets stay short and link back to the project. The pattern is project-first; the next page explains why.

Run the workspace. "What's on my plate this morning?" Ship reads your Inbox, your in-flight work, your open pull requests, and answers in one paragraph. "Snooze that improvement until next week." "Why did that routine fail last night?" Everything you could click your way to is also something you can ask for in chat, and the chat path is usually faster.

Think out loud about product. You float an idea. Ship checks the standing knowledge — has the team already decided this? If the idea is worth a ticket, it gets one. If it belongs in an existing project, the description grows. If it's a clarification you should answer first, it goes to the Inbox.

Look things up. Where is this function defined? What does our brand voice doc say about pricing language? When was this routine last green? Ship has read access to your code, your knowledge, and your audit log, and the chat is the fastest way to surface anything from any of them without changing tabs.

What the team sees

The chat is private to you. Nobody else in the workspace reads your conversations. What the team sees is the result: the ticket you created, the project description that got longer, the Inbox card you resolved, the pull request that got opened. Those carry the trail even though the conversation that produced them is yours alone. Your half-formed thoughts about what to build next don't belong on a shared board; the decisions that came out of them do.

What it won't do without you

Ship pauses before anything irreversible. Creating a ticket, updating a project body, parking a draft, kicking off multi-step work — for every action that changes the state of the workspace, Ship describes what it's about to do and waits for an OK. That's the difference between "the system did something" and "I asked for that, here's the proof."

If you give a direct instruction ("create a ticket for the login bug") Ship moves on it. If your message was a question or ambiguous ("we should probably do something about the login flow") Ship answers and waits. The bar is roughly: would a thoughtful colleague hit save, or would they sketch it on the whiteboard first.

What it won't pretend to know

Ship reads instead of guessing. Ask "how many open inbox items?" and the answer comes from your actual Inbox. Mention a ticket id and Ship looks at the ticket. Mention a file path and Ship reads the file. When something isn't available — a doc that doesn't exist, a metric that wasn't tracked — Ship says so plainly. "I don't have that" is a better answer than a confident guess, and it's the answer you'll get.

The next three pages walk the three things that make the chat work the way it does: project-first planning, memory across threads, and how to switch direction in the middle of a draft.

Chat as the entry point — Ship docs — Harbor Gang