> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rocket.new/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

> See how context flows between Solve and Build tasks in Rocket.new projects.

export const LlmsDirective = () => <blockquote className="llms-directive">
    For the complete documentation index, see <a href="/llms.txt">llms.txt</a>.
    For a lightweight markdown version of this page, append .md to the URL.
  </blockquote>;

<LlmsDirective />

Context is the information Rocket has access to when working on a task. Inside a project, that context is shared. Every task can draw on the same files, connected documents, and outputs from earlier tasks without re-uploading or re-explaining anything.

The more relevant work you do inside a project, the richer the shared foundation becomes.

<Info>
  Context is scoped to a project. Tasks in different projects do not share context with each other.
</Info>

## What counts as context

| Context type     | What it includes                                                    |
| :--------------- | :------------------------------------------------------------------ |
| **My Device**    | `.md`, `.pdf`, `.xlsx`, `.csv`, `.jpg`, `.jpeg`, `.png`             |
| **Google Drive** | Google Docs, Google Sheets                                          |
| **Notion**       | Notion pages (`.md`)                                                |
| **Task outputs** | Findings, decisions, and outputs from earlier Solve and Build tasks |
| **Chat history** | Clarifications and refinements from any task's conversation         |

## How context flows between tasks

Once you have multiple tasks in a project, their outputs become context for each other. A few common patterns:

|                      | What happens                                                                         |
| :------------------- | :----------------------------------------------------------------------------------- |
| **Solve then Build** | Research findings shape what gets built, including features, positioning, and design |
| **Build then Solve** | Development reveals new questions that trigger deeper research                       |
| **Solve then Solve** | Later research builds on earlier findings without duplicating work                   |
| **Build then Build** | Branding and technical decisions carry forward into new tasks                        |

<AccordionGroup>
  <Accordion title="Example: research informing a build">
    You run a Solve task to analyze competitors in your space. The report identifies the three features users expect most.

    You then create a Build task in the same project. Rocket references the competitive findings automatically, so the first generation already prioritizes those features.
  </Accordion>

  <Accordion title="Example: build prompting new research">
    You're building an e-commerce app and realize you need a pricing strategy. You create a Solve task in the same project. Rocket already knows the product category and target audience from the Build task, so the pricing analysis is specific to your product rather than generic advice.
  </Accordion>

  <Accordion title="Example: consistent branding across builds">
    You build an MVP web app as your first Build task. Later, you create a Build task for a companion landing page. Rocket carries forward the branding, messaging, and product details, so the landing page is consistent with the app from the start.
  </Accordion>
</AccordionGroup>

## Standalone tasks vs project tasks

You don't need a project to use Rocket. Standalone tasks work fine for one-off questions and quick builds. The difference is context.

|                                    | Standalone task | Task in a project |
| :--------------------------------- | :-------------- | :---------------- |
| Works on its own                   | Yes             | Yes               |
| Accesses shared files              | No              | Yes               |
| Benefits from other tasks' outputs | No              | Yes               |
| Uses connected services            | No              | Yes               |

<Note>
  If you start with a standalone task and later want shared context, you can add it to a project at any time without losing any history.
</Note>

## Tips

* **Upload files early.** Add brand guidelines, product specs, or reference docs when you create the project so every task starts with the right foundation.
* **Be specific in prompts.** Even with shared context available, explicit references get better results: "Based on the competitive analysis from earlier, build a landing page that emphasizes our differentiators."
* **Keep related work together.** The more relevant tasks you group in one project, the richer the shared context becomes.

## What's next?

<CardGroup cols={2}>
  <Card title="Upload files" icon="file-arrow-up" href="/getting-started/project/context/file-uploads">
    Add documents and data that all tasks in your project can reference.
  </Card>

  <Card title="Connect services" icon="plug" href="/getting-started/project/context/connected-services">
    Bring in live content from Notion and Google Drive.
  </Card>
</CardGroup>