- Home
- Skills
- Tlabs Xyz
- Tbtc V2 Performance
- Global Conventions
global-conventions_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-conventions- SKILL.md2.0 KB
Overview
This skill enforces project-wide development conventions to keep repositories consistent, secure, and easy to navigate. It standardizes project structure, documentation, commit practices, environment configuration, and dependency management across languages and frameworks. Use it to reduce onboarding friction, prevent common mistakes, and simplify reviews and releases.
How this skill works
The skill inspects project layout, README and docs, configuration files (.env, config.yml), dependency manifests (package.json, requirements.txt, Cargo.toml, go.mod), commit messages, changelogs, and feature-flag patterns. It flags missing or inconsistent conventions, recommends fixes (file locations, naming, ignore rules), and suggests secure handling for secrets and environment variables. It also provides templates and examples for README sections, commit message formats, changelog entries, and code review checklists.
When to use it
- Organizing or reorganizing project directory structure
- Writing or updating README, contribution guides, or architecture docs
- Creating commit messages, pull/merge requests, or release notes
- Managing environment variables, config files, or secret handling
- Adding or auditing dependencies and dependency files
- Defining testing, review, or feature-flag conventions
Best practices
- Keep a single source of truth for configuration and document expected file locations
- Store secrets outside source control; use .env templates and gitignore entries
- Use a clear commit message convention (type:scope: short summary) and require changelog entries for releases
- Pin or lock dependencies where reproducibility matters; document upgrade policy
- Include concise README sections: purpose, quick start, environment, tests, contribution, license
Example use cases
- Reformatting a repo to follow a standard src/, tests/, docs/ layout and updating README examples
- Creating a .env.example, adding .env to .gitignore, and documenting secret management steps
- Reviewing a pull request to enforce commit message style and ensure dependency changes are justified
- Adding a changelog template and a release checklist that links to test coverage and migration steps
- Defining a simple feature-flag pattern and documenting how to toggle flags safely across environments
FAQ
It focuses on cross-language conventions (structure, docs, config, secrets) and offers language-specific suggestions where relevant, but not language-exclusive style rules.
How should secrets be stored?
Never commit secrets. Use environment variables, secret managers, or encrypted stores and include a .env.example plus documentation for retrieving secrets securely.
What commit message format do you recommend?
A concise, structured format such as type(scope): short summary (e.g., feat(auth): add JWT refresh) plus an optional longer description in the commit body.