github-codebase-briefing
GitHub Codebase Briefing
This skill performs a "deep read" of a repository. It avoids superficial listings by first understanding the project's architecture and then evaluating open items against that context.
Prerequisites
- Tooling: The agent must have access to the
ghCLI. - Auth: The user must be authenticated (
gh auth status).
Instructions
Step 1: Initialize the Mental Model
Before looking at tasks, understand the environment. Run these commands in sequence:
- Metadata:
gh repo view <owner/repo> --json name,description,stargazerCount,forkCount - Structure:
gh api repos/<owner/repo>/contents/ - Identity: Read the project manifest (e.g.,
package.json,go.mod,pyproject.toml) andREADME.md. - Entry Point: Read the primary entry file (e.g.,
index.ts,main.go) to identify the Public API surface.
Step 2: Retrieve State & Delta
Fetch current items and recent changes:
- Issues:
gh issue list --repo <owner/repo> --state open --json number,title,body,author,createdAt,updatedAt,labels,comments - PRs:
gh pr list --repo <owner/repo> --state open --json number,title,body,author,createdAt,updatedAt,labels,additions,deletions,changedFiles,headRefName - 24h Delta:
gh issue list --state closed --since 24handgh pr list --state merged --since 24h.
Step 3: Deep Analysis Logic
For every issue and PR, do not just summarize the text. Perform a logic check:
- Issues: Use
gh api repos/<owner/repo>/contents/<path>to inspect the code mentioned in the report. - PRs: Use
gh pr diff <number>to review actual implementation. Evaluate if the code follows the patterns found in Step 1. - Flags:
- π¨ SECURITY: Scan for credentials, auth bypass, or injection keywords.
- π€ EXTERNAL: Prioritize PRs from non-maintainers.
- β
READY: Verify mergeability with
gh pr view <number> --json mergeable,statusCheckRollup.
Step 4: Pattern Synthesis
Group items into high-level insights:
- Bug Clusters: Identify if 3+ issues share a root cause in a specific module.
- Hot Modules: Flag files that appear in multiple open items.
- Client Patterns: Group issues by consumer (e.g., "VS Code users are reporting X").
Output Template
# {REPO_NAME} Daily Briefing β {DATE}
Snapshot: {N} Issues ({+X} since yesterday) | {M} PRs ({+Y} since yesterday)
β‘ Suggested Actions Today
- [Priority] #{Num}: {One-line reason}
- [Priority] #{Num}: {One-line reason}
π Open Issues Deep Dive
[Flag] #{Num} β {Title}
- Context: Plain-English explanation of the "why" and "where" in the codebase.
- Key Evidence: > {Blockquote of critical user text}
- Resolution Path: {Quick fix/Design decision/Blocked}
π Pull Request Analysis
[Flag] #{Num} β {Title}
- Impact: Summary of files changed and architectural fit.
- Quality Note: Honest assessment of implementation and CI status.
π Patterns & Health
- Hot Modules:
{list/of/files} - Release Cadence: Last release was
{days}ago.
More from google-labs-code/stitch-sdk
stitch-sdk-usage
Use the Stitch SDK to generate, edit, and iterate on UI screens from text prompts, manage projects, and retrieve screen HTML/images. Use when the user wants to consume the SDK in their application.
164stitch-sdk-readme
Generate or update the README for the Stitch SDK. Use the Bookstore Test structure and source the current API from the codebase. Use when the README needs to be written or updated.
105stitch-sdk-development
Develop the Stitch SDK. Covers the generation pipeline, dual modality (agent vs SDK), error handling, and Traffic Light (Red-Green-Yellow) implementation workflow. Use when adding features, fixing bugs, or understanding the architecture.
94stitch-sdk-domain-design
Design the domain model for the Stitch SDK. Use when mapping MCP tools to domain classes and bindings in domain-map.json. This is Stage 2 of the generation pipeline.
92stitch-sdk-pipeline
Run the full Stitch SDK generation pipeline. Use when a new tool is added, or the SDK needs to be regenerated end-to-end.
91tdd-red-green-refactor
>
87