DEV Community: GBTI Network

/FARLEY : An Agent Skill for Remembering People

GBTI Network — Fri, 18 Sep 2026 00:04:37 +0000

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

This Claude Code skill offers your agent an /farley command that helps keep track of memorable data you learn about the people you meet. This is for those who network with many people and would like to be able to record and recall details that may otherwise slip the memory.

The name comes from James Farley, Franklin Roosevelt's campaign manager and later Postmaster General, who kept a file on everyone the two of them met: family, work, the last conversation. Before a return visit he read it, and a man who had shaken his hand once, a year earlier, got asked about a family member by name.

I came across this concept while reading Robert Heinlein's Double Star, where an actor stands in for a politician and survives the handshakes because the politician's staff keeps exactly that file. Heinlein named it after Farley, and the 1956 novel is how most people who keep one first heard of the idea.

What it does

/farley takes a mode as its first word, and /farleyfile is the same skill under a second name.

Command	What it does
`/farley <name> <notes>`	Creates or updates that person's dossier, logs the meeting, and tags it. Plain sentences work: `/farley Met Tom Ruiz at the fundraiser, his wife is Ana`.
`/farley brief <name>`	Reads the notes back as a pre-meeting brief: names, last conversation, open threads, what to raise, what to avoid.
`/farley search <query>`	Finds people by text (`fly fishing`) or by tag (`tag:role/donor tag:place/austin`). Local only, plain grep.
`/farley research <name>`	Searches the web for their public footprint and records confirmed findings with sources, in their own section.
`/farley list`, `/farley autotag`, `/farley init`	Everyone on file; re-tag one dossier or all of them; set where the file lives.

Install

Create ~/.claude/skills/farley/.
Save the file below into it as SKILL.md. That is the whole skill.
Run /farley init. It asks where the dossiers should live, creates the folder, and writes config.json. Pick somewhere outside every git repository.
Type /farley and it shows you the menu.

The skill file

Save this as ~/.claude/skills/farley/SKILL.md.

---
name: farley
description: >
  Keep the Farley File: a private set of notes about people and organizations the user knows or works with.
  Invoke for "/farley" or "/farleyfile" with any of: init, list, search <search>, research <name>,
  autotag [name], brief <name>, or a name followed by notes. Also for "add this to the farley file",
  "I just met <name>", "note that <name> works with ...", "brief me on <name>", or "who do we
  know who ...". Stores one Markdown record per person or organization, adds useful tags, searches
  those records, and looks up public professional information on the web only when asked. With no
  arguments it asks what the user wants. Works from any project directory; the storage location is
  set once with "/farley init".
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebSearch, WebFetch
---


# /farley: the Farley File


A Farley File is a private set of notes about people and organizations the user knows or works with. It keeps useful context from real interactions, such as roles, interests, past conversations, shared work, associates, and follow-ups. Before meeting again, the user can review the record so the conversation can pick up where it left off.


`/farleyfile` is the same skill under a second name.


## Storage


**Markdown is the only place the notes are stored.** Each person or organization gets a folder
with one Markdown record. The user may keep related material beside it, such as a business card,
meeting notes, or a document. There is no database or background service. Search uses plain text.


```
<root>/
  jane-doe/
    jane-doe.md            the record (the only file that holds data)
    (optional related files: business cards, meeting notes, documents)
```


The location of `<root>` is the one setting, kept in `config.json` beside this file:
`{"root": "<absolute path>"}`. **Init** writes it and nothing else does.


## Step 0: find the Farley File folder (every command)


Read `config.json`. Its `root` value is the folder every command reads and writes, no matter which
project is open. Below, `<root>` means that folder. Use the full path in commands because shell
variables do not carry between calls.


If `config.json` is missing, has no `root`, or the folder no longer exists, tell the user no
Farley File folder is set, run **Init** first, then carry on with what they asked for.


## Pick the command from `$ARGUMENTS`


The first word decides. A person who happens to be named "List" is written as `/farley brief List`
or with notes after the name.


| Arguments | What to do |
|---|---|
| empty | **Ask.** Ask what the user wants to do. |
| `init` | **Init.** Set or change the storage location. |
| `list` | **List.** Every name on file. |
| `search <search>` | **Search.** Find records by text or `tag:`. Local only. |
| `research <name> [focus]` | **Research.** Look up relevant public professional information. |
| `autotag [name]` | **Autotag.** Re-tag one record, or every record when no name is given. |
| `brief <name>`, `prep <name>`, or a bare name | **Brief.** Read the record back for a meeting. |
| a name plus information about them, or a plain sentence | **Record.** Create or update the record. |


