DEV Community: GBTI Network

Upwork will now take a job post from your AI agent

GBTI Network — Fri, 14 Aug 2026 02:50:56 +0000

By @gbti, GBTI Network Member. Originally published on gbti.network.

On August 10, 2026, Upwork announced a server for the Model Context Protocol. An agent can now post a job, shortlist freelancers, prepare an offer and summarize proposals as they arrive, without anyone opening a browser tab.¹

Before getting to why Upwork built one, the protocol itself needs explaining. An MCP server resembles a REST API, and Upwork's sits on the same APIs its website and public API already use.² The difference is who does the calling. A REST endpoint waits for code a developer wrote against its documentation. An MCP server publishes a typed list of what it can do, things like searching jobs, sending a message or creating a milestone, and the assistant, the agent app you added the server to, puts that list in front of the model, then makes whichever calls the model picks. No page is fetched, nothing is rendered, no human clicks anything, and the result lands in the conversation you are already having. Think of an MCP server as an extension to the assistant rather than to the model: the model arrives able to converse, and the server gives the assistant a set of things it can now do on your behalf.

Peter Sanborn, Upwork's chief business officer, described what prompted it:

We started seeing something remarkable this year: AI agents attempting to log into Upwork on their users' behalf to search for the right person to hire.¹

A marketplace watched software try to get in through the front door and decided to install a door.

Any MCP-compatible assistant can reach the Upwork server

The announcement names Claude, ChatGPT and Cursor, then adds "any MCP-compatible product."¹ The documentation goes further, listing Claude on web, desktop and Code, Cursor and Codex in app and CLI form, and naming Windsurf, Cline, VS Code and Goose as examples of anything else that speaks remote MCP with OAuth.²

Upwork's documentation gives claude.ai/directory/connectors/upwork as the recommended install path, with a ChatGPT listing still to come.² That address is not a public page. It opens Claude's own connector directory inside the app, where the entry credits Upwork as the developer and exposes 46 tools under names like upwork__find_freelancers, upwork__confirm_draft and upwork__end_contract.³

Anthropic files it under Community rather than verified, noting that community connectors "have undergone automated reviews" and "may not yet meet the quality tier of verified connectors". The notice beside it reads "Only use connectors from developers you trust. Anthropic does not control which tools developers make available and cannot verify that they will work as intended or that they won't change."³

Every Upwork account gets it free, but your assistant plan may block it

Upwork's MCP server is open to every Upwork user at no additional cost: "available today for every Upwork client and freelancer, at no additional cost."¹ The documentation says the same, that it is "free to use with any Upwork account."²

ChatGPT offers custom MCP connectors on Plus, Pro, Team, Business and Enterprise, which leaves a free ChatGPT account unable to add the Upwork server at all; a Claude free account can add it, but only as its one permitted connector; and ChatGPT's Instant mode cannot make MCP tool calls whatever the plan.²

On the marketplace side, universal availability decides who benefits. A capability that ships to everyone at once and costs nothing confers no advantage by being adopted, only on people who restructure how they work around it.

What the agent can do: mostly administration, plus one delivery step

The announcement lists the prompts it expects:¹

"My prototype is almost ready to launch. Help me find a freelancer on Upwork who can test it end-to-end before it goes live."
"I'm launching a new ecommerce product and need help with paid acquisition. Post a job to Upwork and summarize proposals as they arrive."
"Show me this week's jobs that match my skills and fit my budget and availability."
"Summarize my Upwork client messages and flag which ones need a follow-up today."

Three of the four are administration. Finding, posting, summarizing, triaging. The agent handles the paperwork around the work rather than the work.

The documentation covers a third role the announcement skips. Alongside clients and freelancers, agencies get a team-wide view: one call returning every member's invitations, offers, messages and contracts.²

One capability does touch delivery. A freelancer can submit milestone work through the connector.² With job posting, proposal review and client messaging already inside the agent, the only steps reserved for a person are the binding ones, and a pipeline running from brief to delivered work without anyone opening a browser starts to look like a question of policy rather than plumbing.

How a client is meant to de-risk the expert they pick

Upwork's answer is identity and money. Every connection runs through an authenticated account, and the company leans on its existing identity verification, escrow and dispute protections.¹ Those cover fraud and non-delivery, and they say nothing about whether the three names in front of you are the right three. We read the documentation looking for the ranking inputs and they are not disclosed: a client can "Pull up ranked profiles" and "review proposals received, with ranked summaries", and the page never names Job Success Score, Top Rated, or any other quality signal Upwork already publishes.² The word doing the work is "ranked", and nothing says ranked by what.

The controls on the agent itself are documented far better than the ones on the shortlist. Every write action is drafted for separate confirmation, binding financial actions complete on upwork.com rather than inside the agent, and connecting nonetheless "grants the full set of scopes", so there is no way to attach an agent to job search while withholding messaging, contracts or financial history.² Rohit Singh, founder of Populosof and one of two customers quoted in the announcement, put the upside plainly: "every action that changes anything is previewed and requires my explicit confirmation."¹ So a client de-risks the transaction and picks the expert on trust.

Are AI Agents Themselves Able to Shop On Upwork?

Upwork's FAQ asks whether an AI agent can hire on your behalf without you, which is the client side of the question, and answers: "Not today. In the current release, a person confirms every binding action."²

Read the hedge. "Not today" and "in the current release" are the words of a company that has thought about the other version and has not shipped it.

How does the affiliate program work with MCP?

Upwork's affiliate program pays 70% of a new client's first contract spend, capped at $150, tracked through the Impact platform with a cookie window measured in weeks.⁴ Every part of that mechanism assumes a browser. A link is clicked, a cookie is set, a signup is attributed.

An MCP conversation runs directly between the agent and the server, so the browser, the click and the cookie that mechanism depends on never come into existence. A founder who asks Claude to post a job and hires someone that afternoon leaves no referral trail, so whoever recommended Upwork in the first place is invisible to the attribution system.

Will Anthropic and OpenAI demand a share of the profit? There are arguments for it, most certainly, however there does not seem to be any sign of merchants needing to register with large language models for commission sharing. It is not a crazy model. We would break off a point for the right of representation.

What an agent-driven marketplace means for a vetted network like Codeable

Disclosure: the Codeable link here is a referral link. GBTI Network is a big fan of the Codeable community for React and WordPress work.

Codeable is a closed talent network that accepts roughly 2.2% of applicants, where a client brief goes to a small group of pre-vetted experts who discuss it in a shared workroom and independently estimate, and the platform returns one averaged fixed price against a 17.5% fee.⁵

A network like Codeable has several reasons to publish an MCP server of its own, and they are mostly the reasons Upwork did. A connector puts a vetted talent pool inside the tools its best clients already work in. It makes that same pool reachable by the network's own contractors, who could assemble a team on demand instead of routing it through a coordinator. A devops lead could pipe work straight to the embedded developer they already trust, without rebuilding the relationship each time there is something to do. And every party keeps agentic help for the transactional layer, the scoping and scheduling and status chasing, which is the part none of them wanted to be doing by hand.

Cover photograph by Polina Zimmerman on Pexels.⁶

The resource shared in this post is a new article published by GBTI Network member GBTI Network.

Are you a writer, musician, or product developer? We would love to support your work on the GBTI Network. For more information about how to join our community visit https://gbti.network

To follow GBTI Network's work more closely, consider joining our network and subscribing to them directly: https://gbti.network/members/gbtilabs/

Upwork Inc., "Upwork Talent Is Now Everywhere AI Works," press release via GlobeNewswire, August 10, 2026. Source of the launch date, the example prompts, the escrow and dispute language, and the quotes from Sanborn and from Singh, who is one of two customers quoted; the other is Allison Lee. Sanborn's linked profile was opened and confirmed on August 13, 2026: globenewswire.com ↩
Upwork, "Upwork MCP Server," product documentation dated August 4, 2026, read in a browser on August 12, 2026; the page returns 403 to non-browser clients. Source of the compatible-agent list, the capability sets, the draft-confirm and binding-actions rules, the per-assistant plan requirements, the full-scopes line, the same-APIs comparison and the FAQ answers quoted above. It says "ranked profiles" and "ranked summaries" and names no quality signal anywhere on the page, neither Job Success Score nor Top Rated: upwork.com/ai/mcp ↩
Claude connector directory, Upwork entry, captured on August 13, 2026 from a signed-in session and supplied by the author. The one claim here resting on a logged-in view: the directory is served inside the application and the address returns 403 to signed-out clients, so the screenshot above is the evidence rather than a link anyone can follow. Source of the Community label and its notice, the "Developed by Upwork" credit, the disclaimer, and the stated count of 46 tools, of which eight are visible. ↩
Published summaries of the Upwork affiliate program, read August 12, 2026. Source of the 70% first-contract commission, the $150 cap and the Impact platform. Reported cookie windows vary by link type and none of these figures appears on Upwork's own affiliate page, so the window is given as a range. The conclusion drawn about MCP attribution is ours: upwork.com/affiliates ↩
Codeable, "Codeable vs Upwork," read August 12, 2026, for "roughly 2.2% of applicants are accepted" and the fixed 17.5% fee on hourly rates of $80 to $120: codeable.io/blog/codeable-vs-upwork. The workroom and the averaged estimate are described on the company's how-it-works page. ↩
Cover photograph, "Person Holding Black And Silver Laptops", by Polina Zimmerman on Pexels, used under the Pexels License: pexels.com/photo/3747130 ↩

