Dur: 15'

Welcome. In this workshop, participants build a real-world procurement system MVP using GitHub Copilot in VS Code and GitHub.

Octocat

We are going to work on an existing procurement system. This system already has two main modules/pages:

The aim is to build the PO (Purchase Order) module. Another module GR (Goods Receipts) is open for exploration. The tables for PO and GR modules are already in the database (after migration).

Application scope:

Tech stack:

qr_code

Dur: 10'

In this workshop we are going to build a procurement system MVP (minimum viable product). A procurement system manages how a company buys things, with control and traceability from request to receiving.

In simple terms, it helps answer:

In this app, the workflow chain would be:

  1. Purchase Requisition (PR) → internal request for goods/items
  2. Purchase Order (PO) → official order sent to supplier to buy goods/items
  3. Goods Receipt (GR) → record that goods/items were received

Flow

Definitions and Functions

Purchase Requisition (PR)

An internal document created by a requester (employee/department) to ask for goods or services.

Main function:

Purchase Order (PO)

A commercial document issued to a vendor after PR approval.

Main function:

Goods Receipt (GR)

A record that goods (or service delivery) were actually received against a PO.

Main function:

One practical example

  1. PR: Maintenance team requests 10 safety helmets.
  2. PO: Purchasing orders 10 helmets from Vendor A at agreed unit price.
  3. GR: Warehouse receives 6 helmets today and records GR; later receives remaining 4 and records another GR.

Result: system shows requested = 10, ordered = 10, received = 10, open = 0.

So, a procurement app is essentially a controlled pipeline for spending:

request → approve → order → receive

with quantities and statuses enforced at each step.

Dur: 10'

AI

How do LLMs like GPT or Claude work? LLMs predict the next token based on the context provided to them. So, better context gives better output quality.

Prompt anatomy in GitHub Copilot:

Working rule for this workshop:

  1. If possible, attach relevant docs (markdown plans, actual code files, screenshots, etc.) with every prompt
  2. When working on something new, ask for a plan first. Afterwards, implement in small checkpoints
  3. Always validate the agent's work. You can outsource your code, but you must not outsource your understanding.

Dur: 10'

Open your favorite online LLM application (e.g., ChatGPT, Claude, Gemini, etc.) and write a prompt to recreate this image:

target picture

Dur: 10'

When working with an AI model, the problem (almost always) is not the AI. It is the brief you gave the AI. The gap is not technical—it is communicative. Prompting—communicating with an AI model—is a skill that we need to master so we can provide AI models with the best direction for it to complete its task. You have to make your intention as clear as possible.

Open discussion

Dur: 15'

The most expensive code an AI agent writes is the code you run without thinking. Today, the bottleneck is not anymore whether AI agents can write code. It's whether you can use them economically.

Let's breakdown some new (and old) ideas that can help us optimize AI token usage.

Develop your own analytical skills

1. Analysis is the real value

Can you describe the problem without ambiguity? Can you name the constraints? Do you know what success looks like before you ask the agent to start? If the answer to any of these is "not really," you are not ready to ask the agent. Spend time thinking and doing some research first.

2. Keep your instructions concise and human-written

Many teams make the mistake of using AI to generate their agent's persistent instructions or system prompts. Your instruction file is too important for that. Write it down by yourself.

3. Build architecture that speaks for itself

A tangled, poorly organized project forces the agent to fetch and inspect more files, read more code, generate more explanation of what things do. Good architecture is an optimization strategy. Treat it as such.

Be strategic about what agents actually do

4. Use MCP strategically

Model Context Protocol (MCP) servers are powerful, they are also expensive. Every MCP call is a roundtrip. Use MCP when you genuinely need the agent to interact with a system in real-time, in order to achieve your objective.

5. Avoid SKILL.md unless you actually need it

Most of the time, your SKILL.md is just repeating what it knows, wasting tokens on context that does not add value. If you find yourself writing a SKILL.md that is longer than a few paragraphs, ask whether the agent actually needs it. Most of the time, the answer is no.

Dur: 15'

(Continuing from our previous slide)

6. Divide work into sessions, not monoliths

