DEV Community: GBTI Network

VSCode Extension: Terminal Session Profiles

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

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

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

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

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

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

Terminal session profile manager

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

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

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

Each profile includes:

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

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

For example, a profile can use:

claude --resume ClaudeCodeSessionName

to reopen a particular named Claude Code session.

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

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

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

Restoring profiles after a restart

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

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

Terminal Session Profiles handles the other half of that recovery.

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

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

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

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

Optional workspace layout

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

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

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

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

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

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

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

Independent features

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

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

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

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

Keyboard and workspace controls

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

Default shortcuts include:

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

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

Install

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

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

ext install GBTI.gbti-terminal-sessions

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

GBTI.gbti-terminal-sessions

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

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

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

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

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

Resolve Open Questions: a /qa Skill for Claude Code

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

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

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

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

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

Install

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

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

The skill file

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

# /qa: resolve the open questions before building

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

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

## Read the argument first, it selects the mode

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

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

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

## Step 1: verify before you ask

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

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

## Step 2: what to interrogate

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

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

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

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

## Step 3: how to ask

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

## Step 4: after the answers

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

## Reminders

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

The modes

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

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

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

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

Making it yours

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

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

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

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

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

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

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

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

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

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

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

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

Install

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

The skill file

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

# Managing Scopes of Work

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

## Initialize (/sow init)

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

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

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

## Authoring a SOW: do these steps IN ORDER

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

## Reminders

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

Making it yours

Three dials worth adjusting:

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

Why the rules are in there

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

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

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

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

Pre-Skill Prompt: Responsive Design Audit with MCP Playwright

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

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

"This prompt can be converted into a skill"

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

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

Core responsive strategy:

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

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

Viewport test matrix:

Mobile device viewports:

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

Tablet viewports:

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

Desktop browser widths:

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

For each viewport:

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

Desktop browser compression rules:

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

Mobile device adaptation rules:

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

Tablet rules:

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

Implementation expectations:

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

Decision framework:

For every responsive issue, decide which fix category applies:

Compression fix:

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

Layout preservation fix:

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

Mobile restructuring fix:

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

Content priority fix:

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

Structural redesign fix:

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

Final deliverable:

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

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

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

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

CI Health Check: a /ci Skill for Claude Code

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

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

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

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

Install

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

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

The skill file

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

# CI operations

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

## Tooling lore (read first)

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

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

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

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

## Fix discipline (failing tests especially)

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

## Actions

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

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

### /ci watch

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

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

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

### /ci schedule

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

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

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

### /ci rerun <run-id>

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

### /ci list

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

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

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

## Reporting conventions

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

Making it yours

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

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

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

Why the odd details are in there

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

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

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

How to Generate Professional LinkedIn Headshots Using Nano Banana

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

By Naresh Devineni, GBTI Network Member

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

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

Step 1: Find Your Reference Image

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

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

Step 2: Let AI Describe It

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

Here is an example prompt:

For the uploaded reference image:

### ✅ Be Minimal

Only describe what is clearly visible.

### Never Include

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

### Only Include What’s Visible

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

### Rules

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

### Critical Restrictions

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

Step 3: Generate Your Headshot

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

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

Here is an example headshot and prompt:

For the uploaded picture, generate an image of:

Expression: Warm, genuine smile

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

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

Lighting: Soft, natural outdoor lighting from front

Facial shadows: Face evenly lit with minimal shadows

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

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

Framing: Head and upper torso to mid-chest level

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

CRITICAL RESTRICTIONS:

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

The Result

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

Sounds easy?
It is!

Thanks for reading this article.

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

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

15 Free React Landing Page Templates to help Launch your SaaS

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

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

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

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

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

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

Thanks for paying attention!

Using Hue to create colorful animations 🌈

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

Hi fellow devs! 👋

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

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

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

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

What it does

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

Core Controls:

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

Smart Presets:

The tool includes thoughtfully designed presets for each effect:

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

The technical bits & export formats

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

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

Export Options:

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

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

Social Media Ready:

The output formats work perfectly across all major platforms:

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

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

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

Get Started

Check out the project:

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

Introducing Perplexity AI Lookups for WordPress

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

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

What does this plugin do?

This plugin allows site visitors to:

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

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

Why did we build it?

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

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

It's a very simple and effective implementation!

Use cases

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

Getting started

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

Future plans

We are exploring additional features, including:

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

Contributing

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

Final thoughts

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

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

Automating Git Sign-offs Per Project: A Complete Guide

GBTI Network — Mon, 09 Jun 2025 02:23:55 +0000

