@ketecode/loom 0.0.0-stage → 0.1.0

package/skills/smart-contract-security/SKILL.md

@@ -0,0 +1,110 @@
+---
+name: smart-contract-security
+description: Security audit procedure for Solidity and EVM smart contracts that maps the system's funds, roles and trust assumptions, then hunts reentrancy (including cross-function and read-only), broken access control, price oracle and flash-loan manipulation, rounding and precision loss in share maths, front-running and MEV exposure, signature replay across chains and nonces, and proxy upgrade risks, backed by Slither static analysis plus Foundry, Echidna or Medusa fuzzing and invariant tests, ending in a severity-rated report with a clear professional-audit boundary. Use when auditing a protocol or token contract before deployment, investigating a suspected exploit path, writing invariant tests to break a contract, or deciding whether code is ready for an external audit.
+license: MIT
+compatibility: Any Agent Skills host. Needs Foundry (forge) or Hardhat to build and test; Slither (Python 3.10+) for static analysis; Echidna or Medusa optional for property fuzzing.
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: security
+  kete-loom/risk: runs-commands
+  kete-loom/requires: "forge, slither"
+  kete-loom/owner: "Kete-org"
+---
+
+# Smart contract security
+
+Find the ways a contract loses or locks funds, prove each with a failing test, and say plainly what the review did not cover. Exploits are permanent and public, so a finding without a reproduction is a lead, not a conclusion.
+
+## What this skill is not
+
+- **Not a professional audit.** It is a structured internal review. Any contract that will hold meaningful user funds, mint a token with market value, or bridge assets needs at least one independent audit by a qualified firm, and ideally a bug bounty, before mainnet. Say so in every report.
+- Not financial, legal or token-regulation advice.
+- Not a guarantee: no finding list proves the absence of bugs.
+
+## 1. Scope and threat model
+
+1. Pin the exact commit, compiler version and the list of in-scope files. Build it (`forge build` or `npx hardhat compile`); if it doesn't compile, stop and ask.
+2. Write down, before reading code in depth:
+   - **Assets**: what the contracts hold (ETH, tokens, NFTs, accounting balances) and where the totals live.
+   - **Actors and roles**: users, admins, keepers, oracles, bridges, other protocols; what each can do.
+   - **Trust assumptions**: which external contracts and tokens are trusted, which price feeds, and what a malicious or upgraded dependency could do.
+   - **Invariants**: statements that must always hold (solvency, `totalShares` matches the sum of balances, only role X changes parameter Y).
+3. Map every external and public function that moves value or changes privileged state. Run `slither . --print human-summary` and `--print function-summary` to get the inventory.
+
+## 2. Automated pass
+
+1. `slither .` from the project root (filter out `lib/` or `node_modules` per the Slither wiki). Triage every high and medium detector result: true positive, false positive with reason, or needs a test.
+2. For proxies, `slither-check-upgradeability` against the old and new implementation, plus the OpenZeppelin Upgrades plugin's validation.
+3. Existing tests: `forge test -vvv` and `forge coverage`. Note functions with no test of their revert paths.
+
+Tool output is a starting point. Never report a detector result as a finding without reading the code path.
+
+## 3. Manual review, in this order
+
+Work through `references/vulnerability-checklist.md`. The headline classes:
+
+1. **Reentrancy**: external calls (ETH sends, token transfers, hooks in ERC-721/1155/777 receivers, arbitrary `call`) before state is updated; cross-function and cross-contract reentrancy that `nonReentrant` on one function doesn't cover; read-only reentrancy where another protocol reads a stale view mid-call.
+2. **Access control**: unguarded privileged functions, unprotected or re-callable initializers, uninitialized implementation contracts, role admin misconfiguration, `tx.origin` auth, missing two-step ownership transfer.
+3. **Oracle and price manipulation**: spot prices from an AMM pool's reserves or `balanceOf`, which a flash loan can move within one transaction; Chainlink answers used without checking staleness (`updatedAt`), round completeness and sequencer uptime on L2s; donation attacks on share-price vaults (ERC-4626 inflation).
+4. **Integer and rounding**: rounding in the user's favour on deposit/withdraw or mint/redeem, division before multiplication, precision loss with low-decimal tokens, `unchecked` blocks, unsafe downcasts (`uint128(x)` silently truncates; use `SafeCast`).
+5. **Front-running and MEV**: missing slippage limits (`minAmountOut`) and deadlines on swaps, commit-reveal missing where order matters, approval race conditions, sandwichable liquidations or auctions.
+6. **Signature replay**: signatures without a nonce, without `block.chainid` and contract address in the EIP-712 domain, reusable after cancel, malleable (use OZ `ECDSA`, not raw `ecrecover`), or `ecrecover` returning `address(0)` accepted as a valid signer.
+7. **Upgrade risks**: storage layout collisions between versions, missing `_authorizeUpgrade` guard, selector clashes in proxies, upgrade keys held by a single EOA, no timelock.
+8. **Token integration**: fee-on-transfer and rebasing tokens, tokens that return `false` instead of reverting (use `SafeERC20`), tokens with blocklists or pausable transfers, 6 vs 18 decimals.
+9. **Denial of service and griefing**: unbounded loops, push payments to contracts that revert, dust positions that block liquidation.
+
+## 4. Prove it
+
+For every candidate finding, write a Foundry test that demonstrates it (an exploit test that passes when the bug exists), or a fuzz/invariant test that breaks:
+
+- Fuzz: functions taking `uint256 amount` with `bound()` to realistic ranges.
+- Invariant: a handler contract that calls the system's functions in random order, with `invariant_` functions asserting the invariants from step 1 (`[invariant] runs` and `depth` in `foundry.toml`).
+- Fork tests (`forge test --fork-url $RPC_URL`) for oracle and integration issues against real pool state.
+- Echidna or Medusa for longer property campaigns when the invariants are numerous.
+
+Findings you couldn't reproduce are reported as "unconfirmed", with the reasoning.
+
+## Severity
+
+| Severity | Meaning |
+|---|---|
+| Critical | Direct theft or permanent freezing of user funds, or takeover of admin/upgrade, by an unprivileged attacker |
+| High | Loss of funds under realistic conditions, or protocol insolvency |
+| Medium | Loss of yield, temporary freezing, or a privileged role able to harm users beyond the documented trust model |
+| Low | Hardening, best-practice deviations with no direct loss path |
+| Info | Gas, style, documentation |
+
+## Stop and ask the user
+
+- If you find a critical issue in a contract that is already deployed with funds: stop the review, tell the user immediately, and recommend they contact a security firm or an emergency response group and follow responsible disclosure. Do not publish details, open public issues, or run the exploit on mainnet.
+- Before running anything against a live network other than read-only fork tests.
+- If scope, the trust model or intended admin powers are unclear.
+
+## Never
+
+- Never broadcast transactions, use real private keys, or test exploits on mainnet or public testnets against contracts you don't own.
+- Never mark a contract "secure", "safe" or "audited". Say "no issues found in the reviewed scope".
+- Never drop the professional-audit recommendation for contracts that will hold funds.
+
+## Report format
+
+```
+## Smart contract review: <repo>@<commit>
+Scope: <files>, solc <version>. Out of scope: <...>
+Threat model: assets, roles, trust assumptions, invariants (short)
+
+### Findings
+1. [Critical] Vault.sol:142 — <title>
+   Class: reentrancy | access control | oracle | rounding | MEV | signature | upgrade | token | DoS
+   Impact: <who loses what, under what conditions>
+   Proof: test/exploits/<Name>.t.sol (passes = bug present) | unconfirmed: <why>
+   Fix: <smallest change that removes the root cause>
+
+### Tooling
+Slither: <n> results triaged (<n> true positives). Fuzz/invariant: <runs, depth, results>. Coverage: <%>.
+
+### Not covered
+<economic design, off-chain components, dependencies, anything skipped>
+
+This is an internal review, not a professional audit. Contracts that will hold user funds need an independent audit before mainnet.
+```