If a command is missing what it needs (`/farley search`, for example), ask only for the missing
name or search terms.


## Ask


Do nothing else yet. Reply with a short question asking who or what this is about, and show the
menu so the user can answer in one line:


```
Who is this about, and what should I do?
  <name> <notes>            record what you learned
  brief <name>              read a record back before a meeting
  search <search>            find people by text, or by tag:place/austin
  research <name>           look up relevant public information
  autotag [name]            re-tag one record, or all of them
  list                      everyone on file
  init                      set where the Farley File lives
```


End the turn there. Treat the user's next message as the arguments and pick the command from it.


## Init


1. Read `config.json`.
2. **A root is already set:** say where it is and how many records it holds. Ask with
   AskUserQuestion whether to keep it or change it. Keep ends here.
3. **No root yet, or the user chose to change it:** ask for the location with AskUserQuestion.
   Offer the current working directory and `~/farley` as options; the user can type any other
   path through "Other".
4. Normalize the answer: `~` expands to the home directory, and the result must be absolute. On WSL,
   a Windows path (`D:\Brain\farley`) becomes a WSL path with `wslpath -u`.
5. Create the folder if needed (`mkdir -p`), and write `config.json` as
   `{"root": "<absolute path>"}`.
6. **Changing from an old root that holds records:** ask whether to move them to the new location
   or leave them where they are. Move only on a yes, with `mv`, and never delete anything.
7. Report the new location.


## Step 1: find the person or organization (Record, Brief, Research, Autotag)


1. Make the **folder name** from the name: lowercase it, remove accents, titles and suffixes
   (Dr, Rep, Sen, Mr, Ms, Jr, III), remove apostrophes and periods, and replace spaces with hyphens.
   `Dr. María O'Neil` becomes `maria-oneil`. `The Acme Foundation` becomes `acme-foundation`.
2. Look for an existing record before creating one. Check the folder list, then the `name:` and
   `aliases:` lines of every record, without caring about capitalization, so a nickname, alternate name, or first name
   alone still finds the right person:


   ```bash
   ls <root>
   grep -iE "^(name|aliases):" <root>/*/*.md 2>/dev/null
   ```


3. Decide:
   - **One clear match:** use it.
   - **No match:** Record creates `<folder-name>/<folder-name>.md` from the layout below. The other
     commands say no record exists and ask whether to start one. Never create an empty file.
   - **Several plausible matches** (two Johns, or "Sarah" alone): ask with AskUserQuestion, listing
     each possible match with their role and last contact. Never guess and merge two people.
   - **Same name, different person:** add a short identifying word to the folder name from what the
     notes give (`john-smith-austin`, `john-smith-acme`), and say so.


## Record


Read the whole record first, then edit it in place. Never rewrite it from memory. A new record 
takes this shape, with the headings kept even when empty, so every file reads the same way:


```markdown
---
name: Jane Doe
aliases: []
type: person
relationship: how the user knows them, in a few words
first_met: 2026-09-16
last_contact: 2026-09-16
tags: []
---


# Jane Doe


## At a glance


One or two sentences: who they are and why they matter.


## About


- Role and organization:
- Location:
- Contact:
- Relevant details:


## Associates


## Interests and preferences


## Background


## Topics and positions


## Connections


## Follow-ups


## Research


## Interaction log
```


**Sections.** Put each new fact under the heading where someone reviewing the record before a
meeting would expect to find it. Add a bullet and do not repeat something already recorded.
Only **Research** writes to the `Research` section.


**The interaction log** keeps a simple history of what happened. Add one entry per meeting or note,
**newest first**, directly under `## Interaction log`:


```markdown
### 2026-09-16 · Rotary lunch, Austin
- What was said, done or learned, in the user's own words where possible.
- Anything they asked for, offered, or promised.
```


If the notes are not about a meeting (a fact heard secondhand, a correction), log it as
`### 2026-09-16 · Note` and name the source if the user gave one.


**Details at the top of the file.** Keep them current on every write: add new names or nicknames to
`aliases`, set `last_contact` to the date of the newest real interaction (not a secondhand note or
research), and set `first_met` only once. Keep `aliases` and `tags` as one-line lists
(`tags: [role/donor, place/austin]`) because the search commands read that format.


**Then tag it:** apply **Tags** to the record.


### Rules that keep the file trustworthy


- **Record only what the user supplied.** Do not infer, embellish, or fill gaps. The web is used
  only by **Research**, and only when the user invokes it.
