Welcome to the Shyne blog

Shyne is a place to develop an idea with AI and shape the result together. This blog is where we will share what changes, what we learn, and the decisions behind the product. It is not a changelog dump, and it is not a separate magazine with its own CMS. Every article lives beside the product code, goes through the same review process, and ships with the next build.

If you have used Shyne for even one session, you already know the feeling we are trying to protect: you ask for a deck, a post, or a short film, and the work appears as real frames on a live canvas. You can stop the teammate, move a heading, change a color, or ask for another pass without starting over. That loop is the product. This blog exists to explain that loop in public, in language a person can use, not only in internal docs.

What you will find here

Expect focused product notes, practical walkthroughs, and deeper looks at the craft of making documents, presentations, and visual stories with a shared canvas. Some posts will be short on purpose. This one, and the first set around it, are longer because the first week of a blog should answer the questions people actually ask: what is Shyne, how do I start, what is a canvas, how does the agent work, and how does work leave the project.

We will not use this space to invent a second product. Presentation, document, carousel, social, email, and video are ways of arranging and exporting work. They are not five different file formats you have to migrate between. If a post talks about a pitch deck, it is talking about a sequence of frames. If it talks about a film, it is talking about a timed sequence. The nouns stay stable so the writing stays honest.

You will also find guides. How to create a project. How to connect Claude, Cursor, or ChatGPT over MCP. How to keep brand values in the project instead of in a slide master you forgot to update. Those posts are written for someone who has a deadline this week, not for someone collecting screenshots of a roadmap.

How the blog works

Every article lives beside the product code and goes through the same review process. That keeps each post versioned, reviewable, and connected to the release it describes. There is no separate publishing database. When an article is ready, we publish it with the next build.

That choice is deliberate. A marketing site can drift from the product. A blog that sits in the same repository cannot quietly promise an export format or delivery path the product does not have without someone noticing in review. If we get a fact wrong, the fix is a pull request, the same way a broken tooltip is a pull request.

Drafts stay drafts. An article with draft: true does not appear in the public index, the related-post list, the static route files, or the sitemap. You can read drafts during local development. Preview and production builds only show what we have marked ready.

The same rule applies to categories and authors. A post has to name a category and an author that exist. Related posts have to name real slugs. The build fails if those references are broken. That is a small piece of infrastructure, but it is the reason this blog can grow without becoming a pile of 404s.

Who it is for

The first readers we have in mind are the people Shyne is already built for: consultants, founders, and solo operators who present and publish for a living. They do not need another essay about “the future of creativity.” They need to know whether the teammate will stay on brand, whether a colleague can join the same canvas, and whether the finished work can leave as PNG, PDF, HTML, PowerPoint, or MP4.

Teams will find this useful too. A project has viewing and editing roles. Viewers can look. Editors can make. Project creators and organization admins decide who else gets in. When an agent tries to post or schedule work, Shyne pauses for explicit human permission. If you are evaluating Shyne for a small marketing team, the posts on publishing, brand, and live collaboration are the ones to read first.

Developers and agents are welcome. Shyne has a public REST API, a hosted MCP server at https://mcp.shyne.ai/mcp, and a desktop loopback at http://127.0.0.1:7655/mcp. We will not reprint the entire API reference here. We will explain when to use which door, and what the agent is not allowed to do.

What Shyne is, in one sitting

Shyne is an AI-native creative workspace. The one-line version we use internally is: your AI creative teammate. It designs, writes, and films alongside you, always on brand. The longer version is more precise. The structured document is a Yjs graph. Humans and agents edit that same graph live as peers. The editor projects the graph to real DOM so you can drag, type, and select. HTML is an import and export artifact, not the thing we persist as creative truth.

A workspace holds tasks and projects. A task is a durable agent conversation. It may be filed in one project, but opening a project does not create or move a task. A project is the cloud identity and collaboration boundary. It owns files and canvases. A canvas is the one visual document type. It can hold loose nodes and groups, loose frames, and several sequences. A sequence is an ordered or timed collection of frames. A frame is a bounded region you render, present, or export. A node is editable content.

That vocabulary is not decoration. It is the reason an agent can make a six-slide launch deck and you can immediately select the third heading. Nothing was flattened into a picture. Nothing was written into a private HTML blob the teammate will overwrite on the next turn.

Why we are writing this now

Shyne has been a product you use more than a product you read about. That is the right order. Documentation already covers getting started, concepts, the API, MCP, video, and publishing. The blog is for the decisions around those pages: why the canvas is the document, why actions that leave Shyne require explicit permission, and why the desktop app and the browser share one project identity.

We also want a place that can hold longer answers without turning the marketing homepage into a textbook. The homepage should show the work. The docs should tell you how to connect. The blog should sit between them: narrative enough to be readable, specific enough to be true.

How to read the first set

Start with Your AI creative teammate if you want the positioning in full. Read One canvas, many deliverables if you want the model. Start a project in Shyne is the practical path for a first session. Connect Claude, Cursor, or ChatGPT to Shyne is the door for people who already live in an agent. Publish from the same canvas and Video belongs on the canvas cover the two ways work usually leaves the building.

You do not have to read them in order. Each post is written to stand alone. Related links at the bottom are suggestions, not homework.

What we will not do here

We will not pad these pages with unverified traction numbers. We will not claim an export format the editor does not have. We will not treat a scheduled time as proof that a post went out. We will not tell you the agent can permanently delete a project, rotate keys, access provider tokens, or publish without your approval. Those boundaries stay explicit.

We will also not turn every post into a comparison page. Other tools exist. Some of them are excellent at generation. Some of them are excellent at design files. Shyne’s square is the live teammate across decks, documents, social, and video, on one canvas, with the document remaining editable.

A note on voice

The blog follows the product’s verbal restraint. Headings are for orientation. Body copy is for meaning. We will use the product nouns — project, canvas, sequence, frame, node, task — instead of sliding back into “artboard,” “board,” or “page-as-document.” Those words are retired in the product and they are retired here.

If a sentence could appear on any AI design landing page, we will try to rewrite it until it could only appear on this one.

What happens next

This blog will grow the same way the product grows: in public, in review, with the smallest change that answers the question. If you want the short path into the product itself, open app.shyne.ai or install the desktop app from dl.shyne.ai. If you want the short path into the writing, pick one related post below and stay for the length of a real article.

We will keep publishing notes when something in the product changes shape. We will keep publishing guides when a path that used to be obvious to us is not obvious to a new project. And we will keep publishing craft pieces when the reason for a decision is more interesting than the release note.

Welcome. The canvas is the document. The teammate is a peer. The work you ship should still be the work you can edit.