package/skills/smart-contract-security/evals/triggers.json

@@ -0,0 +1,16 @@
+{
+  "should_trigger": [
+    "Audit our lending protocol contracts for oracle manipulation and reentrancy before launch",
+    "Can a flash loan drain our ERC-4626 vault through a share price inflation attack?",
+    "Write Foundry invariant tests that try to break the solvency of our staking contract",
+    "Our permit-based meta-transaction signatures don't include a nonce, is that exploitable and how bad is it?",
+    "Is our DEX router code ready for an external audit? Run Slither and do a security pass first"
+  ],
+  "should_not_trigger": [
+    "Write an ERC-20 token contract with a capped supply and an owner-only mint using Foundry",
+    "Show the token balance with the right decimals in our wagmi frontend and send an approve transaction",
+    "Review my last commit for security vulnerabilities in the login flow",
+    "Check our npm dependencies for known CVEs and abandoned packages",
+    "Explain how proof of stake consensus works on Ethereum"
+  ]
+}

package/skills/smart-contract-security/references/vulnerability-checklist.md

@@ -0,0 +1,79 @@
+# Smart contract vulnerability checklist
+
+Read this during the manual review step. Each item is a question; answer it for every in-scope contract and note the line you checked.
+
+## Reentrancy
+
+- Does any function make an external call (`call`, `transfer`/`send`, token `transfer`/`transferFrom`, `safeTransferFrom` on ERC-721/1155 which calls `onERC721Received`/`onERC1155Received`, ERC-777 hooks, a callback into a user-supplied address) before it finishes writing state?
+- Are all functions sharing the same state protected together (cross-function reentrancy), not just the one that makes the call?
+- Can another contract read a view function (price, share value, balance) while this contract is mid-call with inconsistent state (read-only reentrancy)?
+- Is `nonReentrant` present where needed and absent from functions that must call each other internally?
+
+## Access control
+
+- Is every function that mints, burns, pauses, sets parameters, moves treasury funds, or upgrades guarded by a modifier or explicit check?
+- Can `initialize` be called by anyone, called twice, or front-run after deployment? Is `_disableInitializers()` in the implementation constructor?
+- Does `_authorizeUpgrade` have access control (UUPS)?
+- Are `AccessControl` role admins set correctly (who can grant `DEFAULT_ADMIN_ROLE`)?
+- Is ownership transfer two-step (`Ownable2Step`)? Is renouncing ownership possible by accident?
+- Any use of `tx.origin` for authorization?
+- Are admin powers documented and bounded (fee caps, timelocks)?
+
+## Oracles and price manipulation
+
+- Is any price derived from AMM reserves, `balanceOf(address(this))`, or a single-block value that a flash loan can move?
+- For Chainlink `latestRoundData`: are `answer > 0`, `updatedAt` freshness against the feed's heartbeat, and (on L2s) the sequencer uptime feed checked? Are feed decimals read, not assumed?
+- Are TWAP windows long enough for the liquidity involved?
+- ERC-4626 or share vaults: can the first depositor inflate the share price by donating assets (virtual shares/offset, minimum deposit, or dead shares)?
+
+## Integer maths and rounding
+
+- Does every conversion round against the user and in favour of the protocol (deposit rounds shares down, withdraw rounds shares up)?
+- Any division before multiplication? Use `Math.mulDiv` for `a * b / c` with large values.
+- Any `unchecked` block without a proven bound?
+- Any downcast (`uint128(x)`, `int256(x)`) without `SafeCast`?
+- Do calculations handle tokens with 6, 8 and 18 decimals, and zero amounts?
+
+## Front-running and MEV
+
+- Do swaps, deposits into AMM positions, and liquidations take a `minAmountOut`/`maxAmountIn` and a `deadline` from the caller?
+- Can an observer of the mempool profit by inserting a transaction before or after (sandwich, back-running oracle updates)?
+- Are approvals set with `forceApprove` or increase/decrease patterns rather than overwriting non-zero allowances?
+- Would commit-reveal or a batch auction be needed for fairness (games, NFT mints, auctions)?
+
+## Signatures
+
+- Does the signed message include a nonce that's consumed, an expiry, `block.chainid`, and the verifying contract (EIP-712 domain separator, rebuilt if the chain ID changes)?
+- Is `ECDSA.recover` (or `SignatureChecker` for smart-contract wallets via ERC-1271) used instead of raw `ecrecover`, and is a `address(0)` signer rejected?
+- Can the same signature be used on another function, another contract, or after cancellation?
+- `permit` (EIP-2612) calls: is a front-run `permit` (which makes the second call revert) handled so it can't grief the user?
+
+## Upgrades and proxies
+
+- Compare storage layouts between versions: no reordered, removed or retyped variables; namespaced storage (ERC-7201) or gaps used consistently.
+- Do inherited contracts change order between versions?
+- Any function selector in the implementation clashing with the proxy's admin functions (transparent proxy)?
+- Who holds the upgrade key? Is there a timelock so users can exit before an upgrade?
+- Does any new `reinitializer(n)` use the right version number?
+
+## Token integration
+
+- Fee-on-transfer: is the received amount measured by balance difference?
+- Rebasing tokens: do stored balances drift from actual balances?
+- Tokens that return `false` or no value: is `SafeERC20` used?
+- Tokens with blocklists, pause, or upgradeable logic (USDC, USDT): can a blocked address freeze the whole system?
+- ERC-777 or tokens with hooks: reentrancy on transfer.
+
+## Denial of service and griefing
+
+- Loops over arrays users can grow (holders, orders, positions)?
+- Push payments where one reverting recipient blocks everyone?
+- Can dust positions, tiny orders or zero-amount calls block liquidation, settlement or withdrawal queues?
+- Does anything depend on `address(this).balance` equalling an internal counter (forced ETH via `selfdestruct` from another contract or coinbase still works)?
+
+## Miscellaneous
+
+- `delegatecall` to user-influenced addresses or to libraries with storage.
+- Randomness from `block.timestamp`, `blockhash` or `block.prevrandao` for anything valuable (use Chainlink VRF or commit-reveal).
+- Hard-coded addresses that differ per chain.
+- Events missing for parameter changes, so monitoring can't see an admin action.