- **Pronouns:** use the ones the user used. If none were given, write around them or use
  they/them. Never infer them from a name.
- **Absolute dates only.** Convert "yesterday", "last Tuesday", "next month" against today's date.
  If no meeting date is given, use today and say so in the reply.
- **Never delete a fact.** When new information contradicts old, write the new value and keep the
  old one beside it with its date: `Works at Dell (previously HP, noted 2026-03-02)`.
- **Keep uncertainty visible.** "I think she now works at UT" becomes
  `May now work at UT (unconfirmed)`.
- **Follow-ups are checkboxes.** Promises made in either direction become `- [ ] Send Tom the grant
  deadline (promised 2026-09-16)`. When the user reports one done, tick it and add the date; do
  not remove it.
- **Associates mentioned in the notes.** Colleagues, collaborators, assistants, contacts, and other
  associates mentioned in passing go under `Associates` or `Connections`. Give someone their
  own record only if the notes are substantially about them too, or the user asks. When both people
  have records, link the two records to each other (`[Ana Ruiz](../ana-ruiz/ana-ruiz.md)`) in each file's
  `Connections`.
- **Write no em-dashes** in any file this skill writes, per the global writing rule. Use commas,
  colons, parentheses or a new sentence. The `·` in log headings is fine.


Report briefly: the record path and whether it was **created** or **updated**, a few bullets of what
was added, the tags added, any conflicting information kept, any assumption made (for example, using
today when no date was given), and this person's open follow-ups. Do not repeat the whole record.


## Tags


Tags help the file answer questions like "who do I know who..." without a database. They are added
automatically on every **Record**, **Research** and **Autotag**; the user never has to ask.


**Tag format:** `group/value`, lowercase with hyphens: `place/travis-county`, `interest/fly-fishing`.


| Group | For | Examples |
|---|---|---|
| `role` | how they relate to the user or their work | `role/donor`, `role/volunteer`, `role/press`, `role/staff`, `role/elected-official` |
| `org` | organizations they belong to or lead | `org/literacy-council`, `org/dell` |
| `place` | where they live, work or are active, online communities included | `place/austin`, `place/district-7`, `place/reddit` |
| `event` | where the user met or saw them | `event/rotary-lunch`, `event/2026-literacy-gala` |
| `interest` | hobbies and passions | `interest/fly-fishing`, `interest/jazz` |
| `issue` | policy areas they care about or work on | `issue/school-funding`, `issue/water-rights` |


**Rules:**


1. **Reuse before inventing.** Read the tags already in use and pick an existing one when it fits,
   so `interest/fishing` does not gain a rival `interest/angling`:


   ```bash
   grep -h "^tags:" <root>/*/*.md | tr -d '[]' | tr ',' '\n' | sed 's/^tags://' | tr -d ' ' | sort -u
   ```


2. **Tag only what the record says.** Every tag must trace to a line in the file. Remove a tag
   only when the fact behind it is gone or superseded, and say so.
3. **Stay within these six tag groups.** If a tag fits none of them, it usually belongs in the notes instead.
4. **Never use sensitive personal information as a tag:** health, religion, ethnicity, sexual
   orientation, immigration status, political party, or anything similar. If the user chose to
   record such a fact, keep it only in the notes. Never make it a way to group or list people.
5. **A handful per record.** Tags that would match almost everyone on file (`place/texas` for a
   Texas office) add nothing; prefer the more specific one.


## List


Read the details at the top of every record and return **every** name, alphabetically, one per
line, with relationship and last contact after it, and the total at the end:


```bash
grep -H -E "^(name|relationship|last_contact):" <root>/*/*.md
```


```
Ana Ruiz · board member, Literacy Council · last contact 2026-08-30
Jane Doe · donor, Travis County · last contact 2026-09-16
2 people on file.
```


If the folder is empty, say so and offer to add someone.


## Search


Local only. This command never uses the web and never edits a record. It searches the Markdown files
on this machine with `grep`.


1. **Tag searches.** `tag:place/austin` finds records carrying that tag. Several `tag:` terms mean
   all of them (`tag:role/donor tag:place/austin`). The brackets match the whole tag, so
   `role/donor` does not also match `role/donor-major` (a `\b` boundary would):


   ```bash
   grep -lE "^tags:.*[[ ]role/donor[],]" <root>/*/*.md | xargs -r grep -lE "^tags:.*[[ ]place/austin[],]"
   ```


2. **Text searches.** Turn the search into a few obvious related words (`fish`, `fishing`,
   `angler`), and search every record with line numbers:


   ```bash
   grep -rinE "fish|angl" <root> --include='*.md'
   ```


