> ## Documentation Index > Fetch the complete documentation index at: https://app.keystroke.ai/docs/llms.txt > Use this file to discover all available pages before exploring further. # Overview > An overview of projects and how they work. In Keystroke, everything you build belongs to a project. A project is a shared space for building and running your agents, workflows, triggers, and actions. Think of a project as the unit you build, deploy, give credentials to, invite teammates into, and inspect run history for. An organization functions as your company's workspace, and projects are the place where work is divided up. You might have one project for personal agents, another for support automations, and another for internal ops. When you join an organization, Keystroke automatically creates a personal project for you. You can keep everything in that project, or create more projects as your work grows. ## What belongs to a project? Projects group the code and operational resources for a specific area of work: * **Agents** decide what to do when the steps are not fully known. * **Workflows** run known steps reliably. * **Actions** are typed capabilities agents and workflows reuse. * **Triggers** start agents or workflows automatically. * **Skills** teach agents how to do a job. * **Files** give agents static context to read. * **Credentials** let actions connect to external services. * **Run history** shows what happened after agents and workflows run. * **Members** can build, deploy, and manage the project. Project membership controls who can see and work in a project. Members can build and deploy to projects they belong to, and org admins can see every project in the organization. ## How code fits in A project is defined in TypeScript. The codebase behind a project is the source of truth for the agents, workflows, triggers, actions, skills, and files it can run. `keystroke init` scaffolds that codebase with a standard layout: ```text theme={null} my-app/ keystroke.config.ts # project configuration tsconfig.json # extends @keystrokehq/cli/tsconfig.json (committed) package.json # dev/build/lint/typecheck/test scripts src/ agents/ # LLM agents actions/ # reusable units of work workflows/ # multi-step automations triggers/ # schedules, webhooks, app events skills/ # project skills for agents files/ # files attached to agents AGENTS.md # guide your coding agent reads ``` Keystroke discovers everything under `src/` by convention. Add a file that exports an agent, workflow, or trigger, and it becomes part of the project. Lint, typecheck, and test tooling ships in `@keystrokehq/cli` — not in project devDependencies. Because the project is code, your coding agent can read it, change it, run tests, and maintain it over time. See [AI onboarding](/build-with-ai/onboarding). ## How to use projects To build agents, workflows, etc, you edit the codebase and deploy it to a project — Keystroke is deploy-first. Deploy often: a full deploy ships everything, or `--filter` redeploys a single module fast. ```bash theme={null} keystroke projects list keystroke projects create --name "Support automations" keystroke projects link --project support-automations keystroke deploy ``` The project is the platform home for your work, and the codebase defines what runs there. After linking and deploying, `keystroke deploy` and other project-scoped commands use the slugs in `keystroke.config.ts` automatically. You can also run a local server with `keystroke dev` for offline iteration; see [targets: local vs cloud](/cli#targets-local-vs-cloud) for the full model. You can also create and build projects from a chat-first agent over the [Keystroke MCP server](/build-with-ai/mcp-for-agents) — it works in a hosted workspace and deploys to the same platform. To go the other way — get an existing project's code onto your machine — `keystroke pull` downloads its active deploy source into a local directory. See [deploy a project](/learn/projects/deploy-a-project#pull-the-active-deploy). ## Next steps Create projects, invite teammates, and manage project settings. Deploy a TypeScript codebase to run on the platform. Keep work-in-progress modules out of deploys. Download a project's active deploy source into a local directory. Inspect the agents and workflows that have run in a project.