turborepo
“Turborepo monorepo build system guidance — task pipelines, dependsOn, caching, remote cache, --filter/--affected, internal packages, and boundaries. Use when configuring tasks, creating packages, sharing code between apps, or debugging cache.”
command
references
best-practices
boundaries
caching
ci
cli
configuration
environment
filtering
watch
aipkg.jsoncommand/turborepo.mdLICENSE.mdLICENSE.txtREADME.mdreferences/best-practices/dependencies.mdreferences/best-practices/packages.mdreferences/best-practices/RULE.mdreferences/best-practices/structure.mdreferences/boundaries/RULE.mdreferences/caching/gotchas.mdreferences/caching/remote-cache.mdreferences/caching/RULE.mdreferences/ci/github-actions.mdreferences/ci/patterns.mdreferences/ci/RULE.mdreferences/ci/vercel.mdreferences/cli/commands.mdreferences/cli/RULE.mdreferences/configuration/global-options.mdreferences/configuration/gotchas.mdreferences/configuration/RULE.mdreferences/configuration/tasks.mdreferences/environment/gotchas.mdreferences/environment/modes.mdreferences/environment/RULE.mdreferences/filtering/patterns.mdreferences/filtering/RULE.mdreferences/watch/RULE.mdSKILL.mdSYNC.md- 01SQP-285%HIGH
command/turborepo.md:42
detailhide
The skill instructs users to modify critical configuration files (package.json and turbo.json) without explicit warnings about the implications or without requiring user confirmation before making changes. This could lead to unintended modifications to the user's build system, loss of existing configurations, or introduction of breaking changes to their monorepo setup. The lack of explicit warnings means users may not understand the potential consequences of following these instructions.
40Apply Turborepo-specific patterns from references to complete the user's request.4142**CRITICAL - When creating tasks/scripts/pipelines:**43441. **DO NOT create Root Tasks** - Always create package tasksfix Add explicit warnings before any file modification instructions, such as: 'WARNING: The following steps will modify your package.json and turbo.json files. Ensure you have committed any changes to version control before proceeding.' Include step-by-step verification instructions that ask users to review changes before applying them. Recommend creating a backup or using git to track changes. Provide clear rollback instructions if modifications cause issues.
- 02SQP-295%HIGH
references/caching/remote-cache.md:30
detailhide
The documentation provides clear instructions for setting TURBO_TOKEN as an environment variable in CI/CD without any warning about credential exposure risks. If developers follow this guidance without proper secret management (e.g., using plaintext secrets, logging output, or accidentally committing to version control), authentication tokens could be exposed to attackers. Token exposure grants full access to the remote cache, potentially allowing cache poisoning or unauthorized access to build artifacts.
28### CI Setup2930Set these environment variables:3132```bashfix Add a prominent security warning section that explicitly instructs: (1) Always use CI/CD platform's native secret management (GitHub Secrets, GitLab CI variables, etc.), never hardcode tokens; (2) Rotate tokens regularly and revoke compromised ones immediately; (3) Use minimal-permission tokens scoped to specific teams/projects when possible; (4) Enable audit logging on cache access; (5) Never commit .turbo/config.json or token files to version control.
- 03SQP-292%HIGH
references/caching/remote-cache.md:65
detailhide
The artifact signing section shows how to set TURBO_REMOTE_CACHE_SIGNATURE_KEY as a plaintext environment variable without any guidance on secure secret management. If developers follow this example literally, they may hardcode, log, or commit signing keys. A compromised signing key allows attackers to forge valid signatures on malicious cached artifacts, leading to cache poisoning attacks where poisoned builds are distributed to the entire team and CI/CD pipeline.
63- `signature`: require artifact signing (default: false)6465## Artifact Signing6667Verify cache artifacts haven't been tampered with:fix Add security guidance that emphasizes: (1) Use secrets management tools (HashiCorp Vault, AWS Secrets Manager, cloud provider vaults) rather than environment variables; (2) Rotate signing keys regularly and implement key versioning; (3) Never log or expose the signing key; (4) Use strong, cryptographically random keys (minimum 256-bit entropy); (5) Implement tamper detection and audit logging for signature validation failures; (6) Add a note that signature checking alone is insufficient—also verify cache server authenticity and use TLS/mTLS for transport security.
- 04SQP-285%MEDIUM
references/ci/RULE.md:28
detailhide
The documentation includes a code example showing how to set TURBO_TOKEN and TURBO_TEAM environment variables without any warning about credential security. While this is presented as a 'your_vercel_token' placeholder, developers reading this documentation may inadvertently commit actual tokens to version control or share them in screenshots/logs. The pattern of showing credentials in examples encourages unsafe practices.
2627```bash28TURBO_TOKEN=your_vercel_token29TURBO_TEAM=your_team_slug30```fix Update the documentation to explicitly warn developers never to commit credentials and instead use CI/CD secret management. Add a security note: 'NEVER commit TURBO_TOKEN to version control. Use your CI platform's secret management (GitHub Secrets, GitLab CI Variables, etc.) to inject these values securely.' Provide platform-specific examples showing how to use secrets instead of hardcoded values.
- 05SQP-285%HIGH
references/ci/github-actions.md:75
detailhide
The documentation demonstrates storing sensitive credentials (TURBO_TOKEN - a Vercel access token) in GitHub Actions environment variables without warning about exposure risks. If credentials are logged, printed in workflow outputs, or exposed through artifacts, they could be compromised. The example doesn't emphasize that tokens should never be logged and CI logs are often accessible.
73## Remote Cache Setup7475### 1. Create Vercel Access Token76771. Go to [Vercel Dashboard](https://vercel.com/account/tokens)fix Add a prominent warning section explaining: (1) Never log or print TURBO_TOKEN in workflow output; (2) Use GitHub's secret masking features; (3) Consider using OpenID Connect (OIDC) for keyless authentication instead of static tokens; (4) Recommend rotating tokens regularly; (5) Add an example showing proper secret handling with proper masking in scripts.
- 06SQP-285%MEDIUM
references/ci/vercel.md:63
detailhide
The documentation instructs users to set sensitive environment variables (DATABASE_URL, API_KEY, etc.) in Vercel Dashboard without warning about credential exposure risks. Users may inadvertently commit these values to repositories, share them insecurely, or fail to properly restrict access, leading to unauthorized access to databases and APIs. The lack of security guidance increases the likelihood of credential compromise in production deployments.
61```6263## Environment Variables6465Set environment variables in Vercel Dashboard:fix Add a prominent security warning section before the environment variables example that explicitly states: (1) Never commit sensitive credentials to version control; (2) Use Vercel's built-in secrets management and mark variables as sensitive; (3) Rotate credentials regularly and monitor access logs; (4) Consider using Vercel's integrated secret management features or external vaults like HashiCorp Vault or AWS Secrets Manager; (5) Audit which team members have access to environment variables in Vercel Dashboard.
- 07SQP-275%HIGH
references/configuration/global-options.md:35
detailhide
The documentation shows `globalPassThroughEnv` being used for sensitive credentials like `AWS_SECRET_KEY` and `GITHUB_TOKEN` without explicitly warning users that these credentials could be exposed in logs, caches, or CI/CD system outputs if not properly managed. While the feature itself is legitimate, the documentation lacks critical security guidance about the risks of passing credentials through environment variables.
33```json34{35 "globalPassThroughEnv": ["AWS_SECRET_KEY", "GITHUB_TOKEN"]36}37```fix Add a prominent security warning in the `globalPassThroughEnv` section explaining: (1) credentials passed through env vars may appear in build logs and cache artifacts, (2) recommend using credential management systems (e.g., Vercel secrets, GitHub Actions secrets) instead, (3) advise users to never commit `.env` files with real credentials, (4) suggest using environment-specific secret injection during CI/CD rather than pass-through variables.
- 08SQP-285%HIGH
references/environment/RULE.md:31
detailhide
The documentation demonstrates use of `passThroughEnv` with AWS credentials and other sensitive tokens without prominently warning users about the critical security implications. Since `passThroughEnv` variables are not included in task hashing, credential changes won't trigger cache invalidation, potentially causing stale cached artifacts to be used with outdated credentials. This creates a risk of leaked credentials being cached and distributed across the monorepo without detection.
29```3031### `passThroughEnv` - Runtime-Only Variables (Not Hashed)3233Variables available at runtime but NOT included in hash. **Use with caution** - changes won't trigger rebuilds.fix Add a prominent security warning section in the documentation immediately after the `passThroughEnv` definition explaining: (1) that credentials in `passThroughEnv` are not hashed and won't invalidate cache, (2) that developers should use `env` instead for security-sensitive values when they need cache invalidation, (3) provide examples of secure alternatives, and (4) recommend rotating any credentials that may have been exposed via `passThroughEnv`.