package/skills/social-media-publishing/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: social-media-publishing
+description: Posts text, images and video to X, LinkedIn, Facebook Pages and Instagram through their official APIs, covering OAuth app setup and token refresh, the scopes each platform needs, media upload flows, rate and publishing limits, queued scheduling with retries, and per-platform length and formatting rules. Use when building or fixing code that publishes or schedules social posts programmatically, a post or media upload call fails with a 401, 403 or rate-limit error, or one message must be formatted correctly for several networks.
+license: MIT
+compatibility: Any Agent Skills host. Live calls need network access to api.x.com, api.linkedin.com and graph.facebook.com, and developer apps the user owns on each platform. Examples are plain HTTP; the rules apply to any SDK.
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: integrations
+  kete-loom/risk: network
+  kete-loom/owner: "Kete-org"
+---
+
+# Social media publishing
+
+Publish to social networks through official APIs only, with tokens stored safely, media uploaded the way each platform expects, every post idempotent, and failures retried without double-posting.
+
+## Ground rules
+
+1. **Official APIs only.** No browser automation, scraped endpoints or shared passwords; they break platform terms and get accounts banned.
+2. **The user owns the developer apps.** Each platform needs an app the user registers and, for some scopes, gets approved (LinkedIn's Community Management API for company pages, Meta App Review for Page and Instagram publishing). **Stop and ask the user** for app IDs and which accounts to post as; never invent them.
+3. **Tokens are secrets.** Store access and refresh tokens encrypted server-side, per connected account, with their expiry and granted scopes. Never log them or send them to the browser.
+4. **Request the least scope** that the feature needs (table below).
+5. **Media first, then the post.** Every platform uploads or registers media in a separate step and returns an ID or container that the post references. Wait until processing finishes before posting.
+6. **Idempotent posting.** Write a `scheduled_posts` row (account, platform, body, media, `publish_at`, status) before calling the API; mark `publishing` with a conditional update, store the returned post ID, and never retry a call that may have succeeded without first checking whether the post exists.
+7. **Respect rate limits.** Read the platform's rate-limit headers or usage endpoint, back off on `429`, and spread scheduled posts instead of firing them all at the top of the hour.
+8. **Read the current docs.** These APIs, their access tiers and pricing change often. Check the version and limits in the official docs before stating them; details in `references/platform-apis.md`.
+
+## Platform map
+
+| Platform | Auth | Post endpoint | Media | Scopes / permissions |
+|---|---|---|---|---|
+| X | OAuth 2.0 with PKCE, user context | `POST https://api.x.com/2/tweets` | `POST /2/media/upload/initialize`, `/{id}/append`, `/{id}/finalize`, then poll status | `tweet.read`, `tweet.write`, `users.read`, `media.write`, `offline.access` for refresh |
+| LinkedIn | OAuth 2.0 three-legged | `POST https://api.linkedin.com/rest/posts` with `Linkedin-Version: YYYYMM` and `X-Restli-Protocol-Version: 2.0.0` | `POST /rest/images?action=initializeUpload`, PUT bytes to `uploadUrl`, use the `urn:li:image:...` | `w_member_social` (member), `w_organization_social` (company page; member needs the ADMINISTRATOR, CONTENT_ADMIN or DIRECT_SPONSORED_CONTENT_POSTER page role) |
+| Facebook Page | Facebook Login, Page access token | `POST /{page-id}/feed` (text, link) or `/{page-id}/photos`, `/{page-id}/videos` | in the same call by URL or upload | `pages_manage_posts`, `pages_manage_engagement`, `pages_read_engagement`, `pages_read_user_engagement`; add `publish_video` for video |
+| Instagram (professional account) | Instagram Login or Facebook Login | `POST /{ig-user-id}/media` creates a container, then `POST /{ig-user-id}/media_publish` | media fetched by Meta from a public `image_url` / `video_url` | `instagram_business_basic` + `instagram_business_content_publish` (Instagram Login), or `instagram_basic` + `instagram_content_publish` + `pages_read_engagement` (Facebook Login) |
+
+## Build steps
+
+1. **Connect accounts.** Implement the OAuth authorization-code flow per platform with a `state` value checked on return (and PKCE for X). Save tokens, expiry, scopes and the account's ID or URN (`urn:li:person:...` from LinkedIn's OpenID `userinfo` `sub`, `urn:li:organization:...` for pages, the Page ID, the IG user ID).
+2. **Refresh before expiry.** A job refreshes tokens ahead of `expires_at`. When refresh fails (revoked, password changed, scope removed), mark the account `needs_reconnect` and tell the user; do not keep retrying.
+3. **Format per platform** using the rules below. Validate length and media count before queueing, not at publish time.
+4. **Upload media.** X: chunked upload (keep chunks at or under 5 MB), then poll status until `processing_info.state` is `succeeded`. LinkedIn: `initializeUpload`, PUT the file, wait until the image or video is `AVAILABLE`. Instagram: host the file at a public HTTPS URL, create the container, poll `status_code` until `FINISHED` (about once a minute, at most 5 minutes) before `media_publish`.
+5. **Publish** from a worker that picks due rows, claims them with `UPDATE ... SET status='publishing' WHERE id=? AND status='scheduled'`, calls the API, then stores the platform post ID and URL.
+6. **Handle errors** by class: `401` refresh once then mark reconnect; `403` missing scope, role or tier (do not retry); `429` back off using the reset header; `5xx` or timeout check whether the post exists, then retry with backoff. Record the platform's error body.
+7. **Scheduling.** Store `publish_at` in UTC with the user's time zone for display. Native scheduling exists on some platforms (Facebook Pages accept `published=false` with `scheduled_publish_time`, 10 minutes to 30 days ahead), but a single queue of your own keeps behaviour the same everywhere.
+
+## Formatting differences
+
+| | X | LinkedIn | Facebook Page | Instagram |
+|---|---|---|---|---|
+| Text length | 280 weighted characters (emoji and CJK count as 2); any URL counts as 23 | 3,000 characters | long posts allowed; first lines show before "See more" | caption up to 2,200 characters |
+| Links | inline, shortened by t.co | inline; link preview via article content | link preview from the `link` field | not clickable in captions |
+| Hashtags | 1 or 2 (style choice) | a few at the end (style choice) | sparing | at most 30 per caption |
+| Mentions | `@handle` in text | `@` + `[Name]` + `(urn)` mention syntax in the commentary; name must match | Page tags need IDs | `@handle` in caption, at most 20 |
+| Media | up to 4 media IDs per post | images, video, documents, multi-image | photos, video | required: image, video, reel, or carousel of up to 10 |
+
+Confirm current limits in each platform's docs before enforcing them in code.
+
+## Stop and ask the user
+
+- Which accounts and pages to post as, and who approved posting on their behalf.
+- Before applying for elevated access or a paid API tier.
+- Before posting anything live during development: use a test account, private visibility, or draft state where the platform offers one.
+- Before deleting or editing published posts in bulk.
+
+## Never
+
+- Post the same text to every network unchanged when it breaks a platform's length or mention rules.
+- Automate likes, follows, replies or DMs at scale; platform rules forbid most of it.
+- Store tokens in the client, or share one token across customers.
+- Retry a publish blindly after a timeout.
+
+## Report format
+
+When reviewing or finishing an integration, report:
+
+```
+Platforms: ...                 Accounts: member / page / IG professional
+Auth: flow, scopes granted, refresh handled yes|no
+Media: upload path and processing wait per platform
+Queue: idempotent claim yes|no, retry policy, timezone handling
+Gaps: ... (each with the fix)
+Needs user action: app review, tier, page roles
+```

