Install
$ agentstack add skill-lugassawan-swe-workbench-language-sql ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
SQL
Query optimization basics
- Start with the access pattern: filters, joins, grouping, sorting, and result size.
- Index columns used for selective
WHERE, join keys, and stableORDER BYclauses. - Prefer narrow projections over
SELECT *; return only the columns callers need. - Avoid accidental row multiplication in joins; check cardinality before adding
DISTINCT. - Watch for N+1 query loops at application boundaries.
EXPLAIN and EXPLAIN ANALYZE
- Use
EXPLAINto inspect the planned access path before changing indexes or query shape. - Use
EXPLAIN ANALYZEwhen you need actual timing and row counts; run it against safe data and statements. - Compare estimated vs actual rows. Large gaps often mean stale statistics, skewed data, or missing predicates.
- Optimize the highest-cost operation first, but confirm the full query got faster.
Schema design
- Model durable facts, not current screens. Let queries influence indexes, not table names.
- Choose primary keys deliberately; use foreign keys for integrity unless there is a measured reason not to.
- Normalize to remove update anomalies, then denormalize only for proven read pressure.
- Encode invariants with constraints:
NOT NULL,UNIQUE,CHECK, and referential actions. - Plan migrations as expand-and-contract changes when existing clients need compatibility.
Transactions and isolation
- Keep transactions short; do not wait on users or remote services while holding locks.
- Pick the weakest isolation level that preserves correctness for the workflow.
- Know the anomalies you are allowing: dirty reads, non-repeatable reads, phantoms, and write skew.
- Use optimistic concurrency with version columns when conflicts are rare and retriable.
Deadlock avoidance
- Touch shared tables and rows in a consistent order across code paths.
- Lock only what you need, as late as possible, and commit as soon as the invariant is protected.
- Add retry logic for deadlock and serialization failures; they are expected under contention.
- Index foreign keys and hot predicates so updates do not scan and lock more rows than intended.
Window functions
- Use window functions for rankings, running totals, deduplication, and "top N per group" queries.
- Keep
PARTITION BYandORDER BYexplicit; frame clauses matter for aggregates.
SELECT customer_id, order_id, total,
row_number() OVER (
PARTITION BY customer_id
ORDER BY created_at DESC
) AS recency_rank
FROM orders;
CTEs vs subqueries
- Use CTEs to name meaningful intermediate results or reuse the same derived relation.
- Use subqueries when the scope is local and the surrounding query stays readable.
- Check your database's optimizer behavior; some engines inline CTEs, others may materialize them.
- Do not use CTEs as a performance hint unless the engine documents that behavior.
Pagination patterns
- Prefer keyset pagination for large or frequently changing result sets.
- Use
LIMIT/OFFSETonly for small, stable lists; deep offsets get slower and can skip or duplicate rows. - Make ordering deterministic with a unique tie-breaker.
SELECT id, customer_id, created_at, total
FROM orders
WHERE (created_at, id) .` (replace `` with e.g. `ansi`, `postgres`, `bigquery` — check `.sqlfluff` config or project README)
- **Lint:** `sqlfluff lint --dialect .`
- **Test:** engine-specific (pgTAP for PostgreSQL, `dbt test` if using dbt)
## Avoid
- Schema changes without rollback or compatibility planning.
- Unbounded queries in production paths.
- Relying on implicit ordering without `ORDER BY`.
- Never build SQL by concatenating untrusted input — use parameterized queries or prepared statements. ORM raw-query escape hatches (e.g. Django's `extra()`, SQLAlchemy's `text()`) are equally dangerous. See `swe-workbench:principle-security`.
## Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- **Author:** [lugassawan](https://github.com/lugassawan)
- **Source:** [lugassawan/swe-workbench](https://github.com/lugassawan/swe-workbench)
- **License:** MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.