App Clips let someone use part of your iOS app without installing it

GBTI Network — Wed, 12 Aug 2026 03:20:35 +0000

By @gbti, GBTI Network Member. Originally published on gbti.network.

We came across App Clips recently and realized how little we knew about them beyond the name. An App Clip runs part of an iOS app with no install: the person never visits the App Store, downloads anything, or creates an account. They do the one thing they came to do and move on, and the software removes itself later without being asked.

App Clips have existed since iOS 14 in 2020, and Apple is still adding to them, most recently in June 2025.¹

How it works

An App Clip is a second, smaller build of an app that already exists, made from the same project and sharing that app's code.²

That smaller build compiles down to its own binary, and that is what makes an install unnecessary: someone runs the clip without installing the full app, and the system removes it from the device after a period of inactivity.³

Everything depends on that binary staying small, so the size limit is the constraint that decides what an App Clip can be. It varies by iOS version and by how the clip is launched: 10 MB on iOS 15 and earlier, 15 MB on iOS 16 and earlier. iOS 17 raises the ceiling to 100 MB, but only for clips launched digitally, from a website or Spotlight, and never from an App Clip Code, a QR code, or an NFC tag. The one route that keeps those physical launches at 100 MB is the demo link App Store Connect generates.

If a tapped link can run part of an app, it is fair to wonder what stops any link from running anything. Apple reviews every app on the store, and a clip ships as part of one.⁴ Launching one is governed separately and checked every time: a developer has to prove they own the domain a link points at, by publishing a file on it that names the App Clip allowed to launch from there.⁵ It is the same mechanism behind a link that opens an app instead of a browser page.

Which leaves the question of whether a clip is a substitute for an app or an addition to one. Apple settles it by requiring the full app to contain everything the clip offers, so a clip is a way to hand someone the useful part of an app before they commit to the rest.⁶ People can reach one eight different ways, from a QR code or an NFC tag to a link shared in Messages.⁷

How it is used in the real world

The public record here is thin, but named deployments exist, and they sort into three kinds: reached at a physical place, sent to someone who is not the customer, and offered as a trial.

ExxonMobil

ExxonMobil put tap to pay at the pump in 2020, one of the examples Apple advertised from day one. The Apple Store used a barcode scan in its own stores to pull up accessory details in 2021, and ParkWhiz put an NFC tag at the spot so someone could pay without installing anything. Panera Bread sits off to the side of this group: its ordering flow comes through Apple Maps rather than something you scan.

SignEasy

SignEasy lets someone sign a document that was sent to them, with no install required of the signer. Parcel tracks a single package from a shared link. Flash Note Cards makes and shares cards inside a conversation.⁸ None of those people are the customer. They were handed a thing and needed to deal with it, the strongest argument for the whole feature, and not the one Apple leads with.

Elloveo

Elloveo, a free trial of a children's science app, is the single early example on record.⁸ It is also the kind of use Apple has invested in most recently, which is what the June 2025 demo work is for.

What every one of them shares, across all three kinds, is that the task happens to finish in about a minute, a pattern in what has been built so far, not a limit Apple sets.

No source reports an install lift, a conversion rate, or a completion figure for any of them. We looked specifically for outcomes: a search for App Clip campaign results returns marketing case studies about other things entirely, and a search for App Clip business results returns mobile-ordering and micromobility material with no App Clips in it. We would rather report that absence than dress up unrelated statistics as evidence.

Both sources are dated: the Heady teardown is from March 2021 and the AppleInsider piece is from December 2022.⁸⁹ Nothing comparable has surfaced since.

Where it might fit next

Picture the same kind of task wherever it lands next: a diner ordering without installing anything, a driver tapping to pay at the pump, someone trying one level of a game before deciding whether to buy the rest. An App Clip fits a task that small and that self-contained, and stops fitting the moment it needs to remember who you are or run while nobody is looking, both hard platform limits.

The case worth watching is try before you buy on the devices carrying a LiDAR scanner. This already works inside a full app: point the camera at the room and the sofa appears at true scale, sitting behind the coffee table rather than floating in front of it. As an App Clip the same thing would run straight from the product page, with nothing installed and nothing left behind once the decision is made.

Two constraints decide where that works. LiDAR narrows the audience to the devices that have it, so accurate placement is an enhancement rather than the whole experience. And while putting a sofa in your living room sounds like the in-person scenario App Clips were sold on, the 100 MB ceiling belongs to clips launched digitally, and a 3D model is heavy. The door that fits is the product page rather than a code printed on a showroom tag, unless the clip ships through the demo link, which is the one physical route Apple allows the larger budget.

Tell us what it was like

If you have built an App Clip, or scoped one and decided against it, the useful part is what documentation never captures: what App Store Connect was like to configure, whether people found the thing at all, whether it moved installs or replaced them, and what you would not do again. A report that it was not worth building is as useful as one that it was.

Leave a comment, or bring it to Discord if it turns into a longer conversation.

Cover photograph by Douglas Mendes on Pexels.¹⁰

The resource shared in this post is a new article published by GBTI Network member GBTI Network.

Are you a writer, musician, or product developer? We would love to support your work on the GBTI Network. For more information about how to join our community visit https://gbti.network

To follow GBTI Network's work more closely, consider joining our network and subscribing to them directly: https://gbti.network/members/gbtilabs/

Apple, "App Clips updates," Apple Developer Documentation, read August 10, 2026. The June 2025 entry covers demo App Clips, the autogenerated demo URL, and Background Assets: developer.apple.com ↩
Apple, "Creating an App Clip with Xcode," Apple Developer Documentation, read August 10, 2026. Source of the target-based architecture and the guidance to share code between the App Clip and the full app rather than duplicate it, refactoring to modular, shared code "to avoid duplicating code": developer.apple.com ↩
Apple, "App Clips," Apple Developer Documentation, read August 10, 2026. Source of the inactivity-removal behavior: developer.apple.com ↩
Apple, "App Review Guidelines," Apple Developer Documentation, re-read August 11, 2026. Source of the review requirement: "every app is reviewed by experts." The document names App Clips twice, requiring that "all App Clip features and functionality must be included in the main app binary" and that they carry no advertising. It does not say when review happens, so no timing is claimed above: developer.apple.com ↩
Apple, "Supporting associated domains," Apple Developer Documentation, read August 10, 2026. Source of the apple-app-site-association file format and the appclips key that authorizes a domain to launch a given App Clip: developer.apple.com ↩
Apple, "Choosing the right functionality for your App Clip," Apple Developer Documentation, read August 10, 2026. Source of the size ceiling, the demo-link conditions, the requirement that "the full app must include the same functionality as the App Clip," and the background and privacy limits: developer.apple.com ↩
Apple, "Configuring App Clip experiences," Apple Developer Documentation, read August 10, 2026. Source of the eight invocation methods: developer.apple.com ↩
Heady, "The App Clips Playbook: 5 Inspiring Examples and Teardowns," March 17, 2021. Source of the ParkWhiz, SignEasy, Parcel, Elloveo, and Flash Note Cards examples. Notably it reports no outcome figures for any of them: heady.io ↩
Lila Riesen, "What happened to Apple's App Clips," AppleInsider, December 11, 2022. Source of the ExxonMobil, Apple Store, and Panera Bread examples: appleinsider.com ↩
Cover photograph by Douglas Mendes on Pexels, used under the Pexels License: pexels.com/photo/14666034 ↩

AirLLM runs a 70B model on a 4GB GPU by refusing to load it all at once

GBTI Network — Wed, 12 Aug 2026 01:05:36 +0000

By @gbti, GBTI Network Member. Originally published on gbti.network.

Most advice about running a large language model locally starts with the same gate: check your VRAM, then pick a model that fits inside it. A 70B model in half precision wants roughly 140GB, so the usual answer is to quantize it down, distill it, prune it, or accept a smaller model.

AirLLM takes a different position. It argues the gate is an artifact of how models are loaded, not a law of the hardware.¹

The idea

A transformer runs one layer at a time. Layer 1 produces an output, that output feeds layer 2, and so on to the end. At the moment layer 40 is computing, layers 1 through 39 have already done their work and layers 41 onward have not started. Nothing requires all of them to be sitting in VRAM simultaneously. It is simply convenient, and until recently there was little reason to arrange things otherwise.

AirLLM shards the model to disk and loads each layer as its turn arrives, then releases it. Peak VRAM stops tracking the size of the model and starts tracking the size of its largest single layer. The project's headline claim follows from that: 70B inference on a single 4GB card, with no quantization, distillation, or pruning involved.¹

Two details do the practical work. Weights are read through memory-mapped files, so a layer does not need a full copy in system RAM on its way to the GPU. And a prefetch thread pulls layer N plus one from disk while the GPU is still working on layer N, which the project measured at roughly a ten percent improvement over loading strictly in sequence.²