package/skills/social-media-publishing/evals/triggers.json

@@ -0,0 +1,17 @@
+{
+  "should_trigger": [
+    "Build a scheduler that posts to our LinkedIn company page and X account from our CMS",
+    "LinkedIn rest/posts returns 403 ACCESS_DENIED when I post as our organization",
+    "How do I upload a video to X with the v2 media upload endpoints and attach it to a post?",
+    "Instagram media_publish fails because the container status is still IN_PROGRESS",
+    "Our social posting worker sometimes publishes the same Facebook Page post twice after a timeout",
+    "Which OAuth scopes do I need to let users connect their X and LinkedIn accounts for posting?"
+  ],
+  "should_not_trigger": [
+    "Turn this 40-minute conference talk into a LinkedIn post, an X thread and a newsletter",
+    "Write a voice and tone guide for how our brand sounds on social",
+    "Our marketing emails fail DMARC, fix the DNS records",
+    "Plan a six-week launch campaign with a budget split across paid social and email",
+    "Write a three-touch outbound email sequence to VPs of engineering"
+  ]
+}

package/skills/social-media-publishing/references/platform-apis.md

@@ -0,0 +1,116 @@
+# Platform API shapes
+
+Request shapes for the common publish paths. Check each platform's docs for the current API version, access tier and limits before relying on these.
+
+## X (docs.x.com)
+
+Auth: OAuth 2.0 authorization code with PKCE, user-context token in `Authorization: Bearer`. `POST /2/tweets` accepts only user-context tokens (OAuth 2.0 user token with `tweet.read`, `users.read`, `tweet.write`, or OAuth 1.0a user token); app-only tokens cannot post. Without `offline.access` the token lasts two hours and no refresh token is issued.
+
+Chunked media upload:
+
+```
+POST https://api.x.com/2/media/upload/initialize
+{ "media_type": "video/mp4", "total_bytes": 10485760, "media_category": "tweet_video" }
+-> { "data": { "id": "<media_id>", ... } }
+
+POST https://api.x.com/2/media/upload/<media_id>/append      (multipart: segment_index, media)
+POST https://api.x.com/2/media/upload/<media_id>/finalize
+GET  https://api.x.com/2/media/upload?command=STATUS&media_id=<media_id>
+     repeat after processing_info.check_after_secs until state is "succeeded"
+```
+
+- Do not send `command=INIT|APPEND|FINALIZE` to `POST /2/media/upload`; that is the previous protocol.
+- Keep each chunk at or under 5 MB (the server maximum is 8 MB). `media_category` values include `tweet_image`, `tweet_gif`, `tweet_video`, `amplify_video`, `dm_image`, `dm_gif`, `dm_video`, `subtitles`. Status states are `pending`, `in_progress`, `succeeded`, `failed`. Size and duration limits depend on the user's account type.
+
+Create the post:
+
+```
+POST https://api.x.com/2/tweets
+{ "text": "Shipping today", "media": { "media_ids": ["<media_id>"] } }
+```
+
+`media_ids` takes 1 to 4 IDs.
+
+Threads: post the first, then each next post with `"reply": { "in_reply_to_tweet_id": "<previous id>" }`.
+
+Access tiers and pricing change; confirm in the developer console which endpoints and volumes the user's plan includes.
+
+## LinkedIn (learn.microsoft.com/linkedin)
+
+Every versioned call sends `Linkedin-Version: YYYYMM` and `X-Restli-Protocol-Version: 2.0.0`. Versions are released monthly and supported for at least one year before sunset; a sunset or missing version returns an error, so keep the header current.
+
+Image:
+
+```
+POST https://api.linkedin.com/rest/images?action=initializeUpload
+{ "initializeUploadRequest": { "owner": "urn:li:organization:123" } }
+-> { "value": { "uploadUrl": "https://www.linkedin.com/dms-uploads/...", "image": "urn:li:image:C4E..." } }
+
+PUT <uploadUrl>   (raw bytes, Authorization header)
+GET https://api.linkedin.com/rest/images/urn:li:image:C4E...   until status is AVAILABLE
+```
+
+Video: `POST /rest/videos?action=initializeUpload` with `owner` and `fileSizeBytes` returns `uploadInstructions` (one upload URL per 4 MB byte range) and an `uploadToken`. PUT each part and keep the `ETag` response header, then `POST /rest/videos?action=finalizeUpload` with `video`, `uploadToken` and `uploadedPartIds` (the ETags, in part order). Poll `GET /rest/videos/{urn}` until status is `AVAILABLE`.
+
+Post:
+
+```
+POST https://api.linkedin.com/rest/posts
+{
+  "author": "urn:li:organization:123",
+  "commentary": "Text of the post",
+  "visibility": "PUBLIC",
+  "distribution": { "feedDistribution": "MAIN_FEED", "targetEntities": [], "thirdPartyDistributionChannels": [] },
+  "content": { "media": { "id": "urn:li:image:C4E...", "altText": "Describe the image" } },
+  "lifecycleState": "PUBLISHED",
+  "isReshareDisabledByAuthor": false
+}
+-> 201, post URN in the x-restli-id response header
+```
+
+- Member posts: `w_member_social`, author `urn:li:person:<sub from /v2/userinfo>`.
+- Company posts: `w_organization_social`, and the member must hold the ADMINISTRATOR, CONTENT_ADMIN or DIRECT_SPONSORED_CONTENT_POSTER role on the page.
+- LinkedIn Help gives 3,000 characters as the post limit; the API returns `FIELD_LENGTH_TOO_LONG` when `commentary` is over its maximum. `commentary` uses LinkedIn's "little text" format: escape the reserved characters `| { } @ [ ] ( ) < > # \ * _ ~` with a backslash whenever they are plain text rather than mention or hashtag syntax. Mentions are `@[Name](urn:li:organization:123)`; the name must match the entity's name.
+- `ugcPosts` is legacy (the Posts API replaces it); use `/rest/posts`.
+
+## Facebook Page (developers.facebook.com, Graph API)
+
+Use a Page access token for a Page the user manages. Facebook Login requests `pages_manage_engagement`, `pages_manage_posts`, `pages_read_engagement` and `pages_read_user_engagement`, plus `publish_video` for video.
+
+```
+POST https://graph.facebook.com/<version>/<page-id>/feed
+  message=...&link=https://...
+POST https://graph.facebook.com/<version>/<page-id>/photos
+  url=https://.../image.jpg&caption=...
+Scheduled: add published=false&scheduled_publish_time=<unix time>   (10 minutes to 30 days from the request)
+```
+
+Pin a Graph API version in the URL (`v<major>.0`) and upgrade before Meta retires it.
+
+## Instagram professional account
+
+```
+POST https://graph.facebook.com/<version>/<ig-user-id>/media          (Facebook Login)
+POST https://graph.instagram.com/<version>/<ig-user-id>/media         (Instagram Login)
+  image_url=https://public.example.com/a.jpg&caption=...
+  or media_type=REELS&video_url=...
+  or media_type=CAROUSEL with children=<up to 10 container ids>
+-> { "id": "<container id>" }
+
+GET  .../<container id>?fields=status_code     IN_PROGRESS -> FINISHED (or ERROR; EXPIRED if not published within 24 hours)
+POST .../<ig-user-id>/media_publish   creation_id=<container id>
+GET  .../<ig-user-id>/content_publishing_limit   current usage against the 24-hour cap
+```
+
+- Media must be at a publicly reachable HTTPS URL; Meta fetches it.
+- There is a rolling 24-hour cap on API-published posts per account (carousels count as one). Meta's pages have stated different numbers over time; read `content_publishing_limit` instead of hard-coding it.
+- The API requires an Instagram professional (business or creator) account; personal accounts are not supported.
+- Captions: at most 2,200 characters, 30 hashtags and 20 @ tags.
+- Permissions: `instagram_business_basic` and `instagram_business_content_publish` (Instagram Login, `graph.instagram.com`), or `instagram_basic`, `instagram_content_publish` and `pages_read_engagement` (Facebook Login, `graph.facebook.com`).
+
+## Sources
+
+- X chunked upload: https://docs.x.com/x-api/media/quickstart/media-upload-chunked . Create post: https://docs.x.com/x-api/posts/create-post . Scopes: https://docs.x.com/fundamentals/authentication/oauth-2-0/authorization-code . Character counting: https://docs.x.com/fundamentals/counting-characters
+- LinkedIn Posts API: https://learn.microsoft.com/en-us/linkedin/marketing/community-management/shares/posts-api . little text: https://learn.microsoft.com/en-us/linkedin/marketing/community-management/shares/little-text-format . Videos: https://learn.microsoft.com/en-us/linkedin/marketing/community-management/shares/videos-api . Versioning: https://learn.microsoft.com/en-us/linkedin/marketing/versioning . Post length: https://www.linkedin.com/help/linkedin/answer/a528176
+- Facebook Pages posts: https://developers.facebook.com/docs/pages-api/posts
+- Instagram publishing: https://developers.facebook.com/docs/instagram-platform/content-publishing . Media reference (caption limits): https://developers.facebook.com/docs/instagram-platform/instagram-graph-api/reference/ig-user/media