3. **Date and relationship searches.** Use the details at the top (`relationship`, `first_met`, `last_contact`)
   and dated log headings (`### YYYY-MM-DD`) for questions like "everyone I met in March" or "people
   I have not spoken to since spring". For "who knows Ana Ruiz", search for links to her record:
   `grep -l "ana-ruiz/ana-ruiz.md" <root>/*/*.md`.
4. Open the matching records and make sure each one really answers the search. Ignore accidental
   matches.
5. Return the most useful matches as a numbered list, at most 15 (say how many more there are):


   ```
   1. Jane Doe (donor, Travis County; last contact 2026-09-16)
      Interested in fly fishing and mentioned going on the Llano with Tom.
      <root>/jane-doe/jane-doe.md:24
   ```


With no results, say so and suggest a broader search or a nearby tag already in use.


## Refresh tags (`autotag`)


`/farley autotag <name>` re-tags one record; `/farley autotag` re-tags every record. Use it after
the tag rules change, or to update older records that were created before tags were added.


1. Read the tags already in use, then each record in turn.
2. Apply **Tags** to its whole content. Add missing tags, reuse an existing tag when two tags mean the same thing, and
   remove only tags whose fact is gone.
3. Change nothing but the `tags:` line. Do not add this cleanup work to the interaction log.
4. Report per record what was added, merged or removed.


## Brief


Read the record and give a short pre-meeting brief:


1. **Who:** one line with their role, organization, how you know them, and when you first met.
2. **People to remember:** relevant associates, colleagues, assistants, collaborators, or contacts.
3. **Last time:** the date, place, and what you discussed.
4. **Open threads:** unfinished follow-ups, things they were waiting on, or upcoming work and events
   that are worth asking about.
5. **Talking points:** useful interests, preferences, and subjects connected to the relationship.


Draw only from the file. Anything taken from `Research` is labelled as coming from public sources.
If the file is thin, say so rather than padding the brief.


## Research


This command searches the web only when the user explicitly asks for it. It sends the person's name
and enough context to distinguish them from people with the same name.


1. **Find the record** (Step 1). With no record, ask for enough context to identify the right person,
   such as where they work, their role, organization, or how the user knows them, and whether to start
   a record for the results. Never search a bare name with no identifying context.
2. **Load web search:** `ToolSearch` with `select:WebSearch,WebFetch`.
3. **Collect useful context** from the record: organization, role, city, known associates, and
   events. Any focus given after the name (`research Jane Doe literacy work`) guides the searches.
4. **Search** using the name together with that context, and open the pages that look
   relevant.
5. **Confirm it is the right person.** A result counts only when it matches the name **and** at least
   one piece of that context. If you are not sure, report the possible match but do not add it to the
   record.
6. **Look only for relevant public information:** current role and work history, organizations and
   boards, public statements, news coverage, awards, published work, professional profiles, and
   public records connected to a public or professional role.
7. **Do not look for or record** a home address, personal phone number or email, date of birth,
   health information, personal finances, or private details about associates. Do not use
   people-search or data-broker sites, and do not try to get past a login or paywall.
   **People known only by a handle** (a Reddit or forum username): research only what they publish
   under that handle. Do not try to discover their real name. Do not assume the same handle on another
   site belongs to the same person unless the record already gives enough context to confirm it. If
   they publicly connect the handle to their own name, that link may be recorded.
   **Blocked sites:** WebFetch cannot reach reddit.com (old or new). Do not work around a block with
   curl or a browser; record that the site could not be read, and suggest the user paste or
   screenshot what they want kept.
8. **Write** confirmed findings as bullets under `## Research`, each with its source and date:


   ```markdown
   - Chairs the Travis County Literacy Council board ([Austin Chronicle](https://...), retrieved 2026-09-16)
   ```


   Do not duplicate an existing bullet; when a finding updates one, keep both with their dates. Do
   not copy findings into the firsthand sections. If a finding contradicts something the user
   recorded, leave the firsthand fact alone and raise it in the reply.
9. **Log it** as `### 2026-09-16 · Web research` with one line: how many findings were added and the
   focus, if any. Do not change `last_contact`. Apply **Tags** (confirmed findings may add `org/`
   and `issue/` tags).
10. **Report:** say what was added and where it came from, which possible matches were left out and
    why, what was searched for but not found, and remind the user that the web searches were sent to
    a search provider.


## Privacy


These records contain private notes about real people and organizations, so keep them limited,
relevant, and local.