Git sign-offs provide accountability and transparency in distributed development environments. The standard implementation requires manual inclusion of the -s flag with each commit, which introduces potential for human error and inconsistency.

Our technical guide presents multiple methods for automating Git sign-offs at the project level, arranged in order of increasing complexity: commit templates, Git aliases, and language-specific scripts (Node.js, PowerShell, Python). Each approach is documented with implementation steps optimized for Windows environments.

The guide includes PowerShell commands for local Git configuration, template creation, and script implementation. Code examples demonstrate how to integrate sign-offs into existing workflows without disrupting development processes.

Complete documentation: https://gbti.network/devops/frameworks/git/how-to-automatically-sign-off-git-commits/

Thanks for paying attention!

Learn how to automate Git sign-offs at the project level using commit templates, aliases, and scripts, ensuring proper sign-offs without disrupting workflow. https://gbti.network/devops/frameworks/git/how-to-automatically-sign-off-git-commits/ #Git

GBTI Network — Mon, 09 Jun 2025 02:16:01 +0000

Reimagining WordPress Category Management with Advanced Taxonomy Manager

GBTI Network — Tue, 08 Apr 2025 12:58:38 +0000

While building the GBTI Network and managing over 80 categories, it became clear that the native WordPress category management system was outdated. The lack of drag-and-drop functionality, slow hard refreshes, and absence of quick editing features slowed down the process of organizing content meaningfully.

This frustration led to the development of Advanced Taxonomy Manager, a fully AJAX-powered plugin designed to modernize category and taxonomy management in WordPress.

The Problem

Managing categories in WordPress has long felt like working in slow motion.

With every change triggering a page reload, and no quick way to reorder or nest categories, maintaining a clean and logical taxonomy structure becomes tedious fast.

Platforms like Slack and Discord have long since solved this, allowing users to quickly organize channels and categories with ease. WordPress, however, lagged behind.

The Solution: Advanced Taxonomy Manager

Advanced Taxonomy Manager brings a modern interface to WordPress taxonomy management.

With this plugin, you can:

Drag and drop categories to nest or un-nest them
Quickly edit categories in a collapsible side drawer
Avoid hard refreshes entirely for a smoother workflow
Generate category descriptions with OpenAI integration
Enjoy better visibility of parent and child categories
Export and Import entire taxonomies, quickly.

Plugin Screenshot

Versions Available

We’ve built two versions of the plugin to meet different needs:

Advanced Taxonomy Manager

Full-featured version, available exclusively to GBTI Network members.
Advanced Category Manager

Focused on categories only, this version is freely available in the WordPress plugin directory.

Check out the free version on the WordPress Plugin Directory

Learn more about the full version for GBTI Network members

Thanks for reading. If you have any thoughts or suggestions, I’d love to hear them in the comments.

GBTI Network

The GBTI Network is a professional co-op network where members have opportunities to share profits, publish products, and contribute articles—all powered by community and GitHub sponsorships.

Sponsor our work by becoming a GBTI Network Member (powered by GitHub Sponsorship).

DEV Community: GBTI Network

VSCode Extension: Terminal Session Profiles

Terminal session profile manager

Restoring profiles after a restart

Optional workspace layout

Independent features

Keyboard and workspace controls

Install

Resolve Open Questions: a /qa Skill for Claude Code

Install

The skill file

The modes

Making it yours

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

Install

The skill file

Making it yours

Why the rules are in there

Pre-Skill Prompt: Responsive Design Audit with MCP Playwright

CI Health Check: a /ci Skill for Claude Code

Install

The skill file

Making it yours

Why the odd details are in there

How to Generate Professional LinkedIn Headshots Using Nano Banana

Step 1: Find Your Reference Image

Step 2: Let AI Describe It

Step 3: Generate Your Headshot

The Result

15 Free React Landing Page Templates to help Launch your SaaS

Using Hue to create colorful animations 🌈

What it does

Core Controls:

Smart Presets:

The technical bits & export formats

Export Options:

Social Media Ready:

Get Started

Introducing Perplexity AI Lookups for WordPress

What does this plugin do?

Why did we build it?

Use cases

Getting started

Future plans

Contributing

Automating Git Sign-offs Per Project: A Complete Guide

Learn how to automate Git sign-offs at the project level using commit templates, aliases, and scripts, ensuring proper sign-offs without disrupting workflow. https://gbti.network/devops/frameworks/git/how-to-automatically-sign-off-git-commits/ #Git

Reimagining WordPress Category Management with Advanced Taxonomy Manager

The Problem

The Solution: Advanced Taxonomy Manager

Plugin Screenshot

Versions Available

GBTI Network

Stay Connected