Relationship: StandupBrief is one of this publisher's independent developer tools. Its purpose is to provide a standup dashboard.

StandupBrief — VS Code Extension

Personal standup-brief dashboard, surfaced directly inside VS Code: PRs awaiting your review, PRs you authored, work items assigned to you, open incidents, and recent local commits — all in one place.

Part of the standup-brief monorepo. This package is the VS Code surface; core data fetching lives in standup-brief-core.

Migration to FocusQuest

StandupBrief 0.1.7 is a compatibility release for the Daily Brief built into focusquest.focusquest. FocusQuest 1.9.0 is the minimum compatible version.

• With FocusQuest 1.9.0 or newer installed, StandupBrief keeps its existing command and setting IDs but delegates visible commands to focusquest.dailyBrief.*. Its own initial refresh, auto-refresh timer, status bar, view provider, and other standalone background work remain disabled.
• Run StandupBrief: Migrate or Retry Migration to FocusQuest to transfer explicitly configured non-secret settings through the focusquest-extension-migration.v1 in-process contract. Stored GitHub and ADO PATs are never read or exposed by the migration API. FocusQuest instead uses its built-in authentication and authenticated CLI/environment fallbacks; the migration command offers an explicit FocusQuest re-authentication action when needed.
• Without FocusQuest, or when its version is older than 1.9.0, StandupBrief continues to run in standalone mode. Existing users can therefore update before installing the compatible FocusQuest release.

The extension remains published as focusquest.standup-brief; this migration release does not rename or remove the Marketplace listing.

Features

• Sidebar TreeView with grouped sections for pull requests, work items, issues, and incidents
• Assigned work items from Azure DevOps — everything assigned to you that is not in a terminal state, across every configured organization and project
• Full webview dashboard that adopts your current VS Code theme
• Status bar item showing an urgent-count badge with one-click refresh
• Auto-refresh on a configurable interval
• GitHub + Microsoft sign-in via VS Code's built-in vscode.authentication providers
• Copy current brief as Markdown for pasting into standups, issues, or notes

All views are rendered from a single BriefResult (see standup-brief-core/types) so the tree, webview, and status bar stay consistent.

Install

Install from the VS Code Marketplace:

• Extensions view (Ctrl+Shift+X): search for StandupBrief, then click Install.

• Command line:

  code --install-extension focusquest.standup-brief
  

Or install a packaged VSIX directly:

code --install-extension standup-brief.vsix

The shipped artifact lives at dist/standup-brief.vsix (~84 KB).

To build the VSIX from source:

pnpm -F standup-brief build
pnpm -F standup-brief package

Configuration

Fourteen settings, organized into four groups under Settings → Extensions → StandupBrief.

General

Azure DevOps

Each entry in ado.scopes is an { "organization", "project" } pair, using bare names rather than URLs:

"standupBrief.ado.scopes": [
  { "organization": "contoso", "project": "OSGS" },
  { "organization": "CEPlanning", "project": "Commerce and Ecosystems Planning" }
]

Work items are matched on assigned to you and not in a terminal state, rather than on a specific state name, because ADO process templates disagree about what "active" is called. A scope that fails (for example, an organization you cannot read) is reported as a warning and skipped — it never blanks the rest of the brief.

GitHub

Local Git

Automated setup (runbook)

Configuring the fourteen settings by hand is tedious. If you use an AI CLI agent (GitHub Copilot CLI, or any agent that can run shell commands and edit files), you can hand it the prompt below and let it detect your gh/az identity, discover your local repos, and write the settings for you. It is self-contained — it needs no extra tooling beyond the gh/az CLIs you may already have.

How to use

1. Open your AI CLI agent in a terminal.
2. Paste the entire prompt block below.
3. Answer the two questions it asks (your Azure DevOps organization and project); everything else is auto-detected.
4. When it finishes, reload VS Code (Developer: Reload Window) and run StandupBrief: Refresh.

The prompt

You are configuring the "StandupBrief" VS Code extension by editing my VS Code
user settings.json. Do NOT install anything. Work with the tools already present.
Follow these steps and report what you changed.

1. Locate my VS Code user settings.json:
   - Windows:  %APPDATA%\Code\User\settings.json
   - macOS:    ~/Library/Application Support/Code/User/settings.json
   - Linux:    ~/.config/Code/User/settings.json
   (For VS Code Insiders, replace "Code" with "Code - Insiders".)
   Parse it as JSONC. Preserve all existing keys and comments. Create the file with
   {} if it does not exist. Never overwrite a non-empty value with an empty one.

2. GitHub identity:
   - Run: gh auth status
   - If not authenticated, tell me to run `gh auth login` and stop.
   - Otherwise run: gh api user --jq .login
   - Set standupBrief.github.viewerLogin to that login.

3. Azure DevOps scopes (required):
   - Ask me which Azure DevOps organizations and projects my work lives in.
     There may be more than one, and a single organization may contribute
     several projects.
   - Set standupBrief.ado.scopes to an array of
     { "organization": "<org>", "project": "<project>" } objects, using bare
     names (not URLs). Do not replace a non-empty existing array.
   - If standupBrief.ado.organization / standupBrief.ado.project are already
     set, fold them in as one scope rather than dropping them.

