Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add avelikiy/great_cto --skill deploy-landedgit clone --depth 1 https://github.com/avelikiy/great_ctoWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/avelikiy/great_cto/deploy-landed)<a href="https://agentmods.dev/skills/avelikiy/great_cto/deploy-landed"><img src="https://agentmods.dev/badge/skills/avelikiy/great_cto/deploy-landed/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/avelikiy/great_cto/deploy-landed"><img src="https://agentmods.dev/badge/skills/avelikiy/great_cto/deploy-landed.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00103 | $0.01102 |
| Opus 5.5 | $0.00041 | $0.00441 |
| Sonnet 5.5 | $0.00021 | $0.00220 |
| Haiku 4.5 | $0.00010 | $0.00110 |
Grade A, and why
deploy-landed scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 24d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 78 lines — stays where its author put it; the contents beside it link to each section on GitHub.
deploy-landed — a deploy is done when the running thing is the thing you meant
A deploy command's exit code says the command finished. It does not say the new code is serving, that its configuration arrived, or that the product works. Every trap below produced a green exit and a broken or stale product on a real project:
| Trap | What happened |
|---|---|
git pull failed, the build went on |
The build succeeded from the old code and reported success |
nohup … & |
Exit 0 twice for a process that died at once |
docker exec into a container |
It does not inherit the entrypoint's env: two "config is missing" readings were false |
sed -i / docker cp on a bind-mounted file |
Replaced the inode; the container kept reading the old file |
| A fix applied only on the server | Lost on the next deploy — it was never in git |
| wrangler / Pages | functions/ not deployed, _headers ignored, five deploys to notice |
| Prod behind SSO | Answers 401/302 to every path, including ones that do not exist — proves nothing about a route |
/health green |
For six hours while the engine made no trades |
Before: is the server what git says it is?
Before pulling or building on a host someone can reach by hand:
git -C /srv/app status --porcelain # anything here is a patch that is not in git
git -C /srv/app log -1 --format=%H # what the host thinks it runs
Anything uncommitted on the host is either committed first or reported as drift — never overwritten silently, and never left as the only copy of a fix.
After: four checks, each with its evidence
- Revision. What is serving equals the commit you meant.
- Cloud Run / k8s: the live revision's image tag or digest, then
git merge-base --is-ancestor <commit> <image-tag-sha>. - Pages / Workers / Vercel: the deployment id and its commit.
- A plain host: the running process's start time is after the deploy, and the file
it serves has the new content (
grepfor a string the change introduced). - A
/versionendpoint, when the app has one, beats all of the above.
- Cloud Run / k8s: the live revision's image tag or digest, then
- Configuration. The variables and secrets the new code reads are present in the
running process — count them against the list the code expects. In a container,
read them from PID 1 (
cat /proc/1/environ | tr '\0' '\n'), not fromdocker exec env. After--set-secrets/--set-env-vars, check that the ones you did not name are still there: those flags replace the whole set. - Function. One request that does the product's job and returns something you can compare to a known value — an order created, a row written, a trade placed on paper. A health endpoint proves the process is up, nothing more.
- Startup errors. Logs for the new revision since it started, at WARNING and above. Zero lines is a finding only if you saw the logs flowing at all.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 24d ago First seen · 78 lines · 103 tokens per session scan A 96ab588cb502
deploy-landed is a skill published in the GitHub repository avelikiy/great_cto (103 stars, last pushed today), licensed MIT. It adds 103 tokens to every session and 1,102 once invoked, about $0.0004 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-23.
Other skills, from other repositories
pr-review
Address feedback left on a GitHub pull request: fetch unresolved review threads, make agreed Elixir/Phoenix code fixes, reply, and resolve. Use for a PR URL/number or reviewer comments. NOT for pre-PR review, findings triage, or CI monitoring.
phx-pr-review
Address feedback left on a GitHub pull request: fetch unresolved review threads, make agreed Elixir/Phoenix code fixes, reply, and resolve. Use for a PR URL/number or reviewer comments. NOT for pre-PR review, findings triage, or CI monitoring.
check-pr
Read-only inspection of a single GitHub PR lifecycle — checks CI, review threads, description sync, and mergeability, and returns PASS or FAIL with per-gate findings. Never invokes the merge button. Use when verifying a PR is ready to merge, polling lifecycle progress, checking mergeability, or babysitting a GitHub PR…
babysit-pr
Author-side PR lifecycle babysitter and companion to review-pr. Use when the user wants to tend an existing GitHub PR through CI, review threads, description sync, mergeability, auto-fixes, or asks to babysit a PR with or without an existing manifest.
review-pr
Autonomous PR review that posts high-signal, human-voiced comments under your account. Use when reviewing someone else's PR or your own manifest-driven PR, when you want a precision-tuned review you can walk away from, or when the user asks to review a PR, post a PR review, autoreview, loop review, or watch a PR.
walk-pr
Walk through a PR or large diff together — your own or someone else's — one sub-changeset at a time and one review topic at a time within it. Use when reviewing a substantive PR collaboratively, walking a large refactor, or when the user asks to walk a PR, walk a diff, explain a PR, review collaboratively, or review a…