github·Apr 6, 2026·3 min readCurated summary

GitHub Copilot CLI combines model families for a second opinion

GitHub Copilot CLI’s experimental Rubber Duck feature adds an independent reviewer from a different AI model family to catch mistakes before they compound. When Claude models orchestrate a task, GPT-5.4 reviews plans, implementations, and tests at key checkpoints. On SWE-Bench Pro, Claude Sonnet 4.6 with Rubber Duck closed 74.7% of the performance gap with Claude Opus 4.6 alone, particularly on complex, multi-file tasks. ## The Problem with Self-Review - Coding agents typically assess a task, plan, implement, test, and iterate. - Early assumptions can create downstream dependencies and make small mistakes expensive to fix. - Self-reflection helps, but a model reviewing its own work may retain the same training biases and blind spots. ## Cross-Family Review with Rubber Duck - Rubber Duck is a focused review agent powered by a complementary model family. - Claude orchestrators currently use GPT-5.4 as the reviewer. - It produces a short list of high-value concerns, including: - Missed details - Questionable assumptions - Architectural risks - Relevant edge cases ## Evaluation Results - On SWE-Bench Pro, Sonnet 4.6 plus Rubber Duck approached the resolution rate of Opus 4.6 running alone. - Benefits were strongest for problems involving at least three files and 70 or more steps. - Sonnet plus Rubber Duck scored: - 3.8% above the Sonnet baseline on difficult tasks - 4.8% higher on the hardest tasks across three trials - Examples included detecting: - A scheduler that would start and immediately exit - A loop overwriting one dictionary key and dropping Solr facet categories - Cross-file Redis references that would silently break email confirmation flows ## When Reviews Happen Rubber Duck can be invoked automatically, reactively, or on request: - After a plan is drafted, to prevent flawed decisions from spreading. - After complex implementation work, to identify edge cases. - After tests are written but before they run, to expose coverage gaps or weak assertions. - When the primary agent is stuck or repeating an unproductive loop. - Any time the user asks Copilot to critique its work. Copilot incorporates the feedback and explains what changed. Reviews are intentionally infrequent and targeted at checkpoints where they provide the most value. ## Availability and Use Cases - Rubber Duck is available in Copilot CLI’s experimental mode through `/experimental`. - It works with Claude Opus, Sonnet, and Haiku as orchestrator models, provided the user has GPT-5.4 access. - It is especially suited to: - Complex refactors and architectural changes - High-stakes coding tasks - Test coverage review - Getting a second opinion before committing to a plan Rubber Duck is a practical way to reduce model-specific blind spots by combining different AI families. Developers can enable it experimentally in Copilot CLI and use automatic or on-demand critiques for difficult work.

Read original(opens in new tab)

AI AgentsCode ReviewGithub Copilot CliClaude+3

github·Apr 3, 2026·3 min readCurated summary

The uphill climb of making diff lines performant

GitHub rebuilt the pull request **Files changed** experience to keep diff reviews responsive across everything from tiny fixes to massive changes. The core conclusion is that no single optimization solves performance at scale; instead, targeted rendering improvements, virtualization, and simpler components must work together. Early results show that even small reductions in DOM size can have substantial effects on memory usage and interaction latency in large pull requests. ## Performance Challenges at GitHub’s Scale - Pull requests may contain thousands of files and millions of lines. - In extreme cases, the old experience reached: - More than **1 GB of JavaScript heap usage** - Over **400,000 DOM nodes** - Unacceptably high Interaction to Next Paint (INP) scores - Large reviews became sluggish or nearly unusable, despite the experience remaining fast for most smaller pull requests. ## A Strategy Based on Pull Request Size GitHub concluded that different pull request sizes require different performance strategies: - **Optimize diff-line components** so medium and large reviews remain fast without losing expected browser behavior, such as native find-in-page. - **Use virtualization for the largest reviews**, rendering only the content currently needed to preserve responsiveness and stability. - **Improve foundational components and rendering**, allowing performance gains to benefit every pull request size. ## Problems with the Original Diff Architecture The first React implementation made each diff line unnecessarily expensive: - Unified view used roughly **10 DOM elements per line**; split view used about **15**, before syntax highlighting added more `<span>` elements. - Each unified diff line typically involved at least **eight React components**, while split view involved at least **13**. - Additional states—such as comments, hover, and focus—could add still more components. - Small components often registered five or six React event handlers each, resulting in **20 or more handlers per line**. - These costs multiplied across thousands of lines, increasing JavaScript heap usage and worsening INP. - The component-heavy design was initially reasonable when React was introduced, but proved unsustainable for unbounded data sets. ## Incremental Improvements in the New Design GitHub’s second version focused on simplification and removing unnecessary structure: - Reduced state, JavaScript, React components, and DOM elements. - Removed redundant `<code>` tags from line-number cells. - Eliminating just two nodes per line saves approximately **20,000 DOM nodes across 10,000 lines**. - The example demonstrates how seemingly minor changes compound into meaningful improvements at large scale. The practical lesson is that performant large-scale interfaces require layered optimizations: simplify every repeated element, reduce per-item overhead, and use virtualization when rendering everything at once is no longer viable.