4. Azure DevOps identity — try the az path first:
   - Run: az account show
     (On Windows, `az` is often off-PATH for GUI apps; if `az` isn't found, try
      "C:\Program Files\Microsoft SDKs\Azure\CLI2\wbin\az.cmd" invoked via cmd.exe /c.)
   - If az is logged in:
       standupBrief.ado.viewerEmail    = `az ad signed-in-user show --query userPrincipalName -o tsv`
       standupBrief.ado.viewerObjectId = `az ad signed-in-user show --query id -o tsv`
   - If `az login` is blocked (e.g. Conditional Access requires a compliant device),
     DO NOT fight it. Skip these two settings and tell me to use the PAT fallback:
       a. Create an Azure DevOps Personal Access Token with scopes
          "Code (Read)" and "Work Items (Read)".
       b. In VS Code, run the command "StandupBrief: Set ADO PAT" and paste it.
     The extension auto-resolves my email and object id from the ADO connectionData
     endpoint once a PAT is set, so leaving viewerEmail/viewerObjectId empty is fine.

5. Local git repos for the "recent activity" section:
   - Ask me for a root folder to scan (default: C:\repos on Windows, ~/repos otherwise).
   - For each immediate subdirectory that contains a .git folder, build an entry:
       { "name": "<folder name>", "path": "<absolute path>", "branch": "<current branch>" }
     using the checked-out branch (git -C <path> rev-parse --abbrev-ref HEAD).
   - Set standupBrief.gitRepos to that array.

6. Write settings.json back (valid JSON), then print a summary of every key you set
   and remind me to reload VS Code (Developer: Reload Window) and run
   "StandupBrief: Refresh". If ADO still shows no data, run
   "StandupBrief: Diagnose Auth" and "StandupBrief: Show Logs".

Notes

• The PAT fallback in step 4 is the reliable path on machines where interactive az login is blocked by Conditional Access / device-compliance policies. Because the extension derives your ADO email and object id from a PAT automatically, you do not need to look those ids up manually.
• PATs are scoped to a single organization. Microsoft (AAD) sign-in covers every organization with one token, so if ado.scopes spans more than one organization, the PAT fallback will only satisfy the organization the PAT was issued for; the others are reported as failed scopes. Prefer the sign-in path when using multiple organizations.
• The prompt only writes the keys documented in Configuration; the remaining tuning settings (refresh interval, stale age, watched/incident repos) keep their defaults and can be adjusted afterwards.

Commands

All commands are available under the StandupBrief category in the command palette.

Authentication

The extension prefers VS Code's built-in vscode.authentication providers for GitHub and Microsoft (AAD) sign-in. For ADO, it next tries the Azure CLI for a Bearer token. Tokens from these primary paths are issued and refreshed outside the extension and sent by AdoClient as Bearer credentials.

If sign-in is unavailable, run StandupBrief: Set GitHub PAT or StandupBrief: Set ADO PAT to store a fallback token in VS Code SecretStorage. The ADO fallback chain checks that stored PAT and then the ADO_PAT environment variable. AdoClient sends an ADO PAT using HTTP Basic authentication with an empty username.

Multi-organization note: Existing global ADO PATs can authenticate across all organizations the user can access, but Azure DevOps Services will decommission global PATs on December 1, 2026. Organization-scoped PATs cover only their issuing organization. If ado.scopes spans organizations, prefer Bearer authentication rather than depending on the retiring global PAT type.

Screenshots

Validation screenshots are regenerated on demand via the PowerShell capture script:

pnpm -F standup-brief build
pnpm -F standup-brief package
pwsh packages/vscode/scripts/capture-screenshots.ps1

Outputs (gitignored) land in packages/vscode/test-artifacts/screenshots/:

The script launches an isolated VS Code instance (dedicated --user-data-dir and --extensions-dir under $env:TEMP) so it does not perturb your primary profile. It is idempotent: existing screenshots and isolated dirs are deleted at the start of each run.

Implementation note — test-electron vs PowerShell

An earlier design used @vscode/test-electron + Electron capturePage() to automate capture from inside an Extension Host (Option A in the design notes). VS Code 1.85 ships with Electron 25, where @electron/remote is deprecated and BrowserWindow is not reachable from the extension-host Node process without bespoke IPC — brittle enough that we standardised on the PowerShell wrapper (Option B) as the validation protocol. The internal command standupBrief._loadFixture (env-var gated by STANDUP_BRIEF_ALLOW_FIXTURES=1, otherwise a no-op) is retained so Option A can be wired up later without another round-trip.

Roadmap

• Telemetry opt-in for usage and error reporting

Development

Source lives in packages/vscode/src/. The extension is bundled with esbuild (esbuild.config.mjs) into dist/extension.js.

To iterate locally:

1. Open the monorepo in VS Code.
2. Run pnpm -F standup-brief build (or pnpm -F standup-brief watch for incremental builds).
3. Press F5 to launch an Extension Development Host with the extension loaded.

Useful scripts:

pnpm -F standup-brief build       # one-shot esbuild bundle
pnpm -F standup-brief watch       # rebuild on change
pnpm -F standup-brief typecheck   # tsc --noEmit
pnpm -F standup-brief lint        # biome check src
pnpm -F standup-brief package     # produce dist/standup-brief.vsix

pnpm -F standup-brief test runs the Vitest unit suite (e.g. identity resolution). Broader webview and tree-provider coverage is tracked alongside the roadmap items above; typecheck remains a required gate.