{"owner":"spinframework","repo":"spin","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# Repository Guidelines\n\n## Project Structure & Module Organization\n\nSpin is a Rust workspace for the `spin` CLI and supporting crates. The `spin` binary is `src/bin/spin.rs`; shared CLI modules live in `src/`. Reusable implementation is split across `crates/*` with names such as `spin-trigger-http`, `spin-factor-key-value`, and `spin-templates`. Tests live in `tests/`: `tests/runtime-tests` validates runtime behavior, `tests/test-components` provides WebAssembly components, and `tests/testing-framework` contains shared helpers. Examples are in `examples/`, docs in `docs/`, templates in `templates/`, and WIT interfaces in `wit/`.\n\n## Build, Test, and Development Commands\n\n- `make build`: builds the release binary with `cargo build --release`; run this before opening PRs that change dependencies, features, or production imports because it does not rely on dev/test dependencies.\n- `make install`: installs the local CLI with `cargo install --path . --locked`.\n- `cargo run --bin spin -- --help`: runs the development CLI from source.\n- `make lint`: runs workspace `clippy -D warnings` and checks `rustfmt`.\n- `make test`: runs lint, unit tests, and integration tests.\n- `make test-unit`: runs workspace unit tests, excluding integration/runtime suites.\n- `make test-crate crate=spin-key-value-azure`: runs tests for one crate.\n- `make test-integration`: runs runtime and integration tests without heavy external dependencies.\n- `make test-integration-full`: includes Docker or extra toolchain tests.\n\n## Coding Style & Naming Conventions\n\nUse Rust 2024 with the minimum Rust version in `Cargo.toml`. Format with `cargo fmt --all`; do not hand-format around rustfmt. Keep `clippy` clean under `make lint`. Use `snake_case` for modules, functions, variables, and tests; `PascalCase` for types and traits; and `SCREAMING_SNAKE_CASE` for constants. New workspace crates should follow the `spin-*` pattern in `crates/`.\n\n## Testing Guidelines\n\nPrefer focused crate tests during development, then run `make test-unit`, `make build`, and the relevant integration target before opening a PR. Use `make build` specifically to catch production build issues that may be hidden when dev dependencies, tests, or `--all-targets` accidentally enable missing dependency features. Put crate-local tests near the code or in that crate's `tests/` directory. Add runtime scenarios under `tests/runtime-tests/tests` when validating Spin manifests and compliant WebAssembly components. Integration tests cover multi-subsystem CLI behavior and belong under `tests/`.\n\n## Commit & Pull Request Guidelines\n\nRecent history uses imperative commit subjects such as `Remove unnecessary module` or `Allow config for how low we await connection semaphore`; scoped conventional subjects appear in automation, for example `chore(rust-sdk-release): ...`. Keep commits focused and explain user-visible changes in the PR body. PRs should link related issues, describe test coverage, note new dependencies or services, and include screenshots only for UI or documentation rendering changes.\n\n## Security & Configuration Tips\n\nDo not commit credentials, certificates, or service-specific secrets. Keep generated TLS files, local runtime config, and dependency-heavy test setup out of commits unless intentionally part of a checked-in fixture.\n"},"files":{"AGENTS.md":"# Repository Guidelines\n\n## Project Structure & Module Organization\n\nSpin is a Rust workspace for the `spin` CLI and supporting crates. The `spin` binary is `src/bin/spin.rs`; shared CLI modules live in `src/`. Reusable implementation is split across `crates/*` with names such as `spin-trigger-http`, `spin-factor-key-value`, and `spin-templates`. Tests live in `tests/`: `tests/runtime-tests` validates runtime behavior, `tests/test-components` provides WebAssembly components, and `tests/testing-framework` contains shared helpers. Examples are in `examples/`, docs in `docs/`, templates in `templates/`, and WIT interfaces in `wit/`.\n\n## Build, Test, and Development Commands\n\n- `make build`: builds the release binary with `cargo build --release`; run this before opening PRs that change dependencies, features, or production imports because it does not rely on dev/test dependencies.\n- `make install`: installs the local CLI with `cargo install --path . --locked`.\n- `cargo run --bin spin -- --help`: runs the development CLI from source.\n- `make lint`: runs workspace `clippy -D warnings` and checks `rustfmt`.\n- `make test`: runs lint, unit tests, and integration tests.\n- `make test-unit`: runs workspace unit tests, excluding integration/runtime suites.\n- `make test-crate crate=spin-key-value-azure`: runs tests for one crate.\n- `make test-integration`: runs runtime and integration tests without heavy external dependencies.\n- `make test-integration-full`: includes Docker or extra toolchain tests.\n\n## Coding Style & Naming Conventions\n\nUse Rust 2024 with the minimum Rust version in `Cargo.toml`. Format with `cargo fmt --all`; do not hand-format around rustfmt. Keep `clippy` clean under `make lint`. Use `snake_case` for modules, functions, variables, and tests; `PascalCase` for types and traits; and `SCREAMING_SNAKE_CASE` for constants. New workspace crates should follow the `spin-*` pattern in `crates/`.\n\n## Testing Guidelines\n\nPrefer focused crate tests during development, then run `make test-unit`, `make build`, and the relevant integration target before opening a PR. Use `make build` specifically to catch production build issues that may be hidden when dev dependencies, tests, or `--all-targets` accidentally enable missing dependency features. Put crate-local tests near the code or in that crate's `tests/` directory. Add runtime scenarios under `tests/runtime-tests/tests` when validating Spin manifests and compliant WebAssembly components. Integration tests cover multi-subsystem CLI behavior and belong under `tests/`.\n\n## Commit & Pull Request Guidelines\n\nRecent history uses imperative commit subjects such as `Remove unnecessary module` or `Allow config for how low we await connection semaphore`; scoped conventional subjects appear in automation, for example `chore(rust-sdk-release): ...`. Keep commits focused and explain user-visible changes in the PR body. PRs should link related issues, describe test coverage, note new dependencies or services, and include screenshots only for UI or documentation rendering changes.\n\n## Security & Configuration Tips\n\nDo not commit credentials, certificates, or service-specific secrets. Keep generated TLS files, local runtime config, and dependency-heavy test setup out of commits unless intentionally part of a checked-in fixture.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# Repository Guidelines\n\n## Project Structure & Module Organization\n\nSpin is a Rust workspace for the `spin` CLI and supporting crates. The `spin` binary is `src/bin/spin.rs`; shared CLI modules live in `src/`. Reusable implementation is split across `crates/*` with names such as `spin-trigger-http`, `spin-factor-key-value`, and `spin-templates`. Tests live in `tests/`: `tests/runtime-tests` validates runtime behavior, `tests/test-components` provides WebAssembly components, and `tests/testing-framework` contains shared helpers. Examples are in `examples/`, docs in `docs/`, templates in `templates/`, and WIT interfaces in `wit/`.\n\n## Build, Test, and Development Commands\n\n- `make build`: builds the release binary with `cargo build --release`; run this before opening PRs that change dependencies, features, or production imports because it does not rely on dev/test dependencies.\n- `make install`: installs the local CLI with `cargo install --path . --locked`.\n- `cargo run --bin spin -- --help`: runs the development CLI from source.\n- `make lint`: runs workspace `clippy -D warnings` and checks `rustfmt`.\n- `make test`: runs lint, unit tests, and integration tests.\n- `make test-unit`: runs workspace unit tests, excluding integration/runtime suites.\n- `make test-crate crate=spin-key-value-azure`: runs tests for one crate.\n- `make test-integration`: runs runtime and integration tests without heavy external dependencies.\n- `make test-integration-full`: includes Docker or extra toolchain tests.\n\n## Coding Style & Naming Conventions\n\nUse Rust 2024 with the minimum Rust version in `Cargo.toml`. Format with `cargo fmt --all`; do not hand-format around rustfmt. Keep `clippy` clean under `make lint`. Use `snake_case` for modules, functions, variables, and tests; `PascalCase` for types and traits; and `SCREAMING_SNAKE_CASE` for constants. New workspace crates should follow the `spin-*` pattern in `crates/`.\n\n## Testing Guidelines\n\nPrefer focused crate tests during development, then run `make test-unit`, `make build`, and the relevant integration target before opening a PR. Use `make build` specifically to catch production build issues that may be hidden when dev dependencies, tests, or `--all-targets` accidentally enable missing dependency features. Put crate-local tests near the code or in that crate's `tests/` directory. Add runtime scenarios under `tests/runtime-tests/tests` when validating Spin manifests and compliant WebAssembly components. Integration tests cover multi-subsystem CLI behavior and belong under `tests/`.\n\n## Commit & Pull Request Guidelines\n\nRecent history uses imperative commit subjects such as `Remove unnecessary module` or `Allow config for how low we await connection semaphore`; scoped conventional subjects appear in automation, for example `chore(rust-sdk-release): ...`. Keep commits focused and explain user-visible changes in the PR body. PRs should link related issues, describe test coverage, note new dependencies or services, and include screenshots only for UI or documentation rendering changes.\n\n## Security & Configuration Tips\n\nDo not commit credentials, certificates, or service-specific secrets. Keep generated TLS files, local runtime config, and dependency-heavy test setup out of commits unless intentionally part of a checked-in fixture.\n","category":"root","tokens":829}]}