Read original(opens in new tab)

ReactJavaScriptHTMLWeb Performance+3

github·Apr 1, 2026·3 min readCurated summary

Securing the open source supply chain across GitHub

Attackers increasingly target GitHub Actions workflows to steal secrets, publish malicious packages, and spread into additional projects. GitHub recommends reducing credential exposure, hardening workflows, and using automated tools such as CodeQL and Dependabot. It is also expanding trusted publishing, malware detection, and GitHub Actions security improvements in response to campaigns such as Shai-Hulud. ## How attacks begin - Many supply-chain attacks start by exploiting insecure GitHub Actions workflows. - Stolen API keys and other secrets can let attackers publish packages from their own machines. - Malicious packages can then compromise downstream projects and propagate the attack. ## Securing GitHub Actions today - Enable CodeQL’s GitHub Actions queries, which are free for public repositories, to identify workflow security weaknesses. - Avoid triggering workflows with `pull_request_target`. - Pin third-party Actions to full-length commit SHAs. - Updates should be made by maintainers or Dependabot. - Treat pull requests that change pinned Actions with suspicion. - Protect workflows against script injection when using pull-request or other user-submitted content. - Monitor GitHub’s Advisory Database and use Dependabot malware alerts to detect compromised or vulnerable dependencies. ## Replacing secrets with trusted publishing - GitHub recommends using short-lived OpenID Connect tokens containing a workflow’s workload identity instead of storing long-lived secrets. - Cloud providers, package registries, and hosted services can use these tokens to authorize workflow activity. - Through collaboration with OpenSSF, trusted publishing is supported by npm, PyPI, NuGet, RubyGems, Crates, and other registries. - Trusted publishing both removes credentials from build pipelines and provides a signal when a package unexpectedly switches away from it. ## Detecting malicious packages - npm publishes more than 30,000 packages daily and scans every package version for malware. - Hundreds of newly published packages contain malicious code each day. - Human review confirms detections before action is taken, helping avoid disrupting legitimate maintainers. - Even a 1% false-positive rate would affect hundreds of valid package releases daily at npm’s scale. ## GitHub’s upcoming security work - Attacks such as Shai-Hulud accelerated npm’s security roadmap. - GitHub is expanding trusted publishing, malware detection and removal, and collaboration with maintainers. - The company is also revisiting and accelerating its GitHub Actions security roadmap. - New protections may require workflow changes or create compatibility concerns, so GitHub aims to make the transition gradual and solicits community feedback. Projects should audit their Actions workflows immediately, eliminate long-lived publishing credentials where possible, pin dependencies, and enable CodeQL and Dependabot. Adopting trusted publishing provides both stronger protection and useful evidence for identifying suspicious package releases.

Read original(opens in new tab)

GitHub ActionsNpmSupply Chain SecurityCodeql+3

github·Apr 1, 2026·3 min readCurated summary

Run multiple agents at once with /fleet in Copilot CLI

GitHub Copilot CLI’s `/fleet` command lets multiple subagents work on independent tasks simultaneously rather than completing everything sequentially. An orchestrator decomposes the objective, manages dependencies, dispatches agents, and verifies their results. To benefit from parallel execution, users should define clear deliverables, boundaries, dependencies, and validation requirements. ## How `/fleet` Works - Breaks a task into discrete work items and identifies dependencies. - Runs independent items in parallel as background subagents. - Waits for completed work before dispatching dependent tasks. - Verifies results and assembles the final output. - Gives each subagent its own context window while sharing the same filesystem. - Prevents direct communication between subagents; the orchestrator coordinates them. ## Getting Started - Run `/fleet <objective prompt>` interactively, such as: ```bash /fleet Refactor the auth module, update tests, and fix the related docs in docs/auth/ ``` - For terminal-based non-interactive use: ```bash copilot -p "/fleet <YOUR TASK>" --no-ask-user ``` - The `--no-ask-user` option is required when no one is available to answer prompts. ## Writing Parallelizable Prompts - Define concrete deliverables such as individual files, test suites, or documentation sections. - Avoid vague requests that make it difficult to identify independent work. - Explicitly state: - File or module ownership - Constraints, such as avoiding dependency changes - Required tests, linting, or type checks - List dependencies so the orchestrator can serialize only the necessary work while parallelizing the rest. ## Using Custom Agents - Specialized agents can be defined in `.github/agents/`. - Agent definitions may specify: - Model - Tools - Role-specific instructions - Prompts can assign different agents to different tracks, such as using a technical writer for documentation and the default agent for code. - If no model is specified, the agent uses the current default model. ## Monitoring Fleet Execution - Review the initial decomposition to ensure the task has multiple independent tracks. - Use `/tasks` to inspect active background work. - Look for progress updates from separate tracks. - If work is proceeding sequentially, ask Copilot to decompose the task first and report each track’s status and blockers. ## Avoiding File Conflicts - Subagents share a filesystem without file locking. - If two agents edit the same file, the last completed write silently overwrites the other. - Assign distinct files or directories to each track. - For shared files, use temporary outputs and merge them afterward, or impose an explicit execution order. Use `/fleet` for well-partitioned work with clear ownership and dependencies. Careful prompt structure is essential: parallelism is most effective when agents can operate independently without competing for the same files.

Read original(opens in new tab)

Multi Agent SystemsGithub Copilot CliSlash CommandsParallel Processing+2

github·Mar 31, 2026·3 min readCurated summary

Agent-driven development in Copilot Applied Science

The post describes how Tyler McGoffin used GitHub Copilot to automate the intellectual work of analyzing coding-agent evaluation trajectories. This led to `eval-agents`, a tool designed to let researchers create, share, and run specialized agents. By making coding agents the primary contributors, the team rapidly added 11 agents, four skills, and workflow support while learning new approaches to prompting, architecture, and collaboration. ## The Motivation: Automating Evaluation Analysis - McGoffin analyzes coding-agent performance using benchmarks such as TerminalBench2 and SWEBench-Pro. - Each benchmark task produces a trajectory: a large JSON record of the agent’s thoughts and actions. - Reviewing hundreds or thousands of trajectories can involve hundreds of thousands of lines of data. - Copilot initially helped identify patterns, reducing the amount of material requiring manual inspection from hundreds of thousands of lines to a few hundred. - The repetitive nature of this process inspired `eval-agents`, which automates parts of the analysis itself. ## Project Goals The project was designed around three objectives: - Make agents easy for others to share and use. - Make authoring new agents straightforward. - Make coding agents the primary mechanism for contributing to the project. The third goal had the greatest architectural impact. Using Copilot to build the tool also made the repository easier for teammates to understand, extend, and collaborate on. ## An Agent-First Development Setup McGoffin’s development environment consisted of: - Copilot CLI as the coding agent. - Claude Opus 4.6 as the model. - VS Code as the IDE. - The Copilot SDK for creating agents, registering tools and skills, and accessing existing MCP servers. This setup allowed the project to reuse Copilot’s existing agent infrastructure instead of implementing those capabilities from scratch. ## Prompting Strategies - Agents perform best when treated like capable engineers rather than simple code generators. - Effective prompts are conversational, detailed, and explicit about assumptions. - Planning mode should be used before implementation mode, especially for complex tasks. - McGoffin used stream-of-consciousness descriptions to explain problems and collaborate with Copilot on possible solutions. - For example, a discussion about preventing agents from weakening regression tests led to protected test areas and human-controlled contract-test-like guardrails. - The broader lesson is that agents benefit from many of the same practices as human engineers: context, dialogue, planning, and clear constraints. ## Architectural Strategies An agent-first codebase makes maintainability work especially valuable: - Refactoring names and file structures improves the repository’s understandability. - Documentation gives agents the context needed to implement features consistently. - Additional tests expose and prevent recurring mistakes. - Removing dead code helps keep agents from copying outdated or irrelevant patterns. - Work that was traditionally postponed—cleanup, documentation, and test improvements—becomes foundational when agents are responsible for much of the implementation. ## Rapid Team Collaboration Applying these principles enabled substantial development in a short period: - Five people contributed to the project for the first time. - The team created 11 agents and four skills. - They introduced eval-agent workflows for structured streams of scientific reasoning. - In under three days, the changes amounted to approximately 28,858 added and 2,884 removed lines across 345 files. ## Practical Recommendation Teams adopting agent-driven development should invest first in clear architecture, documentation, tests, and conversational planning practices. Agents become substantially more effective when the repository provides strong context and guardrails, allowing developers to focus less on repetitive implementation and more on directing, reviewing, and improving the overall system.

Read original(opens in new tab)

AI AgentsModel Context ProtocolGithub CopilotCopilot Cli+2

github·Mar 30, 2026·1 min readCurated summary

GitHub for Beginners: Getting started with GitHub security

Kedasha is a Developer Advocate at GitHub who shares her software development experience with the broader developer community. She is passionate about helping others learn about technology and the tech industry. ### Professional Role - Works as a Developer Advocate at GitHub. - Shares lessons from her career with developers and learners. ### Community Engagement - Enjoys helping others understand the technology industry. - Maintains an online presence as **@itsthatladydev**.

Read original(opens in new tab)

GithubSoftware DevelopmentDeveloper AdvocateCommunity Learning

github·Mar 26, 2026·1 min readCurated summary

A year of open source vulnerability trends: CVEs, advisories, and malware

The passage identifies a security professional involved in several major vulnerability-management initiatives. They curate the GitHub Advisory Database, participate in GitHub’s Security Lab, issue CVE IDs, and publish CVE records. ### Responsibilities and Affiliations - Works as a security analyst. - Curates entries in the GitHub Advisory Database. - Is a member of the Security Lab. - Helps issue CVE identifiers for vulnerabilities. - Publishes official CVE records. Overall, the individual contributes to documenting, coordinating, and communicating software security vulnerabilities.

Read original(opens in new tab)

Vulnerability ManagementCveSecurity AnalystGithub Advisory Database+1

github·Mar 24, 2026·3 min readCurated summary

Building AI-powered GitHub issue triage with the Copilot SDK

The post demonstrates how to build IssueCrush, an AI-powered GitHub issue triage app using the GitHub Copilot SDK. The app presents issues as swipeable cards and uses Copilot to generate concise summaries and recommended actions. Because the SDK depends on Node.js and the Copilot CLI, the integration runs on a server rather than directly inside the React Native client. ## IssueCrush: Faster Issue Triage - IssueCrush displays GitHub issues as swipeable cards: - Swipe left to close an issue. - Swipe right to keep it. - Use “Get AI Summary” to receive actionable context. - Copilot summarizes lengthy issue descriptions and suggests actions such as: - Investigate the problem. - Implement the request. - Assign it to a relevant team. - Close it as a duplicate. - The goal is to reduce the cognitive load of reviewing many issues across active repositories. ## Server-Side Architecture - React Native cannot directly use the Node.js-based Copilot SDK. - The SDK launches a local Copilot CLI process and communicates with it through JSON-RPC. - The recommended architecture is: - React Native or web client communicates with a Node.js server over HTTPS. - The server runs the Copilot SDK and manages the Copilot CLI. - Clients separately use GitHub OAuth and the GitHub REST API for issue data. - Server-side integration provides: - A shared SDK instance for multiple clients. - Secure storage of Copilot credentials and API tokens. - Graceful fallback summaries when AI services are unavailable. - Centralized logging for latency, failures, prompts, and responses. ## Required Setup - Install the Copilot CLI on the server and ensure it is on the system `PATH`. - Use either: - A GitHub Copilot subscription, or - A BYOK configuration with personal API keys. - Authenticate the CLI with `copilot auth` or the `COPILOT_GITHUB_TOKEN` environment variable. ## Copilot SDK Lifecycle The SDK uses a session-based workflow: - Import `CopilotClient` and `approveAll`. - Create and start a `CopilotClient`, which launches the CLI. - Create a session with a selected model such as `gpt-4.1`. - Send a prompt using `session.sendAndWait()`. - Read the response from `response.data.content`. - Disconnect the session and stop the client. The required lifecycle is: `start() → createSession() → sendAndWait() → disconnect() → stop()` Sessions should always be cleaned up in a `finally` block. Missing `disconnect()` calls can leak resources and cause memory issues, while suppressed cleanup errors prevent them from hiding the original failure. ## Prompt Design for Triage - The prompt provides structured issue information instead of only passing raw text. - Context includes: - Title and issue number. - Repository name. - State and labels. - Creation date. - Author. - Full issue body. - The model is instructed to produce a concise two- or three-sentence summary that: - Explains the issue. - Identifies the key problem or request. - Recommends a practical next step. - The response should be clear, actionable, and free of Markdown formatting. A server-side Copilot integration offers a practical way to add AI-assisted triage while keeping credentials secure, maintaining fallback behavior, and preserving reliable resource management.

Read original(opens in new tab)

TypeScriptNode.JsReact NativeGithub Copilot Sdk+2

github·Mar 23, 2026·2 min readCurated summary

GitHub expands application security coverage with AI‑powered detections

GitHub is expanding application security coverage with AI-powered detections that complement CodeQL’s traditional static analysis. The approach targets languages and frameworks that are difficult to support through semantic analysis alone, including Bash, Dockerfiles, Terraform, and PHP. Planned for public preview in early Q2, the system brings detection, automated remediation, and enforcement directly into pull requests. ## Hybrid Static Analysis and AI Detection - CodeQL remains the primary tool for deep analysis of supported languages. - AI-powered detections extend coverage to scripts, infrastructure definitions, and less-supported ecosystems. - The system can identify vulnerabilities and suggest fixes within the pull request workflow. - Internal testing analyzed more than 170,000 findings in 30 days, receiving positive feedback from over 80% of developers. - Early supported areas include: - Shell/Bash - Dockerfiles - Terraform/HCL - PHP - The capability is part of GitHub’s broader agentic detection platform, which also supports code quality and code review. ## Security Findings in Pull Requests - GitHub automatically analyzes changes when a pull request is opened. - It selects CodeQL or AI-powered detection based on the code being reviewed. - Findings appear alongside existing code-scanning results, without requiring developers to switch tools. - Example risks include: - Unsafe string-built SQL queries or commands - Weak cryptographic algorithms - Infrastructure configurations exposing sensitive resources - Detecting issues during review allows teams to address vulnerabilities before code is merged or deployed. ## Copilot Autofix for Remediation - GitHub connects detection with Copilot Autofix, which proposes fixes developers can review, test, and apply. - Autofix resolved more than 460,000 security alerts in 2025. - Alerts were resolved in an average of 0.66 hours with Autofix, compared with 1.29 hours without it. - This reduces the gap between discovering a vulnerability and correcting it. ## Security Enforcement at Merge - GitHub positions pull requests as the point where security policies can be enforced. - Detection, remediation, and governance operate within the same workflow. - Teams can reduce risk without adding separate post-deployment review steps. - GitHub plans to demonstrate the technology at RSAC, highlighting hybrid detection and developer-native remediation. GitHub’s recommendation is effectively to combine CodeQL’s precision with AI-based coverage for modern, diverse repositories, while using Copilot Autofix and merge policies to turn findings into timely, enforceable fixes.

Read original(opens in new tab)

Docker & ContainersTerraformAi SecurityStatic Analysis+4

github·Mar 19, 2026·3 min readCurated summary

How Squad runs coordinated AI agents inside your repository

Squad is an open-source GitHub Copilot project that places a preconfigured team of AI agents directly inside a repository. Rather than relying on a single chatbot or complex orchestration infrastructure, it coordinates specialized agents for design, implementation, testing, documentation, and review. Its core argument is that repository-native, versioned context makes multi-agent development more accessible, inspectable, and resilient. ## Coordinating Specialized Agents - Install Squad with `npm install -g @bradygaster/squad-cli`, then run `squad init` in a repository. - The setup creates roles such as lead, frontend developer, backend developer, tester, and documentation specialist. - A coordinator interprets natural-language requests, loads repository context, and assigns work to specialists. - Agents can work in parallel, create files and branches, write tests, and open pull requests. - They use shared decisions and project history rather than requiring every detail to be repeated in prompts. - Testing and review happen within the workflow: - Testers evaluate implementations and reject failing code. - A rejected author is prevented from revising its own work. - Another agent must address the problems, providing a more independent review. - Developers still answer questions, correct assumptions, and review and merge pull requests; Squad is collaborative orchestration rather than full autonomy. ## Repository-Based Shared Memory - Squad uses a “drop-box” model instead of depending on live chat synchronization or complex vector databases. - Architectural decisions, library choices, and conventions are appended to a versioned `decisions.md` file. - This creates: - Persistent shared knowledge - An understandable audit trail - Recovery after disconnects or restarts - Memory that can be reviewed and changed like code ## Replicating Context Across Agents - The coordinator remains a thin router instead of attempting to manage all implementation work. - Each specialist runs in its own inference call with an independent context window. - This replicates relevant repository context across agents rather than splitting one limited context among multiple roles. - Parallel, independent contexts reduce the risk that project-management instructions and other agents’ reasoning crowd out the actual coding task. - Supported models may provide context windows of up to 200,000 tokens. ## Versioned Agent Identities and History - Each agent’s behavior is primarily defined by repository files: - A charter describing its role and responsibilities - A history recording previous work - Shared team decisions - These files live in `.squad/` alongside the application code. - Cloning a repository also restores the team’s accumulated knowledge, making the agents effectively pre-onboarded. - Keeping memory in plain text makes it inspectable, versioned, and independent of hidden model state. ## Lowering the Barrier to Multi-Agent Development Squad’s main goal is to make agentic workflows practical without requiring users to build orchestration layers, configure databases, or master advanced prompt engineering. Its repository-native design favors simple setup, transparent memory, independent review, and recoverable project context. Developers interested in this approach can install Squad and experiment with it directly in the project repository.

Read original(opens in new tab)

AI AgentsGithub CopilotPrompt EngineeringMulti Agent Systems+4

github·Mar 17, 2026·3 min readCurated summary

Investing in the people shaping open source and securing the future together

Open source security depends on supporting the maintainers who sustain critical software, not merely hosting their code. GitHub argues that funding, education, practical security tools, and AI assistance can reduce maintainer burnout while improving the broader software supply chain. Its new commitments focus on making security work more manageable as AI accelerates both vulnerability discovery and attacks. ## A $12.5 Million Open Source Security Commitment - GitHub is joining Anthropic, AWS, Google, and OpenAI in committing $12.5 million to the Linux Foundation’s Alpha-Omega initiative. - The funding will help integrate emerging AI security capabilities into existing open source workflows. - The effort builds on GitHub’s broader role as a provider of security tools, education, and long-term maintainer support. ## Expanding Maintainer Resources - More than 280,000 GitHub maintainers are eligible for free access to: - Core GitHub services - GitHub Copilot Pro - GitHub Actions - Code scanning and Autofix - Secret scanning and push protection - Dependency alerts - GitHub’s Secure Open Source Fund is adding $5.5 million in Azure credits and funding for training, expertise, community support, and new partners such as Datadog, Open WebUI, the Atlantic Council, and OWASP. - GitHub Security Lab is improving security advisories and Private Vulnerability Reporting to reduce low-quality reports and ease the burden on maintainers. ## Results from Security-Focused Funding - Previous Secure Open Source Fund programs supported 138 projects and more than 200 maintainers across 38 countries. - Participating projects produced: - 191 new CVEs - More than 250 prevented secret leaks - More than 600 detected and resolved leaked secrets - These projects collectively affect billions of monthly software downloads. - GitHub concludes that security improves when maintainers receive dedicated time, funding, education, and tools that fit naturally into their workflows. ## Using AI to Reduce Maintainer Burden - AI has increased the speed and scale of vulnerability discovery for both attackers and defenders. - Maintainers are facing more automated pull requests and security reports, often with poor signal-to-noise ratios, contributing to burnout. - GitHub’s goal is to use AI for triage, pull request review, vulnerability identification, and remediation—not simply to generate more findings. - GitHub has open sourced an AI-powered security research framework so maintainers, rather than only specialized security teams, can benefit from it. - Copilot Pro provides eligible maintainers with AI-assisted code review, agentic security remediation workflows, and access to multiple leading models. GitHub’s overall recommendation is to treat AI as a force multiplier and pair it with sustained funding, education, and workflow-integrated security tools. Supporting maintainers directly is presented as the most effective way to protect the wider software ecosystem.

Read original(opens in new tab)

AIGithubGithub CopilotSoftware Supply Chain Security+3

github·Mar 16, 2026·3 min readCurated summary

GitHub for Beginners: Getting started with GitHub Actions

GitHub Actions is GitHub’s built-in platform for automating CI/CD and repetitive repository tasks. Workflows are YAML files triggered by events such as pushes, pull requests, schedules, or newly opened issues, then executed as jobs on hosted or self-hosted runners. The post guides beginners through creating a workflow that automatically labels new issues. ## What GitHub Actions Provides - GitHub Actions supports: - Continuous integration and delivery - Automated tests and vulnerability scans - Release creation - Team reminders and other repetitive tasks - Workflows are stored in the repository and run automatically when configured events occur. - Jobs execute in virtual machines called runners, provided by GitHub or managed by the user. ## How Workflows Operate - **Events** trigger workflows, such as: - Pushing code - Opening or merging pull requests - Creating issues - Scheduled times - **Runners** are virtual machines that execute workflow jobs. GitHub offers Ubuntu, Windows, and macOS hosted runners, while teams can also use self-hosted runners. - **Jobs** contain groups of steps executed on the same runner. - **Steps** can either run shell commands or invoke reusable Marketplace actions. ## Workflow Structure Workflow files use YAML and live in `.github/workflows`. The three main sections are: - **`name`**: Describes the workflow. - **`on`**: Specifies the event or events that trigger it. - **`jobs`**: Defines the work performed after triggering. The post recommends descriptive filenames such as `build-and-test.yml`, `security-scanner.yml`, or `label-new-issue.yml`. ## Creating an Issue-Labeling Workflow The example workflow automatically adds a `triage` label whenever a new issue is opened. - It is named `Label New Issues`. - Its trigger is configured as: ```yaml on: issues: types: [opened] ``` - The `label-issues` job runs on `ubuntu-latest`. - Permissions are explicitly granted: - `issues: write` allows the workflow to add labels. - `contents: read` allows it to access repository content. ## Using Actions and Shell Commands The workflow contains two steps: - `actions/checkout@v6` uses a prebuilt Marketplace action to check out the repository code. - A shell command uses the GitHub CLI to add the label: ```bash gh issue edit "$ISSUE_NUMBER" --add-label "$LABEL" ``` Environment variables provide the command with: - `GITHUB_TOKEN` for authentication - The issue number from `github.event.issue.number` - The label name, `triage` The `uses` keyword invokes reusable actions, while `run` executes a shell command directly. Start with a small workflow in `.github/workflows`, define its trigger and required permissions carefully, and build from reusable actions plus simple commands. The post also recommends practicing with GitHub’s “Hello GitHub Actions” exercise to become familiar with workflow creation.

Read original(opens in new tab)

CI/CDGithubAutomationGitHub Actions+2

github·Mar 12, 2026·3 min readCurated summary

Continuous AI for accessibility: How GitHub transforms feedback into inclusion

GitHub built a continuous, AI-assisted accessibility feedback system to replace scattered reports, unclear ownership, and unresolved “phase two” promises. The workflow combines GitHub Actions, Copilot, and GitHub Models to turn user feedback into tracked, prioritized issues while preserving human judgment. Its goal is continuous follow-through: every accessibility barrier is captured, routed, reviewed, and acted upon. ## Accessibility as a Living System - GitHub treats accessibility as an ongoing methodology rather than a one-time audit or standalone product. - The approach combines: - Automation - Artificial intelligence - Human expertise - Real user feedback is considered more valuable than automated code scans because it reveals barriers experienced in real workflows. - The system supports GitHub’s 2025 Global Accessibility Awareness Day pledge to improve accessibility across the open source ecosystem. - Technology helps process feedback at scale, turning unstructured reports into clearer, implementation-ready work. ## Designing for Different Users The workflow was designed around three primary groups: - **Issue submitters** - Community managers, support agents, and sales representatives submit reports for users and customers. - Since they may not be accessibility specialists, the system guides them and teaches accessibility concepts during submission. - **Accessibility and service teams** - Engineers and designers need actionable reports containing reproducible steps, WCAG references, severity ratings, and ownership information. - **Program and product managers** - Leaders need trend data, issue categories, and progress visibility to prioritize investments. The design treats feedback as data moving through a pipeline and allows the process to evolve over time. ## Event-Driven Feedback Workflow - Each workflow stage triggers a GitHub Action that determines what happens next. - Key events include: - New issues launching Copilot analysis through the GitHub Models API - Status changes initiating hand-offs between teams - Resolutions triggering follow-up with the original submitter - Actions can be started manually or rerun, allowing humans to intervene whenever necessary. - GitHub initially built the system largely by hand in mid-2024; newer tools such as Agentic Workflows could now create similar Actions from natural-language instructions. - The workflow contains seven stages: - Intake - Copilot analysis - Submitter review - Accessibility team review - Link audits - Closing the loop - Improvement - Feedback loops allow submitters to rerun analysis, resolved issues to return for further review, and improvements to update Copilot prompts. ## Actioning Intake - Accessibility feedback can arrive through support tickets, social media, email, direct outreach, or GitHub’s accessibility discussion board. - Approximately 90% of feedback currently comes through the public discussion board. - Public discussions let other users: - Confirm reported problems - Add context - Share workarounds - Reports from the community often contain more detail than conventional support tickets. - GitHub acknowledges every report within five business days, including reports it cannot directly address. - When internal action is needed, a team member creates a tracking issue using a custom accessibility feedback template. - The template records: - The user’s original report - The feedback source - Relevant product components - This preserves important context as feedback moves from intake into triage.

Read original(opens in new tab)

Github CopilotGitHub ActionsAgentic WorkflowsWcag+3

github·Mar 10, 2026·2 min readCurated summary

The era of “AI as text” is over. Execution is the new interface.

The post argues that AI is moving beyond text-based question-and-answer interactions toward embedded execution. The GitHub Copilot SDK lets applications use Copilot’s planning, tool use, file modification, command execution, and error recovery capabilities directly. This enables teams to build adaptable AI workflows without creating their own orchestration infrastructure. ## Delegating Multi-Step Work to Agents - Applications can express intent and constraints instead of hard-coding every workflow step. - For a task such as “Prepare this repository for release,” an agent can: - Explore the repository - Plan the necessary work - Modify files - Run commands - Recover and adapt when failures occur - This approach is more flexible than scripts, which become brittle when workflows depend on changing context or unexpected errors. - Teams can use agentic execution while maintaining defined boundaries and observability. ## Using Structured Runtime Context - Relying on prompts to contain system logic makes workflows difficult to test, maintain, and evolve. - The Copilot SDK supports structured, composable context through: - Domain-specific tools and agent skills - Model Context Protocol (MCP) - Runtime retrieval of relevant data - Agents can directly access systems such as: - Service ownership records - Historical decisions - Dependency graphs - Internal APIs - Permissioned tools and real-time data provide more reliable grounding than embedding organizational knowledge in prompts. ## Embedding Agents Beyond the IDE - Agentic capabilities can be integrated into: - Desktop applications - Internal operational tools - Background services - SaaS products - Event-driven systems - Applications can invoke Copilot in response to events such as file changes, deployments, or user actions. - Execution happens within the product itself rather than in a separate IDE or terminal interface. - This turns AI from an auxiliary developer tool into application infrastructure available wherever the software operates. ## Execution as a New Interface - Agentic workflows are programmable planning-and-execution loops that: - Integrate with real systems - Operate under constraints - Adapt during runtime - Use tools to complete tasks - The Copilot SDK provides this execution layer so teams can focus on defining outcomes instead of rebuilding orchestration systems. The practical recommendation is to treat AI as an executable application capability rather than merely a text interface. Teams can start by identifying multi-step workflows or event-driven tasks where structured tools, runtime context, and adaptive execution would provide more value than fixed scripts.

Read original(opens in new tab)

AI AgentsModel Context ProtocolGithub CopilotAgentic Workflows+2

github·Mar 9, 2026·3 min readCurated summary

Under the hood: Security architecture of GitHub Agentic Workflows

GitHub Agentic Workflows are designed to bring autonomous agents into CI/CD without giving them unrestricted access to repositories, secrets, or the internet. Because agents can be prompt-injected and behave unpredictably, GitHub treats them as untrusted components and compiles workflows into constrained GitHub Actions. The architecture relies on layered isolation, controlled communication, staged writes, and comprehensive auditing. ## Threat Model - Agents reason over repository state and act autonomously, so they cannot be trusted by default. - GitHub Actions normally place components in one permissive trust domain with broad access to: - Repository contents - Authentication secrets - MCP servers - Arbitrary network destinations - A malicious webpage, issue, or repository file could prompt an agent to: - Read credentials from files, environment variables, logs, or `/proc` - Upload secrets externally - Embed secrets in issues, pull requests, or comments - Make unwanted repository changes - Strict mode follows four principles: - Defense in depth - Never trust agents with secrets - Stage and vet writes - Log everything ## Layered Security Architecture GitHub Agentic Workflows use three complementary layers: - **Substrate layer** - Runs on a GitHub Actions runner VM. - Uses trusted containers, Docker isolation, network controls, and kernel-enforced boundaries. - Separates components and mediates privileged operations and system calls. - Is intended to contain damage even if an untrusted component is compromised. - **Configuration layer** - Defines which components run and how they connect. - Controls communication channels, privileges, firewall policies, Docker images, and MCP configuration. - Determines which tokens are loaded into which containers. - Converts declarative workflow configuration into a secure runtime structure. - **Planning layer** - Controls which components are active and how data moves between them over time. - Creates staged workflows with explicit data exchanges. - Uses the Safe Outputs subsystem to govern potentially dangerous operations. ## Keeping Secrets Away from Agents - In ordinary GitHub Actions, secrets may be visible through environment variables and configuration files across the shared runner trust domain. - This creates a major prompt-injection risk: an agent with shell access could discover credentials and exfiltrate them. - Agentic Workflows instead place the agent in a dedicated container with: - Firewalled internet access - MCP access through a trusted gateway - LLM communication through an API proxy - A private network connects the agent only to approved services. - The trusted MCP gateway launches MCP servers and exclusively handles MCP authentication material. - LLM authentication tokens are kept in the isolated API proxy rather than exposed directly inside the agent container. ## Controlled Execution and Writes - Open-ended workflow authoring is separated from governed execution. - Workflows are compiled into GitHub Actions with explicit constraints covering: - Permissions - Outputs - Network access - Auditability - The planning and Safe Outputs systems are intended to mediate GitHub write operations and apply controls such as call filtering, volume limits, secret removal, and moderation. GitHub’s approach is to treat agents as untrusted CI/CD components rather than granting them normal workflow privileges. Organizations adopting agentic automation should isolate agents, broker access to tools and credentials, restrict network connectivity, stage all writes for review, and maintain detailed logs.

Read original(opens in new tab)

CI/CDModel Context ProtocolDocker & ContainersGitHub Actions+3