Default development workflow

Speedwave ships a set of engineering skills with the speedwave- prefix that give a session structure when you want it. A quick fix still works as a plain request. For larger work, you start a flow by typing its skill in the chat or the CLI; nothing runs on its own at session start. The full list is in Built-in skills and plugins, and /speedwave-ask recommends a flow for your situation.

Before the first flow

Run /speedwave-setup once per repository. It asks where your tickets live: GitHub, GitLab, Jira or Redmine through the enabled integration, or local markdown files under .speedwave/scratch/. It also records the triage labels and where the project glossary (SPEEDWAVE.md) and decision records (docs/adr/) are kept.

From idea to reviewed code

1. Sharpen the idea. /speedwave-grill-with-docs interviews you about the plan until the open questions are settled, and records agreed terms in SPEEDWAVE.md and hard-to-reverse decisions as ADRs. If a question needs running code to answer, /speedwave-prototype builds a throwaway prototype first.

2. Write the spec and tickets. For work that spans several sessions, /speedwave-to-spec turns the conversation into a spec and /speedwave-to-tickets splits it into small tickets, each naming the tickets that block it. On Redmine the blocking becomes native issue relations; on the other trackers it is a Blocked by: line.

3. Implement. /speedwave-implement builds one ticket at a time, test-first through /speedwave-tdd: a failing test, the smallest code that passes it, then the next slice. It commits to the current branch. Clear the context between tickets, since each ticket carries everything the next session needs.

4. Review. When a ticket is done, Claude asks you to run /speedwave-code-review, which checks the changes with fourteen review agents in parallel (see AI-assisted code review). Merging stays your decision.

Small work skips step 2: /speedwave-implement can run in the same session right after the interview.

Other starting points

• Incoming issues: /speedwave-triage moves bug reports and requests you did not write through triage roles and turns them into tickets ready for an agent.
• Something is broken: /speedwave-diagnosing-bugs first builds a command that reproduces the bug, then fixes it with a regression test.
• A project too big for one session: /speedwave-wayfinder maps the open decisions as tickets on your tracker and resolves them one by one before handing off to /speedwave-to-spec.

Keeping context under control

Keep the interview, spec and tickets in one context window so each step builds on the same reasoning. /speedwave-handoff writes a summary file to .speedwave/handoffs/ when work moves to another directory or colleague.

Relationship to planning integrations

Tickets and triage go through the same integration workers as any other tool call, so they respect the credentials and project scopes described in Planning and user stories.

Customization

A team can replace any of these skills by committing a skill with the same name under .claude/skills/ in the repository; project files take precedence over the bundled ones.