- Records stay on this machine. Never publish them as an Artifact, put them in Claude Docs,
  Google Drive or email, or commit them to a repository.
- **Research** is the only command that sends anything to the web, and only when the user asks for it.
- Never use sensitive personal information as a tag.
- Do not copy a record into another project or conversation unless the user asks.
- If the user asks to remove a record, confirm first, delete that folder, then say what was deleted.

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/

The Turtle King: A look into the Turtly World of Jeff Bezos

GBTI Network — Wed, 16 Sep 2026 01:35:53 +0000

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

In a world where billionaires and tech moguls are often likened to superheroes or visionary geniuses, Jeff Bezos, the founder of Amazon and space exploration company Blue Origin, has garnered a unique and somewhat whimsical comparison: the turtle.

Bezos’ resemblance to other famous turtles has been a playful topic on social media. We particularly like this rendition played by Dana Carvey in the movie The Master of Disgu i se.

Dana Carvey from the movie The Master of Disguise

Listening to Jeff Bezos on the latest Lex Fridman podcast you get a sense of how tutrly Bezos really can be as you can easily imagine this highly interesting conversation being held with the famous turtle from the Pixar movie Finding Nemo:

“Righteous! Righteous!” – Crush rides the East Aulstrailian Current, Finding Nemo

Leaning into the theme: The Blue Origin Coat of Arms

Blue Origin’s coat of arms includes turtles reaching for the stars, symbolizing the company’s philosophy of steady progress in space exploration, mirroring a turtle’s journey.

Image sourced from Blue Origin brand audit by Cynthia Shen.

The coat of arms features a central shield with a graphical representation of Earth and space, flanked by two turtles looking upwards the celestial kingdom.

Above the shield is a banner with the company’s motto, “Gradatim Ferociter” which translates to “Step by Step, Ferociously.” This coat of arms encapsulates Blue Origin’s mission and philosophy, with the turtles symbolizing steady, determined progress towards space exploration goals.

The Tortoise and the Hare

In July of 2021, Trung Phan a developer, writer, and podcaster, produced an X/Twitter thread that highlighted the relationship between Elon Musk and Jeff Bezos and their mutual interest in space travel. Elon, musk noticed this thread, specially a tweet that highlighted a reference to the story Tortoise and Hare in comparison to the Blue Origin strategy of approaching space travel, reading:

The lesson from “tortoise & hare” is not that tortoises are faster, but rather that hares should not be complacent

— Elon Musk (@elonmusk) September 17, 2021

The Master’s Chamber

Mackenzie Bezos, Jeff’s ex-wife, reportedly had turtle-themed dreams before their split, adding a surreal layer to the turtle motif in Bezos’ life.

“MacKenzie dreamt I redecorated the bedroom.”

“I kept doing it and it got weirder and weirder and weirder. Until I was sewing stuffed turtles into the comforter.”

https://www.nationalenquirer.com/celebrity/jeff-bezos-shared-wifes-pillow-talk-with-mistress-lauren-sanchez/

Jeff Bezos, intentional or coincidental, seems to lean into the appeal of the long-living turtle. And Jeff, in case you are reading this. This isn’t a bad thing at all. We can only hope and even request that we get more turtle content in the future.

For this reason, in the spirit of The Doors, we have lovingly dubbed Jeff Bezos the Turtle King.

Thanks for reading! Please leave your turtle-related comments below. 🐢

If you like our content, please consider following us! If you like our free open-source assets, please give them a github star. We’re also happy to have lurkers on our Discord community where we manage our syndication network and curate together.

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/

Is our future full of MCP servers?

GBTI Network — Wed, 16 Sep 2026 01:35:50 +0000

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

MCP stands for Model Context Protocol, and recently the Windsurf IDE released a new feature to their Cascade agent that enables support for connecting the Claude 3.5 to MCP servers.

The emergence of MCP servers in chat agents is still very new, but considering the current trajectory, there is a strong change that it could be very common in the near (and potentially distant) future. In this blog post I’ll share my thoughts about MCP and how it is already affecting the coding world as well as how it may affect the consumer and social aspects of the future.

To begin with, let’s look at how it’s being used to code and by getting a quick introduction of what MCP servers are and how they are being incorporated in the Windsurf IDE, a LLM integrated fork of VS Code:

https://twitter.com/windsurf\_ai/status/1891664001941037123

https://twitter.com/windsurf_ai/status/1891664001941037123

The Model Context Protocol (MCP) was introduced by Anthropic in November 2024 as “a new standard for connecting AI assistants to the systems where data lives, including content repositories, business tools, and development environments.”

