setup

Initialize Beat configuration in the current project.

<decision_boundary>

Use for:

• Setting up Beat for the first time in a project
• Updating existing Beat configuration (language, testing frameworks, rules)
• Detecting project tech stack and recommending test frameworks

NOT for:

• Editing beat/config.yaml directly (just edit the file)
• Configuring non-Beat tools or project settings
• Creating changes or writing feature files (use /beat:design)

Trigger examples:

• "Set up Beat" / "Initialize Beat" / "Configure Beat for this project" / "Update Beat config"
• Should NOT trigger: "edit config.yaml" / "design a feature" / "create a change"

</decision_boundary>

Input: None required. The skill gathers information interactively.

Steps

1. Check if config already exists

   Check if beat/config.yaml exists.

   • If yes: read it, show current config, ask if user wants to update or keep it
   • If no: proceed to creation

2. Check superpowers dependency

   Check if the superpowers plugin is available by looking for any superpowers:* skill in the skill list.

   If not available:

   "Beat works standalone, but is better with superpowers — it provides structured brainstorming, TDD discipline, task decomposition, and git worktree isolation.

   Install with: /plugin marketplace add obra/superpowers

   Without it, Beat falls back to simpler built-in flows."

   Use AskUserQuestion tool:

   1. "Install now" -- run the install command
   2. "Continue without it"

   If available: proceed silently.

3. Ask artifact language

   Use AskUserQuestion tool:

   "What language should Beat use for artifacts (proposals, features, designs, tasks)?"

   Provide options:

   1. "English (en)" -- default
   2. "繁體中文 (zh-TW)"
   3. "简体中文 (zh-CN)"
   4. Other -- let user specify a BCP 47 tag

   This sets the language field in config.

4. Gather project context and detect tech stack

   Use AskUserQuestion tool to ask:

   "Describe your project so Beat can tailor its artifacts. Include: tech stack, test framework, and any key conventions."

   Provide example options:

   1. "Let me describe it" -- open-ended input
   2. "Detect from codebase" -- agent scans package.json, Cargo.toml, go.mod, etc.

   If user chooses detection:

   • Scan common manifest files for tech stack and primary language
   • Look for test configuration (vitest.config, jest.config, pytest.ini, etc.)
   • Look for BDD runner configuration (cucumber.js, behave.ini, etc.)
   • Look for e2e configuration (playwright.config, cypress.config, etc.)
   • Check for linter/formatter configs
   • Summarize findings and confirm with user

   Record the detected/described tech stack — this informs Step 5 framework recommendations.

5. Configure test frameworks

   Based on the tech stack from Step 4, recommend appropriate frameworks.

   Step 5a: Ask project type

   Use AskUserQuestion tool:

   "What type of project is this?"

   1. "Web app (has UI)" -- needs browser automation for e2e
   2. "API server" -- needs HTTP client for e2e
   3. "CLI tool" -- needs process execution for e2e
   4. "Library / SDK" -- e2e usually not needed, behavior tests suffice

   Step 5b: Recommend frameworks using the table below

   Cross-reference (language × project type) to recommend a framework pair. Present as defaults the user can accept or customize:

   "Based on your stack ({language} + {project type}), recommended test frameworks:

   • Behavior tests: {recommendation}
   • E2E tests: {recommendation}

   Accept defaults or customize?"

   Framework recommendation table:

   Behavior test frameworks (UT / integration):

   Language	Primary	Alternative
   TypeScript / JavaScript	vitest	jest
   Python	pytest	pytest-bdd
   Go	go test	—
   Java	JUnit	TestNG
   C#	xUnit	NUnit
   Ruby	RSpec	—
   Rust	cargo test	—