diff --git a/.agents/skills/style_lint/style_lint.py b/.agents/skills/style_lint/style_lint.py index 26662510..116ef2c8 100644 --- a/.agents/skills/style_lint/style_lint.py +++ b/.agents/skills/style_lint/style_lint.py @@ -85,7 +85,6 @@ ("Oz run", "PLATFORM_RUN", "{VARS.PLATFORM_RUN} in prose or {{PLATFORM_RUN}} in frontmatter"), ("Oz API & SDK", "API_SDK_NAME", "{VARS.API_SDK_NAME} in prose or {{API_SDK_NAME}} in frontmatter"), ("Oz Platform", "WARP_AUTOMATION_PLATFORM", "{VARS.WARP_AUTOMATION_PLATFORM} in prose or {{WARP_AUTOMATION_PLATFORM}} in frontmatter"), - ("Oz", "WARP_AUTOMATION_PLATFORM", "{VARS.WARP_AUTOMATION_PLATFORM} in prose or {{WARP_AUTOMATION_PLATFORM}} in frontmatter"), ] # Oz terms to avoid (case-insensitive patterns) @@ -908,19 +907,15 @@ def check_hardcoded_vars(lines: List[str], filepath: str) -> List[Issue]: `oz.warp.dev` in a code fence are not flagged. Literals are checked longest-first and matches are deduplicated by span so - a specific match (e.g. "Oz Platform", "Oz CLI") doesn't also get re-flagged - by the more general bare "Oz" entry for the same occurrence. + overlapping rename-sensitive names are not double-flagged. Matches use word boundaries (`\b`) rather than plain substring search, so - short literals like bare "Oz" don't false-positive inside unrelated tokens - such as URL query params, hashes, or other identifiers (e.g. a YouTube - share link's `si=OzvuInMl8DoNR97R` parameter). - - An "@"-prefixed occurrence is skipped. "@Oz" is a literal mention handle - that a user types in Slack or Linear, not the product name appearing in - prose. Handles are strings the product owns, so they do not necessarily - change when the product name does -- variabilizing them would silently - rewrite a working handle into an invalid one at rename time. + literals don't false-positive inside unrelated tokens such as URL query + params, hashes, or other identifiers. + + An "@"-prefixed occurrence is skipped because mention handles are literal + strings that do not necessarily change with product names. Variabilizing + a handle could silently rewrite it into an invalid value at rename time. """ issues = [] in_code_block = False @@ -943,7 +938,7 @@ def check_hardcoded_vars(lines: List[str], filepath: str) -> List[Issue]: span = m.span() if any(span[0] >= s and span[1] <= e for s, e in matched_spans): continue - # "@Oz" is a mention handle users type, not prose. See docstring. + # Mention handles are literal strings, not prose. See docstring. if span[0] > 0 and prose_line[span[0] - 1] == "@": continue matched_spans.append(span) diff --git a/astro.config.mjs b/astro.config.mjs index 58bc4e23..ff8398ed 100644 --- a/astro.config.mjs +++ b/astro.config.mjs @@ -167,8 +167,9 @@ export default defineConfig({ customSets: [ { label: 'Terminal', description: 'Warp Terminal features and configuration.', paths: ['terminal/**'] }, { label: 'Agents', description: 'Warp\'s agents: capabilities, local agents, and CLI agents.', paths: ['agents/**'] }, + { label: 'Factories', description: 'Warp Factories documentation for setup, agent roles, definitions as code, integrations, measurement, and infrastructure.', paths: ['factories/**'] }, { label: 'Warp Agent CLI', description: 'The Warp Agent CLI: agent conversations, shell commands, permissions, and configuration in any terminal.', paths: ['agents/cli/**'] }, - { label: 'Oz Platform', description: 'Warp\'s Oz platform: cloud agents, orchestration, triggers, integrations, environments, harnesses, and self-hosting.', paths: ['platform/**'] }, + { label: 'Automation Platform', description: 'Warp\'s Automation Platform: cloud agents, orchestration, triggers, integrations, environments, harnesses, and self-hosting.', paths: ['platform/**'] }, { label: 'Code', description: 'Code editor, code review, and Git worktrees.', paths: ['code/**'] }, { label: 'Enterprise', description: 'Enterprise features, SSO, team management, and security.', paths: ['enterprise/**'] }, { label: 'Getting Started', description: 'Installation, quickstart, and migration guides.', paths: ['index', 'quickstart', 'getting-started/**'] }, diff --git a/src/components/WarpTopicNav.astro b/src/components/WarpTopicNav.astro index be4c83b7..75430a8c 100644 --- a/src/components/WarpTopicNav.astro +++ b/src/components/WarpTopicNav.astro @@ -5,9 +5,8 @@ // Reference, etc.) as an inline-flex row with a small icon + label. The list // is sourced from `starlight-sidebar-topics`'s middleware, which exposes // `Astro.locals.starlightSidebarTopics.topics` on every Starlight route. -// Each topic carries `{ link, label, icon, badge, isCurrent }`; we consume -// `link`/`label`/`icon`/`isCurrent` and ignore `badge` for now (none of our -// topics ship one). The plugin's per-topic sidebar filtering lives in its +// Each topic carries `{ link, label, icon, badge, isCurrent }`. The plugin's +// per-topic sidebar filtering lives in its // middleware (it rewrites `starlightRoute.sidebar`), so removing the topic // list from the sidebar markup does NOT break that filtering — the same // filtered nav still renders below this row in the page sidebar. @@ -26,7 +25,7 @@ // underline share `--sl-color-text-accent`, which auto-adapts to dark // and light themes. // - No surrounding chip / box / bg — just type + icon -import { Icon } from '@astrojs/starlight/components'; +import { Badge, Icon } from '@astrojs/starlight/components'; const { topics } = Astro.locals.starlightSidebarTopics; @@ -122,6 +121,11 @@ const CUSTOM_TOPIC_ICONS: Record = { ) : null} {topic.label} + {topic.badge && ( + + + + )} ))} @@ -210,6 +214,11 @@ const CUSTOM_TOPIC_ICONS: Record = { color: var(--sl-color-text-accent); font-weight: 600; } + .warp-topic-nav__badge { + display: inline-flex; + align-items: center; + margin-inline-start: 0.125rem; + } /* 2px accent underline under the active tab, anchored to the link's own bottom edge so it hugs the tab. It previously dropped down to the diff --git a/src/content/docs/enterprise/getting-started/quickstart.mdx b/src/content/docs/enterprise/getting-started/quickstart.mdx index 63b7da5e..7c8b86f2 100644 --- a/src/content/docs/enterprise/getting-started/quickstart.mdx +++ b/src/content/docs/enterprise/getting-started/quickstart.mdx @@ -35,7 +35,7 @@ If you have an existing Warp account from before your organization enabled SSO, ## 3. Configure and run your first agent -When you use agents in Warp, you're working with **Warp's built-in agents**. {VARS.WARP_AUTOMATION_PLATFORM} is Warp's programmable system for running and coordinating agents at scale, whether they run locally on your machine or in the cloud. +When you use Agent Mode in Warp, you're working with the Warp Agent, Warp's built-in agent. {VARS.WARP_AUTOMATION_PLATFORM} is Warp's programmable system for running and coordinating agents at scale, whether they run locally on your machine or in the cloud. ### Index your codebase @@ -52,14 +52,14 @@ Start a conversation right in the terminal. Try the following prompt: Explain the architecture of this project ``` -{VARS.WARP_AUTOMATION_PLATFORM} reads your codebase, understands its structure, and responds with a context-aware explanation. +The Warp Agent reads your codebase, understands its structure, and responds with a context-aware explanation. ### Try more prompts * **Write code** - "Add input validation to the signup form" * **Debug** - "Why is this test failing?" (paste the error output) * **Explore** - "What patterns does this repo use for error handling?" -* **Plan** - Use `/plan` to have {VARS.WARP_AUTOMATION_PLATFORM} create a structured task plan for complex features +* **Plan** - Use `/plan` to have the Warp Agent create a structured task plan for complex features ## 4. Run a cloud agent diff --git a/src/content/docs/factories/configure-your-factory.mdx b/src/content/docs/factories/configure-your-factory.mdx deleted file mode 100644 index 0198192b..00000000 --- a/src/content/docs/factories/configure-your-factory.mdx +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: Configure your Factory -description: >- - Define agent roles, skills, MCPs, and permissions for your Warp Factory as - version-controlled code. -sidebar: - label: "Configure your Factory" ---- - -[STUB — pending content from HYC/content team for the 8/18 closed-beta soft launch. Owner: HYC. - -Lightweight aggregation page — mostly link into existing detailed docs rather than duplicate them. Cover: -- Factory definitions as code: repos, agent role definitions, skills, MCPs, permissions -- Configuring the default agents (triage, spec, implement, review) and adding custom agents/automations -- Model and harness choice per agent role (link to the Automation Platform tab's Harnesses docs) -- Metrics, evals, and self-improvement configuration (control room, scorers, benchmarks) - -Cross-link to the Automation Platform tab for underlying primitives (Environments, Integrations, Orchestration) rather than duplicating that content.] diff --git a/src/content/docs/factories/control-room.mdx b/src/content/docs/factories/control-room.mdx new file mode 100644 index 00000000..d6a1f555 --- /dev/null +++ b/src/content/docs/factories/control-room.mdx @@ -0,0 +1,9 @@ +--- +title: Control room +description: >- + Factory control room documentation will cover monitoring and intervention in a follow-up PR. +sidebar: + label: "Control room" +--- + +Factory control room documentation will land in a follow-up PR. diff --git a/src/content/docs/factories/factory-agents.mdx b/src/content/docs/factories/factory-agents.mdx new file mode 100644 index 00000000..0d75580e --- /dev/null +++ b/src/content/docs/factories/factory-agents.mdx @@ -0,0 +1,9 @@ +--- +title: Factory agents +description: >- + Factory agent documentation will cover specialized roles and configuration in a follow-up PR. +sidebar: + label: "Factory agents" +--- + +Factory agent documentation will land in a follow-up PR. diff --git a/src/content/docs/factories/factory-as-code.mdx b/src/content/docs/factories/factory-as-code.mdx new file mode 100644 index 00000000..25881dba --- /dev/null +++ b/src/content/docs/factories/factory-as-code.mdx @@ -0,0 +1,9 @@ +--- +title: Definitions as code +description: >- + Definitions-as-code documentation for Warp Factories will be added in a follow-up PR. +sidebar: + label: "Definitions as code" +--- + +Definitions-as-code documentation for Warp Factories will land in a follow-up PR. diff --git a/src/content/docs/factories/factory-mcp.mdx b/src/content/docs/factories/factory-mcp.mdx new file mode 100644 index 00000000..f051c2e7 --- /dev/null +++ b/src/content/docs/factories/factory-mcp.mdx @@ -0,0 +1,9 @@ +--- +title: Factory MCP +description: >- + Factory MCP documentation will cover programmatic factory connections in a follow-up PR. +sidebar: + label: "Factory MCP" +--- + +Factory MCP documentation will land in a follow-up PR. diff --git a/src/content/docs/factories/integrations/github.mdx b/src/content/docs/factories/integrations/github.mdx new file mode 100644 index 00000000..a32a4ed6 --- /dev/null +++ b/src/content/docs/factories/integrations/github.mdx @@ -0,0 +1,9 @@ +--- +title: GitHub integration +description: >- + GitHub integration documentation for Warp Factories will be added in a follow-up PR. +sidebar: + label: "GitHub" +--- + +GitHub integration documentation for Warp Factories will land in a follow-up PR. diff --git a/src/content/docs/factories/integrations/jira.mdx b/src/content/docs/factories/integrations/jira.mdx new file mode 100644 index 00000000..e299a6dc --- /dev/null +++ b/src/content/docs/factories/integrations/jira.mdx @@ -0,0 +1,9 @@ +--- +title: Jira integration +description: >- + Jira integration documentation for Warp Factories will be added in a follow-up PR. +sidebar: + label: "Jira" +--- + +Jira integration documentation for Warp Factories will land in a follow-up PR. diff --git a/src/content/docs/factories/integrations/linear.mdx b/src/content/docs/factories/integrations/linear.mdx new file mode 100644 index 00000000..cd24dcd0 --- /dev/null +++ b/src/content/docs/factories/integrations/linear.mdx @@ -0,0 +1,9 @@ +--- +title: Linear integration +description: >- + Linear integration documentation for Warp Factories will be added in a follow-up PR. +sidebar: + label: "Linear" +--- + +Linear integration documentation for Warp Factories will land in a follow-up PR. diff --git a/src/content/docs/factories/integrations/slack.mdx b/src/content/docs/factories/integrations/slack.mdx new file mode 100644 index 00000000..816906dc --- /dev/null +++ b/src/content/docs/factories/integrations/slack.mdx @@ -0,0 +1,9 @@ +--- +title: Slack integration +description: >- + Slack integration documentation for Warp Factories will be added in a follow-up PR. +sidebar: + label: "Slack" +--- + +Slack integration documentation for Warp Factories will land in a follow-up PR. diff --git a/src/content/docs/factories/measure-and-improve.mdx b/src/content/docs/factories/measure-and-improve.mdx new file mode 100644 index 00000000..732ac25f --- /dev/null +++ b/src/content/docs/factories/measure-and-improve.mdx @@ -0,0 +1,9 @@ +--- +title: Measure and improve +description: >- + Factory measurement and improvement documentation will be added in a follow-up PR. +sidebar: + label: "Measure and improve" +--- + +Factory measurement and improvement documentation will land in a follow-up PR. diff --git a/src/content/docs/guides/agent-workflows/build-a-self-improving-agent.mdx b/src/content/docs/guides/agent-workflows/build-a-self-improving-agent.mdx index 7668c92e..d61ea4d4 100644 --- a/src/content/docs/guides/agent-workflows/build-a-self-improving-agent.mdx +++ b/src/content/docs/guides/agent-workflows/build-a-self-improving-agent.mdx @@ -120,7 +120,7 @@ Over time, the companion skill accumulates a clear description of how your team ## Next steps -* [What is a software factory?](/platform/software-factory) — How the outer improvement loop fits into the full factory model. +* [Warp Factories overview](/factories/) — How the outer improvement loop fits into the full factory model. * [Set up your software factory](/guides/agent-workflows/set-up-a-software-factory) — The inner loop the outer loop improves. * [Run a software factory in the cloud](/guides/agent-workflows/run-a-software-factory-in-the-cloud) — Move the loop to {VARS.WARP_AUTOMATION_PLATFORM} for team-wide visibility. * [Scheduled agents](/platform/triggers/scheduled-agents) — Full reference for running cloud agents on a cadence. diff --git a/src/content/docs/guides/agent-workflows/build-a-triage-agent.mdx b/src/content/docs/guides/agent-workflows/build-a-triage-agent.mdx index 327fecaa..37e80e0f 100644 --- a/src/content/docs/guides/agent-workflows/build-a-triage-agent.mdx +++ b/src/content/docs/guides/agent-workflows/build-a-triage-agent.mdx @@ -11,7 +11,7 @@ tags: --- import { VARS } from '@data/vars'; -Learn how to use {VARS.WARP_AUTOMATION_PLATFORM} to build a triage agent that reviews each new GitHub issue for clarity, applies labels, and flags open questions before implementation begins. After completing the steps in this guide, you will have a working triage skill deployed as a GitHub Action. This is the first agent in your [software factory](/platform/software-factory). +Learn how to use {VARS.WARP_AUTOMATION_PLATFORM} to build a triage agent that reviews each new GitHub issue for clarity, applies labels, and flags open questions before implementation begins. After completing the steps in this guide, you will have a working triage skill deployed as a GitHub Action. This is the first agent in your [software factory](/factories/). ## Prerequisites @@ -121,7 +121,7 @@ Add repo-specific context without forking the core skill by creating a `triage-i ## Next steps -* [What is a software factory?](/platform/software-factory) — How the triage agent fits into the full development loop. +* [Warp Factories overview](/factories/) — How the triage agent fits into the full development loop. * [Write product and tech specs with agents](/guides/agent-workflows/write-product-and-tech-specs-with-agents) — Add the spec role once your backlog is well-triaged. * [Build a self-improving agent](/guides/agent-workflows/build-a-self-improving-agent) — Automate skill improvement based on your corrections. * [GitHub Actions integration](/platform/integrations/github-actions) — Full documentation for `warpdotdev/oz-agent-action`. diff --git a/src/content/docs/guides/agent-workflows/run-a-software-factory-in-the-cloud.mdx b/src/content/docs/guides/agent-workflows/run-a-software-factory-in-the-cloud.mdx index 5fc431ac..92a47874 100644 --- a/src/content/docs/guides/agent-workflows/run-a-software-factory-in-the-cloud.mdx +++ b/src/content/docs/guides/agent-workflows/run-a-software-factory-in-the-cloud.mdx @@ -96,7 +96,7 @@ See [Multi-agent orchestration](/platform/orchestration) for fan-out, sharding, ## Next steps -* [What is a software factory?](/platform/software-factory) — The conceptual overview of the full loop. +* [Warp Factories overview](/factories/) — The conceptual overview of the full loop. * [Build a self-improving agent](/guides/agent-workflows/build-a-self-improving-agent) — Add the outer improvement loop on a schedule. * [Environments](/platform/environments) — Full reference for cloud agent environments. * [Deployment patterns](/platform/deployment-patterns) — Choose the right architecture for your team. diff --git a/src/content/docs/guides/agent-workflows/set-up-a-software-factory.mdx b/src/content/docs/guides/agent-workflows/set-up-a-software-factory.mdx index 9abf9700..6a31f8e4 100644 --- a/src/content/docs/guides/agent-workflows/set-up-a-software-factory.mdx +++ b/src/content/docs/guides/agent-workflows/set-up-a-software-factory.mdx @@ -162,7 +162,7 @@ The reviewer agent surfaces issues and inconsistencies; the human makes the fina ## Next steps -* [What is a software factory?](/platform/software-factory) — The conceptual overview of the full loop. +* [Warp Factories overview](/factories/) — The conceptual overview of the full loop. * [Run a software factory in the cloud](/guides/agent-workflows/run-a-software-factory-in-the-cloud) — Move the loop into a managed {VARS.WARP_AUTOMATION_PLATFORM} deployment. * [Build a self-improving agent](/guides/agent-workflows/build-a-self-improving-agent) — Add the outer improvement loop. * [Review AI-generated code](/guides/agent-workflows/how-to-review-ai-generated-code) — The human review workflow for agent-generated PRs. diff --git a/src/content/docs/guides/agent-workflows/write-product-and-tech-specs-with-agents.mdx b/src/content/docs/guides/agent-workflows/write-product-and-tech-specs-with-agents.mdx index 45f25ec0..86d176c2 100644 --- a/src/content/docs/guides/agent-workflows/write-product-and-tech-specs-with-agents.mdx +++ b/src/content/docs/guides/agent-workflows/write-product-and-tech-specs-with-agents.mdx @@ -72,7 +72,7 @@ A tech spec defines how the feature will be implemented, including architecture ## Next steps -* [What is a software factory?](/platform/software-factory) — How specs fit into the full development loop. +* [Warp Factories overview](/factories/) — How specs fit into the full development loop. * [Set up your software factory](/guides/agent-workflows/set-up-a-software-factory) — Connect the spec role to implementation and review. * [`warpdotdev/common-skills`](https://github.com/warpdotdev/common-skills) — The full set of shared skills including `write-product-spec`, `write-tech-spec`, and `validate-changes-match-specs`. * [Planning](/agents/capabilities/planning) — Warp's built-in planning feature for smaller tasks. diff --git a/src/content/docs/platform/deployment-patterns.mdx b/src/content/docs/platform/deployment-patterns.mdx index 8801109e..ae95204d 100644 --- a/src/content/docs/platform/deployment-patterns.mdx +++ b/src/content/docs/platform/deployment-patterns.mdx @@ -113,7 +113,7 @@ When a task is naturally divisible, use [multi-agent orchestration](/platform/or ## Pattern 3: Self-hosted execution -Use this when you need to control where agent execution happens while still using {VARS.WARP_AUTOMATION_PLATFORM} orchestration and visibility. Repositories are cloned and stored only on your infrastructure; orchestration metadata, session transcripts, and LLM inference route through Warp's backend under [ZDR](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr). +Use this when you need to control where agent execution happens while still using {VARS.WARP_AUTOMATION_PLATFORM} orchestration and visibility. Repositories are cloned and stored only on your infrastructure. Orchestration metadata and session transcripts route through Warp's backend; cloud conversations require Warp to store conversation data according to Warp's retention terms. LLM inference requests and responses route through Warp to contracted model providers under [ZDR](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr), except for provider-specific models that are not covered by ZDR and follow the provider's retention requirements. Think of self-hosted execution as **customer-hosted execution with Warp-hosted orchestration**, not as a fully offline agent stack. Code repositories, build artifacts, runtime secrets, and execution workspaces stay on your infrastructure. Code context can still appear in session transcripts and LLM prompts as the agent works. diff --git a/src/content/docs/platform/software-factory.mdx b/src/content/docs/platform/software-factory.mdx deleted file mode 100644 index fd0eb40e..00000000 --- a/src/content/docs/platform/software-factory.mdx +++ /dev/null @@ -1,82 +0,0 @@ ---- -title: Software factory -description: >- - A software factory uses specialized agents to take new issues through triage, spec, implementation, and review, producing pull requests for your team to merge. -# Unlisted: superseded by the new Factories tab (/factories/) for the 8/18 -# launch and redirected there in vercel.json. Kept as source material for -# HYC/content to migrate rather than deleted -- see the Factories tab stubs. -# The `topic` field associates this orphaned page with the Automation -# Platform topic so starlight-sidebar-topics can resolve it without listing -# it under any group. -topic: platform ---- - -A software factory is a development system where specialized agents take new issues through triage, spec, implementation, and review, producing pull requests for your team to merge. Instead of every developer executing every step — reading each issue, writing specs, implementing changes, reviewing output — agents execute and humans review. The team's job shifts from doing the work to defining the process and raising the quality bar over time. - -Warp uses this model to build Warp itself. The [agent dashboard at build.warp.dev](https://build.warp.dev) shows the work Warp's agents are tackling across the open source repository in real time. - -Read on to learn about the two loops that make up a software factory, the agent roles involved, and how to decide if this model is right for your team. - -## The two loops - -A software factory has two loops that work together. - -**The inner loop** is the execution loop: a triage agent, spec agent, implementation agent, and reviewer agent work in sequence, turning a new issue into a pull request for human review. - -**The outer loop** is the improvement loop: a [scheduled agent](/platform/triggers/scheduled-agents/) reviews past inner-loop runs, observes where maintainers made corrections, and opens a pull request to update the skill files that drive the inner-loop agents. Over time, the factory gets better without anyone manually rewriting prompts. - -The inner loop ships software. The outer loop improves the factory that ships it. - -## Agent roles - -A software factory delegates work to specialized agents, each with a narrow responsibility: - -* **Triage agent** - Reviews new issues for clarity and completeness. Labels issues as ready to implement, needs more information, or a duplicate. Flags open questions for the reporter before implementation begins, so the backlog stays clean and actionable. -* **Spec agent** - Drafts a product spec (user stories and acceptance criteria) and a tech spec (implementation strategy, relevant code locations, and edge cases). The specs serve as the blueprint for the implementation agent and the review criteria for the reviewer agent. -* **Implementation agent** - Builds against approved specs. Uses spec context to make better architectural decisions and raises a blocked status when specs are missing or ambiguous rather than guessing. -* **Reviewer agent** - Checks the implementation against specs, code conventions, and security requirements. Posts inline review comments and validates that acceptance criteria are met before a human reviewer opens the PR. - -The [`warpdotdev/oz-for-oss`](https://github.com/warpdotdev/oz-for-oss) repository is the complete reference implementation with all four roles deployed in a working system. - -## How it works - -Each agent role is backed by a **skill**, a markdown file checked into a Git repository that defines the agent's behavior: what to check, how to classify results, what to output, and when to escalate. Skills are versioned, reviewed as code changes, and composable across repositories. - -The inner loop runs when a new issue is filed: - -1. A webhook or GitHub Action triggers the triage agent. The agent runs in a cloud [environment](/platform/environments/), analyzes the issue, and applies labels and comments. -2. When the issue is labeled `ready-to-spec`, the spec agent creates `PRODUCT.md` and `TECH.md` in a `specs/` directory in the repository. -3. A human reviews and approves the specs. -4. When the implementation label is applied, the implementation agent opens a PR that includes the spec files alongside the code. - -Oz orchestrates each agent as a cloud run. Every run has its own environment (repository checkout, secrets, toolchain), its own permissions, and a session link your team can use to inspect what the agent did, steer it mid-run, or use [Handoff](/platform/handoff/) to move work back to a local session. For parent/child fan-out and review swarms across those roles, see [Multi-agent orchestration](/platform/orchestration/). - -The outer loop runs on a [schedule](/platform/triggers/scheduled-agents/), not in response to events. - -A scheduled cloud agent collects signals from past inner-loop runs and generates a diff to the relevant skill files. That diff goes through a normal pull request review before merging. Humans decide what improves; agents propose it. - -## When to use a software factory - -A software factory is a strong fit when: - -* Your team has a repeatable development workflow: a backlog of issues with consistent shape, and a process you can write down and teach to an agent. -* The cost of a missed edge case in agent output is recoverable. The agent opens a pull request, not a deploy, so humans stay in control of what ships. -* You want to scale throughput without scaling headcount linearly, or you want to move faster on a large backlog with a small team. - -Start with one agent role. Most teams start with a triage agent, which is the simplest loop to close correctly. A well-groomed backlog immediately benefits every developer on the team. Add spec, implementation, and reviewer agents as you build confidence in each step. - -## Reference implementation - -[`warpdotdev/oz-for-oss`](https://github.com/warpdotdev/oz-for-oss) is Warp's open-source software factory platform for GitHub-hosted repositories. It includes a Vercel webhook layer, GitHub App, and skill files for every agent role in the loop: triage, spec, implementation, review, verification, and self-improvement. Get started with the [onboarding guide](https://github.com/warpdotdev/oz-for-oss/blob/main/docs/onboarding.md). - -## Related pages - -* [Build a triage agent for your issue backlog](/guides/agent-workflows/build-a-triage-agent) — Start the series with the simplest agent role. -* [Write product and tech specs with agents](/guides/agent-workflows/write-product-and-tech-specs-with-agents) — Write specs that guide implementation agents. -* [Set up your software factory](/guides/agent-workflows/set-up-a-software-factory) — Connect the four roles into a working loop. -* [Run a software factory in the cloud](/guides/agent-workflows/run-a-software-factory-in-the-cloud) — Move the loop off your laptop with Oz. -* [Build a self-improving agent](/guides/agent-workflows/build-a-self-improving-agent) — Add the outer improvement loop. -* [Multi-agent orchestration](/platform/orchestration/) — Coordinate specialized agent roles as parent and child runs. -* [Skills](/agents/capabilities/skills) — How skill files work in Warp and Oz. -* [Cloud agents overview](/platform) — Setting up cloud agents on Oz. -* [Deployment patterns](/platform/deployment-patterns) — Common architectures for cloud agent deployment. diff --git a/src/content/docs/quickstart.mdx b/src/content/docs/quickstart.mdx index c6f3a75a..980e0bc6 100644 --- a/src/content/docs/quickstart.mdx +++ b/src/content/docs/quickstart.mdx @@ -5,7 +5,6 @@ description: >- commands, talk to an agent, and discover what makes Warp different. --- import { Tabs, TabItem } from '@astrojs/starlight/components'; -import { VARS } from '@data/vars'; Get up and running with Warp in about 10 minutes. Install the app, run your first commands using Blocks and the modern text editor, and start an agent conversation to write code, debug issues, or explore your codebase, all from natural language prompts inside the terminal. @@ -91,7 +90,7 @@ Learn more about [Autosuggestions](/terminal/command-completions/autosuggestions ## 5. Ask your first agent question -Everything you've done so far has been in **terminal mode**, running shell commands the way you normally would. Warp also has **Agent Mode**, a dedicated conversation view where you interact with {VARS.WARP_AUTOMATION_PLATFORM}, Warp's built-in agent, using natural language. +Everything you've done so far has been in **terminal mode**, running shell commands the way you normally would. Warp also has **Agent Mode**, a dedicated conversation view where you interact with the Warp Agent, Warp's built-in agent, using natural language. Start an agent conversation by pressing `⌘↩` (macOS) or `Ctrl+Shift+Enter` (Windows/Linux). Then type a prompt: @@ -99,7 +98,7 @@ Start an agent conversation by pressing `⌘↩` (macOS) or `Ctrl+Shift+Enter` ( Explain the architecture of this project ``` -{VARS.WARP_AUTOMATION_PLATFORM} reads your codebase, understands its structure, and responds with a context-aware explanation. From here you can ask follow-up questions, have {VARS.WARP_AUTOMATION_PLATFORM} write or refactor code, debug errors, or run commands on your behalf — all within the same conversation. +The Warp Agent reads your codebase, understands its structure, and responds with a context-aware explanation. From here you can ask follow-up questions, have the Warp Agent write or refactor code, debug errors, or run commands on your behalf — all within the same conversation. :::note You don't always need to switch modes manually. If you type a natural-language prompt in terminal mode, Warp auto-detects it and offers to send it to an agent. diff --git a/src/sidebar.ts b/src/sidebar.ts index 9fa13fc3..c4fcad8a 100644 --- a/src/sidebar.ts +++ b/src/sidebar.ts @@ -369,26 +369,53 @@ export const sidebarTopics: StarlightSidebarTopicsUserConfig = [ ], }, { - // New for the 8/18 Warp Factories soft launch. Stub pages live at - // src/content/docs/factories/ pending content from HYC/content team. - // Icon is a placeholder (gear) -- Starlight's built-in icon set has no - // literal factory glyph. A true factory icon would need a custom icon - // library plugin + Sidebar component override; revisit post-launch. + // Warp Factories documentation for Early Access. + // Starlight has no built-in factory glyph, so use its settings icon. + id: 'factories', label: 'Factories', link: '/factories/', icon: 'setting', + badge: { text: 'Early Access', variant: 'note' }, items: [ { - label: 'Factories', + label: 'Get started', items: [ { slug: 'factories', label: 'Overview' }, { slug: 'factories/quickstart', label: 'Quickstart' }, - { slug: 'factories/how-factories-work', label: 'How Factories work' }, - { slug: 'factories/configure-your-factory', label: 'Configure your Factory' }, - { slug: 'factories/connect-your-factory', label: 'Connect your Factory' }, + { slug: 'factories/how-factories-work', label: 'How Warp Factories work' }, + ], + }, + { + label: 'Configure', + items: [ + { slug: 'factories/factory-agents', label: 'Factory agents' }, + { slug: 'factories/factory-as-code', label: 'Definitions as code' }, { slug: 'factories/infrastructure-and-security', label: 'Infrastructure & security' }, ], }, + { + label: 'Connect', + items: [ + { slug: 'factories/connect-your-factory', label: 'Connect your factory' }, + { + label: 'Integrations', + items: [ + { slug: 'factories/integrations/slack', label: 'Slack' }, + { slug: 'factories/integrations/github', label: 'GitHub' }, + { slug: 'factories/integrations/linear', label: 'Linear' }, + { slug: 'factories/integrations/jira', label: 'Jira' }, + ], + }, + { slug: 'factories/factory-mcp', label: 'Factory MCP' }, + ], + }, + { + label: 'Operate', + items: [ + { slug: 'factories/control-room', label: 'Control room' }, + { slug: 'factories/measure-and-improve', label: 'Measure and improve' }, + ], + }, ], }, {