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
In this repository15 other files it gives its agents.
- sqlpysim/AGENTS.mdAGENTS.md
- sqlsim/AGENTS.mdAGENTS.md
- .github/copilot-instructions.mdCopilot instructions
- sqlpysim/.github/copilot-instructions.mdCopilot instructions
- sqlsim/.github/copilot-instructions.mdCopilot instructions
- docs/llms.txtllms.txt
- sqlpysimSkill
- sqlsimSkill
- sqlsimstudio-load-testSkill
- sqlsimstudio-manual-testSkill
- sqlsimstudioSkill
- sqlsimtools-project-statsSkill
- sqlsimtools-releaseSkill
- sqlpysimSkill
- sqlsimSkill
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
- Distinctive: line 16
Run its smoke test.
- Distinctive: line 17
Run its full test suite if behavior changed.
- Very specific: line 30
All tools need Microsoft ODBC Driver 18 to reach a live SQL target.
- Very specific: line 169
Never edit plugins/<tool>/skills/ directly.
- Very specific: line 173
Use each tool's own scripts.
- Very specific: line 175
Never append 2>&1, > file, or | Select-String to a tool invocation.
- Very specific: line 178
Keep credentials out of process arguments.
- Distinctive: line 180
Do not scale thread counts against a shared or production SQL instance.
- Distinctive: line 181
Treat a failing test as a real defect until proven otherwise.
≈ “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.
Files
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
- Check prerequisites.
- Build the tool.
- Run its smoke test.
- 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
| Tool | Windows | Linux |
| sqlsim | .\check-prerequisites.ps1 | bash ./check-prerequisites-linux.sh --require-driver |
| sqlpysim | python --version (3.10+), then python -c "import mssql_python" after installing requirements | Verify 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-x64sqlpysim has no build step:
cd sqlpysim
python -m pip install -r requirements.txtBuild outputs:
| Tool | Windows | Linux |
| sqlsim | build/x64/Release/sqlsim.exe, build/ARM64/Release/sqlsim.exe | build/linux-x64/sqlsim |
| Studio | build/win-x64/sqlsimstudio.exe | build/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 -PreviewIt 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 -SkipBuildcd sqlsim
bash ./smoke-test-linux.sh
bash ./full-test-suite-linux.shShared 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 FILEFor 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 $tokenSuite 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.ps1Plugin 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 CINever edit plugins/<tool>/skills/ directly.
Rules
- Use each tool's own scripts. Do not call
cmake,msbuild, ordotnet publishdirectly. - Never append
2>&1,> file, or| Select-Stringto a tool invocation. Capture into a variable instead, or use the script's-OutputFile. - Supply exactly one authentication mode. Nothing defaults.
- Keep credentials out of process arguments. Use
-P -or-T -with redirected stdin where a script supports it. - Do not scale thread counts against a shared or production SQL instance.
- Treat a failing test as a real defect until proven otherwise. Do not skip or disable tests to get a green run.
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
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.

