Setup
From zero to a running harness in one session. The agent handles every technical step — you provide intent and credentials.
The Model Before the Setup
Before the steps: the environment matters. ProductHarness runs inside a developer environment — an IDE like Cursor or VS Code, or a CLI tool like Claude Code — with an AI coding agent present. This is true for every role, including PMs.
This isn't incidental. The AI coding agent lives in the developer environment, and it operates on the local repository as its primary context. When requirements, discovery documents, and standards are files in that repo, the agent can read them, reason about them, and act on them — without you having to copy anything into a chat window or summarize what you've already written. The model only works because the work and the agent share the same space.
PMs working in ProductHarness aren't learning to code. They're working where the agent already lives — so it can do its job with full context, not a fragment of it.
From that foundation, setup is minimal. Most of what looks like "technical setup" is agent work — the agent reads the setup instructions and executes them. You provide what only you can provide: credentials, context, and intent.
No Node.js knowledge required. No Git configuration expertise required. No understanding of MCP servers, Storybook configuration, or environment variables required. Those are setup tasks — the agent executes them from the SETUP.md instructions already in the repo.
The team lead role is necessary only because creating a new repository typically requires permissions that aren't granted to everyone. Once the repo exists and access is provisioned, the team lead's involvement in setup is complete.
Six Steps to a Running Harness
At your request, the team lead opens a new private repository in your org's GitHub or GitLab instance and provisions your access. This is the project repo — where your work will live. It starts empty. This is the only step that requires someone other than you.
Open your AI coding agent — Cursor, VS Code with a Claude or Copilot extension, Claude Code, or equivalent — and create a new local folder, naming it the same as the repo the team lead just created. This folder is the working directory for your project. All your files live here, and the agent has this directory as its context for every interaction.
This is the environment you'll work in from here forward. Not a separate tool for product work and a different one for engineering — the same environment, with the agent present throughout.
Ask the agent to clone your org's ProductHarness repo into your new folder. This pulls down the complete harness: steering documents, directory structure, node definitions, document templates, MCP configuration templates, and dependency definitions.
A note on where that repo came from: ProductHarness is distributed as a specification, not as files from outside your org. When your org adopted the framework, an agent generated the harness repo from that specification — inside your source control, reviewed by your team, yours from the first commit. Nothing in it was cloned from anyone else's infrastructure.
The agent handles the Git clone operation. You don't need to know the clone command or the repo URL — both are in your org's harness documentation the agent can access.
If this is your first time using ProductHarness, prompt the agent to complete the setup sequence. The agent reads the SETUP.md file already in the repo and executes its instructions autonomously.
What the agent does:
First, it checks that Node.js is installed and prompts you to install it if not. Then it runs npm install to pull in Storybook, Playwright, and other dependencies. It copies the environment variable template and asks you to fill in the values that are specific to your org — API tokens and identifiers for your backlog, design tool, and test management integrations. Using those values, it configures the MCP servers that connect the agent to your tools.
Finally, it asks which stage of adoption this project is starting at. The default is the starting-out configuration, which activates immediately with no additional input. If you're connecting to a production codebase, the agent asks for the production repository URL and uses it to populate the local production component structure and capture current stack conventions. It then runs a verification script to confirm everything is working and summarizes what was configured.
If you've done this setup before on another project, skip to Step 5 — the dependencies are already in place.
Once setup is complete, tell the agent to configure both Git remotes. This is the step that connects your local work to both the project repo and the harness template.
The agent configures two remotes:
origin
upstream
Why two remotes matter is covered in the next section.
Setup is complete. The harness is in place — the agent knows your project conventions, has MCP connections to your tools, and can read the org's steering documents. Your work is automatically version-controlled, routed to the right places, and synced to the project repo. Start with whatever the project actually calls for: writing requirements, generating discovery documents, implementing a component, or generating test cases.
Everything Technical, Automatically
Every Git and technical operation in the setup flow is agent-managed. Your only technical requirement is Git installed and source control access provisioned. That boundary is intentional — it keeps the bar for starting a new project as low as possible across all roles.
The agent executes the Git clone command from a standing prompt. You don't need to know the repo URL or clone syntax — the agent handles it and confirms when the files are in place.
Running npm install pulls Storybook, Playwright, and any other dependencies defined in the harness. The agent runs this and reports the result — no terminal knowledge required.
MCP server configuration requires JSON files with credentials and endpoint URLs. The agent takes the values you provide in the environment variable setup and populates these configuration templates automatically. The connections to your backlog, design tool, and test management integrations are established without manual JSON editing.
Setting up the origin and upstream remotes requires Git remote commands with specific URLs. The agent handles both from a single prompt — pointing origin to your project repo and upstream to the ProductHarness Template, then confirming both are configured correctly.
Why Two Remotes Matter
The upstream remote is the governance mechanism. When the org's steering documents are updated, project repos pull from upstream. Standards stay current without manual copying.
The origin remote is how your work gets to the project repo — commits pushed there are accessible to the team, reviewable, and deployable. The upstream remote is the connection back to the ProductHarness Template.
Here's why that connection matters over time: steering documents evolve. The org refines its technical standards, updates its templates, adds new node definitions, or pulls improvements from the ProductHarness source. Without the upstream remote, those updates would need to be manually copied into every active project repo — fragmented, error-prone, and easy to forget. With the upstream remote, each project repo can pull the latest standards with a single command.
This is also how governance changes propagate intentionally. When a standard is updated — say, the authentication pattern changes after an org-wide security review — the ProductHarness Template is updated once, and active project repos pull it deliberately. No informal communication. No hoping everyone got the memo. The update travels through the same version-controlled channel as everything else.
What to Do After Setup
The harness doesn't prescribe what to work on first — that depends on where your project actually is. But a few starting points are common:
The standards files in steering/standards/ ship as blank templates. Filling them in is the highest-leverage first task — every generated output from that point forward draws on the decisions you encode there. Start with the standards most relevant to your current work.
The docs/work/<feature>/00-overview.md file establishes the feature-level context the agent draws on across all subsequent work. Even a rough first draft — problem statement, goals, key stakeholders, open questions — gives the agent the context it needs to be useful from the first prompt.
With the harness in place, ask the agent to help you draft a discovery document from a template, review acceptance criteria for gaps, or generate test cases from a requirement. The first session reveals what's working and what still needs configuration — that feedback is how the setup gets refined.