Nettt Tools Laravel Package

Getting Started

Because nettt/nettt-tools is a private Bitbucket package with no public metadata (0 stars, 0 dependents, minimal description), the first step is confirming you actually have access and understanding what is inside before wiring it into a project. Start by asking the Nettl team or your Bitbucket admin for repository access, then clone it locally and read the README and directory layout directly:

git clone [email protected]:nettt/nettt-tools.git
cd nettt-tools
ls -la          # look for bin/, scripts/, skills/, deploy/, etc.
cat README.md   # confirm entry points and required env vars

Where to look first:

• README.md and any CHANGELOG.md — deployment tools often encode assumptions about servers, PHP versions, and hosting.
• bin/ or scripts/ — the actual deploy commands you'll invoke day-to-day.
• A skills/ or ai/ directory — the "AI skills" portion is likely prompt/tool definitions (e.g. Claude skills, Cursor rules, or agent tool manifests) rather than executable PHP.
• composer.json — check whether it is a library you require, or a set of scripts you copy/vendor into projects (deployment tooling is often the latter).

Minimal first use case: do a trial deploy of a small Laravel app to a staging environment. Copy or install the scripts, run the "dry run" or "build only" step, and inspect what artifacts it produces before pointing it at anything production-adjacent. For the AI skills portion, drop the skill definitions into a throwaway repo (or your editor's agent config directory) and exercise one skill on a non-critical branch to see what files it touches.

Implementation Patterns

Since the package is described as "deployment scripts and AI skills for Laravel and Statamic projects," treat it as two separate concerns and adopt each one deliberately.

Deployment scripts

• Script-per-project, not global install. Deployment tooling rarely belongs in require for runtime apps. Clone or submodule the repo into a tools/ or .nettt/ directory, or copy the relevant script into scripts/ in each project, so each project can pin a version of the deploy logic.
• Wrap scripts in Composer commands. Expose them as composer deploy:staging / composer deploy:production in composer.json "scripts" so developers don't memorize invocations. This keeps CI and local workflows identical.
• CI integration. In GitHub Actions or Bitbucket Pipelines, call the deploy script with an explicit environment argument and secrets from the CI secret store. Do not commit .env files; the script should expect them from the environment.
• Staging-first cadence. Typical day-to-day pattern: push branch → CI runs deploy:staging on merge → verify → tag release → run deploy:production from CI, not from a laptop.
• Statamic specifics. If deploying a Statamic project, confirm the scripts handle php please commands, content directory permissions, static caching warmup (php please static:clear / warm), and asset compilation — Statamic deploys tend to have content and cache steps that plain Laravel doesn't.

AI skills

• Keep skills in version control per project. If the repo ships skill/tool definitions, check them into the project (e.g. .ai/, .claude/, or whatever your editor/agent convention is) so every developer gets the same behavior.
• Scope a skill to a task, not a whole app. Use a skill for a narrow operation (generate a migration, scaffold a Statamic fieldset, produce a deploy checklist) and review the output. Do not let a skill touch production config or migrations unreviewed.
• Pair skills with the deploy scripts. A skill that "prepares a release" should read from the same scripts directory so the checklist matches what actually runs.

Integration tips

• Pin to a specific commit or tag per project; add a comment in each project's README noting which version of nettt-tools is in use.
• If the repo is consumable via Composer, add it as a path or VCS repository entry so composer update can pull from Bitbucket using an auth token in CI.
• Document required environment variables (SSH host, deploy user, paths) in the project README rather than relying on script comments.

Gotchas and Tips

• Access is the real gate. With 0 dependents and 0 stars, there is no public ecosystem to lean on — no issue threads, no forks, no SO answers. If you cannot get Bitbucket access, treat it as unusable and replicate the behavior yourself.
• Private repos break CI by default. Bitbucket VCS requires an app password or access token added as a CI secret; a plain composer install in GitHub Actions will fail unless you configure COMPOSER_AUTH or the equivalent for VCS repositories.
• Deployment scripts are dangerous by default. Audit every destructive command (rm -rf, git clean -fdx, database resets, rsync --delete) before its first real run. Prefer scripts that support a --dry-run or --plan flag; if none exists, add a small wrapper that echoes commands instead of executing them.
• Never let a deploy script source production secrets locally. Require secrets from the environment/CI store and fail loudly if they're missing, so a mis-run on a laptop can't hit production.
• AI skills can be silently ignored or silently destructive. Two failure modes: the agent never loads the skill (wrong directory, wrong manifest format — check your editor's docs) or it loads it and edits files you didn't intend. Diff agent-generated changes before committing; keep the skill definitions small and explicit about what they may touch.
• Statamic content vs code. Ensure the deploy process treats content/, users/, and resources/ correctly — some pipelines overwrite staging-only content. Verify with a real content edit post-deploy.
• Version drift. Because the package is private and internal, its API can change without semver discipline. Pinning per project and recording the pinned commit is your only safeguard. When updating, diff the scripts between versions before switching.
• Extension points to look for. Ideally the scripts expose hooks (pre-build, post-deploy) and read config from a project-local file (e.g. .nettt.yml or environment variables) rather than hardcoded paths. If they don't, that's your first contribution back to the repo.
• Debugging tips. Run deploy scripts with bash -x in a disposable environment to see exactly what executes; log all remote commands with timestamps; and keep a rollback path (previous release symlink, or a tag you can redeploy) — deployment tooling without rollback is a liability.
• Score of 0 / no description depth means you should treat this as an internal tool, not a mature package. Budget time to read the code, not just the docs.