package/skills/solidity-patterns/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: solidity-patterns
+description: Writes Solidity contracts for Ethereum and other EVM chains the safe way, applying checks-effects-interactions ordering, Ownable2Step or AccessControl roles, OpenZeppelin Contracts instead of hand-rolled tokens, a deliberate choice between immutable and UUPS or transparent proxy deployments with ERC-7201 namespaced storage, events for every state change, custom errors and basic gas hygiene, inside a Foundry or Hardhat project with tests. Use when creating or extending a smart contract, adding an ERC-20, ERC-721 or ERC-1155 token, deciding whether a contract should be upgradeable, or setting up a new Foundry or Hardhat workspace.
+license: MIT
+compatibility: Any Agent Skills host. Needs Foundry (forge) or Hardhat with Node.js to compile and test. Examples target Solidity 0.8.x and OpenZeppelin Contracts 5.x.
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: security
+  kete-loom/risk: runs-commands
+  kete-loom/requires: "forge"
+  kete-loom/owner: "Kete-org"
+---
+
+# Solidity patterns
+
+Write contracts that are boring on purpose: audited building blocks, state updated before any external call, every privileged function guarded, every change logged by an event, and tests that try to break it. Deployed code is public and usually permanent, so a bug is a loss, not a ticket. This is engineering guidance, not financial or legal advice.
+
+## Ground rules
+
+1. **Pin the compiler.** `pragma solidity 0.8.x;` with an exact version in `foundry.toml` (`solc_version`) or `hardhat.config` (`solidity.version`). 0.8 reverts on overflow by default; `unchecked { }` only where you proved the bound in a comment.
+2. **Use OpenZeppelin Contracts** (`@openzeppelin/contracts`, or `@openzeppelin/contracts-upgradeable` for proxies) for tokens, access control, `ReentrancyGuard`, `SafeERC20`, `ECDSA`, `EIP712`. Never copy-paste or re-implement an ERC standard. Pin the library version.
+3. **Checks-effects-interactions.** Validate inputs (checks), write storage (effects), then call other contracts or send ETH (interactions). Add `nonReentrant` on functions that make external calls and touch balances anyway.
+4. **Guard every privileged function** (`mint`, `pause`, `setFee`, `withdraw`, `upgradeTo...`, initializers). Default to `Ownable2Step` for a single admin or `AccessControl` for several roles; the owner should be a multisig or timelock in production, not a laptop key.
+5. **Events for every state change** an off-chain system or user cares about: transfers, role grants, parameter changes, upgrades, pauses. Index the fields people filter on (addresses, IDs), at most three indexed.
+6. **Custom errors** (`error InsufficientBalance(uint256 have, uint256 want);` with `revert InsufficientBalance(...)`) instead of revert strings.
+7. **Pull over push** for payouts: record what each address is owed and let it `withdraw()`; never loop over an unbounded array sending ETH.
+8. **No `tx.origin` for auth**, no `block.timestamp` or `blockhash` as randomness, no `selfdestruct`, no `delegatecall` to an address a user can influence.
+
+## Project layout
+
+Foundry (preferred for new work): `forge init`, then
+
+```
+src/            contracts
+test/           *.t.sol tests (forge-std Test), fuzz and invariant tests
+script/         *.s.sol deploy scripts (forge script)
+lib/            dependencies (forge install OpenZeppelin/openzeppelin-contracts)
+foundry.toml    solc_version, optimizer, remappings, [fuzz] runs
+```
+
+Hardhat: `contracts/`, `test/`, `ignition/modules/` or `scripts/`, `hardhat.config.ts`, dependencies from npm. Follow whichever the repo already uses; don't mix both without reason.
+
+Keys and RPC URLs come from environment variables or an encrypted keystore (`cast wallet import`), never from committed files.
+
+## Steps for a new or changed contract
+
+1. **Write the spec first** in the contract's NatSpec: who can call each external function, what invariants must hold (for example "sum of balances == totalSupply", "only owner can mint"), and what happens on failure.
+2. **Pick the building block.** Token: inherit `ERC20`, `ERC721` or `ERC1155` and add only what's needed (`ERC20Permit`, `ERC20Votes`, `Pausable`). Do not override `transfer` or `_update` hooks unless the spec needs it, and then call `super`.
+3. **Decide on upgradeability** using the table below. Write the answer and the reason at the top of the contract.
+4. **Write the contract** following the ground rules. Mark functions `external` when not called internally, state `immutable` or `constant` where possible, and visibility on everything.
+5. **Handle tokens defensively.** Use `SafeERC20` (`safeTransfer`, `safeTransferFrom`, `forceApprove`) for arbitrary ERC-20s. For deposits, measure the balance before and after if fee-on-transfer tokens are possible, or document that they're unsupported.
+6. **Test**: unit tests for each function and each revert, a test per access-controlled function proving a stranger is rejected, fuzz tests on amount inputs, and invariant tests for the spec's invariants (`forge test`, `[invariant]` in `foundry.toml`). Fork tests (`--fork-url`) when integrating live protocols.
+7. **Static analysis**: run `slither .` and fix or justify every finding. For the full audit procedure use the `smart-contract-security` skill.
+8. **Deploy** to a local node (`anvil`) and a testnet first with the same script you'll use on mainnet; verify the source on the block explorer.
+
+## Upgradeability: decide deliberately
+
+| Option | Choose when | Costs |
+|---|---|---|
+| Immutable contract | Logic is small, well tested, and trust minimisation matters | Bugs need a migration to a new address |
+| UUPS proxy (`UUPSUpgradeable`) | You need upgrades and want them cheap; upgrade logic lives in the implementation | Forgetting `_authorizeUpgrade` access control, or shipping an implementation without it, can brick or hand over the proxy |
+| Transparent proxy (`TransparentUpgradeableProxy`) | You want the admin path separated from user calls | Extra deploy cost; in OZ 5.x the proxy deploys its own `ProxyAdmin` owned by `initialOwner` |
+
+Rules for any proxy:
+
+- No constructor logic; use an `initialize` function with the `initializer` modifier, call every parent `__X_init`, and call `_disableInitializers()` in the implementation's constructor.
+- Use ERC-7201 namespaced storage (the OZ 5.x upgradeable contracts do) or append-only layouts; never reorder, remove or change the type of an existing state variable.
+- Check every upgrade with the OpenZeppelin Upgrades plugin (`@openzeppelin/hardhat-upgrades` or `openzeppelin-foundry-upgrades`) before deploying it.
+- Put upgrades behind a multisig and, where users hold funds, a timelock so they can exit.
+
+## Gas basics (after correctness)
+
+- Cache storage reads in memory inside loops; pack small types that are read together into one slot.
+- `calldata` instead of `memory` for read-only external array and struct arguments.
+- `immutable`/`constant` for values fixed at deploy.
+- Avoid unbounded loops over user-growable arrays; they become a denial of service once gas exceeds the block limit.
+- Measure with `forge test --gas-report` or `forge snapshot` before and after; never trade a safety check for gas.
+
+## Stop and ask the user
+
+- Before deploying or broadcasting anything to a mainnet, or to any network with real funds; confirm the network, chain ID and deployer address.
+- Who should own admin roles in production (EOA, multisig, timelock, or renounced).
+- Whether the contract should be upgradeable at all, when the spec doesn't say.
+- Before writing token economics, fees or anything that holds user funds and will launch without a professional audit; recommend one.
+
+## Never
+
+- Never put private keys, mnemonics or RPC keys in source, tests or scripts.
+- Never write a custom ERC-20/721 from scratch, a custom signature scheme, or inline assembly to save gas without a written reason and tests.
+- Never leave an initializer unprotected or an implementation contract uninitialized.
+- Never claim a contract is secure; say what was tested and what wasn't.
+
+## Before you finish
+
+Report: compiler version, libraries and versions, upgradeability choice and why, roles and who holds them, events emitted, test and fuzz results (`forge test` output summary), Slither results, and what still needs an external audit.

package/skills/solidity-patterns/evals/triggers.json

@@ -0,0 +1,16 @@
+{
+  "should_trigger": [
+    "Write an ERC-20 token contract with a capped supply and an owner-only mint using Foundry",
+    "Should our staking vault contract be upgradeable with UUPS or deployed immutable?",
+    "Set up a new Foundry project with OpenZeppelin and a basic NFT contract",
+    "Add a withdraw function to my Solidity escrow contract that follows checks-effects-interactions",
+    "Refactor this Solidity contract to use custom errors and emit events when the fee changes"
+  ],
+  "should_not_trigger": [
+    "Audit our lending protocol contracts for oracle manipulation and reentrancy before launch",
+    "Connect MetaMask to our React app with viem and show the user's USDC balance",
+    "Review the Solidity diff in this PR for missing access control and storage collisions",
+    "Integrate Stripe subscriptions into the billing page",
+    "Write a Rust program that parses a CSV of transactions"
+  ]
+}