Divide tasks into sequential sessions, eg. research-planning-implementation. Long session is expensive because the context window is bloated the entire time. And if context window is bloated, response quality declines. Bad response will cost you more token in the long run.

7. Choose the right model for the task

Not every task needs your most powerful model.

8. Use AGENTS.md to stop the agent early

A subtle but important detail: most agents will keep generating output until they hit their token limit. They are optimistic by default. Your persistent instruction file should include explicit stopping criteria.

Do not over-rely on agents for everything

9. Use deterministic tools when they exist

Want to check code quality? Use a linter. Want to find security issues? Use a scanner. Want to understand test coverage? Use an existing coverage tool. These tools are fast, deterministic, and cheap (often free). When you hand their output to the agent, the agent can focus on interpretation instead of discovery.

10. Create guardrails that do not require agents

Unit tests, linters, type systems, security scanning; none of these require tokens. All of them save tokens by preventing the agent from generating code that will need fixing later.

11. The agent is not your QA engineer

Validation is not optional. It is your job, and it saves you money in the long run by catching mistakes before they multiply.

Dur: 20'

In this workshop we are going to learn how to use specifications to create an application. But before we do that, let's try the reverse process.

In this exercise we are going to use Copilot to create specifications of an existing application.

  1. Open the web application at https://simplydemo.secure.simplybook.me/v2/dashboard/new
  2. Login using these credentials:

reverse

  1. Learn and observe as much as you can from that web application.
  2. Create a new workspace.
  3. Open the workspace in VS Code.
  4. Enter this prompt in Copilot Chat:
Create specification documents in markdown format for a web application that:
- <your observation>
- <your observation>
- <your observation>
- <your observation>
- <your observation>
- <etc.>

Run the prompt and wait for Copilot to finish creating the specifications.

Dur: 15'

We are going to conduct the previous exercise, but with new tools to help Copilot create better result.

Install an MCP server

An MCP Server (Model Context Protocol Server) is a universal adapter that securely bridges AI models with external tools, databases, and services.

For this exercise we are going to use the chrome-devtools MCP. It allows Copilot to perform browsing actions on a headless browser.

  1. Open the MCP configuration file in VS Code.
  2. Copy this line to connect VS Code to the MCP server:
"chrome-devtools": {
  "command": "npx",
  "args": ["-y", "chrome-devtools-mcp@latest", "--slim", "--headless"]
}

Prompt

Before executing the prompt, let's add a file to create a more comprehensive context.

  1. Create a new workspace.
  2. Open the workspace in VS Code.
  3. Create a file called plan.md
  4. Put the content below in plan.md:
Based on the following url https://simplydemo.secure.simplybook.me/v2/dashboard/new, create a comprehensive specification of a fully working web application with the following structure template.

specs/
└── features/
    ├── README.md                          # Feature catalog / index
    ├── _template/                         # Boilerplate for new features
    │   └── feature-template.md
    │
    └── F-001-online-booking/              # One folder per feature
        ├── overview.md                    # Summary, goals, value prop
        ├── user-stories.md                # Stories + acceptance criteria
        ├── screens.md                     # Screens involved + states
        ├── wireframes/                    # Visual mockups
        │   ├── 01-service-select.png
        │   ├── 02-time-pick.png
        │   └── 03-confirmation.png
        ├── business-rules.md              # Logic, validations, policies
        ├── data-model.md                  # Entities, fields, relationships
        ├── edge-cases.md                  # Error states, empty, conflicts
        ├── permissions.md                 # Who can do what (RBAC)
        ├── notifications.md               # Emails, SMS, in-app triggers
        ├── analytics.md                   # Events tracked, KPIs
        ├── dependencies.md                # Other features, 3rd parties
        ├── test-scenarios.md              # Gherkin / acceptance tests
        └── open-questions.md