Following the launch of the MCP protocol, websites like glama.ai and MCP.so, emerged to support the documentation and accessibility of open-source MCP servers, making servers available for a wide variety of applications. These MCPs, numbering over 1,000 at the time of writing, are opening up LLM access to platforms such as Google Drive, Slack, GitHub, Clickup, WordPress, and many others.

It may not be too long before the general public begins augmenting their own agent experiences with one-click MCP integrations that change the behavior of their agent experience.

Some mainstream examples would be: joining influencer-owned shopping networks, brand-owned content networks, financial data API access, and even local community news and events; all for the prompting waiting in the background of a normal agent experience.

If LLM-powered micro internets are not considered a brave enough new world. It becomes even braver when the models we use leverage UI frameworks to assemble shopping portals inside the model container.

But let’s bring it back to earth and away from the social and shopping-related examples and go to the more modern, pragmatic example. How can it help make me a better coder, today?

How can it help make me a better coder, today?

Today, I am using the Windsurf IDE to work on the Traveler’s Series Minecraft mods, and it is not easy work. For the bulk of it I’ve had to hire a Java coder, but I still want to be able to use the model to improve the code base and tackle low hanging fruit; while saving our human talent for the tougher problems.

The difficulty with the above is that all the code is written in Java, and the API docs for Minecraft seem esoteric to me because I am not a Java developer and the game is very extensive. These docs are also on the web and cannot be downloaded as a zip, which makes access difficult. If I can somehow manage to create an MCP server to download and serve these docs directly to my agent, then I should be able to drastically improve the accuracy of the agent’s predictive capabilities.

For this reason I have set out to create a MCP server that does just that, but it will take some hard work to get it produced. Once I have it ready, I will test it and confirm whether or not it improved my experience working with Java for Minecraft mod development.

Anthropic versus Open AI; MCPs versus “Plugins”

One question I have is… did Anthropic risk their future by naming these addons “MCP”s? The upcoming generation Z might not be attracted to this nomenclature due to the technical aspect of it. ChatGPT did have a plugin’s marketplace, but they retired it in April 2024, citing many of the plugin hosted were becoming redundant to features added to the model itself; which was causing complications.

The very reason MCPs are on my radar right now is because of the work Anthropic has done and my current favorite IDE adopting the standard.

GPT 4o is integrated with the Windfall IDE, but it does not appear to share the MCP integration feature anthropic offers. I may be wrong here. Let me know in the comments if so.

And while “plugins” seems like it would go far with the average consumer and “MCP” seems like it would go far only with developers. Yet, MCP appears to have no competition at all.

Anyway, I’m trying my luck at building a node-based local MPC server that will help me connect my local Windsurf IDE for massive gains in Minecraft modding. I don’t know if it will work, but its worth exploring.

And remember, it’s also always worth exploring the ways today’s technologies influence tomorrow’s consumer.

Thanks for paying attention and remember, a read is a leader!

The resource shared in this post is a new article 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/

SavePoint Broadcasting Software

GBTI Network — Sun, 13 Sep 2026 00:35:17 +0000

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

SavePoint Station Manager is a self-hosted desktop application for Windows, macOS, and Linux that lets communities, DJ collectives, indie podcast networks, and hobbyist broadcasters run their own 24/7 online radio or video station.

Key capabilities:

Weekly programming schedule with automated content playout
Live contributor slots delivered over RTMP, so co-hosts can tunnel into their allotted airtime from any studio setup (OBS or any RTMP encoder)
Simulcast a single station's output to YouTube, Twitch, Kick, TikTok, Mixcloud, SoundCloud, Substack, X, Discord, and any RTMP endpoint you own
Self-hosted by design. Your station runs on your own hardware and storage. No cloud lock-in, no per-listener fees, no shared logins for co-hosts
Optional cloud backend for artist relay, permission workflows, scheduling coordination, and multi-user contributor access
Pairs with Discord for community-driven station operation and always-on chat around the broadcast
License management for community operators running multi-station deployments

Free version and free trial available. Paid tiers unlock a broadcast pass (Year Pass or subscription) for scaling stations.

The resource shared in this post is a new project 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/

How to always show Claude Code usage in the terminal

GBTI Network — Tue, 08 Sep 2026 01:55:27 +0000

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

Recently I learned that you can modify Claude Code's terminal behavior directly, by dropping in a script of your own.

