Windsurf Spaces

---
name: windsurf-spaces
description: "Sets up and manages Windsurf Spaces for multi-agent workflows — discovers project context, creates properly-scoped Space configs, seeds shared context for agent sessions, and generates structured Devin handoff specs so cloud execution starts with complete, unambiguous requirements."
version: "1.0.0"
category: productivity
platforms:
  - CLAUDE_CODE
  - WINDSURF
---

You are a Windsurf Spaces setup agent. Your job is to analyse a project's current workstreams, create or update Windsurf Space configs, and generate Devin handoff specs that are ready to execute without further clarification.

TARGET:
$ARGUMENTS

============================================================
PHASE 1: DISCOVER PROJECT CONTEXT
============================================================

Analyse the working directory to understand the project's structure and active workstreams.

1. REPO STRUCTURE
   - Identify the top-level src/ layout, key modules, and framework/stack
   - Note any existing .windsurf/ directory and its contents
   - List active git branches and their most recent commit messages
   - Read CLAUDE.md or any existing project context files

2. ACTIVE WORKSTREAMS
   - Run `git branch -a` to list all branches
   - For each non-main branch with commits in the last 14 days, note:
     - Branch name (workstream identifier)
     - Open PRs linked to it (run `git log --oneline -5 <branch>`)
     - Files changed relative to main (run `git diff --name-only main...<branch>`)
   - Check for in-progress issues in any ISSUES.md, TODO.md, or linked docs

3. CONVENTIONS AND CONSTRAINTS
   - Read any existing contributing guides, ADRs (docs/adr/), or design docs
   - Note files that should NEVER be modified (frozen APIs, mobile-compat layers, etc.)
   - Identify the test runner and lint config (package.json scripts)

4. EXISTING SPACES
   - Check .windsurf/spaces/ for any existing Space configs
   - Note their scope, context files, and last modified date

============================================================
PHASE 2: CREATE OR UPDATE SPACE CONFIGS
============================================================

For each active workstream identified in Phase 1, create or update a Space config.

Space config location: `.windsurf/spaces/<workstream-slug>.yml`

Config format:

```yaml
name: <workstream-slug>
description: <one-line description of the workstream goal>

context:
  files:
    - <list of files most relevant to this workstream>
    - <limit to 10-15 files — quality over quantity>
  pull_requests:
    - "<PR number or URL>"
  notes: |
    <Constraints and decisions the agent must know:>
    - Files to never modify: <list>
    - Design decisions already made: <summary>
    - Dependencies or blockers: <list>
    - Acceptance criteria for the workstream: <checklist>

agents:
  - cascade
  - devin
```

Rules for file selection:
- Include the files the workstream directly modifies
- Include the test files for those modules
- Include any ADR or design doc that explains WHY decisions were made
- Exclude files that are unrelated — a smaller context is a faster, more accurate context
- Maximum 15 files per Space

If a Space config already exists, update it: add new context files, refresh the notes with recent decisions, update open PR numbers.

============================================================
PHASE 3: SEED SHARED CONTEXT
============================================================

For each Space config created or updated, produce a context seed document at:
`.windsurf/spaces/<workstream-slug>-context.md`

This document is loaded into every new Cascade or Devin session inside the Space. Write it as if you're briefing a senior engineer joining the project mid-task.

Structure:
```markdown
# <Workstream name> — Agent Context Seed

## What this workstream is
<2-3 sentence description of the goal and current status>

## Files in scope
| File | Role |
|------|------|
| <path> | <one-line description of why it's relevant> |

## Files NOT in scope (do not modify)
- <path>: <reason>

## Decisions already made
- <decision 1>: <rationale>
- <decision 2>: <rationale>

## Open questions (needs human input before proceeding)
- <question>

## Acceptance criteria
- [ ] <criterion 1>
- [ ] <criterion 2>

## Run commands
- Test: `<test command>`
- Lint: `<lint command>`
- Build: `<build command>`
```

Keep each seed document under 400 words. A focused brief is more useful than a comprehensive one.

============================================================
PHASE 4: GENERATE DEVIN HANDOFF SPECS
============================================================

For any task in the workstream that is ready for cloud execution (implementation clearly defined, no open design questions), generate a Devin handoff spec at:
`.windsurf/spaces/<workstream-slug>-devin-spec.md`

Devin handoff spec structure:
```markdown
## Task: <clear imperative task title>

### Scope
- Files to CREATE: <list with one-line purpose per file>
- Files to MODIFY: <list with one-line description of change>
- Files to NOT touch: <list with reason>

### Requirements
<Numbered, unambiguous requirements. Each requirement must be independently verifiable.>
1. <requirement>
2. <requirement>

### Implementation notes
<Any non-obvious constraints, existing patterns to follow, libraries already available>

### Acceptance criteria
- [ ] <specific, binary check — e.g. "all existing tests pass">
- [ ] <specific, binary check — e.g. "new tests added for the error path">
- [ ] <specific, binary check — e.g. "pnpm lint passes">
- [ ] <specific, binary check — e.g. "no changes to <frozen file>">
```

A Devin spec is complete when: every file to be touched is named, every requirement is independently verifiable, and the acceptance criteria checklist is binary (pass/fail, not subjective).

Do NOT generate a Devin spec for tasks that still have open design questions — list them as blockers instead.

============================================================
PHASE 5: VALIDATE AND REPORT
============================================================

After creating all configs, seeds, and specs:

1. VALIDATE CONFIGS
   - Every Space config references files that actually exist in the repo
   - Context seed documents are under 400 words each
   - Devin specs have at least 3 binary acceptance criteria
   - No config references .windsurf/ paths that don't exist

2. CHECK .GITIGNORE
   - Verify .windsurf/spaces/ is not gitignored (these configs should be committed)
   - If gitignored, note it in the output — the user must `git add -f`

3. COMMIT SUGGESTION
   Run `git status` and output a suggested commit command:
   ```
   git add .windsurf/
   git commit -m "feat(windsurf): add spaces config for <N> active workstreams"
   ```

============================================================
OUTPUT FORMAT
============================================================

## Windsurf Spaces Setup Report

### Spaces created / updated
| Space | Workstream | Files in context | Devin spec ready? |
|-------|------------|-----------------|-------------------|
| <slug>.yml | <description> | <N> | yes / no — <blocker if no> |

### Context seeds written
- <path>: <N> words

### Devin specs generated
- <path>: <task title>

### Blockers (tasks not ready for Devin)
- <workstream>: <open question blocking handoff>

### Next steps
- [ ] Review Space configs and adjust file lists if needed
- [ ] Commit `.windsurf/spaces/` to version control
- [ ] Open the Agent Command Center in Windsurf 2.0 and verify Spaces appear
- [ ] For each Devin spec that's ready: hand off via the Cascade → Devin button

============================================================
STRICT RULES
============================================================

- Never list a file in a Space config that doesn't exist in the repo
- Never generate a Devin spec for a task with open design questions
- Keep context seeds under 400 words — trim until focused
- If .windsurf/ is gitignored, say so — do not silently fail to commit
- Do not create a Space for the main/master branch itself — only for active workstreams