For sparse mixture-of-experts models the same reasoning goes further. A token routes to a small number of experts, so AirLLM streams individual experts rather than whole layers. The project reports Kimi K3, at 2.8 trillion parameters, running in 3.72GB of VRAM measured end to end on a single RTX 6000 Ada.¹

What it costs

This is where a careful reading matters, because the framing invites a misunderstanding.

AirLLM does not make a 70B model fast on a 4GB card. It makes a 70B model possible on a 4GB card. Every layer crosses the disk-to-GPU boundary on every forward pass, which as one write-up puts it converts a memory bottleneck into a disk bottleneck, feasible only because an NVMe drive reading at several gigabytes per second can keep the GPU fed at reduced throughput.³

The most useful framing we found comes from Umesh Malik, who points out that the floor is arithmetic rather than opinion. A 70B model in half precision is roughly 140GB, and every token has to pull all of it past the GPU, so the storage bandwidth alone sets a minimum: about 20 seconds per token on a 7GB/s Gen4 NVMe, about 40 on Gen3, and around 255 seconds on a SATA SSD. Those are pure transfer floors that assume zero compute and zero overhead. Quantizing to 4-bit cuts the bytes per token to roughly 35GB and the Gen4 floor to about 5 seconds.⁴

Reported speeds from people who ran it vary enough that the spread is itself the finding, which is a good reason to read several accounts rather than one:

Source	Reported speed
Dashen Tech	typically 1 to 3 tokens per second⁵
explainx.ai	0.5 to 2 tokens per second, against 10 to 20 for a resident-in-memory setup⁶
Nerd Level Tech	about 0.7 tokens per second for Llama 2 70B on NVMe with a dedicated GPU, and about 0.07 on an M2 MacBook Pro, roughly 50 tokens in 12 minutes⁷
Community reports cited by Umesh Malik	as low as 0.003 tokens per second, at which rate a 108,000-token output would take 416 days⁴

Abrarqasim frames the comparison bluntly: a response that a 4-bit quantized 70B under llama.cpp returns in 20 to 90 seconds can take 5 to 20 minutes through AirLLM, putting it somewhere between 50 and 200 times slower than either a paid API or a quantized local model.⁸ Nerd Level Tech reaches the same conclusion from the other direction, calling it a genuine accessibility achievement but not a replacement for production inference tools like llama.cpp or vLLM.⁷

Those are the terms the project is offering, and they suit a batch job or an overnight evaluation, where the work can run unattended and the wait costs nothing. They suit anything interactive very poorly.

One cost that is easy to miss, and that we have not seen the project address: Abrarqasim notes that streaming an entire model off the drive for every token puts serious mileage on consumer SSDs, which are typically rated somewhere between 600 and 1200 terabytes written. Sustained use draws down a measurable share of that budget.⁸ If you plan to leave a job running for days, that is worth thinking about before you start.

The project does offer a speed lever: optional block-wise quantization compression, which it reports at up to three times faster inference with what it describes as almost ignorable accuracy loss.⁹ Note that turning it on means the run is quantized, which trades away the specific thing that makes the unquantized claim interesting. Dashen Tech adds a fair counterpoint here: because the bottleneck is disk throughput rather than compute, only the weights need compressing, which is an easier thing to do without hurting accuracy than quantizing an entire inference path.⁵

Where it stands

AirLLM is Apache-2.0 licensed and has been in development since June 2023. At the time of writing it carries about 29,800 stars and 3,100 forks, with commits landing this month.¹⁰ It has had its rounds of attention on Hacker News, and enough independent write-ups now exist that a reader can triangulate the claims rather than take the README at its word.¹¹¹²

Installation is a pip package, and the entry point is deliberately unremarkable:

from airllm import AutoModel

model = AutoModel.from_pretrained("Qwen/Qwen3-32B")

The same single line reportedly scales up, with the project citing Qwen3-235B at around 3GB and DeepSeek-V3 at 671B in around 12GB.¹ Version 3.0, released in June 2026, added FP8 support alongside Qwen3, Llama 3.x and 4, DeepSeek V2 and V3, Phi-4 and Gemma. Earlier releases added macOS support and CPU inference.²

Newer support can carry sharp edges. The Kimi K3 path, for example, requires compressed-tensors and flash-attn, a CUDA 12 build of torch because no prebuilt flash-attention wheel exists for CUDA 13 yet, and transformers 4.56.x because the model's remote code does not load on 5.x.² That is worth knowing before setting aside an evening for it.

Why it is worth a look

The interesting part is not the specific numbers, which will move. It is the reframing.

Treating VRAM as a hard ceiling makes hardware the thing that decides which models you are allowed to run at all. Treating it as a working buffer makes hardware decide how long you wait. The second framing is the friendlier one for anyone learning, evaluating, or building on a machine they already own, and it is a useful reminder that some constraints are conventions that nobody has yet had a reason to question.

We have not run it, and we would like to hear from people who have

To be plain about it: nobody at GBTI Network has used AirLLM. Everything above comes from the project's own documentation and from third-party write-ups, cited as such, and none of the performance figures have been reproduced here. Treat this as a pointer to something worth investigating, not as a review.

That gap is exactly where the network is useful. If you have run AirLLM, we would like to hear the specifics that documentation never captures: what card and what storage, which model, what token rate you actually saw, whether the compression option was worth enabling, and what broke on the way. A report that it did not work is as useful as one that it did.

Leave a comment on this article, or bring it to Discord if it turns into a longer conversation. If enough measurements come in, we will write them up as a follow-up and credit the members who supplied them.

Photographs by Sergei Starostin¹³ and Andrey Matveev¹⁴, both on Pexels.

The resource shared in this post is a new article published by GBTI Network member GBTI Network.

Are you a writer, musician, or product developer? We would love to support your work on the GBTI Network. For more information about how to join our community visit https://gbti.network

To follow GBTI Network's work more closely, consider joining our network and subscribing to them directly: https://gbti.network/members/gbtilabs/

AirLLM project README, accessed August 7, 2026: lyogavin/airllm ↩
AirLLM release notes in the project README (v2.5 prefetching, v2.8.2 macOS, v2.10.1 CPU inference, v3.0 FP8, and the July 2026 Kimi K3 entry), accessed August 7, 2026. ↩
Starlog, "Running 70B LLMs on a 4GB GPU: How AirLLM Trades Speed for Accessibility," accessed August 7, 2026: starlog.is ↩
Umesh Malik, "Run 70B LLM on 4GB GPU: AirLLM's Real Tradeoff," accessed August 7, 2026. The per-storage-tier floors and the 416-day figure are his: umesh-malik.com ↩
Dashen Tech, "The Complete AirLLM Guide: Run 70B LLMs on a 4GB GPU," accessed August 7, 2026: dashen-tech.com ↩
explainx.ai, "AirLLM: Run 70B LLM on 4GB GPU, No Quantization," accessed August 7, 2026: explainx.ai ↩
Nerd Level Tech, "AirLLM Tested: Run a 70B LLM on a 4GB GPU, Does It Work?," accessed August 7, 2026: nerdleveltech.com ↩
Abrarqasim, "AirLLM Review: The Truth Behind Running 70B LLMs Locally," accessed August 7, 2026. The 50x to 200x comparison and the SSD endurance point are his: abrarqasim.com ↩
AirLLM README, "Model Compression - 3x Inference Speed Up," which cites block-wise quantization research at arXiv:2212.09720 ↩
GitHub repository metadata for lyogavin/airllm, read August 7, 2026: Apache-2.0, created June 12, 2023, most recent push August 6, 2026. ↩
Hacker News discussion, "AirLLM 70B inference with single 4GB GPU": news.ycombinator.com ↩
Bright Coding, "AirLLM: Run 70B Models on 4GB GPUs Without Compromise," February 27, 2026: blog.brightcoding.dev ↩
Memory modules photograph by Sergei Starostin on Pexels, used under the Pexels License: pexels.com/photo/6636474 ↩
Storage media photograph by Andrey Matveev on Pexels, used under the Pexels License: pexels.com/photo/35147150 ↩

VSCode Extension: Terminal Session Profiles

GBTI Network — Tue, 04 Aug 2026 02:20:57 +0000

By @atwellpub, GBTI Network Member. Originally published on gbti.network.

Over the past two years, the introduction of tools such as Claude Code has made terminal management a much more central part of the day-to-day development workbench. Terminals are no longer temporary scratch space. They often represent distinct, long-running parts of a project, each with its own name, working directory, and purpose.

Our own terminal configuration commonly includes several named Claude Code sessions, each with its own name inside Claude Code and remote control enabled by default. We also tend to keep one PowerShell terminal open for running Windows commands and one WSL terminal for working directly within Windows Subsystem for Linux. It is therefore not unusual for us to have three to five terminal tabs open within a single project.

VS Code already supports persistent terminal sessions, but its native features are spread across terminal profiles, tasks, settings, and workspace permissions.

Terminal Session Profiles brings those pieces into one UI and adds reusable workspace or global profiles, ordered startup commands, automatic reprovisioning, and optional Claude session resume commands.

Terminal session profile manager

