# SpecRow Agent Install Instructions

Use this file when the user asks an agent to apply SpecRow from:

```txt
apply https://raw.githubusercontent.com/nektobit/SpecRow/refs/heads/main/install language=<language-code>
```

Follow these steps in the current project root.

## 1. Determine the working language

Determine the working language before initializing SpecRow.

Priority:

1. Use the explicit `language=<language-code>` argument from the apply command.
2. If `.specrow/config.yml` already exists, read its `language` field.
3. If neither source is available, ask the user which working language to use.

Ask the language question in the user's current conversation language.

Once the language is determined, use it for all replies, status updates, questions, final installation reports, and SpecRow files created or revised during this flow.

Do not silently choose English for a new project when the language is ambiguous.

Next step: check whether the `specrow` MCP server is available.

## 2. Require MCP

Before changing the workspace, check whether the current agent already has an MCP server named `specrow` available.

Use only the `specrow` MCP server for this install flow:

- `specrow_project_status`
- `specrow_init`
- `specrow_validate`
- `specrow_integration_status`
- other `specrow_*` tools for proposal, review, build, revise, accept, archive, status, context, and template workflows

If the `specrow` MCP server is unavailable, cannot be registered, fails, points at a different workspace, or does not create the expected files, stop the install process and report the exact blocker to the user.

Do not run shell-based SpecRow project commands to continue this install flow.

Next step: verify the MCP server configuration.

## 3. Verify MCP server configuration

If manual MCP configuration is required, register SpecRow in the actual MCP configuration used by the current agent, editor, or MCP host. Do not assume that a global CLI config file is used by every host.

Use a server named `specrow`.

Recommended npm-based server configuration:

```txt
server name: specrow
command: npx
args: -y specrow@latest mcp
```

For Windows hosts that do not resolve `npx` from PATH, use the explicit Node.js command wrapper:

```txt
server name: specrow
command: C:\Program Files\nodejs\npx.cmd
args: -y specrow@latest mcp
```

If the host is configured to use a globally installed SpecRow binary instead, `command: specrow-mcp` with no project path is also valid.

For TOML-based MCP configuration, the equivalent workspace-aware entry is:

```toml
[mcp_servers.specrow]
command = "npx"
args = ["-y", "specrow@latest", "mcp"]
```

Do not pass a project path by default. Without an explicit path, SpecRow MCP uses the current working directory provided by the agent/editor as `projectRoot`, which keeps the configuration reusable across projects.

Do not write an MCP entry like this unless the user explicitly wants this MCP server locked to one project:

```toml
args = ["-y", "specrow@latest", "mcp", "/path/to/one/project"]
```

If the current agent session still sees an old MCP server after configuration changes, stop the install and tell the user to restart or reload the agent/editor MCP session before expecting MCP tools to use the new workspace.

Verify success through MCP `tools/list`. The server should expose `specrow_project_status`, `specrow_init`, `specrow_validate`, and other `specrow_*` tools. Do not use MCP resources as the success criterion; resources may be empty or irrelevant for this workflow.

Next step: inspect the current project with MCP.

## 4. Inspect the workspace

Use MCP:

```txt
specrow_project_status
```

Check the returned fields:

- `projectRoot`
- `initialized`
- `absoluteConfigPath`
- `absoluteProjectPath`
- `language`, when present

If `projectRoot` does not match the current shell workspace, stop immediately and report that MCP is pointed at the wrong workspace.

If `initialized` is `true`, do not reinitialize the workspace unless the user explicitly asks to change the configuration.

If `initialized` is `false`, initialize the workspace with the determined language.

Next step:

- Existing project: run `specrow_validate`.
- New project: run `specrow_init`.

## 5. Initialize a new workspace

Use MCP:

```txt
specrow_init
```

Pass the language explicitly:

```json
{ "language": "<language-code>" }
```

After `specrow_init`, verify:

1. The MCP result includes `projectRoot`.
2. The MCP result includes `absoluteConfigPath` and `absoluteProjectPath`.
3. `.specrow/config.yml` exists in the current shell workspace.
4. `.specrow/project.md` exists in the current shell workspace.

If any check fails, stop immediately and report whether MCP pointed at the wrong workspace or failed to create files.

Next step: run `specrow_validate`.

## 6. Validate and report

Use MCP:

```txt
specrow_validate
specrow_integration_status
```

If either MCP validation or MCP integration status fails, stop and report the MCP error.

Tell the user:

- which `projectRoot` MCP used;
- which language is configured;
- whether the workspace was initialized or already existed;
- whether validation passed;
- which integration files MCP reported;
- the next logical SpecRow step.

For a successfully installed workspace, the next logical step is usually `specrow proposal` to describe the first intended change.

Do not implement project code as part of this install flow unless the user separately asks for a SpecRow change workflow such as `specrow proposal` or `specrow build`.