The feature is called the status line, and it is a supported part of Claude Code rather than a hack. You point a statusLine setting at any shell script. Claude Code hands that script the session data as JSON on stdin on every render, and prints whatever the script prints in the bar at the bottom of the terminal.

The payload carries rate_limits, with your five hour and seven day windows, each as a used percentage and a reset time. So a script drop-in can put your model usage in the CLI permanently, visible while you work, instead of something you stop and ask for. Once it is in the bar you stop running /usage to find out where you stand.

Stefano Ginella (GitHub, Codeable) wrote a single-file status line that does exactly this, and it is the one I installed:

Reading the first line from left to right:

The model and its effort level
How full the context window is
The share of the five hour rate limit spent, and how long until it resets
The same pair for the seven day limit
A daily pace figure, written as today's spend against today's share of the week

The second line carries the session id, the project path, and the git branch.

The daily figure is two numbers, both percentages of the seven day limit: what today has spent, and what today is allowed. The allowance is whatever is left of the week divided evenly across the days until the reset, so D:10/24% means today has taken 10 percent against an even share of 24 percent. It turns yellow at 85 percent of that share and red past it. Going over is not forgiven. Tomorrow's share is recalculated from what is left, so a heavy day makes every day after it smaller.

Right now the rate_limits object is only present for Claude.ai Pro and Max subscribers, and only after the session's first API response. Before that first response arrives, and on any other plan, the field is simply not there. A script that reads it without checking will print an error into the bar instead of your usage, so it has to look first. None of this costs an API call either, because Claude Code is already handing the numbers to your script.

How to install manually

Save Stefano's script as ~/.claude/statusline/statusline.mjs, then add a statusLine block to ~/.claude/settings.json:

{
  "statusLine": {
    "type": "command",
    "command": "node /Users/you/.claude/statusline/statusline.mjs"
  }
}

Use your own absolute path. Putting it in ~/.claude/settings.json applies it everywhere; putting the same block in a project's .claude/settings.json tries it on one repo first.

If you run Claude Code inside VS Code, the status bar renders in terminal mode only. It does not appear in the sidebar chat.

Install it globally with one prompt

Paste this into Claude Code and it will do the whole installation, including the parts that are easy to get wrong.

Install Stefano Ginella's Claude Code status line for me, globally.

1. Create ~/.claude/statusline/ and download the script into it as statusline.mjs:
   https://gist.githubusercontent.com/stefanoginella/ffe56f293baf6241abe74c3883082755/raw/statusline.mjs
   Make it executable and run `node --check` on it before going further.

2. Read my existing ~/.claude/settings.json first, then MERGE a statusLine block
   into it. Do not overwrite the file and do not disturb any other key:

   "statusLine": { "type": "command", "command": "node <absolute path to that file>" }

   Use my real home directory in the command, not a tilde, and confirm the JSON
   still parses afterwards.

3. Prove it works before telling me it is done. Pipe a realistic payload into the
   script and show me the output, using a throwaway HOME so my real state files
   are untouched:

   HOME=$(mktemp -d) node ~/.claude/statusline/statusline.mjs <<'JSON'
   {"model":{"display_name":"Opus 5"},"effort":{"level":"high"},
    "session_id":"test","workspace":{"current_dir":"."},"cwd":".",
    "rate_limits":{"five_hour":{"used_percentage":20,"resets_at":9999999999},
                   "seven_day":{"used_percentage":15,"resets_at":9999999999}}}
   JSON

4. Tell me if the status line needs a restart to appear, and confirm you changed
   nothing else in my settings.

What it looks like once it is running

Here is the same status line in a live session, sitting under the prompt in the VS Code terminal panel. The model and its effort level, the context window, both rate limit windows and the daily pace figure stay on screen while the work happens.

Credits

Credit to Stefano Ginella for the script, and for writing it to run entirely offline. You can find his work on GitHub, and he takes on client work through Codeable.

Disclosure: the Codeable links here are referral links. GBTI Network is a longstanding fan of the Codeable community for WordPress and React work.

The resource shared in this post is a new article 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/

/GROK : An Agent Skill for Narrative Summaries

GBTI Network — Thu, 27 Aug 2026 01:25:41 +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 /grok command that takes its own last reply and re-tells it as two or three short paragraphs of plain narrative prose.

The term "Grok" comes from Robert Heinlein's novel Stranger in a Strange Land, where to "grok" something is to drink it deeply enough to essentially be one with it.

What makes it different from asking for a summary

The skill is explicit that there are no new tool calls, no fresh research, and no findings that were not already in the previous reply. The /grok skill asks the agent to only consider the last reply. We are not asking it to QA its response, rather we just want it to rephrase it.