A profile is a saved terminal setup: which shell to open, where, and what to run once it is ready. Create one from the sidebar's ＋, or right-click any terminal and choose Save as Instance Profile to start from a terminal you already have open.

Profiles can be created from the Session Profiles sidebar or saved from a terminal that is already open. Once created, each profile remains available within the project and can be launched whenever it is needed.

A typical project might include separate profiles for several named Claude Code sessions, a development server, a build watcher, a general PowerShell terminal, and a WSL terminal. Instead of manually rebuilding each of these environments, they become reusable parts of the project.

Each profile includes:

A profile name
A shell
A working directory
An ordered list of commands

Commands are replayed literally and in the order they are written. Every command except the final one is awaited before the next begins. This allows a profile to prepare an environment before launching a long-running process such as an agent, development server, or file watcher.

For example, a profile can use:

claude --resume ClaudeCodeSessionName

to reopen a particular named Claude Code session.

This allows each terminal profile to correspond directly with a specific Claude Code session. A project can maintain several independently named agents, each launched in the correct working directory with its intended session restored.

Commands are not limited to coding agents. A profile can also activate an environment, start a local server, launch a build process, open a project-specific shell, or perform any other command-line preparation the project requires.

Profiles can optionally be added to the terminal + dropdown as named terminal profiles. This allows them to remain accessible through VS Code’s familiar terminal controls while still benefiting from the command replay managed by the extension.

Restoring profiles after a restart

VS Code includes native terminal persistence, but restoring a terminal tab is not necessarily the same as restoring the terminal session that previously occupied it.

A restored tab may retain its old name and scrollback while reopening as a new default shell with none of its previous processes running. The tab looks familiar, but the environment it represented is no longer there.

Terminal Session Profiles handles the other half of that recovery.

Profiles that were running are remembered per workspace. When the project is opened again, the extension identifies the restored terminal tabs associated with those profiles and relaunches them using the correct shell, working directory, and command sequence.

Restoration happens automatically by default. It can also be started manually through the Restore control in the status bar.

Before replacing a restored terminal, the extension compares the process recorded when the profile was launched with the process that returned. If the original process genuinely survived, the terminal is left alone rather than being terminated and recreated.

The objective is simple: reopening a project should also restore the terminal environment that belongs to it.

Optional workspace layout

By default, VS Code places the terminal in a horizontal panel beneath the primary workspace, while the Explorer, editor, and AI chat interface occupy the taller areas above it. This arrangement reflects a workflow in which the terminal is treated as a supporting tool rather than one of the main places where work happens.

That was no longer true for us. As Claude Code and other terminal-based tools became a larger part of our development process, the terminal became just as central as the editor, and sometimes more important. We wanted the option to bring it into the primary workspace as its own column, alongside the Explorer, editor, and chat interface, rather than leaving it confined to a secondary row at the bottom of the IDE.

Once each of these areas became a meaningful part of the daily workbench, we also needed better ways to control focus and move quickly between them. The layout enhancements provide status-bar controls for showing and hiding the Explorer, editor, terminal, and chat areas, with each workspace remembering its own arrangement.

The layout controls VS Code’s real interface containers rather than replacing or recreating them. The Explorer remains the standard Explorer. The terminal retains its normal terminal list and controls. Claude Code, Codex, and other chat interfaces continue to operate within their existing panels.

This is important because the layout enhancement does not attempt to introduce a replacement workspace. It provides faster controls for arranging the tools already present in VS Code.

One column always remains visible, preventing the workspace from being reduced to an empty window. A Reset Layout command restores the standard arrangement whenever needed.

We felt these improvements belonged naturally within the same extension because they address the workspace surrounding the terminal sessions it manages. The layout remains entirely optional and can be disabled through the extension settings without affecting session profiles, command replay, or terminal restoration.

Independent features

The terminal session profile manager and the column layout are related enhancements, but neither depends on the other.

Disabling the column layout does not disable profiles. Saved profiles can still be launched, their commands can still be replayed, and active profile sessions can still be restored when a project reopens.

Layout preferences are also remembered separately for each workspace. A project in which the layout has been disabled will remain that way across restarts, while another workspace can continue using the column arrangement.

There is deliberately no master switch inside the extension that disables every feature at once. The column controls manage the layout, while the session settings manage profile restoration. The extension itself can still be disabled through VS Code’s Extensions view.

Keyboard and workspace controls

The extension includes commands for managing profiles, restoring sessions, navigating the column layout, and resetting the workspace.

Default shortcuts include:

