agentleFS
MicrosoftKnown publishermicrosoft/sqlsimtools/.github/skills/sqlsimtools-build/SKILL.md

sqlsimtools-build

Skill42 starsChanged 32 days agoMITView on GitHub

Build and test sqlsimtools from source. USE WHEN: cloning the repository, setting up a development environment, compiling sqlsim, preparing sqlpysim, building sqlsim Studio, running smoke tests or the full test suite, checking prerequisites, or diagnosing a build or test failure on Windows or Linux. DO NOT USE FOR: running SQL workloads with the released tools (use the sqlsim or sqlpysim skills), or cutting a release (use the sqlsimtools-release skill).

  • Installs packages

The file

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 4 are distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Run its smoke test.

    line 16
  2. Distinctive:

    Run its full test suite if behavior changed.

    line 17
  3. Very specific:

    All tools need Microsoft ODBC Driver 18 to reach a live SQL target.

    line 30
  4. Very specific:

    Never edit plugins/<tool>/skills/ directly.

    line 169
  5. Very specific:

    Use each tool's own scripts.

    line 173
  6. Very specific:

    Never append 2>&1, > file, or | Select-String to a tool invocation.

    line 175
  7. Very specific:

    Keep credentials out of process arguments.

    line 178
  8. Distinctive:

    Do not scale thread counts against a shared or production SQL instance.

    line 180
  9. Distinctive:

    Treat a failing test as a real defect until proven otherwise.

    line 181

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Build and test sqlsimtools

Developer skill for working with this repository's source. Each tool builds and tests independently and owns its own scripts. Always run a tool's scripts from that tool's directory.

Order of operations

  1. Check prerequisites.
  2. Build the tool.
  3. Run its smoke test.
  4. Run its full test suite if behavior changed.

Studio depends on step 2 for sqlsim: its build copies the compiled binary out of sqlsim/build/<arch>/Release/. Build sqlsim before building Studio.

Prerequisites

ToolWindowsLinux
sqlsim.\check-prerequisites.ps1bash ./check-prerequisites-linux.sh --require-driver
sqlpysimpython --version (3.10+), then python -c "import mssql_python" after installing requirementsVerify Python 3.10+, install mssql-python, then use the native Bash suites below
Studio.NET 10 SDK.NET 10 SDK

All tools need Microsoft ODBC Driver 18 to reach a live SQL target. sqlsim also needs CMake 3.15+ and a C++17 toolchain: Visual Studio 2022 or 2026 Build Tools on Windows, build-essential and unixodbc-dev on Ubuntu.

Build

# sqlsim, Windows. Default builds x64 and ARM64.
cd sqlsim
.\build.ps1 -Clean -Architecture x64

# sqlsim Studio, Windows. Requires sqlsim built first.
cd sqlsimstudio
.\build.ps1 -Runtime win-x64
# sqlsim, Ubuntu 24.04 or 26.04 LTS x64
cd sqlsim
bash ./build-linux.sh --clean

# sqlsim Studio, Linux
cd sqlsimstudio
bash ./build-linux.sh linux-x64

sqlpysim has no build step:

cd sqlpysim
python -m pip install -r requirements.txt

Build outputs:

ToolWindowsLinux
sqlsimbuild/x64/Release/sqlsim.exe, build/ARM64/Release/sqlsim.exebuild/linux-x64/sqlsim
Studiobuild/win-x64/sqlsimstudio.exebuild/linux-x64/sqlsimstudio

Install a source build into a project

To install sqlsim (and optionally sqlpysim) with its manual, examples, skill, and Workload Builder into another project, use the wrapper from the repository root rather than copying files:

.\scripts\install-local.ps1 -Workspace C:\myproject -Build
.\scripts\install-local.ps1 -Workspace C:\myproject -Tool sqlsim, sqlpysim -Preview