1. Use [chrome-devtools-mcp](https://github.com/ChromeDevTools/chrome-devtools-mcp) to access the web application above.
2. Use the following credentials to access the application:
  - login: `admin`
  - password: `demo`

Once the file plan.md is ready, enter this prompt in Copilot Chat:

Use the file #plan.md to conduct a reverse engineering process, ie. from application to specification documents.

Dur: 5'

vscode

Optional MCP tools:

Dur: 15'

Open the project URL: https://github.com/eComindo/2026-github-copilot-workshop

github repo

  1. Open the project URL in your browser
  2. Fork the repo. You can click the Fork button, on the top right

fork

Open discussion

Dur: 15'

Go to your forked repo and clone it to your local machine.

1. Set up the repo

git clone https://github.com/<your-username>/<forked-repo>.git
cd <repo>
git checkout -b feature/po-module

Ensure project references:

2. Prepare the database

Bootstrap files used by all participants:

Cross-OS readiness note:

Dur: 20'

Bootstrap workshop database (schema + sample data):

chmod +x docker/postgres/init/00-init-mvp-db.sh
docker compose down -v
docker compose up -d db

What this does:

Verification:

docker compose exec -T db psql -U workshop -d procurement_mvp -c "SELECT COUNT(*) FROM purchase_requisitions;"

Dur: 20'

1. Install libraries

Run npm install 3 times, each in:

  1. / (project root)
  2. backend/
  3. frontend/

2. Config for backend server

Create backend's environment variable: backend/.env:

PORT=3000
DATABASE_URL=postgres://workshop:workshop@localhost:5433/procurement_mvp

The backend server is running on port 3000.

3. Config for frontend server

Create frontend's environment variable: frontend/.env:

VITE_API_BASE_URL=http://localhost:3000

This will tell the frontend the URL of the backend service.

4. Start the application

To run the app, execute npm run dev from root.

Open the app (frontend server) on http://localhost:5173.

Base expectations:

Dur: 20'

Before implementation, update custom instructions to shape Copilot output quality.

Make sure you are in Ask mode, then enter this prompt:

Review this repository instruction file and improve it with a concise checklist for implementation quality, testing, and documentation discipline.

Manually open AGENTS.md. Based on the answer, add instructions to make sure the content of AGENTS.md is more consistent with project standards

You can also add rules such as:

Example of the AGENTS.md file we are using for this project:

instruction

Dur: 15'

Tool: RTK

RTK is installed globally on our computer. It is a tool (written in Rust) that filters and compresses command outputs before they reach your LLM context.

Installation

Homebrew (recommended)

brew install rtk

Cargo

cargo install --git https://github.com/rtk-ai/rtk

Verify installation

rtk --version

Check token savings stats

rtk gain

rtk_gain

Usage

Add these lines into AGENTS.md:

rtk

Example text:

Dur: 20'

Tool: Graphify

Graphify is a set of tools for AI coding assistants. By combining Tree-sitter static analysis with LLM-driven semantic extraction, Graphify turns an entire repository — including source code, documentation, research papers and diagrams — into an interactive graph that explains both what the code does and why it was designed that way.

In this example we are going to use a tool (written in Python) to build a queryable knowledge graph from our repo's documents and codebase.

Installation

*Note that there are two "y"'s in the installation command. But the installed tool will only have one "y"

uv tool install graphifyy

Configuration

When scanning the repo to create a knowledge graph, we can choose not to use LLM, so no token cost.

To make sure Graphify creates a pure, AST-based knowledge graph of only our source code (costing $0 and zero LLM tokens), let's first create the .graphifyignore file and fill it with this:

# Ignore documentation and text assets
*.md
*.txt
*.pdf
*.html

# Ignore images, diagrams, and video walkthroughs
*.png
*.jpg
*.jpeg
*.svg
*.mp4
*.wav

# Ignore config and infrastructure files (which sometimes trigger semantic parsing)
*.yaml
*.yml
*.json
*.toml

# Ignore generated build artifacts and test output (contain minified code that pollutes the graph)
playwright-report/
test-results/
coverage/
graphify-out/

# Ignore HTML files (build output, reports)
*.html

Then run this to start the scanning process:

graphify .

Graphify will look at the code files (e.g., .py, .js, .go, .rs, etc.), pull them through the local syntax tree parser, and write the final knowledge graph directly to graphify-out/graph.json without making a single network call.

Usage

Add this to AGENTS.md:

## Codebase Context & Knowledge Graph Protocol

You have access to a pre-computed AST knowledge graph of this repository at `graphify-out/graph.json`. To minimize context window clutter, prevent hallucinations, and accurately map cross-file dependencies, you MUST follow these routing rules:

1. **Consult the Graph First:** Before writing plans, making sweeping structural modifications, or tracing function call blast-radii, read `graphify-out/graph.json`. Filter nodes to only those whose `id` paths start with `backend/` or `frontend/src/` — nodes from `playwright-report/`, `test-results/`, and `coverage/` are minified build artifacts and must be ignored.
2. **Identify God Nodes:** Rank nodes by edge degree. The highest-degree nodes are the structural hubs (e.g., service files, route registries). Avoid duplicating responsibilities already owned by a god node.
3. **Trace Structural Paths:** If the user asks about relationships between modules or layers (e.g., how the API layer reaches the DB), do not grep blindly. Traverse the `links` array in `graph.json` to find the actual dependency path.
4. **Graph State:** The graph is derived strictly via AST extraction — no documentation or semantic layer. Treat all node hierarchies and import edges as 100% extracted truth (`EXTRACTED` confidence tier). Do not infer structure that isn't in the graph.

To visualize the graph, run this command:

uvx --from graphifyy graphify export callflow-html

graph_01

graph_01

Dur: 10'

vcdeadImage source: Vibe Coding Is Dead. Here's What Replaced It.

You probably have experienced this pattern:

This works for fast prototyping. It does not work for production-grade, maintainable, auditable software — especially in a regulated banking environment. The output is only as precise as your prompt, and prompts are inherently imprecise.

What is a "spec"?

A "spec" (short for specification) is a structured, human-readable document that defines:

Section

What it captures

Intent

What this feature is meant to accomplish — in one sentence

Behavior

Inputs, expected outputs, state changes

Constraints

Performance requirements, security boundaries, architecture rules

Edge cases

Boundary conditions, failure scenarios, unexpected inputs

Acceptance criteria

Testable, unambiguous, one per line

Data

What data is touched, its classification, handling requirements

A spec is not code. It is not a design document. It is the contract between intent and implementation.

Dur: 10'

1. What is SDD

Spec-driven development (SDD) is a software engineering approach where structured, human-readable specifications are the primary artifact and "source of truth".

Why SDD matters:

2. How to start using SDD

There are various libraries and frameworks that help you create an SDD pattern (we will discuss them at the end of the workshop). We can start by setting up your own preferred pattern. To make sure your development follows spec-driven development guidelines:

Dur: 10'

Use Copilot Spaces for onboarding and product brainstorming.

Create a space:

Prompt 1 (onboarding):

Create a new team member onboarding summary for this repository.
Explain the business flow (PR -> PO -> GR), tech stack, and first 3 tasks.

Prompt 2 (brainstorming):

For this procurement MVP, suggest 5 realistic enhancements for a future version.
Keep workshop scope unchanged and mark each as out-of-scope for today.

Dur: 10'

To start this project, we use an already created plan document, the spec for the MVP. Use Copilot Plan mode with docs/plan.md attached and enter the following prompt.

plan

Validate this plan for an MVP.
Return a strict task sequence with checkpoints.
Focus implementation on PO backlog.

Once you are satisfied with the plan, switch to Agent mode:

agent

Save the refined checklist to docs/runbook.md.

Here we are creating another "spec" document, a document that contains all the items the agent needs to implement in order to create the MVP.

Dur: 10'

Agent skills are folders of instructions, scripts, and resources that Copilot can load when relevant to improve its performance in specialized tasks. The Agent Skills specification is an open standard, used by a range of different AI systems.

You can create your own skills to teach Copilot to perform tasks in a specific, repeatable way—or use skills shared online, for example in the anthropics/skills repository or GitHub's community-created github/awesome-copilot collection.

How a skill works

A SKILL.md file contains structured instructions that tell Copilot how to behave when the skill is invoked — what inputs to look for, what outputs to produce, what format to follow, and what constraints to apply. Copilot reads the skill as context before responding, which makes its output consistent and predictable across team members and sessions.

Dur: 15'

1. Adding "skills" support

Create a new folder .github/skills

This will be the location for all the skill configurations.

2. Add a Vue.js best practices skill

3. Add a Figma design implementation skill

Sometimes skills include other configuration files, not just the SKILL.md file.

Dur: 10'

Before we start with the PO module implementation in our procurement system MVP, let's validate the backend API first. Use the Agent mode and enter this prompt:

Add Swagger/OpenAPI support to this Fastify JavaScript backend.
Use @fastify/swagger and @fastify/swagger-ui.
Expose API documentation at /api-docs.

The goal is:

  1. Add Swagger/OpenAPI support
  2. Start backend and open Swagger UI
  3. Verify baseline PR endpoints are listed and callable

Dur: 20'

Figma is the default tool for designing frontend pages and user interfaces. Adding Figma MCP allows the AI model to access a Figma file directly.

Modify the MCP config

  1. Use the Command Palette, open the MCP configuration file mcp.json.

mcp-config

  1. Add Figma configuration in the mcp.json file.

mcp-figma

Important Note

Before you ask Copilot to access a Figma file, make sure that:

Dur: 10'

Start developing the PO module by generating the Create PO page. We will be using a design in Figma to create the frontend codes.

Use Agent mode in Copilot chat and enter the prompt below:

Using Figma MCP, generate Vue code for the PO Create page from this Figma file https://www.figma.com/design/1PpeiduceHdtCB0Qds30am/Github-Copilot--Workshop-?node-id=38-323&p=f&t=QJcJvfEN1Kpy8NGa-0
Include reusable components for header form and line allocation table.
Do not implement API calls yet. Keep structure simple.

Scope for generated page:

Dur: 15'

Ask Copilot to help us create unit tests for the pages we have just created. Enter this prompt:

Create unit tests for important backend functions.
Focus on services that provide lists to the frontend.

Create Jest tests for frontend validations.
Focus on rendering of pages and components.

Keep tests readable.

Unit test result: tests

Unit test coverage report: coverage

Dur: 10'

It is best practice to have a document that tracks the status of the project. This can help Copilot get context on the overall status of the system we are building. Use Agent mode and enter this prompt:

Analyze this repository and summarize what is already implemented.
Identify the available API endpoints for PO module.
Document the latest state of the project in `docs/progress.md`.

The goal here is to make Copilot aware of what has been done and avoid redundancy.

Dur: 20'

Use this prompt to start integrating the Create PO page. Attach the related documents to provide context to Copilot.

Integrate the available PO endpoints with the "Create PO" page.
Keep generated Figma components and wire them to purchase order APIs.
Special request for the module functionality:
- enforce over-allocation validation against PR remaining quantities
- return 422 for rule violations with clear messages

The end result should be a working PO Create page.

create po

Dur: 30'

Create the rest of the PO module pages and connect them to the PO module API endpoints. We don't have Figma file for these pages, so ask Copilot to follow the existing design rules (using available codes as context).

Finish the PO module.
Implement PO list and detail pages in Vue using existing patterns.
Keep UI simple for clarity and follow the existing design system.
Use existing components when possible. Only create components that aren't already available.
Connect the new pages with the existing backend API endpoints for PO module.

The end result should be

po detail

Dur: 15'

GitHub offers various features to make sure our project is secure and reliable. But before we take a look into those features, let's try something we can implement locally.

Git hooks let us do a lot of things. They are triggered by the git command. In this example we will make a hook that does pre-push checks, that can block low-quality pushes quickly.

Create the hook

Create a new .git/hooks/pre-push file.

Then enter this prompt:

Create a git hook pre-push script that runs npm test and blocks the push if there's a failed test.

Copy the script provided by Copilot to the file you have just created.

Below is an example of a simple pre-push script that runs npm run test:unit:

#!/bin/sh

set -eu

echo "Running unit tests before push..."
cd app
npm run test:unit

Make sure you implement a script that runs the unit tests and cancels the push if an error is found.

Test the hook

Before testing the hook, make sure the hook file is executable:

chmod +x .githooks/pre-push

Then:

  1. Create a failing test
  2. Create a git commit
  3. Push the commit and check the result

Dur: 15'

Code Quality is a feature from GitHub that allow scanning of the codes in your repository.

GitHub Code Quality helps you ensure your codebase is reliable, maintainable, and efficient. It provides actionable insights and automated fixes so you can improve and maintain the code health of your repository efficiently.

code quality

Code Quality performs rule-based analysis of the following languages using CodeQL:

We can check the progress and result of Code Quality in the Actions tab of the repository:

actions

Dur: 10'

To enable and run checks:

codeql

We can ask Copilot to create the workflow file:

Create a GitHub Actions workflow for JavaScript CodeQL analysis.
Run on push and pull_request for main and feature branches.

Code Scanning scans your codebase and commits for vulnerabilities like hardcoded API key and secrets.

Dur: 20'

Copilot is also available on Github's website. Click on this link to open Copilot on Github.

copilot home

Let's see some of the things Copilot can do for us in the Github website.

1. Add PR Summary

We can ask Copilot to add Pull Request description.

  1. Commit the changes from the previous slide.
  2. Push to your repo.
  3. Open your Github repo page, create a new Pull Request.

generate summary

The summary from Copilot: summary

It will create a comprehensive PR description based on the commits in the branch that we wanted to merge.

2. Add As PR Reviewer

We can also add Copilot as a reviewer to a Pull Request. Very handy if you're working solo on a project.

After pushing, let's create a Pull Request on GitHub.com and utilize Copilot's code review functionality.

  1. Access your repository on GitHub
  2. Click Open a pull request
  3. On the Pull Request creation screen, click Copilot icon » Summary

PR Reviewer

In the Reviewers section, you can assign Copilot as a reviewer to request code review from Copilot.

Copilot would check all the files in the PR and make appropriate comments.

After the Pull Request is opened, you can view Copilot Code Review results:

copilot comment

You can go ahead ask Copilot to work on its proposed changes to the PR. It will automatically create a new separate PR that targets your working branch in the original PR.

Dur: 20'

Let's use the website version of GitHub Copilot to assign the Coding Agent to work on a new feature using the Issues feature.

First, make sure Issues is enabled in your Github repository's Settings.

issues enabled

Automatic Issue Creation with GitHub Copilot

In this section we want to implement a new feature: bookmarks.

  1. Access GitHub.com and click the Copilot icon in the top right
  2. Confirm your repository is added to the Chat context
  3. Enter the following prompt:
I want the user to be able to bookmark an item in this app and then see all the bookmarks in a "Bookmarks" page.

Create a feature which allows user to bookmark any item in the PR, PO, and GR list.

Create the necessary API endpoints, database migration scripts, and frontend page/components.
  1. Assign the issue to Copilot

assign issues

  1. Wait for the agent to finish creating the PR. Once it is done, review generated branch/PR.

issue pr

Dur: 15'

Now we create an end-to-end test using Playwright.

The required scenarios for this end-to-end test:

  1. Happy path: create + submit PO from approved PR data
  2. Negative path: reject over-allocation qty

Make sure Copilot chat is in Agent mode. Then, create a dedicated Playwright spec using this prompt:

Create tests/e2e/po-module.spec.js using the Playwright library.
Add happy path and negative over-allocation path with stable selectors and clear assertions.

The required artifacts:
- HTML report (`playwright-report/index.html`)
- screenshots/traces/videos - store them in `test-results/`

playwright

Dur: 10'

Set Copilot Chat to Agent mode, then ask Copilot to generate implementation docs with diagrams.

Prompt:

Create documentation for how the current application works.
Add a user flow chart and sequence diagram in Mermaid.
Save as markdown.

Use your favorite markdown viewer plugin to check the result, including the charts.

Because the charts are created using Mermaid format, you can also copy-paste the Mermaid code into Mermaid's tool.

App documentation

App documentation

Dur: 15'

Prompt Files

Prompt files define reusable prompts for specific tasks that you can invoke when needed. We define it in a markdown file inside the .github/prompts/ folder.

1. Create a "code explainer" agent

  1. Create a file: .github/prompts/explain-code.prompt.md
  2. Add this into the file:
---
agent: 'agent'
description: 'Generate a clear code explanation with examples'
---

Explain the following code in a clear, beginner-friendly way:

Code to explain: ${input:code:Paste your code here}
Target audience: ${input:audience:Who is this explanation for? (e.g., beginners, intermediate developers, etc.)}

Please provide:

* A brief overview of what the code does
* A step-by-step breakdown of the main parts
* Explanation of any key concepts or terminology
* A simple example showing how it works
* Common use cases or when you might use this approach

Use clear, simple language and avoid unnecessary jargon.

Explainer

2. Custom Agents

Other than the default agent provided by Copilot, you can create your own custom agent for specific use cases. Like custom prompts, we define custom agents in a markdown file inside a specific folder, in this case the .github/agents/ folder.

Create a "readme creator" agent

  1. Create a file: .github/agents/readme-creator.agent.md
  2. Add this into the file:
---
name: readme-creator
description: Agent specializing in creating and improving README files
---

You are a documentation specialist focused on README files. Your scope is limited to README files or other related documentation files only - DO NOT modify or analyze code files.

Focus on the following instructions:
- Create and update README.md files with clear project descriptions
- Structure README sections logically: overview, installation, usage, contributing
- Write scannable content with proper headings and formatting
- Add appropriate badges, links, and navigation elements
- Use relative links (e.g., `docs/CONTRIBUTING.md`) instead of absolute URLs for files within the repository
- Make links descriptive and add alt text to images

You will be able to access your custom agent in Copilot Chat.

Copilot VSCode

Dur: 30'

Using what you have learned so far, let's try to implement the last module in this procurement app: Goods Receipts (GR) module. You have 30 minutes to explore on your own, plan well.

gr

Dur: 15'

1. Why use framework

SDD frameworks can help us create a standardized specifications throughout the organization.

Why use a ready-made framework:

OpenSpec

Common SDD framework options:

Comparison matrix of various SDD frameworks:

SDD frameworksSource: Comparing 15 SDD frameworks - Medium

2. Why spec matters in AI-enabled SDLC

A good spec does not die when the code is written. It becomes:

Dur: 20'

OpenSpec has these philosophies:

Getting started OpenSpec

Install OpenSpec globally:

npm install -g @fission-ai/openspec@latest

Go to your root folder in the terminal/console and initialize OpenSpec:

cd <your-project-folder>
openspec init

On this screen, press enter to continue: OpenSpec init

If GitHub Copilot is automatically detected, you can press enter to continue: OpenSpec setup 1

Once setup is complete, restart VS Code to let the changes take effect: OpenSpec setup 2

Expected outcome:

Once you have completed setting up OpenSpec, you will see:

New custom skills and prompts: OpenSpec result 1

New slash commands: OpenSpec result 2

Dur: 10'

OpenSpec workflow

The standard workflow for OpenSpec is a fluid, iterative workflow for spec changes. No rigid phases, just actions you can take anytime.

OpenSpec flow

Most common OpenSpec commands:

TERMINAL   $ npm install -g @fission-ai/openspec@latest
TERMINAL   $ cd <your-project> && openspec init
AI CHAT      /opsx:explore                    (optional: think it through first)
AI CHAT      /opsx:propose add-dark-mode      (AI drafts the plan; you review it)
AI CHAT      /opsx:apply                      (AI builds it)
AI CHAT      /opsx:archive                    (specs updated, change filed away)

Below is some examples of what you can do with OpenSpec commands:

OpenSpec example

Dur: 20'

Create a functional specification for the GR module using OpenSpec /opsx:propose command:

/opsx:propose goods-receipts-module

After the proposition process is done, you will get the specification documents for the GR module.

openspec propose 1

You can check the specification documents in the newly created openspec/ folder:

openspec propose 2

Dur: 30'

Use this session to implement the GR (Goods Receipt) module based on the specifications from the previous process.

You have 30 minutes. You can also explore OpenSpec's custom prompt and skill files. Check this documentation for more information about OpenSpec's workflow.

Implementation

Type this in the GitHub Copilot Chat:

/opsx:apply

Once the implementation is finished, review the result:

  1. Implementation of GR backend APIs
  2. Implementation of GR frontend pages using existing project patterns
  3. Unit/integration tests for business rules and edge cases

Validate with realistic sample data from migration/seed context. Final checkpoint: GR module is implemented end-to-end and aligned with spec + constitution

grmod

Archive the spec

Use this command to archive the spec once the implementation is complete.

/opsx:archive

Dur: 15'

In this workshop, we learned to use GitHub Copilot to do the following:

Next Steps

Resources

Great work! 🎉