Action	Shortcut
Toggle Explorer	`Ctrl+Alt+1`
Toggle editor	`Ctrl+Alt+2`
Toggle terminal	`Ctrl+Alt+3`
Toggle chat	`Ctrl+Alt+4`
Open a new terminal in the terminal column	Ctrl+Shift+`
Grow the focused column	`Ctrl+Alt+Right`
Shrink the focused column	`Ctrl+Alt+Left`

Additional commands are available through the Command Palette and status-bar controls for creating profiles, editing profiles, restoring the last session, enabling or disabling the layout, and resetting the workspace arrangement.

Install

Search for Terminal Session Profiles in the VS Code Extensions view.

You can also install it through Quick Open with Ctrl+P:

ext install GBTI.gbti-terminal-sessions

Terminal Session Profiles is published through the Visual Studio Marketplace as:

GBTI.gbti-terminal-sessions

It is also available through Open VSX for VSCodium and compatible editors.

Terminal Session Profiles is free, open source, and licensed under MIT.

The resource shared in this post is a new product published by GBTI Network member Hudson Atwell.

Are you a writer, musician, or product developer? We would love to support your work on the GBTI Network. For more information about how to join our community visit https://gbti.network

To follow Hudson Atwell's work more closely, consider joining our network and subscribing to them directly: https://gbti.network/members/atwellpub/

Resolve Open Questions: a /qa Skill for Claude Code

GBTI Network — Fri, 31 Jul 2026 17:22:00 +0000

By @atwellpub, GBTI Network Member. Originally published on gbti.network.

Claude Code loads any markdown file at .claude/skills/<name>/SKILL.md as a reusable slash command (a "skill"). This one gives your agent a /qa command that stops before it builds, pulls every unresolved decision into a single batch of questions, and refuses to write code until you have answered them.

It exists because open questions have a habit of surfacing at the wrong end of the work. A sprint finishes, and only then does the agent raise the decisions it should have raised at the start, at exactly the point where acting on them means redoing something.

The mechanism is plan mode, invoked deliberately. The agent puts ITSELF into a read-only state, does its research there, asks everything it found in one batch, and only then acts. That ordering is the whole feature.

Install

Create .claude/skills/qa/ in your repo, or ~/.claude/skills/qa/ to have it in every project.
Save the file below as SKILL.md inside it.
Type /qa in Claude Code.

Nothing to configure. The skill reads your project, not a config file.

The skill file

---
name: qa
description: ">"
  Resolve the open questions before the work proceeds. Invoke for "/qa", "/qa continue", "/qa proceed",
  "/qa deep", "/qa <topic>", or when the user asks you to ask your questions first, clarify before
  building, or answer the things you just raised. By default it interrogates only YOUR OWN LAST REPLY:
  the questions, options and flagged decisions already sitting in it. "/qa deep" runs the full
  six-category sweep instead. Every mode enters plan mode; "continue" and "proceed" skip the plan
  approval and build straight from the answers.
---

# /qa: resolve the open questions before building

The point of this command is to move every decision that is the user's call OUT of your head and
into one batch of questions, answered before any code is written. No silent defaults, no drip of
ad-hoc questions later.

The common case is small and cheap: a reply just ended with open questions in it, and the user wants
those answered properly instead of letting them evaporate. That is the default. The exhaustive sweep
is a separate, deliberate mode, because it costs real tokens and most invocations do not need it.

## Read the argument first, it selects the mode

`continue`, `proceed` and `deep` are reserved words. Anything else is a topic.

| Invocation | Mode |
|---|---|
| `/qa` | **Ask and hold, last reply.** Enter plan mode (`EnterPlanMode`), interrogate your own last reply, ask what it left open, then present a plan for approval (`ExitPlanMode`). Write nothing until approved. |
| `/qa continue` or `/qa proceed` | **Ask and go.** Identical, minus the confirmation before acting: once the answers land you build straight from them, with no plan written for review. |
| `/qa deep` | **Full sweep.** Step 2's six categories instead of the last-reply scope. Use when starting real work, not when closing out a reply. |
| `/qa deep continue` or `/qa deep proceed` | Full sweep, no approval round. Scope and approval are independent. |
| `/qa <anything else>` | **Scoped.** The trailing text names the subject to interrogate. Add `continue` or `proceed` to drop the approval round for it. |

Every mode enters plan mode and holds its read-only discipline until the questions are answered. The
question-asking discipline in step 3 is identical in all of them; only the SCOPE and the approval
round change.

## Step 1: verify before you ask

Never ask what the repository can answer. Check the claims your questions rest on before putting them
to the user, so every question is one that genuinely cannot be resolved without them. A question the
code already answers is noise, and it teaches the user that /qa wastes their time.

In the default mode this is targeted, not a survey: confirm the specific facts behind the items your
last reply raised. A flagged failure may already have its reason recorded somewhere; an offered option
may turn out to be impossible or already done. Verifying first routinely dissolves a question or
changes what it should have been.

## Step 2: what to interrogate

**Default: your own last reply.** Re-read the reply you just gave and pull out everything you left
open: questions you asked, options you offered, decisions you named as the user's, caveats you
attached, and anything you said you COULD do next. That set is the batch. Do not sweep the codebase.

If the last reply left nothing open, say so plainly and stop. Do not go hunting for work to justify
the invocation.

**Deep (`/qa deep`): the full sweep.** Cover all of these, not just the obvious one:

1. **The request itself.** Scope boundaries, what is deliberately excluded, naming, placement.
2. **The governing doc.** If the work traces to a planning document (a scope of work, a ticket, a
   spec), its open-questions section is the primary source. Pull those forward verbatim.
3. **What the audit surfaced.** Which existing pattern to reuse, where a shared helper lives,
   whether to extend a surface or add one.
4. **Anything you were about to default silently.** If you caught yourself picking, it is a
   question. This is the highest-yield category.
5. **The user's call by nature.** Product and UX behavior, copy, data-shape changes, anything
   irreversible or outward-facing, and anything that costs money or needs provisioning.
6. **Conflicts.** Where the request contradicts an existing convention, the code, or an earlier
   decision, surface the conflict rather than quietly picking a side.

## Step 3: how to ask

- **One batch, numbered, in prose.** Free-form conversational questions, not multiple-choice
  pickers, unless a question is a genuine either/or.
- **Give each question a recommendation.** State the option you would take and why, so the user can
  answer "your call" on any of them and you are still unblocked.
- **Give each question its stakes in one line.** What changes depending on the answer. A question
  whose answer changes nothing should not be asked.
- **Order by consequence**, most structural first.
- **Say so when there are none.** If verification resolved everything, report that plainly and state
  the assumptions you are proceeding under. Do not manufacture questions to justify the command.

## Step 4: after the answers

- **Do not re-ask.** Answered means settled; carry it forward without relitigating.
- **Record the resolutions where they belong.** If a planning doc raised the question, write the
  answer back into it so it reads as resolved, not still open.
- In ask-and-hold mode, present the plan for approval. In continue/proceed mode, leave plan mode as
  soon as the answers land and build, without composing a plan for review. The harness still
  surfaces a single prompt on the way out of plan mode; that is a formality, not a review round, so
  keep what you write there to a line or two.
- If something genuinely new surfaces mid-build, finish everything that does not depend on it, then
  raise the one question at the right moment.

## Reminders

- Follow the project's own plan-mode and writing conventions throughout.
- The command is about decisions, not permission. Do not turn it into a request to confirm work the
  user already asked for.

The modes

The argument controls two independent things: how wide the agent looks, and whether a plan gets approved before it acts.

/qa is the default, and it is deliberately narrow: the agent interrogates its own last reply. Whatever it just left open becomes the batch. This is the everyday case, and it costs almost nothing because there is no sweep.
/qa continue or /qa proceed is the same, minus the approval round. You answer, it builds. Still plan mode, so nothing gets written while the questions are open.
/qa deep widens the scope to the full six-category sweep in the skill file: the request, the governing doc, the audit findings, silent defaults, the decisions that are inherently yours, and conflicts with existing conventions. Use it when you are starting real work, not when you are closing out a reply.
/qa <anything else> scopes to a subject. "/qa the rate limiter" asks everything unresolved about the rate limiter specifically.

Scope and approval compose, so /qa deep continue runs the wide sweep and then builds from your answers without a plan to approve.

The narrow default is the important design choice. An exhaustive sweep on every invocation is expensive and mostly wasted, because the usual reason you type /qa is that the agent just handed you a list of open questions and you want them asked properly rather than left to evaporate.

Making it yours

Tune the deep sweep. Step 2 lists six places to look under /qa deep. The list is deliberately generic, so add the categories your projects actually produce. A team with a design system adds "which token or component does this reuse". A team with a data model adds "does this change a stored shape, and what happens to existing rows". A regulated project adds an approvals category. The sweep is only as good as its list, and it only runs when you ask for it.

Point it at your planning docs. The highest-yield item in the sweep is a governing document with an open-questions section, since those questions are already written and already yours to answer. If your project keeps scopes of work, tickets or design docs, name that location explicitly in step 2 so the agent reads it every time.

Decide how hard the hold is. As written, bare /qa will not touch a file until you approve a plan. If that is heavier than you want for routine work, make continue the implied default in your copy and reserve the plan-approval round for large changes.

Decide what "last reply" means to you. The default reads the agent's most recent message and treats everything it left open as the batch. If your sessions tend to sprawl across several exchanges before you reach for /qa, widen that to the current thread of work, or just type /qa deep when the narrow read would miss something.

The resource shared in this post is a new prompt published by GBTI Network member Hudson Atwell.

Are you a writer, musician, or product developer? We would love to support your work on the GBTI Network. For more information about how to join our community visit https://gbti.network

To follow Hudson Atwell's work more closely, consider joining our network and subscribing to them directly: https://gbti.network/members/atwellpub/

Manage Scopes of Work: a /sow Skill for Claude Code

GBTI Network — Tue, 28 Jul 2026 13:10:49 +0000

By Hudson Atwell, GBTI Network Member. Originally published on gbti.network.

Claude Code loads any markdown file at .claude/skills/<name>/SKILL.md as a reusable slash command (a "skill"). This one gives your agent a /sow command for managing Scopes of Work: local, lane-based planning documents that move kanban-style from queue to completed, living beside your code but outside version control.

It exists because agent-driven projects accumulate work items faster than anyone can track them in their head. A SOW gives every work item one canonical markdown file with a status banner, phases, and open questions; the lanes give the whole project a glanceable board; and the authoring rules keep the agent from duplicating items or writing plans detached from the real code.

Install

Create .claude/skills/sow/ in your repo.
Save the file below as .claude/skills/sow/SKILL.md.
Adjust the lane subfolders and conventions to your project (see Making it yours).
Type /sow init once to scaffold the framework, then /sow <request> to author.

The skill file

---
name: sow
description: ">"
  Author or improve a Scope of Work (SOW) in .data/sow/. Invoke for "/sow", "/sow init",
  "create a sow", "write a sow", or when the user asks to capture work as a SOW. "/sow init"
  scaffolds the lane framework (idempotent). Otherwise enforce the pre-checks: improve an existing
  SOW before creating a new one, ground it in a code audit, reference related completed SOWs,
  default the lane to queue, and follow the project's plan-mode and writing conventions.
---

# Managing Scopes of Work

SOWs are local planning documents in `.data/sow/` (kept OUT of version control), organized into
lanes a work item moves through: `0_queue` -> `1_progressing` -> `2_waiting_review` ->
`3_completed`, plus a `_staging` side-lane for items parked on an external blocker. One canonical
markdown file per SOW; move the same file between lanes as the work advances.

## Initialize (/sow init)

When invoked as /sow init (or when the lane folders do not exist yet), scaffold idempotently, then
stop (this command only builds folders, it never authors a SOW):

```bash
mkdir -p .data/sow/{_staging,0_queue,1_progressing,2_waiting_review,3_completed}
[ -f .data/sow/todo.md ] || printf '# SOW todo\n' > .data/sow/todo.md
grep -qxF '.data/' .gitignore 2>/dev/null || echo '.data/' >> .gitignore
```

It creates only what is missing and never overwrites an existing todo.md.

## Authoring a SOW: do these steps IN ORDER

1. **Improve an existing SOW first (never duplicate).** Search the open lanes for a SOW this work
   belongs in and extend it (a decision, a phase, an open-question resolution). An item in
   2_waiting_review is code-complete, so additions there are dated review-feedback notes. Only
   create a new SOW when no open SOW is a reasonable home, and say that you checked.
2. **Ground it in a code audit (no guessing).** Read the real code so the SOW cites file and line
   and the true root cause, not assumptions. For a bug, name the root cause; for a feature, name
   the surfaces and the pattern to reuse. Prefer reusing existing infrastructure.
3. **Reference related completed SOWs.** Search the completed lane and cite the relevant items:
   dependencies, the origin of a regression, or the pattern to reuse, each by id and path.
4. **Number and place it.** Find the next free sow-NNN. Default the lane to 0_queue unless told to
   start in 1_progressing. Group SOWs into subfolders matching your project's areas.
5. **Plan mode and conventions.** Every SOW is BUILT in plan mode: add a banner note saying its
   build begins there, and leave genuine decisions as open questions rather than pinning what is
   the owner's call. Follow your project's writing conventions throughout.
6. **Structure.** Frontmatter: id, title, status (matching the lane), priority, phase, created (an
   absolute date), depends_on, related, owner. Then the title, a status banner (what and why,
   grounded in the audit), design decisions, phases, constraints and guardrails, open questions,
   and cross-references.
7. **Design-first SOWs.** A SOW that redesigns a visual surface is never built from prose: request
   a mockup, store the assets under `sow-NNN-assets/` with a source note, and reference them.

## Reminders

- The planning docs are local only and never committed.
- A SOW is a living document: keep its status field and lane in sync as work moves.
- When a build completes, write an as-built note into the banner before moving lanes, so the doc
  reads true months later.

Making it yours

Three dials worth adjusting:

Lane subfolders: group SOWs by your project's real areas (a frontend/backend split, per-service folders, whatever matches how work divides). The skill file's step 4 is where that rule lives.
Conventions: point step 5 at your project's actual writing and review conventions so authored SOWs match the docs around them.
The planning root: .data/sow/ is a convention, not a requirement; any gitignored folder works. Keep it out of version control either way; plans churn too fast for useful history and the lanes ARE the state.

Why the rules are in there

Each authoring rule closes a failure mode agents repeat: creating a duplicate SOW instead of extending the open one (rule 1); writing plans from memory that cite code that does not exist (rule 2); losing the thread between related work items (rule 3); and building straight from a prose wish without surfacing the decisions that belong to a human (rule 5). The lane system does the rest: at any moment, the queue is the backlog, progressing is the work in flight, waiting-review is what needs a human eye, and completed is the record.

The resource shared in this post is a new prompt published by GBTI Network member Hudson Atwell.

Are you a writer, musician, or product developer? We would love to support your work on the GBTI Network. For more information about how to join our community visit https://gbti.network

To follow Hudson Atwell's work more closely, consider joining our network and subscribing to them directly: https://gbti.network/members/atwellpub/

Pre-Skill Prompt: Responsive Design Audit with MCP Playwright

GBTI Network — Tue, 21 Jul 2026 22:29:12 +0000

By @atwellpub, GBTI Network Member. Originally published on gbti.network.

"This prompt can be converted into a skill"

Use MCP Playwright to visually inspect the site across desktop browser widths, tablet widths, and real mobile device viewports. Improve the layout so every major section feels polished, intentional, readable, and usable across each context.

The goal is not to apply one responsive rule to every narrow viewport. Treat desktop browser narrowing and confirmed mobile devices differently.

Core responsive strategy:

Desktop browser resizing should preserve the desktop design shape for as long as it remains usable. As desktop viewport width narrows, compress the existing layout first by reducing font sizes, gaps, padding, margins, icon sizes, avatar sizes, card spacing, media sizes, and line heights. Avoid jumping to a mobile layout just because the width is smaller.

Confirmed mobile device viewports should be treated as mobile experiences. On mobile, solve layout issues through mobile-native restructuring when appropriate: two columns may become one, sidebars may move above or below content, secondary metadata may be hidden or condensed, button groups may stack, dense card grids may simplify, and complex sections may become accordions, carousels, horizontal scroll regions, or reordered content.

Viewport test matrix:

Mobile device viewports:

320 x 568, small mobile
360 x 740, Galaxy S8+
375 x 667, iPhone SE
390 x 844, iPhone 12/13/14
393 x 852, iPhone 14/15 Pro
412 x 915, Pixel 7
430 x 932, iPhone 14/15 Pro Max

Tablet viewports:

600 x 960, small tablet portrait
768 x 1024, iPad Mini portrait
810 x 1080, iPad portrait
1024 x 768, tablet landscape
1024 x 1366, iPad Pro portrait
1366 x 1024, iPad Pro landscape

Desktop browser widths:

600 x 900, narrow desktop browser
650 x 900, desktop compression threshold
768 x 900, narrow desktop/tablet boundary
1024 x 768, small desktop
1280 x 720, desktop 720p
1366 x 768, common laptop
1440 x 900, laptop/desktop
1536 x 864, large laptop
1920 x 1080, desktop 1080p
2560 x 1440, desktop 1440p

For each viewport:

Open the page with MCP Playwright.
Capture a full-page screenshot.
Inspect each major section individually.
Compare mobile, tablet, narrow desktop, and full desktop presentation.
Identify text overflow, cramped spacing, broken grids, awkward wrapping, clipped content, deformed cards, misaligned buttons, uneven card heights, weak hierarchy, poor touch targets, and sections that no longer feel visually balanced.
Note whether the issue should be solved by compression, restructuring, simplification, or hiding expendable content.

Desktop browser compression rules:

For desktop browser widths down to approximately 600px, preserve the desktop structure wherever possible.
Do not automatically stack multi-column rows, sidebar layouts, media/text pairs, pricing cards, feature rows, or inline cards above 600px.
First shrink competing elements: headings, supporting text, avatar sizes, icons, gaps, card padding, media dimensions, CTA spacing, and metadata.
Use proportional scaling with clamp(), min(), max(), fluid spacing variables, CSS grid, and flexible sizing.
A desktop section should feel like the same section at smaller scale, not a different design.
If a title wraps one word per line, a row overflows, a card becomes crushed, or buttons collide, reduce surrounding pressure before changing structure.
Only restructure desktop-browser layouts when compression creates unreadable text, unusable controls, or obviously broken visual hierarchy.

Mobile device adaptation rules:

Treat confirmed mobile viewports as mobile-native experiences, not miniature desktop layouts.
Prioritize readability, thumb-friendly interaction, clear hierarchy, and strong vertical rhythm.
Convert two-column and multi-column layouts to single-column when that produces a better mobile experience.
Stack CTAs when inline buttons become cramped.
Move sidebars above or below primary content when needed.
Hide, shorten, or collapse expendable metadata when it competes with the main content.
Preserve important content, but remove visual clutter where it harms the mobile experience.
Consider accordions, compact cards, horizontal scrolling groups, reduced media, simplified grids, reordered content, and mobile-specific section treatments.
Do not shrink body text below readable mobile sizes.
Do not preserve desktop shape on mobile when doing so creates awkward wrapping, tiny text, crowded controls, or weak hierarchy.

Tablet rules:

Treat tablets as an intermediate design context, not automatically desktop and not automatically mobile.
Preserve desktop structure on larger tablets when it remains balanced.
Use hybrid layouts where appropriate: two-column grids, compressed sidebars, reduced card density, smaller media, and tighter spacing.
On portrait tablets, avoid overly wide single-column sections unless the design benefits from it.
On landscape tablets, preserve more desktop-like structure where possible.

Implementation expectations:

Make targeted CSS and layout changes.
Prefer responsive CSS using clamp(), min(), max(), CSS grid, flexbox, container queries where useful, and breakpoint-specific rules.
Keep existing design tokens and naming conventions where they exist.
Avoid broad rewrites unless a section is structurally unsalvageable.
Use separate logic where needed for viewport width, pointer type, hover capability, and device-like mobile contexts.
Do not rely only on screen width when deciding mobile behavior.
Preserve the desktop design language while allowing mobile to have its own practical layout.
After edits, rerun MCP Playwright screenshots at the same viewport sizes.
Confirm that each major section looks intentional, balanced, readable, and usable across mobile, tablet, narrow desktop, and full desktop.

Decision framework:

For every responsive issue, decide which fix category applies:

Compression fix:

Use when the desktop structure still works but needs smaller spacing, typography, icons, cards, or media.

Layout preservation fix:

Use when the section should remain in its desktop shape across narrow desktop widths.

Mobile restructuring fix:

Use when the viewport is a real mobile device and the section would be more usable as a stacked, simplified, reordered, or collapsed layout.

Content priority fix:

Use when secondary metadata, decorative elements, repeated labels, dates, avatars, or supporting copy are crowding the core experience.

Structural redesign fix:

Use only when CSS scaling and responsive reflow cannot make the section work cleanly.

Final deliverable:

Summarize the responsive issues found.
Group issues by mobile, tablet, narrow desktop, and full desktop.
List the CSS/layout changes made.
Explain where compression was used to preserve desktop structure.
Explain where mobile-specific restructuring was used.
Note any content that was hidden, shortened, collapsed, or deprioritized.
Note any sections that still need design input.
Include before/after observations for:
Smallest mobile viewport
One larger mobile viewport
One tablet portrait viewport
One narrow desktop viewport near 600px
One standard desktop viewport
Confirm that screenshots were rerun after implementation.

The resource shared in this post is a new prompt published by GBTI Network member Hudson Atwell.

Are you a writer, musician, or product developer? We would love to support your work on the GBTI Network. For more information about how to join our community visit https://gbti.network

To follow Hudson Atwell's work more closely, consider joining our network and subscribing to them directly: https://gbti.network/members/atwellpub/

CI Health Check: a /ci Skill for Claude Code

GBTI Network — Sat, 11 Jul 2026 23:44:04 +0000

By Hudson Atwell, GBTI Network Member. Originally published on gbti.network.

Claude Code loads any markdown file at .claude/skills/<name>/SKILL.md as a reusable slash command (a "skill"). This one gives your agent a /ci command that audits your GitHub Actions: a red/green health board, real failure triage, a post-push watcher, and a living inventory of what every workflow does.

It exists because agents (and humans) keep re-deriving the same motions every time CI goes red: which runs failed, how to actually get the logs, whether the failure is your commit or something that was already broken. The skill encodes those motions once, including a few non-obvious gh behaviors that cost me real debugging time.

Install

Create .claude/skills/ci/ in your repo.
Save the file below as .claude/skills/ci/SKILL.md.
If your repo commits build artifacts, fill in the drift action; either way, seed the workflow inventory table.
Type /ci (or /ci health check) in Claude Code.

Requires the gh CLI authenticated against your repo. The skill runs from the project folder, so the repo is already known: gh resolves it from the working directory, and the {owner}/{repo} tokens in API paths are native gh api placeholders it fills in for you. Nothing to configure.

The skill file

---
name: ci
description: ">"
  Inspect and diagnose this repo's GitHub Actions CI. Invoke for "/ci", "/ci health", "/ci health check",
  "/ci watch", "/ci schedule", "/ci diagnose <run-id>", "/ci list", or when the user asks whether CI is
  green, why a workflow failed, or what a workflow does. Pulls recent runs with gh, downloads failed job
  logs the reliable way, and triages failures to their real root cause.
---

# CI operations

All commands run from the repo root with the `gh` CLI (it resolves the repo from the working directory;
`{owner}/{repo}` in API paths is a native gh placeholder). Default action when none is named: `health`.

## Tooling lore (read first)

- **Fetching logs:** `gh run view <id> --log-failed` often returns NOTHING. The reliable recipe:
  ```bash
  JOB=$(gh run view <run-id> --json jobs -q '.jobs[0].databaseId')
  gh api repos/{owner}/{repo}/actions/jobs/$JOB/logs > /tmp/job.log
  ```
  Then grep the file; strip the timestamp column with `cut -c30-` when quoting. Multi-job runs: iterate
  `.jobs[]` and pick by `.conclusion == "failure"`. Step-level status without logs:
  `gh api repos/{owner}/{repo}/actions/runs/<id>/jobs -q '.jobs[0].steps[] | .name + " " + .conclusion'`.
- **Scheduled-failure attribution:** the failure email for a SCHEDULED workflow cites the LATEST main sha,
  which is often NOT the commit that broke it. Always check
  `gh run list --workflow <file> --limit 5 --json conclusion,createdAt,event` first; if the failures predate
  the cited commit, it is a standing provisioning or external problem, not a regression.
- **Secrets vs variables:** repo secrets via `gh secret list`, plain variables via `gh variable list`. A
  workflow reading `secrets.X` where X was never created gets an EMPTY string, not an error, so the symptom
  is a downstream "not set" message, a 401, or an empty env var in the step header.
- **Setting secrets may be gated:** an agent session may be blocked from `gh secret set` by permission
  policy. Prepare the value in a local untracked file and hand the human the one command.

## Failure triage (a starting taxonomy — extend it to fit the project)

Classify every red into a named bucket, because the bucket decides the response. These three cover most
repos; add project-specific buckets as you meet them (examples: environment/toolchain drift, a dependency
or upstream API regression, resource exhaustion such as OOM or disk or rate limits, data- or state-dependent
failures, expired credentials). When a failure fits no bucket, name a new one in the report rather than
forcing it into a wrong response.

1. **Broken by commit:** the failure starts at a specific sha and the log implicates changed files. Fix the
   root cause (see Fix discipline below); verify with a rerun on the fix commit.
2. **Provisioning gap:** missing or empty secret, unset variable, an external account not configured. Route
   to the human with the exact command; do not retry.
3. **Flaky / external:** network hiccup, provider outage, rate limit; the same job passed before and after
   without a related change. `gh run rerun <id> --failed` once, then re-check.

## Fix discipline (failing tests especially)

When a test fails, evaluate the REAL defect the test is exposing and propose a fix for that root cause.
Never patch the symptom, and never modify a test so it passes while the underlying failure remains — if you
find yourself weakening an assertion, deleting a case, or special-casing the test input, stop and re-derive
what the test was protecting. Changing a test is only correct when the test itself is wrong about the
intended behavior, and the report must say that explicitly and justify it. The same rule generalizes beyond
tests: a fix that makes the red go away without explaining WHY it was red is a symptom patch, not a fix.

## Actions

### /ci health [N]   (also: /ci health check; the default)

1. `gh run list --limit ${N:-30} --json databaseId,workflowName,conclusion,headSha,event,createdAt` and
   group by workflow. Report a red/green board: latest conclusion per workflow, streak (consecutive fails),
   and the event (push vs schedule).
2. For each currently-red workflow: pull its recent history (`--workflow <file> --limit 5`) to date the
   breakage, download the failed job log (recipe above), and triage it (the taxonomy above) with a
   one-line root cause and the proposed fix.
3. End with the board, the diagnoses, and what to do next. Offer to make low-risk code-side fixes (root
   cause, per Fix discipline); provisioning gaps go to the human.

### /ci watch

The post-push ritual. Find the runs for the current HEAD and watch until all conclude:
```bash
SHA=$(git rev-parse HEAD)
gh run list --limit 15 --json databaseId,workflowName,conclusion,headSha \
  -q ".[] | select(.headSha==\"$SHA\")"
