Install any skill in seconds. Free to start, no credit card required.
Get Started Free →lifinance/deploy-contract-tron
Deploys a facet/periphery contract to Tron (mainnet or Shasta testnet) from the `contracts-tron` fork — the two-repo, TronWeb-based round trip that Foundry's `deployContractToNetworks.sh` cannot run.
Passed 13 of 17 test cases with the skill, and 6 of 17 without it.
and 11 more in the full report
11 fixed6 passed either way3 still failing2 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 11 test cases the skill fixed. Same model, same prompt, with and without the skill.
When copying deployment outputs from lifinance/contracts-tron to upstream lifinance/contracts for the tracking PR, which two JSON files must be transferred?
| Checked | Without skill | With skill |
|---|---|---|
| Names deployments/tron.json as a required deployment artifact | Passed | Passed |
| Names deployments/tron.diamond.json as a required deployment artifact | Missed | Passed |
The instructions your model reads when the skill loads.
Tron has no Foundry support, so it does not go through deployContractToNetworks.sh or CREATE3 — it uses the TypeScript/TronWeb scripts in script/deploy/tron/, run from a separate fork repo, lifinance/contracts-tron. This skill is the Tron analog of /deploy-contract; use it whenever a target network is tron or tronshasta.
main in lifinance/contracts carries zero Tron branching by design — Tron USDT is a broken ERC-20, so the fix (a bypass in LibAsset.transferERC20 + a WithdrawablePeriphery re-route) lives only in the fork as a small, deliberate delta. Code flows one-way contracts → contracts-tron; deploy logs flow back the other way via a PR against upstream — never a direct commit to the fork. Full rationale, the exact fork delta, and the sync mechanism: docs/TronFork.md (read it if anything below is unclear on why, not just what).
contracts-tron checkoutA normal session is rooted in contracts, but every step in this skill except Phase 5 must run from a contracts-tron working copy — a different clone, not a worktree of this repo (worktrees share one .git; forks don't).
Find it. Check, in order: $CONTRACTS_TRON_PATH if set, then a sibling directory next to the current repo root (../contracts-tron). Use the first that exists and has origin pointing at lifinance/contracts-tron.
Clone it if missing.
gh repo clone lifinance/contracts-tron ../contracts-tron
ln -s "$(git rev-parse --show-toplevel)/.env" ../contracts-tron/.env # symlink, never copy — reuses this checkout's secrets
cd into it for the rest of Phase 0 through Phase 4. All commands below assume the working directory is the contracts-tron checkout.
Confirm you're in contracts-tron, not contracts, and on main.
git remote get-url origin | grep -q 'contracts-tron' || { echo "not in contracts-tron — abort"; exit 1; }
git rev-parse --abbrev-ref HEAD # must be main for a production deploy
Check the fork is synced for the contract you're about to deploy. If upstream contracts:main has changes to <Contract> (or to LibAsset/WithdrawablePeriphery) not yet in the fork, stop and merge the pending sync/upstream-YYYY-MM-DD PR first (or open one) — do not deploy stale code.
Verify the -tron delta survived the last sync. After any sync, confirm the bypass branch is still present:
grep -q "TRON_USDT" src/Libraries/LibAsset.sol || { echo "Tron USDT bypass missing from LibAsset — sync broke the delta"; exit 1; }
If missing, the sync merge dropped the fork's delta — resolve before deploying; do not deploy without the bypass on a chain where USDT is effectively all volume.
test cases passed, vs 6 / 17 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.