uplift-technology-company-limited
- 4 skills
- 0 followers
- 1 day ago last updated
- ▌ Upliftgha · uplift-technology-company-limited bundleSet up, migrate, or audit GitHub Actions CI/CD for an Uplift repo — including converting an existing Jenkins pipeline to GHA, or building a pipeline from scratch when there's no CI at all yet. Orchestrates the deploy-target-specific skills: hands off to `upliftvercel` for Vercel frontends, and always invokes `upliftcontrolversion` to wire the git-tag version contract, regardless of target. Owns the AWS EC2 (docker-compose) and ECS (Fargate + ECR) deploy shapes directly. Use this WHENEVER the user wants to: set up GitHub Actions for a repo, migrate/convert a Jenkinsfile to GHA, replace Jenkins with GitHub Actions, add a first-time CI/CD pipeline, choose between a self-hosted runner and GitHub-hosted, or figure out how a repo without a pipeline should deploy (Vercel vs AWS, EC2 vs ECS). Trigger on phrases like "ทำ repo เป็น GHA", "แปลง jenkins เป็น github actions", "ย้ายจาก jenkins ไป gha", "ตั้ง ci/cd ให้ repo นี้", "set up github actions", "convert this jenkinsfile", "this repo has no pipeline yet", even if t
- ▌ Vercel Gha Deploy · uplift-technology-company-limited bundleSet up (or fix) deploying a Next.js / frontend repo to Vercel from a GitHub Actions workflow — with an org-level VERCEL_TOKEN, a main-only branch gate, and an auto-bumped vX.Y.Z version tag baked into the build and shown in the UI. Use this WHENEVER the user wants to add a Vercel deploy pipeline via GitHub Actions, move a repo from manual `vercel --prod` to CI deploy, run the build on a self-hosted runner, wire auto-versioning onto Vercel deploys, or bootstrap a not-yet-set-up repo (git init → GitHub → vercel link → deploy) — even if they don't name this skill. NOT for: fixing app/code bugs that happen to surface in a Vercel build, one-off manual `vercel --prod` runs, Vercel dashboard settings (env vars, domains, rollbacks), Vercel's native git integration (this skill uses GitHub Actions instead), or deploys to other targets (AWS ECS, Docker, a VPS).
- ▌ Uplift Repo Polish · uplift-technology-company-limitedPolish a GitHub repository's presentation so it reads like a well-maintained project — README badges (static ones for private repos) + scannable structure, the About sidebar (description, topics, homepage), a LICENSE it always asks about first (OSS, or an explicit proprietary one for private/internal repos), GitHub Releases cut/backfilled from existing tags, and — with a small deploy-pipeline change — real GitHub Deployment records so the Deployments tab isn't empty. Use this WHENEVER the user wants to make a repo "look professional / more legit / เรียบร้อย", add shields/badges, fill in the About section or topics/tags, add a license, turn vX.Y.Z tags into Releases so the Releases sidebar shows up, make the Deployments tab reflect real deploys, or points at a nice reference repo and says "make mine look like that". Trigger on phrases like "ตกแต่ง repo", "แต่ง readme ให้สวย", "ใส่ badge", "set up the About section", "add topics", "add a license", "make a release", "wire deployments", "polish this repo", "ทำ re
- ▌ Upliftcontrolversion · uplift-technology-company-limited bundleSet up and manage the Uplift auto-increment version system in an Uplift repo (account, the sso service, admin-portal, payment, media, message, subscription, cms, and siblings). Use this WHENEVER the user wants to: add version tags that bump automatically on every deploy, show the running version in the UI or expose it via a /version API, stop OTEL_SERVICE_VERSION from drifting (the hardcoded "1.0.0" bug), make git tags the source of truth for what's deployed, or answer "what version is prod running?". Trigger on phrases like "version bump on deploy", "show the app version", "add a /version endpoint", "auto-increment version", "tag every release", "wire up versioning", even if the user doesn't say the skill name. Mirrors upmove's auto-bump on top of the sso service's existing SemVer/tag convention. (Not about Single Sign-On.)