- Home
- Skills
- Tlabs Xyz
- Tbtc V2 Performance
- Global Tech Stack
global-tech-stack_skill
- TypeScript
0
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill tlabs-xyz/tbtc-v2-performance --skill global-tech-stack- SKILL.md2.0 KB
Overview
This skill enforces consistency with the project's global technology stack when making any dependency or tooling decisions. It helps authors choose libraries, configure build and test tools, and align services with the established languages, package managers, frameworks, databases, and CI/CD practices. Use it to avoid drifting from the agreed stack and to document choices clearly.
How this skill works
The skill inspects dependency manifests and configuration files (package.json, requirements.txt, Gemfile, go.mod, Cargo.toml, etc.) and compares proposed changes to the project's declared stack and conventions. It flags mismatches, recommends preferred alternatives, and provides concrete configuration snippets that follow existing tools, package managers, and version constraints. It also advises on integration concerns for testing, deployment, and third-party services.
When to use it
- Adding new dependencies or libraries to the project
- Choosing technologies for new features (frontend, backend, infra)
- Configuring build tools, bundlers, or package managers
- Setting up or modifying testing frameworks and linters
- Configuring databases, ORMs, authentication, email, or monitoring
- Designing or updating CI/CD pipelines and deployment workflows
Best practices
- Prefer versions and packages already used in the repo to minimize conflicts
- Keep package manager and lockfile changes atomic and documented
- Match testing and linting frameworks to existing conventions and CI jobs
- Avoid introducing multiple overlapping tools for the same concern
- Document deliberate deviations and the migration plan if a change is required
Example use cases
- Replacing a library: recommend an in-stack alternative and show migration steps
- Adding auth/email: suggest services compatible with existing env and secrets management
- New frontend feature: pick the UI framework and bundler that align with current build
- CI change: propose pipeline steps that reuse existing runners and caching
- Database change: advise ORM choices and schema migration patterns already in use
FAQ
Recommend the best-fit option and require justification, a migration plan, and a small proof-of-concept that demonstrates compatibility and minimal disruption.
How strict should adherence be?
Favor consistency for maintainability, but allow exceptions with documented trade-offs and approvals for technical debt, security, or performance reasons.