Asking the bot to summarize does not inform the bot how to summarize or what the reader will consider valuable in a summary. This skill takes some of that extra definition off the plate of the operator (you).

Install

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

Nothing to configure. Add a topic after the command (/grok the migration part) to narrow it to one thread within the last reply.

The skill file

---
name: grok
description: ">"
  Re-tell your own last reply as 2 or 3 short narrative paragraphs, so the point survives without the
  scaffolding. Invoke for "/grok", or when the user asks you to say that again plainly, give them the
  short version, or explain what it actually means. It re-expresses what you ALREADY said: no new
  research, no tool calls, no fresh findings. Prose only, no headers, no bullets, no tables.
---

# /grok: say it again, as a story

Your last reply was structured for completeness. This one is structured for understanding. Take what you
just said and re-tell it in **2 or 3 short paragraphs of plain narrative prose**, as if explaining it to a
capable colleague who missed the detail and wants the shape of it.

## What to re-tell

**Your own previous reply, and nothing else.** Not the whole conversation, not the task, not a fresh look
at the code. If your last message was itself a `/grok` response, go back to the one before it. If the user
typed `/grok` with a topic after it, narrow to that thread within your last reply.

**Add nothing.** No new investigation, no tool calls, no findings that were not already in the reply. If
you notice something new while re-reading, that is a separate message, not part of the grok. The value
here is compression and clarity, and a grok that smuggles in fresh claims is neither.

If the last reply was already two plain paragraphs, say so and stop rather than paraphrasing it into
something worse. If there is no previous reply of yours to work from, say that instead of inventing one.

## How to write it

**Narrative means causal, not chronological.** Not "first this, then that." Say what was true, what that
caused, and what it means now. A reader should finish knowing the shape of the situation, not a list of
events. Lead with the thing that matters most, which is often the surprise, the reversal, or the decision
waiting on them, and let the rest hang off it.

**Strip the scaffolding, keep the load-bearing detail.** Out: file paths, line numbers, commit hashes,
counts, tables, headers, bullets, bold labels. In: any specific that carries the meaning. "The reconcile
bot published it overnight" needs no commit hash to land, but "nobody is on it" and "this breaks at the
$5 price" are the substance and must survive.

**Two or three paragraphs, short ones.** If it will not compress that far, the compression is the point:
choose what matters and drop the rest rather than writing four dense paragraphs. Plain sentences. No
em dashes or en dashes.

## What must survive the compression

These are the things a summary is most tempted to smooth away, and losing them makes the grok actively
worse than the reply it replaced:

- **Anything waiting on the user.** A pending decision, an unanswered question, a required approval. If
  they read only the grok, they must still know what is theirs to do.
- **Corrections and reversals.** If the last reply corrected an earlier claim, admitted an error, or
  withdrew something, that stays. Narrative flow is not a reason to quietly drop the part where you were
  wrong.
- **Uncertainty, as uncertainty.** What was unverified stays unverified. Never let compression promote a
  hedge into a fact; "this looks like" must not become "this is".
- **Bad news.** A failure, a live bug, a thing that did not work. If the reply led with a problem, the
  grok leads with it too.

A grok that reads better than the reply because it left out the awkward parts is a failure, not a success.

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/

Ryker: In-Browser Visual Editor for HTML and Markdown with agent-ready change exports

GBTI Network — Sun, 23 Aug 2026 15:53:39 +0000

HTML has become an increasingly useful format for working with large language models.

Models can generate complete HTML documents very quickly, but editing those documents manually can still be awkward.

HTML is normally edited through source code. That works well for development, but it is not always the best way to proofread a document, move content around, or make small editorial changes.

We built Ryker to make that process easier.

Ryker is a Chrome extension for visually editing HTML and Markdown while recording the changes you make as prompt-ready change requests.

The idea is simple:

You make the edits directly to the document.

Ryker records what changed as a text blob of machine-readable change requests.

When you are finished proofreading, you can hand those changes back to your agent for implementation.

That workflow influenced most of the feature decisions behind Ryker. The goal is not to replace the agent or permanently modify the source behind its back. The goal is to give you a more natural way to review the document while still allowing the agent to handle the final implementation.

Ryker supports two primary workflows:

Edit any live HTML page directly in the browser.
Load HTML and Markdown files from your hard drive into Ryker for inline editing.

As you work, Ryker records those edits so they can be exported as a prompt-ready change request.

You can learn more about Ryker and install the Chrome extension here:

https://gbti.network/products/ryker/

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/