It checks prerequisites, builds, installs, validates offline, and prints a receipt. It never deletes project files and stops before writing if a file it installs already differs; re-run with -Force only after the user agrees to replace those files. On Ubuntu use bash sqlsim/publish-linux.sh --skip-build --release-dir <project>, which accepts --preview and --force. Re-check an installed project with release\validate-package-layout.ps1.

Test

Smoke tests are fast and validate core behavior. The full suites are the gate for any behavior or CLI change.

cd sqlsim
.\smoke-test.ps1 -SkipBuild
.\full-test-suite.ps1 -SkipBuild
cd sqlsim
bash ./smoke-test-linux.sh
bash ./full-test-suite-linux.sh

Shared parameters for sqlsim smoke-test.ps1 and full-test-suite.ps1: -Server, -Database, -UseToken, -Username, -Password, -SkipBuild, -Verbose, -OutputFile. full-test-suite.ps1 also accepts -SkipScale to skip the 1024-thread test on constrained targets.

sqlpysim Windows tests use smoke-test.ps1 and full-test-suite.ps1. Native Linux/WSL Bash suites are supported for both tools, so PowerShell is not required. They take the target as options and work from any Linux VM, container, or WSL distribution that can reach the server over TCP:

cd sqlpysim   # or sqlsim
bash ./smoke-test-linux.sh --server HOST --database DB \
  --username USER --password-file FILE
bash ./full-test-suite-linux.sh --server HOST --database DB \
  --username USER --password-file FILE

For token authentication, use --token-file FILE instead of the username and password options. Secret files are read from their first line, and a Windows CRLF ending is ignored. Every suite, PowerShell and Bash, hands the token or password to the engine on stdin (-T -, -P -), so it never appears in a process list. When adding a test, build its arguments from the suite's auth array and launch the engine through the suite's launcher ($runSqlsim, $runSqlPySim, or with_secret) so this stays true. All four suites support --list-tests and --help. The sqlpysim suites also take --python and --skip-install. The sqlsim full suite takes --sqlsim, --skip-scale, and --stop-on-error, and needs jq. A WSL distribution in NAT mode cannot reach SQL Server on the Windows host via localhost; target a reachable server name or address instead.

Studio smoke-test.ps1 takes -SkipBuild, -StartupOnly, -StudioExecutable, and -QueryStoreDatabase. -StartupOnly is what CI uses to verify a packaged build starts without touching SQL Server. Interactive GUI coverage is manual and tracked in sqlsimstudio/MANUAL-TEST.md.

Azure SQL targets are auto-detected by server name. Prefer -UseToken over interactive authentication so runs stay non-interactive:

$token = az account get-access-token --resource https://database.windows.net --query accessToken -o tsv
.\full-test-suite.ps1 -SkipBuild -Server myserver.database.windows.net -Database mydb -UseToken $token

Suite parity

The PowerShell and native Bash suites are deliberate parity counterparts for sqlsim and sqlpysim, so Linux and WSL users do not need PowerShell for the supported test suites. Adding or changing a test in only one counterpart is a defect. Check with:

./scripts/check-suite-parity.ps1

Plugin packages

Canonical skills live under .github/skills/. Plugin copies are generated.

./scripts/sync-plugins.ps1      # after editing a canonical skill
./scripts/validate-plugins.ps1  # gate; also runs in CI

Never edit plugins/<tool>/skills/ directly.

Rules

  1. Use each tool's own scripts. Do not call cmake, msbuild, or dotnet publish directly.
  2. Never append 2>&1, > file, or | Select-String to a tool invocation. Capture into a variable instead, or use the script's -OutputFile.
  3. Supply exactly one authentication mode. Nothing defaults.
  4. Keep credentials out of process arguments. Use -P - or -T - with redirected stdin where a script supports it.
  5. Do not scale thread counts against a shared or production SQL instance.
  6. Treat a failing test as a real defect until proven otherwise. Do not skip or disable tests to get a green run.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.