gh run watch <id> --exit-status   # per unfinished run
```
Report each result; diagnose any red as in health.

### /ci drift   (only if your repo commits build artifacts)

The LOCAL pre-push check that committed artifacts match their source:
```bash
<your full artifact build command(s)>
git diff --name-only -- <artifact-dir-1> <artifact-dir-2>
```
Empty diff = safe to push. Non-empty = stage those files with the commit that changed the source. Fill in
EVERY build command: partial rebuilds that skip one artifact are the classic way this check reds your main
branch anyway.

### /ci schedule

Staleness audit of the scheduled workflows. For each one (list yours here with cadences): pull the last 5
runs and report the last SUCCESS date. Alarm on any workflow whose last success is older than 2x its
cadence. A scheduled job can be silently red for days; nobody rereads yesterday's failure email. Note which
scheduled jobs are load-bearing (a backup, a data sync something else depends on) so staleness there is
escalated, not just listed.

### /ci diagnose <run-id | workflow-name>

Deep-dive one run (or the latest run of a named workflow): step table, failed job log to disk,
triage bucket, root cause, fix proposal.

### /ci rerun <run-id>

`gh run rerun <run-id> --failed` then watch it. Only for the flaky/external bucket; never rerun a
provisioning gap (it cannot pass) or a broken-by-commit red (fix the root cause first).

### /ci list

Print this workflow inventory (keep it current when workflows are added or changed):

| Workflow (file) | Trigger | What it does | Needs |
|---|---|---|---|
| <Name> (<file>.yml) | push / PR / cron | <one line on what it validates or does> | <secrets or nothing> |

To seed it, read every file in `.github/workflows/` and summarize: name, trigger, the job's purpose (the
header comment usually says), and which secrets it reads.

## Reporting conventions

- Lead with the board (workflow, latest state, streak), then diagnoses, then actions taken or proposed.

Making it yours

There is nothing to configure for the repo itself: gh infers it from the working directory, so the skill works the moment you drop it in. Only two parts are inherently repo-specific:

The drift action: keep it only if your repo commits build artifacts (bundled JS, generated schemas, packaged extensions). List every build command and every artifact directory. If you do not commit artifacts, delete the action.
The inventory table: have your agent seed it once from .github/workflows/ and then treat it as living documentation. This is the part future sessions (and new contributors) thank you for.

And treat the failure taxonomy as a starting point, not a fixed set: projects fail in project-shaped ways, so add the buckets yours actually produces.

Why the odd details are in there

Each lore item is a real failure mode: --log-failed silently returning nothing while the jobs API works; a scheduled backup that failed for four days while its failure emails blamed whatever commit happened to be newest on main; a workflow reading a secret nobody ever created and reporting it as a vague downstream error instead of failing fast; a drift check that stayed red because the rebuild command regenerated only one of two committed bundles. The Fix discipline section is there because agents notoriously "fix" a failing test by editing the test — the classification buckets plus that rule keep the agent from the three classic wastes: rerunning a job that can never pass, "fixing" code that was never broken, and silencing a test that was telling the truth.

Are you a writer, musician, or product developer? We would love to support your work on the GBTI Network. For more information about how to join our community visit https://gbti.network

To follow Hudson Atwell's work more closely, consider joining our network and subscribing to them directly: https://gbti.network/members/atwellpub/

How to Generate Professional LinkedIn Headshots Using Nano Banana

GBTI Network — Thu, 09 Oct 2025 20:13:08 +0000

By Naresh Devineni, GBTI Network Member

Creating a professional LinkedIn headshot doesn’t need to be difficult or expensive.

In this guide, I will share a simple method for producing AI-generated headshots that look authentic, clean, and career-ready using Nano Banana.

Step 1: Find Your Reference Image

Look for a professional headshot you like (make sure you’re using it ethically and legally).

This image will serve as your style reference — the goal is to recreate its lighting, framing, and background style with your own photo later.

Step 2: Let AI Describe It

Upload your chosen reference image to an AI chatbot (like ChatGPT, Gemini, or Claude) and ask it to describe the photo.
This helps generate a consistent, professional image prompt that Nano Banana can follow.

Here is an example prompt:

For the uploaded reference image:

### ✅ Be Minimal

Only describe what is clearly visible.

### Never Include

* Racial, ethnic, or skin tone descriptors
* Facial features, hair details, body type
* Accessories, age, or gender indicators

### Only Include What’s Visible

**Expression:** Simple description only (e.g., “warm smile” or “neutral expression”)
**Clothing:** Describe exactly what’s worn – color, garment type, style
**Clothing shadows:** Note visible shadows under lapels, collars, or folds
**Lighting:** Direction and quality (e.g., “soft frontal lighting” or “three-point lighting”)
**Facial shadows:** Shadows under chin, on neck, or one side of face — or state “evenly lit”
**Background:** Exact color, brightness level, and subtlety of gradient (if any)
**Background shadows:** Only if visible — otherwise, state “no background shadow”
**Framing:** What’s visible (e.g., “head and shoulders” or “upper chest to top of head”)
**Position:** Head/body angle relative to camera

### Rules

1. Describe only what you actually see — don’t infer or imagine details
2. Keep descriptions factual and minimal
3. Any gradients should be described as **VERY SUBTLE** with minimal tonal variation

### Critical Restrictions

CRITICAL RESTRICTIONS:
1. NO multiple backgrounds or layered backgrounds
2. NO rounded corners or circular crops
3. NO additional background colors or borders
4. NO dramatic background gradients – background should be evenly lit or have only minimal, natural variation
5. Standard rectangular crop only
6. DO NOT add shadows if none exist in the reference image

Step 3: Generate Your Headshot

Upload your own photo to Nano Banana.
Paste the AI-generated description as your image prompt.
Generate your professional headshot.

Nano Banana will produce an image that matches the lighting, framing, and background style of your reference photo — but featuring your own face.

Here is an example headshot and prompt:

For the uploaded picture, generate an image of:

Expression: Warm, genuine smile

Clothing: Dark gray textured suit with light blue dress shirt and navy blue tie with small dot pattern

Clothing shadows: Visible shadows under suit lapels, along tie, and in jacket fabric folds

Lighting: Soft, natural outdoor lighting from front

Facial shadows: Face evenly lit with minimal shadows

Background: Blurred outdoor corporate/office building environment (bokeh effect) with modern glass windows and architectural elements visible, blue-gray and white tones

Background shadows: Background is out of focus, no distinct shadows visible

Framing: Head and upper torso to mid-chest level

Position: Body angled slightly to left, face turned toward camera at slight angle

CRITICAL RESTRICTIONS:

NO multiple backgrounds or layered backgrounds
NO rounded corners or circular crops
NO additional background colors or borders
NO dramatic background gradients – background should be evenly lit or have only minimal, natural lighting variation
Standard rectangular crop only
DO NOT add shadows if none exist in the reference image

The Result

You’ll get a professional, consistent, and natural-looking headshot that reflects your desired style, without the guesswork or endless prompt tweaking.

Sounds easy?
It is!

Thanks for reading this article.

Visit my article "15 Ready-to-Use Nano Banana Prompts for Realistic LinkedIn Headshots" to see how I put this method to use!

Also consider joining me on the GBTI Network where we share tips like this regularly inside our own private discord network.

15 Free React Landing Page Templates to help Launch your SaaS

GBTI Network — Mon, 18 Aug 2025 13:42:28 +0000

This past month we worked hard to make the Fall Y-Combinator 2025 submission window with one of our projects, and to do this we wanted to have a very basic landing page ready for our product demo site.

This sprint lead us to investigate the best free React + Tailwind CSS templates we could find. We performed our search using tools like ChatGPT, Google, Dev.to, Daily.dev, and Github to find the highest quality free templates available.

Through our research, we compiled the best 15 completely free React landing page templates we were able to find and have showcased them in our lasted article:

"15+ Free REACT Landing Page Templates to Launch your SaaS"

We hope you enjoy our efforts and if you are working on a free React landing page template and would like us to add it to our list above, leave a comment below and we'll consider adding it!

Thanks for paying attention!

Using Hue to create colorful animations 🌈

GBTI Network — Sun, 27 Jul 2025 21:41:08 +0000

Hi fellow devs! 👋

We're excited to share our latest coding experiment and what turned out to be a surprisingly fun tool: a browser-based hue animation generator.

https://gbti.network/products/js-animate-hue/

You know that moment when you're adjusting the hue slider in your favorite image editor and watching your image cycle through the entire color spectrum - from electric blues, vibrant magentas, and sunset oranges? Haven't you thought at some point, "This transition would make an incredible animation"?

We decided to scratch that itch and build exactly that: a JavaScript tool that transforms any image into a mesmerizing color-shifting animation.

What it does

The tool takes any image you upload and creates smooth animations by cycling through hue transformations. But it goes beyond just basic hue shifts - you can also animate brightness and contrast changes to create some truly psychedelic effects.

Core Controls:

Interactive SVG color wheel - Drag handles on a half-circle hue selector to define exactly which colors your animation cycles through (-180° to +180°)
Brightness animation - Ranges from -100 (completely dark) to +100 (super bright) with presets like "Sunrise Effect" and "Fade to Black"
Contrast animation - Adjust from -100 (flat/washed out) to +100 (ultra-sharp) with options like "Dramatic Reveal" and "Vintage Film"
Animation timing - Control frame count (1-360 frames), speed (1-60 FPS), and seamless looping
Resolution scaling - Output from 50% to 150% of original size for file size optimization

Smart Presets:

The tool includes thoughtfully designed presets for each effect:

Hue: Full spectrum rainbow, warm sunset tones, cool ocean shifts
Brightness: Sunrise/Dawn Effect, Fade to Black, Flash/Glow, Breathing Light, Reveal Effect
Contrast: Dramatic Reveal, Dreamy to Vivid, Pop Effect, Sharp to Soft, Vintage Film

The technical bits & export formats

What started as a simple hue-shifting experiment evolved into a pretty robust image processing tool. Under the hood, it uses:

Canvas API for real-time image manipulation and frame generation
Web Workers with gif.js and gifenc libraries for smooth GIF encoding without freezing the browser
MediaRecorder API for high-quality WebM and MP4 video output with configurable bitrates
SVG-based controls for that smooth, interactive color wheel

Export Options:

The tool supports three major formats, each optimized for different use cases:

GIF Animation - Universal compatibility, perfect for web embedding and social sharing
WebM Video - Modern codec with excellent compression, ideal for web platforms
MP4 Video (H.264) - Industry standard with multiple quality settings:
- Low (5 Mbps) - Smaller files for quick sharing
- Medium (10 Mbps) - Balanced quality and size
- High (20 Mbps) - Professional quality
- Lossless (50+ Mbps) - Maximum quality for final output

Social Media Ready:

The output formats work perfectly across all major platforms:

X (Twitter) - MP4 with H.264 codec (up to 512MB, 140 seconds)
LinkedIn - MP4 with H.264 and AAC audio (up to 5GB, 10 minutes)
Instagram - MP4 with H.264 for Feed, Reels, and Stories (up to 4GB)

The codec implementations include built-in brightness and contrast adjustments that work at the pixel level, giving you smooth transitions that would be difficult to achieve in traditional video editing software.

The whole thing runs entirely in your browser - no servers, no uploads, no tracking. Your images never leave your device.

Get Started

Check out the project:

Give it a try and let us know what you create! We'd love to see what kind of psychedelic masterpieces people come up with. Upload your creations to giphy and share them in the comments or tag us on social media @gbti_network!

Introducing Perplexity AI Lookups for WordPress

GBTI Network — Mon, 30 Jun 2025 13:59:44 +0000

At the GBTI Network, we’re committed to developing novel tools that empower publishers and readers alike. Today, we’re announcing the release of our WordPress Perplexity AI Plugin, which enables AI-powered lookups on highlighted text within your WordPress content.

What does this plugin do?

This plugin allows site visitors to:

Highlight any text on a post or page.
Optionally click a Perplexity icon to open a Perplexity instance with the selected query attached.

This creates a novel way for readers to engage with your content without interrupting their reading flow and Receive AI-generated lookups instantly, offering definitions, explanations, or contextual expansions for the highlighted text.

Why did we build it?

Writers often struggle to balance brevity with sufficient explanation. Excessive footnotes, hyperlinks, or side notes can disrupt readability and clutter pages. This simple implementation assists these challenges by:

Providing readers with on-demand context and deeper understanding.
Allowing writers to maintain concise content without sacrificing detail.
Enhancing engagement and time on page by encouraging interactive exploration.

It's a very simple and effective implementation!

Use cases

Educational sites: Students can quickly look up terms and definitions while reading course material.
Blogs: Readers can gain clarity on concepts without breaking their reading rhythm.
Technical documentation: Developers and technical readers can explore deeper context for terms and functions on-demand.

Getting started

To install the plugin please visit our full release announcement for download and setup instructions:
Introducing Our New WordPress Perplexity AI Plugin

Future plans

We are exploring additional features, including:

Custom prompt templates for specialized sites and terminology.
Admin-side analytics for usage tracking and content strategy insights.
Expanded AI provider support for diversified lookup outputs.

Contributing

We welcome community contributions to extend and refine this plugin. If you’re interested, please visit our GitHub repository for issue tracking and PR guidelines.

Final thoughts

AI-enhanced reading experiences are becoming increasingly common. Our Perplexity AI Plugin is a small step towards creating more interactive and intelligent web content in novel ways.

We look forward to your feedback and suggestions as we continue improving this tool for the WordPress community.