.agents/skills: Building a Repo for AI Contributors

---
name: rust-unit-tests
description: Write, improve, and run Rust unit tests in the warp Rust codebase.
---

# Rust Unit Tests in warp

## Scope
- This skill focuses on crate-level unit tests.
- Favor incremental, well-scoped tests that exercise a single function or behavior per case.

## Where unit tests live
- Put unit tests in separate files named `${filename}_tests.rs` or `mod_test.rs`.
- Include the test module at the end of the corresponding source file:

```rust
#[cfg(test)]
#[path = "filename_tests.rs"] // or "mod_test.rs"
mod tests;
```

The `/open-file` slash command handler does not expand `~` before resolving the file path. The argument is unescaped and then joined directly with the current working directory, so `~/foo.txt` becomes `/cwd/~/foo.txt`. The Cmd-O open file palette already handles this correctly by calling `shellexpand::tilde()`.

## Relevant code

- `app/src/terminal/input/slash_commands/mod.rs (445-450)` — The `/open-file` (`commands::EDIT`) handler that parses the path argument and resolves it. This is the code that needs to change.
- `app/src/search/command_palette/files/data_source.rs:196` — The Cmd-O palette's tilde expansion: `shellexpand::tilde(&query_file_content).into_owned()`. This is the pattern to follow.
- `crates/warp_util/src/path.rs (149-181)` — `CleanPathResult::with_line_and_column_number()`, which strips line/column suffixes from the path string. Called before path resolution.
- `app/src/terminal/input_test.rs (2553-2596)` — Existing test `test_open_slash_command_clears_buffer_on_success` that exercises the `/open-file` handler with a real file.

## Current state

The handler in `slash_commands/mod.rs` does this sequence:

1. Parses line/column suffix with `CleanPathResult::with_line_and_column_number(args.trim())`

---
name: integration-test-video
description: Run Warp integration tests with screenshot and video capture, including event overlay annotations for mouse and keyboard input. Use this whenever the user wants to record an integration test, collect screenshots from a test, review generated recording artifacts, or author a test that captures video for debugging or demos.
---

# Integration Test Video Recording

Use this skill when working with Warp's integration test recording pipeline on this branch.

The relevant implementation lives in:
- `integration/src/bin/integration.rs`
- `integration/src/test/video_recording.rs`
- `integration/tests/integration/ui_tests.rs`
- `ui/src/integration/driver.rs`
- `ui/src/integration/step.rs`
- `ui/src/integration/video_recorder.rs`
- `ui/src/integration/artifacts.rs`
- `ui/src/integration/overlay.rs`

  - Bug fixes skip both steps; they are implicitly `ready-to-implement` once triaged.
- **Review is largely automated.** When you open a PR, Oz is auto-assigned and produces an initial review. Once Oz approves, it automatically requests a follow-up review from a Warp team subject-matter expert — you do not need to assign human reviewers yourself.

### Readiness labels

The Warp team applies one of the following labels when an issue is ready for contribution:

- **`ready-to-spec`** — The problem is understood but the design is open. Open a spec PR with a *product spec* (`product.md`) and a *tech spec* (`tech.md`) under [`specs/`](specs/) — see [Opening a Spec PR](#opening-a-spec-pr) for what goes in each. This label is **reserved for feature requests**.
- **`ready-to-implement`** — The design is settled. Open a code PR. **All triaged bug reports are implicitly `ready-to-implement`** once accepted — you don't need to wait for an explicit label on a confirmed bug.
- **`needs-mocks`** — Design mocks are required before implementation can begin. Wait for the Warp team to land them.

Anyone can pick up a ready issue — readiness labels are not assignments, and the best implementation wins through normal review. If an issue has been sitting un-triaged or you'd like readiness re-evaluated, mention **@oss-maintainers** in a comment to flag it for the team.

## Requirements

### Frontmatter (Required)

Every SKILL.md must start with YAML frontmatter containing:

- **name**: Kebab-case identifier (lowercase letters, numbers, hyphens only)
  - Example: `add-feature-flag`, `rust-unit-tests`, `update-skill`
- **description**: Specific description of what the skill does and when to use it
  - Must be non-empty
  - Should include key terms for skill discovery
  - Begin with an action verb to clearly state what the skill accomplishes (e.g., "Adds feature flags..." instead of "Helps with features..."), and immediately follow with a specific use case or context (e.g., "Use when working with feature flags")
  - Write in third person (e.g., "Adds feature flags..." not "I can help you add...")

### Writing Effective Descriptions

The description field is critical for skill discovery. Include both **what** the skill does and **when** to use it. Some good examples: