If you’ve used slash commands in the GitHub Copilot CLI, you already know how powerful a quick / can be. In the GitHub Copilot app, slash commands take that idea further, giving you shortcuts for managing sessions, navigating projects, and customizing your Copilot workflow.

What are slash commands?

Slash commands are text shortcuts you type directly into the GitHub Copilot app’s chat composer. Start by typing / and an autocomplete menu appears, showing the commands available in your current context. It’s a small character with a lot of potential, opening the door to shortcuts that help you work with Copilot in new ways.

If you’re coming from the CLI, here’s the key difference: CLI slash commands are designed around a terminal-first workflow. Things like adding directories, setting your working directory, and managing terminal access happen through commands. This makes sense, because the CLI lives inside your terminal where there’s no visual interface.

The app, on the other hand, provides a visual interface for managing context. File access commands like /add-dir or /cwd aren’t needed since the app manages project context automatically. App slash commands are more about workflows. You can navigate between sessions, manage projects, and control how the agent works.

Why use slash commands?

Slash commands may look like simple shortcuts, but they can change how you interact with Copilot. They help you move faster, stay focused, and quickly access the workflows you need. Instead of digging through options or breaking your focus to find the right tool, you can type a command and keep moving. A single / opens up the list of slash commands that can help you move faster, explore new ideas, and get the most out of the app.

Let’s take a look at some of the slash commands available in the GitHub Copilot app and how they can fit into your everyday workflows.

Before you write code, make a /plan

Good code starts with a good plan. /plan helps you break down a task before you start writing code, think through your approach, identify potential challenges, and decide what needs to happen next. It also switches your session into Plan mode, which you can also select from the Mode dropdown in the chat composer.

• Plan a new feature. Break down new feature ideas before jumping into implementation. Have Copilot identify files, components, and dependencies so you have a clearer path forward.
• /plan I need to add two-factor authentication to our application. Help me break down the work involved, identify what files need to change, and outline an implementation approach.
• Prepare for a large refactor. Map out complex changes before touching your code. Uncover potential risks and develop an incremental approach for making large changes safely.
• /plan We want to refactor our notification system code to make it easier to support new channels like push notifications. Help me understand the changes needed and create an incremental migration plan.
• Triage and fix bugs. If you know something is wrong but aren’t sure where to start, /plan can help you explore possible causes and outline the steps needed to diagnose and resolve the problem.
• /plan Users are reporting that our checkout flow randomly fails after payment processing. Help me investigate possible causes and create a plan to diagnose and fix the issue.

Let Copilot play devil’s advocate with /spar

Sometimes the best way to validate an idea is to challenge it. /spar is like that one teammate who raises their hand and asks, “Have we thought about what happens when this goes wrong?” It helps you pressure-test your approach by having Copilot question your assumptions and point out potential risks or tradeoffs before you commit to a solution. Here are a few ways you can use it:

• Validate an architecture choice. Pitch your plan to use Redis for caching and have Copilot question your invalidation strategy, scalability, or whether another approach better fits your workload.
• /spar I'm planning to use Redis as a caching layer for our product API. Challenge my approach and point out any scalability or consistency concerns I may have missed.
• Compare implementation options. Ask Copilot to debate the pros and cons of REST versus GraphQL, or synchronous versus asynchronous processing, based on your application’s requirements.
• /spar Help me decide between REST and GraphQL for a customer-facing API. Ask questions, challenge my assumptions, and recommend which approach fits best for an app with mobile clients.
• Review a migration plan. Walk through a database migration or infrastructure change and have Copilot identify edge cases, risks, or rollout concerns before you begin.
• /spar I'm migrating our database to a new managed service with minimal downtime. Poke holes in my migration plan and identify any risks or edge cases I should account for.
• Challenge a performance optimization. Share an optimization you’re considering and ask Copilot to point out hidden bottlenecks, unintended side effects, or simpler alternatives.
• /spar I'm planning to lazy load most of the components on my site to improve initial load time. Critique my approach and tell me where it could hurt user experience or introduce unnecessary complexity.

/autopilot take the wheel

Once you have a /plan, the next step is turning that idea into working code. /autopilot helps you work through implementation, make changes, and iterate as needed. Instead of managing each individual step, give Copilot a goal and let it work through the steps needed to complete the task. It also switches your session into Autopilot mode, which you can also select from the Mode dropdown in the chat composer.

• Implement a new feature. Hand off a task and let Copilot work through the implementation steps.
• /autopilot Add support for exporting user reports as CSV files. Identify the files that need changes, implement the feature, and update any relevant tests.
• Complete a larger maintenance task. Use /autopilot for tasks that require multiple steps, such as updating dependencies, refactoring code, or improving documentation.
• /autopilot Update this project to the latest version of React. Identify breaking changes, update the code where needed, and make sure the test suite passes.

Talk it through with /rubber-duck

I’ve learned from personal experience that talking things through with your cat isn’t always helpful. Their listening skills are questionable at best, and their debugging advice usually ends with them sitting on my keyboard or chewing my wires. /rubber-duck gives you something even better: a fresh set of eyes.

It uses a different model to independently review your work, helping surface blind spots, question assumptions, and catch issues your primary model may have missed. It’s especially useful for complex refactors, architectural decisions, migration plans, or any time you want a second opinion before moving forward.

• Get a second opinion on a plan. Before you start implementing a complex feature, have a different model independently review your plan and point out assumptions, missing steps, or potential risks.
  /rubber-duck Review the implementation plan we've created for adding two-factor authentication. Identify any blind spots, edge cases, or risks that we may have overlooked.
• Review a large refactor. After making significant changes, ask /rubber-duck to critique the approach and highlight anything that could be simplified, improved, or handled differently.
  /rubber-duck Review the refactoring we've completed for the notification system. Look for architectural concerns, unnecessary complexity, or areas that could be improved before I open a pull request.
• Validate a migration strategy. Before rolling out a complex migration, use a second model to independently evaluate your approach and identify rollout or reliability concerns.
  /rubber-duck Review our database migration plan and implementation. Point out any blind spots, rollback concerns, or edge cases we should address before deployment.

Turn conversations into interactive experiences with /create-canvas

Not every problem is best solved through a chat window. /create-canvas lets you create interactive interfaces directly from a conversation with Copilot. Instead of working through information in a long chat, you can turn it into a visualization, dashboard, or custom workflow you can interact with. For example:

• /create-canvas Create an interactive diagram showing how services in this application connect.
• /create-canvas Create an issue triage board that lets me review and categorize open issues.

For more information and examples on creating canvases, check out our blog post.

When one task becomes many, use /orchestrate

Not every task fits neatly into a single workflow. Sometimes you need to make changes across multiple repositories or tackle several related tasks at once. /orchestrate helps you coordinate work across sessions and repositories by breaking larger efforts into smaller tasks that can move forward in parallel.

• Coordinate changes across repositories. When a feature touches multiple codebases, /orchestrate can help you track the work and coordinate updates across each repository.
• /orchestrate I need to add support for a new authentication flow across our frontend, backend, and shared repositories. Help me break down the work and coordinate the changes needed in each codebase.
• Manage parallel development tasks. For larger projects, Copilot can divide the work into focused efforts so multiple pieces can move forward together.
• /orchestrate Prepare this feature for release. Identify the work needed for implementation, testing, documentation, and deployment, then help coordinate each task.

Your next workflow starts with /

You don’t need to memorize any commands to get started. Pick a few slash commands that match how you work and build from there. The autocomplete menu has your back for the rest. Type / and start exploring! You can also read our docs to learn more about the GitHub Copilot app.

The post A guide to slash commands in the GitHub Copilot app appeared first on The GitHub Blog.

Teams testing prompts in ChatGPT before moving them to Codex or Work may notice the difference on longer tasks.

OpenAI announced Thursday that it has updated GPT-5.6 Sol inside consumer ChatGPT while leaving the versions used by Codex and ChatGPT Work alone.

“Because this version of GPT‑5.6 Sol is optimized for everyday chats, it will only be available in the Chat experience in ChatGPT,” OpenAI said in its announcement. “The version of GPT‑5.6 Sol that powers Work and Codex is not changing as part of this release.”

“The version of GPT‑5.6 Sol that powers Work and Codex is not changing as part of this release.”

Same name, different model

ChatGPT has always handled things a bit differently from other environments. Now, those differences might become even more obvious. But the only way to know is to test prompts where they’ll actually run. There’s nothing in the announcement about changes to the GPT-5.6 Sol API model. So, it’s too soon to guess what this means for the API.

A slider replaces separate models

Because ChatGPT now uses the same Sol model for quick answers and deeper dives, Plus and Pro users get a new slider — that works on web, mobile, and desktop — to choose how much thought ChatGPT puts into an answer. Developers already make this call with the API. But they’ll still have to decide when the better answer is worth waiting and paying for.

But they’ll still have to decide when the better answer is worth waiting and paying for.

Classifiers monitor every answer

OpenAI’s GPT-5.6 System Card, published in July, indicates that Sol and Terra are paired with classifiers that monitor an answer as it is being generated. If one detects a problem, the answer is held while another system checks it. OpenAI tunes those classifiers separately for each model.

The System Card also flags a problem developers may recognize: GPT-5.6 sometimes went beyond the assignment and attempted changes the user had not requested. It did this more often than GPT-5.5, although OpenAI said it was still rare.

Benchmarks without baselines

OpenAI says the updated Sol makes fewer factual mistakes. In its internal tests of financial, medical, and legal questions, answers containing at least one error were 68% less common than those produced by GPT-5.5 Instant. Luna, which will become the default for Free and Go users, reduced errors by about 62%.

But OpenAI didn’t release the prompts or enough detail for anyone to reproduce those results. It also compared the new Sol with GPT-5.5 Instant, rather than the previous version of Sol in ChatGPT. That makes it impossible to tell how much Sol itself has improved.

That makes it impossible to tell how much Sol itself has improved.

Engineering teams will need to find out for themselves by testing prompts where they’ll actually run.  Saving that configuration with each prompt will make the results easier to reproduce — and reveal whether an upgrade on paper produces better results in practice.

The post GPT-5.6 Sol just got better in one place and stayed the same everywhere else appeared first on The New Stack.

“Software factory” is a buzzword, but it doesn’t have to be. Building software is a well-understood process: we know every activity involved and every tool required. A software factory just automates it.

In this post we’ll describe the process and list the capabilities needed to automate it. Then we’ll build a software factory and discuss when using one is a good idea. We’ll see that a software factory isn’t a product but a workflow, and it only succeeds when you think of it this way. And building one is pretty easy.

We’ll also touch on why software factories fail in real organizations and how to make them work.

How We Build Software

These are the steps:

• FIND WORK. You go to an issue tracker (e.g., Linear) to see what needs to be done.
• GET DEBRIEFED. You read the issue and find related past work. Maybe you talk to other engineers to fill in the gaps.
• SET UP REPOS. You figure out which repositories are relevant for the change, clone them, install dependencies, etc.
• IMPLEMENT. You make the change across all the relevant repos.
• REVIEW. You do a thorough review of the code before opening PRs.
• OPEN PRs. You open the relevant PRs and make sure CI is green for all of them.
• RECORD. You write down the decisions made, the design, so others can find it later.
• COMPLETE. You mark the item as complete in the issue tracker.

The Capabilities We Need

To implement the steps above with an agent we need the following:

• VCS
• CI
• Issue Tracker
• PR and CI Orchestrator
• Institutional Memory
• Ephemeral Workspaces
• Cross-repo Orchestrator
• Adversarial Reviews
• Trigger

Note, it’s very unlikely all of these will be provided by a single tool. VCS, CI, issue tracking are each deep, complex products, so the chances of your VCS provider also being the best CI and the best issue tracker are low. But they don’t need to be. One of the nicer things about agentic development is that agents compose external systems well, as long as each one has a well-defined agentic API. Whether that’s MCP or a CLI doesn’t matter.

How Agents Build Software (aka Factory)

• FIND WORK. An agent accesses the Issue Tracker through an MCP server to see what needs to be done.
• GET DEBRIEFED. An agent reads the issue and queries Institutional Memory for everything relevant: related past work, decisions, gotchas.
• SET UP REPOS. An agent uses Institutional Memory to figure out which repos are relevant and uses Ephemeral Workspaces to provision fresh copies.
• IMPLEMENT. An agent uses the Cross-repo Orchestrator to implement the change. Without it, the agent can only update one repo at a time.
• REVIEW. An agent invokes Adversarial Reviews to analyze the source code and address the feedback.
• OPEN PRs. An agent uses the PR and CI Orchestrator to create PRs and make sure CI is green.
• RECORD. An agent uses Institutional Memory to record what it has done, both the high-level picture and the details. This is how Institutional Memory stays up to date.
• COMPLETE. An agent marks the item as complete in the Issue Tracker.

The Cross-repo Orchestrator matters more than it may seem. Humans carry cross-repo context in their heads, so even when changing a single repo, we have deep cross-repo awareness. Agents have to actually look at the other repos to get that.

Let’s Build It

Once we have the capabilities, building a factory. It’s just a script that wires everything together. It’s more of a workflow, not a product.

We are going to use Github for VCS (and whatever CI is connected to that repo). We will use Linear as an issue tracker, and Polygraph for “PR and CI Orchestrator”, “Institutional Memory”, “Ephemeral Workspaces”, “Cross-repo Orchestrator” and “Adversarial Reviews”. Polygraph is a agent-agnostic meta-harness.

This is the script here. It’s about 400 lines. Most of it is our integration with Linear and formatting.

This is the high-level view of what the script does:

main():
    if already ran today: exit  
    # LaunchAgent fires morning + wake; dedupe via stamp file

    issues  = linear.query("my Todo issues in $LINEAR_PROJECT_NAME 
                            labeled 'factory'")
    
    for issue in issues:
        processIssue(issue) # errors logged, loop continues


processIssue(issue):
    # CLASSIFY — cheap go/no-go screen
    verdict = claude -p "can a coding agent solve this autonomously?"         if verdict != "yes": return skipped

    # DO THE WORK — one step; everything happens inside Polygraph
    sessionId = polygraph session start -- prompt
 .  # prompt = issue context + "complete the task;
    #   adversarial-review it if non-trivial; open PRs, CI green;
    #   link this issue to the session"
    # the session agent picks its own repos, implements, reviews, opens PRs
    
    if no sessionId (timeout / failure): return error

    # COMPLETE
    linear.attachToIssue(issue, session url)
    linear.moveTo(issue, "In Progress")

All the these steps (GET DEBRIEFED, SET UP REPOS, IMPLEMENT, REVIEW, OPEN PRs, and RECORD) are done with the following prompt:

You are working on a Linear issue. All context is below.

Linear issue: ${issue.identifier} — ${issue.title}
Linear issue id: ${issue.id}
Linear issue URL: ${issue.url}

Description: ${issue.description}

Complete this task. After you are done with the implementation, check whether it is trivial; if it is not, use the adversarial review skill to review the changes and address the feedback it provides. Open pull requests with your changes, mark them ready for review, and make sure CI is green. Link the Linear issue as a reference on this session.

On PRDs and Markdown Files

Much of the conversation around Software Factories is around PRDs and design documents, basically moving software development from code to high-level markdown files. Design documents have a place in this process. The Issue Tracker can and probably should contain them.

But design documents by themselves aren’t enough. Software engineers tried this many times, and it has never worked, and for good reasons. First, you cannot plan complex things separately from implementation, because the implementation is what reveals what actually needs to happen. Second, however accurate the plan was at first, it drifts away from the code. Documentation rots and code does not, because code is what actually runs.

So instead of plans and PRDs, record what has actually occurred. Capture the design after it has been implemented. Capture agent traces for more detail. That’s what the RECORD step does.

Workflow, Not a Product

There is some skepticism about Software Factories. Even the biggest proponents are admitting that “they fail.”

If you think a Software Factory is a product that will write 100% of your code, it will not work. A lot of work still needs a human developer to be engaged. It is just very hard to plan in advance. A lot of changes still require code reviews.

If you instead think about it as a workflow, a pattern, then suddenly it can be used effectively for a good number of issues (but not all of them).

Using Software Factories in real organizations hits a lot of wall:

• Most organizations cannot move their issue tracker to a new tool.
• Most organizations already have some form of company brain. You can easily integrate Slack, Notion, or ClickUp into the script above.
• Most organizations have complex cross-repo relationships, which software factory products can’t handle.
• Most organizations don’t build greenfield projects, which software factory products are optimized for.

None of these problems exist with the script above, if you look at it as just one way of automating your software production, not the only way. For instance, the script above only takes issues labeled with “factory” and even for those assesses how much input will be required.

Also, any item implemented by the script above can be resumed on the same or a different machine if some changes are required. A lot of the times some changes will be required, but having a change that is 90% there still saves time.

You can build other workflows using the exact same building blocks. For instance, I have a workflow that looks at all the PRs and sessions I need to review:

• It gets the relevant data from Linear
• It resumes those sessions for review locally using Polygraph
• It does an adversarial review via Polygraph
• It creates a summary of the change
• It creates a dashboard file I can open

I then open the dashboard to see what PRs are on my plate. Each of them is already prereviewed. I can quickly scan to see what needs my attention and what doesn’t. I can resume complex sessions to ask the agent more questions about the change, about how things work. This drastically cuts down on review time without sacrificing quality.

Summary

Whether you like it or not, more of software production will be automated: producing code, testing it, reviewing it. To maximize your chance of success, think of these automations as workflows built on top of powerful primitives, not as products.

Try:

• Create an account on https://trypolygraph.com
• Take the script above and modify it to fit into your workflow.

A Software Factory Is a Workflow, Not a Product. Build One in 20 Minutes. was originally published in Nx Devtools on Medium, where people are continuing the conversation by highlighting and responding to this story.