Skills, workflows, and apps are the three things you build in General Input. Until now they all lived in one flat pile.
That is fine for the first few. It stops being fine once you have a goal that takes several of them: a skill holding the procedure, a workflow running it on a schedule, an app where someone reads the output, and the reference files behind all three. Four things that only make sense together, scattered across four lists.
Projects Are Now Live
A project is a container for one goal. It holds workflows, apps, and skills, plus its own files and its own chats, and it gives that whole system a single home you can open, extend, and hand to someone.
Create one from Projects in the sidebar, give it a name and an icon, and you have somewhere for the work to accumulate.
Describe the System, Not the Pieces
The fastest way to fill a project is to skip the pieces entirely and describe what you want the system to do.
Open a chat from inside the project and it gets pinned to the input, so everything created in that conversation lands in the project instead of loose in your workspace. Then say what you want in plain English.
In the video above, the ask is one paragraph: read the previous day's news at 3am, generate five blog post ideas from it, learn our writing tone from the posts already on our blog, and give us somewhere to work the ideas.
What comes back is three pieces, wired together: a skill holding the tone, a workflow on a 3am schedule, and an app to triage the output. That took about fifteen minutes, and it is a first prototype rather than a finished thing.
Extending it later is another sentence typed into the same project. Adding search data or saving images from each article is not a new build, because there is somewhere for the change to land.
Every Project Has Its Own Memory
A project keeps a memory separate from your workspace memory and your personal memory. It builds that from the project's files, the workflows pinned to it, and how those runs go, so the system gets better at its job without you maintaining a prompt by hand.
Share the System, Not the Pieces
Sharing a project shares what is in it. Give a teammate access and the workflows, apps, and skills pinned to it come along, which is usually what you want when you are handing over a system rather than a file.
Access set directly on a resource still wins. Somebody can be an editor on the project and a viewer on one particular workflow inside it.
Deleting a Project
Deleting a project asks what should happen to the work inside it. Delete them too removes everything you own along with the project. Keep them in my workspace moves it all back out to the top level, where it keeps working, and only the project goes away.
Anything a teammate owns is never deleted. It moves to your workspace instead.
A Few Projects Worth Building
- Content engine. A skill holding your writing tone, a workflow that reads the news each morning and drafts ideas, and an app to approve or kill them.
- Client onboarding. The steps written down as a skill, a workflow that creates the accounts and folders, and an app showing where every new client is in the process.
- Engineering health. Your data model as a skill, bug-triage workflows on a cadence, and a dashboard app over the results.
- Weekly reporting. The report format as a skill, a workflow that assembles it from your connected systems every Monday, and the past quarter's reports as files the project can reference.
Each one is a system rather than a task, which is exactly the thing projects are for.
Projects are available in every workspace now. Open Projects in the sidebar to create your first one, or read the full walkthrough.