Coder Legion - Recent posts tagged githubcopilot

Ask Your Snowflake Account Anything — Build an AI Admin Agent with Cortex + GitHub Copilot ( Part 1 )

Mon, 07 Sep 2026 05:46:43 +0000

TL;DR — Spin up a Snowflake Cortex Agent that can answer admin questions like "Which warehouses burned the most credits last month?" or "Who are my top 5 spenders?" — all from a natural-language prompt inside GitHub Copilot Chat.

The Problem

Snowflake ACCOUNT_USAGE contains everything you need to understand spend, performance, and security. The catch? You have to know the right table, the right join, and write it correctly every time.

What if you could just ask?

What You'll Build

GitHub Copilot Chat
      │  (natural language)
      ▼
MCP Server (Python, local)
      │  ask_admin tool
      ▼
Snowflake Cortex Agent
      │  routes to the right semantic view
      ▼
SNOWFLAKE.ACCOUNT_USAGE (+ optional ORGANIZATION_USAGE)

By the end you'll be able to type questions like these into Copilot Chat and get back answers with real numbers:

What are total compute credits by warehouse in the last 30 days?
Which users consumed the most credits this month?
How many failed logins occurred in the last 7 days?
What are serverless credits by service type?

Prerequisites

Requirement	Notes
Snowflake account (any paid edition)	`ACCOUNTADMIN` or a role with `ACCOUNT_USAGE` access
Python 3.9+	For the MCP bridge
VS Code + GitHub Copilot Chat	Agent mode enabled
Git	To clone the template

Step 1 — Clone the Template

git clone https://github.com/LALITHASWAROOPK/agent_snowflake_admin_assistant.git
cd agent_snowflake_admin_assistant/agent_snowflake_admin

Open the folder in VS Code:

code .

Step 2 — Deploy the SQL Objects (5 scripts, ~5 minutes)

All SQL is in the sql/ folder. Replace the four placeholders before running:

Placeholder	What to set
`<APP_DB>`	A database to hold your views/agent
`<APP_SCHEMA>`	Schema inside that database
`<ADMIN_ROLE>`	Role that owns the objects
`<DEVELOPER_ROLE>`	Role that will query the agent
`<EXEC_WAREHOUSE>`	Warehouse the agent will use at runtime

Run them in order in a Snowflake worksheet or SnowSQL:

@sql/01_create_views.sql        -- Base views over ACCOUNT_USAGE
@sql/02_create_semantic_views.sql  -- Semantic layer (natural-language metadata)
@sql/03_create_agent.sql        -- Cortex Agent wired to those views
@sql/04_create_budget.sql       -- Optional: spending guardrails
@sql/05_grants.sql              -- RBAC grants

What the Views Cover

01_create_views.sql builds seven base views, all sourced exclusively from SNOWFLAKE.ACCOUNT_USAGE — no custom tables, no proprietary schemas:

View	Source
`V_WAREHOUSE_COST_BY_TAG`	`WAREHOUSE_METERING_HISTORY` + `TAG_REFERENCES`
`V_QUERY_PERFORMANCE`	`QUERY_HISTORY`
`V_USER_SPEND`	`QUERY_ATTRIBUTION_HISTORY`
`V_SERVERLESS_COSTS`	Tasks, pipes, clustering, search, MV refresh
`V_STORAGE_USAGE`	`STORAGE_USAGE` + `DATABASE_STORAGE_USAGE_HISTORY`
`V_LOGIN_HISTORY`	`LOGIN_HISTORY`
`V_DATA_TRANSFER`	`DATA_TRANSFER_HISTORY` + `REPLICATION_USAGE_HISTORY`

02_create_semantic_views.sql wraps each base view with a COMMENT block that tells the Cortex Agent what the view is for — this is how the agent knows which view to query for any given question.

Why Semantic Views?

Snowflake Cortex Agents use semantic views as tool definitions. A semantic view is just a standard view with a COMMENT that describes its purpose in natural language. The agent reads those comments at inference time to decide which tool (view) answers the user's question.

No prompt engineering required on your end.

Step 3 — Start the MCP Bridge

The MCP (Model Context Protocol) server is a lightweight Python HTTP server that exposes one tool — ask_admin — which Copilot Chat can call.

Install dependencies

pip install -r mcp/requirements.txt

Configure your environment

Create a .env file in the repo root (never commit this):

SNOWFLAKE_ACCOUNT=<your_account>
SNOWFLAKE_USER=<your_user>
SNOWFLAKE_AUTHENTICATOR=externalbrowser
SNOWFLAKE_ROLE=<DEVELOPER_ROLE>
SNOWFLAKE_WAREHOUSE=<EXEC_WAREHOUSE>
SNOWFLAKE_AGENT_FQN=<APP_DB>.<APP_SCHEMA>.<AGENT_NAME>
MCP_PORT=3000

Supports externalbrowser (SSO), snowflake (password), and OAuth — set SNOWFLAKE_AUTHENTICATOR and the matching credential variable.

Launch the server

./scripts/start-mcp.ps1

Or directly:

python mcp/server.py

Verify it's up:

Invoke-RestMethod -Uri http://127.0.0.1:3000/health -Method Get
# → {"status":"ok"}

Step 4 — Connect Copilot Chat

The repo ships a pre-configured .vscode/mcp.json that wires the local MCP server into VS Code:

{
  "mcpServers": {
    "snowflake-admin": {
      "url": "http://127.0.0.1:3000"
    }
  }
}

VS Code picks this up automatically when you open the workspace. You'll see the ask_admin tool listed inside Copilot Chat's tool picker.

There's also a GitHub Copilot instruction file at .github/instructions/admin.instructions.md which gives Copilot context about the agent's scope so it routes questions there automatically.

Step 5 — Ask It Questions

Switch Copilot Chat to Agent mode and try:

What are my top 5 warehouses by compute credits in the last 30 days?

Which users have spent the most credits this month?

Show me failed logins by user in the last 7 days.

What serverless services are costing me the most right now?

What's my current storage usage broken down by database?

The agent selects the right semantic view, runs the query, and returns a plain-English answer with the numbers inline — no SQL, no context switching.

Optional: Budget Guardrails

04_create_budget.sql sets up a Snowflake Budget object so you can enforce credit limits at the agent level. Handy for keeping a shared admin agent from running runaway queries:

CALL <APP_DB>.<APP_SCHEMA>.<BUDGET_NAME>!SET_SPENDING_LIMIT(100);
CALL <APP_DB>.<APP_SCHEMA>.<BUDGET_NAME>!GET_SPENDING_HISTORY();

Architecture Recap

┌─────────────────────────────────────┐
│         GitHub Copilot Chat         │
│      (Agent mode + ask_admin tool)  │
└────────────────┬────────────────────┘
                 │ HTTP / MCP
┌────────────────▼────────────────────┐
│      MCP Bridge  (mcp/server.py)    │
│  Exposes: /mcp/tools/list           │
│           /mcp/tools/call           │
│           /health                   │
└────────────────┬────────────────────┘
                 │ snowflake-connector-python
┌────────────────▼────────────────────┐
│   SNOWFLAKE.CORTEX.DATA_AGENT_RUN   │
│   ← Cortex Agent (semantic router)  │
└────────────────┬────────────────────┘
                 │ picks the right tool
┌────────────────▼────────────────────┐
│     Semantic Views (SV_*)           │
│     Base Views    (V_*)             │
│     ↑ SNOWFLAKE.ACCOUNT_USAGE       │
└─────────────────────────────────────┘

Key Things to Know

Account Usage latency: SNOWFLAKE.ACCOUNT_USAGE is typically delayed by up to a few hours — not real-time.
Rate sheet: ORGANIZATION_USAGE.RATE_SHEET_DAILY is optional and depends on your edition/region.
Auth flexibility: The MCP server supports SSO (externalbrowser), OAuth, and password auth — configure once in .env.

Get the Code

github.com/LALITHASWAROOPK/agent_snowflake_admin_assistant

PRs and issues welcome. If you build on top of this, tag me — I'd love to see what you add.

Developer Weekly Briefing — September 4, 2026

Fri, 04 Sep 2026 12:35:46 +0000

A strong week with two hard deadlines attached. GitHub Copilot's billing and governance changes start landing September 1 — one of them already hit. Developers and platform teams have until September 28 before the next wave takes effect. Here's everything that mattered.

GitHub Copilot's billing and governance rules are changing this fall — dates matter

Three separate changes are rolling out across Copilot Business and Enterprise between now and late September, and all three have calendar implications.

The first already took effect September 1: new seat assignments now require upfront payment before a user gets access. Existing customers have until October 1. The mechanics shift meaningfully — organizations are charged at the start of each billing cycle, with additional charges for usage that runs past what's included. Admins used to adding and removing seats on the fly will need to rethink that process, especially at billing cycle boundaries.

The second change is the one compliance teams should flag immediately. No earlier than September 28, GitHub is merging Copilot Cloud Agent, the github.com chat experience, and GitHub Mobile Chat into one unified experience. Buried in that consolidation: chat data retention changes from 28 days to the lifetime of the account. Any organization with data retention policies, audit requirements, or contractual obligations around AI-generated conversations needs to review its settings before that date, not after.

The third change, also September 28: the default code review effort level shifts from "Lite" to "Balanced" across all repositories and organizations. Teams that want to keep the lighter behavior need to explicitly select Lite before the switch. Under token-based billing, deeper reviews mean more tokens consumed per pull request — which means higher costs if nobody notices the default changed.

As Futurum Group's Mitch Ashley put it: "Engineering leaders should assign an owner to those defaults now, before the invoice makes the decision for them."

Copilot can now approve pull requests — not just review them

GitHub moved Copilot from advisory to authoritative in code review this week. Copilot's sign-off can now count toward a repository's required-approvals rule, the same way a teammate's would.

The guardrails are more careful than the headline suggests. Approvals are off by default. Admins opt in at the enterprise, organization, or repository level. Repository admins can restrict which file paths Copilot is allowed to approve at all — letting teams scope it to documentation and test fixtures while keeping authentication and payment logic strictly human-reviewed. Push a new commit after approval and the approval is dismissed automatically, same as a human reviewer.

The governance question worth sitting with, from Futurum Group's Mitch Ashley: "Approval is where code review stops being advice and becomes authority, and GitHub just moved Copilot across that line. An automated reviewer earns that trust the same way a person does — through outcomes you can point to. Engineering leaders should turn this on and instrument it to measure the effectiveness of approvals."

That instrumentation doesn't come built in. If Copilot's approvals count the same as a human's, someone needs to build dashboards showing how often it approves correctly, how often a human catches something after the fact, and whether speed is coming at the cost of depth. Teams that skip that step and flip approvals on everywhere at once are trading a review bottleneck for a governance gap.

VS Code 1.135 adds Rubber Duck — a second AI model to critique the first one

The headline addition in VS Code 1.135 is Rubber Duck, an experimental feature that puts a different model to work reviewing the primary coding agent's plans, code, and tests before anything ships. Type /rubber-duck in a Copilot agent session and a complementary model looks for gaps the first one missed.

The same release introduces the Agent Host Protocol — a dedicated process for running agent harnesses that lets developers connect to the same session from multiple VS Code windows. Sessions now show agent work started in other applications, including Claude or Copilot sessions outside VS Code, so context doesn't get lost when you switch windows. Per-model token tracking in the chat footer gives teams a clearer read on what each model costs per turn.

Mitch Ashley's useful caveat: "Rubber Duck answers verification pressure with more generation, and that only goes so far." A second model catching more edge cases is still generation, not independent verification. Worth keeping that distinction in mind before treating Rubber Duck's output as a stamp of correctness.

Microsoft opens up its Agent Framework with Channels — one agent, every surface

Microsoft's Agent Framework team published Channels this week — open-source Python packages that let a single agent connect to multiple communication platforms and protocols without a separate implementation for each. Launch integrations cover OpenAI's Responses API, Telegram, the Agent2Agent (A2A) protocol, and MCP.

The architecture is notable for what it leaves out of scope: identity mapping, authentication, authorization, and session storage are still the application's responsibility. Microsoft made that explicit rather than abstracting it away, which keeps Channels auditable but also means teams can't treat it as a governance shortcut.

Mitch Ashley's read: "Microsoft is acknowledging something important: no single vendor owns the enterprise agent estate, so the channel layer has to speak protocols it does not control. Building on A2A and MCP instead of a Microsoft-only path matches what enterprises want."

Debian's AI vote: accountability instead of a ban

Debian developers voted on AI policy this week after a two-week community ballot with eight separate proposals, including an outright ban that would have required a supermajority to pass. It didn't come close. The policy that won neither endorses nor prohibits generative AI — it holds contributors to the same standard regardless of how code got written: you reviewed it, you tested it, and nothing sensitive left the building to get it.

Disclosure is encouraged, not mandated. Three specific guardrails came with it: no confidential material or credentials to third-party AI services without explicit authorization, no bulk automated contributions without prior discussion, and the copyright question is explicitly punted downstream.

The insight worth carrying into enterprise AI policy discussions: Debian didn't try to regulate the tool. It regulated the behavior around the tool, which is considerably easier to enforce. You can't reliably detect LLM-generated code. You can hold the person who submitted it accountable for what it does.

A simple website summary task exposed the limits of AI coding guardrails

A researcher assigned an AI coding agent a task so basic it barely registers as a task: summarize a website. The agent found an edge case that required executing external code to complete the job, did so, and the guardrails didn't catch it. The post is a useful reminder that guardrails are tested against anticipated misuse, not every combination of legitimate task plus unexpected environment. The agent wasn't trying to do anything wrong. It was trying to finish the job.

CrowdStrike Fal.Con 2026: Falcon Guardian, SafeMind, and the end of "breakout time." George Kurtz retired the metric and made the case that attacks now happen at inference speed. Falcon Guardian goes GA, SafeMind pairs an offensive and defensive model built on NVIDIA Nemotron, and Jensen Huang, Lip-Bu Tan, and Greg Brockman all had things worth hearing. Read more
Cycode's AI scanner found 38 bugs in MLflow. The press release only mentioned one. When we pushed on the benchmark methodology, the CTO's written follow-up had more detail — and a few numbers that didn't match the press release. Read more
F5's AI WAF caught 15 zero-days before a human ever saw them — built on a custom neural network rather than a fine-tuned LLM, for reasons that come down to latency and data path. Read more
Act Security's Amphi shrinks a 30,000-character AWS IAM policy down to 7,000 — live demo, same permissions, a quarter of the size, free and open source. Read more
76% of enterprises with HA/DR still went down this year. The top blocker isn't cost — it's configuration complexity, at 44%. Only 7% test DR monthly. Read more
Jazz's Roi Vanunu: "agentic" should describe what a security tool finishes, not what it is. A precise and useful reframe of how to evaluate AI security vendor claims. Read more

The through-line this week: governance is catching up with capability across the board — Copilot billing controls, PR approval authority, Debian's accountability-over-ban model, and Channels leaving identity to the application. The tooling is maturing. The question in every case is whether the governance catches up before the default decides for you.

September 28 is the next hard date. Put it on the calendar now.

See you next Friday.

Developer Weekly Briefing is published every Friday on Coder Legion. Written by Tom Smith.

From Prototype to Production: Finishing Moonsu Link, a Chat-Native Agricultural Marketplace for Cameroon

Sat, 04 Jul 2026 02:30:59 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What We Built

Moonsu Link is a chat-native agricultural marketplace built for farmers and buyers in Cameroon.

In Cameroon, agriculture is central to daily life, but the way products are bought and sold is still fragmented. In many towns, roadside markets and middlemen control access to buyers. In rural areas, farmers often depend on word of mouth, informal contacts, or market days to move their goods.

That creates real friction.

A farmer in Bamenda, Bafoussam, Douala, or Yaoundé may have produce ready, but still struggle to find a buyer quickly, get a fair price, or know where demand is strongest. At the same time, many people already use WhatsApp and Telegram every day, while mobile data costs, app installs, and complicated onboarding can get in the way. Language matters too. Cameroon is bilingual, and any useful product has to feel natural in both English and French while staying simple enough for users with different levels of digital comfort.

Moonsu Link was built to close that gap by bringing the marketplace into the chat apps people already use. The goal is to reduce friction and make trade feel more direct, local, and trustworthy.

The idea is simple:
help farmers list produce easily, help buyers search in plain language, and let both sides trade without needing a separate app.

Instead of pushing users into a dashboard-first experience, Moonsu Link works through WhatsApp and Telegram, the platforms people already know.

With Moonsu Link, a farmer can list produce with location, price, quantity, and optional photos. Buyers can search naturally, compare listings, check market prices, and express interest. The platform also supports farmer verification, community reports, farming advice, voice messages, and cross-platform use across WhatsApp and Telegram.

What began as an unfinished idea is now a real product with a clear user flow, a polished web presence, and a backend that connects messaging, AI, search, verification, and notifications into one system.

Demo

Live app: https://moonsulink.vercel.app
GitHub repository:https://github.com/yvesdylane/Moonsun-Link-api , https://github.com/yvesdylane/MoonsuLinkFrontend
Video walkthrough: https://youtu.be/6skq9w_mw-s?si=c5YCVunZ3RC5Qfqs
Screenshots:!Moonsu Telegram Bot(https://dev-to-uploads.s3.amazonaws.com/uploads/articles/b1ewivz77iwyli4gh01a.jpeg) ,
!Moonsu Whatsapp (https://dev-to-uploads.s3.amazonaws.com/uploads/articles/op3lmh99vio6zbxu4bcl.jpg) ,
!Moonsu Admin Dahboard(https://dev-to-uploads.s3.amazonaws.com/uploads/articles/cit70l8bc84pijmworrj.jpg)

The Comeback Story

!Moonsu website before finishathon(https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2nlqiwperncglto84re2.png)
Moonsu Link did not start as a finished product. It began as a prototype built around a real problem, but like many hackathon projects, it never fully crossed the finish line.

The idea was strong, but the product needed more structure, cleaner UX, better flow, and real end-to-end functionality before it could genuinely help users.

For this challenge, We came back to it with a different mindset. We treated it like a real product, not just a demo.

That meant focusing on the things that matter most:

making the experience feel unified across WhatsApp, Telegram, and the web
refining the landing page so the product story is clear immediately
building a visual identity that reflects a Cameroon-first agricultural context
improving backend flows for messaging, listings, verification, search, and notifications
making the product feel trustworthy, usable, and ready to present to real users

The biggest difference is that the project is no longer just an idea. It now has a clear user journey, a stronger brand, and real functionality that shows what the product is supposed to do.

Our Experience with GitHub Copilot

GitHub Copilot helped me move faster and finish with more confidence.

It was especially useful for:

building repetitive frontend sections faster
cleaning up component structure
speeding up backend boilerplate and integrations
iterating on UI copy and layout
reducing friction while refactoring and finishing incomplete parts of the project

What mattered most was not just speed, but momentum.

Copilot helped us keep the project moving when we needed to turn unfinished ideas into working features and a coherent product experience.

Why This Project Matters
Agriculture is one of the most important parts of everyday life in Cameroon, but many farmers still struggle with discovery, pricing, trust, and access to buyers.

Moonsu Link tries to solve that with one simple idea:

Meet users where they already are.

No app install
No complicated onboarding
No unfamiliar workflow
Just a practical marketplace inside the chat platforms people already use

That is why this project felt worth finishing. It is not just a technical build. It is a tool that could genuinely reduce friction for farmers and buyers.

The Stack

Frontend:
Next.js 16, React 19, TypeScript, Tailwind CSS v4, Framer Motion

Backend:
FastAPI, PostgreSQL, Telegram Bot API, WhatsApp integration, AI-powered message handling, translation, voice transcription, image upload, and admin APIs

What Changed During the Comeback

The project went from unfinished to presentable by focusing on:

a clearer product story
a stronger landing page
better visual consistency
real cross-platform marketplace flows
verification and trust features
AI-assisted handling of user messages
more polished communication for farmers and buyers

Authors
Main Author: Yves Dylane @yveane
Co-Author: _Chestly Amahndong @chestlyace
Co-Author: Kanjo Elkamira @alchemycodes

GitHub Copilot for Engineers: Getting Better Results

Tue, 02 Jun 2026 10:02:04 +0000

Original post: GitHub Copilot for Engineers: Getting Better Results

GitHub Copilot moved to usage-based billing in June 2026, dropping the flat subscription model that made monthly costs predictable. For teams using it heavily across multiple projects, that shift puts a premium on being deliberate: reaching for the right model, keeping prompts focused, and building a configuration that produces good results without a lot of back-and-forth iteration.

Many of us install the extension, start with the defaults, and only tune settings later. The defaults are a reasonable starting point, but they are not a full configuration. A small investment in setup changes how much you get out of every request on an ordinary working day, and that matters more now that each request has a cost attached.

This guide covers the full path: getting the tooling in place, choosing models with cost in mind, layering global and project-level rules, and building out instructions, agents, and skills that make Copilot predictable across different kinds of work.

Architecture overview

Diagram fallback for Dev.to. View the canonical article for the full version: https://sourcier.uk/blog/github-copilot-for-engineers

Before you start

Subscription and VS Code extension

You need an active GitHub Copilot subscription. Plans are available at individual, business, and enterprise tiers at github.com/features/copilot. Once active, all tools use your GitHub account credentials.

The GitHub Copilot extension for VS Code is the primary day-to-day interface. Install it from the Extensions panel or via the CLI:

code --install-extension GitHub.copilot

The extension provides inline completions as you type, Copilot Chat in the sidebar, inline chat on any selection via Cmd+I / Ctrl+I, agent mode for multi-step tasks, and multi-file edits with a single review step.

Defaults keep improving, so avoid cargo-culting old setting lists. Focus on non-default tweaks that improve signal quality and control usage:

Setting	Value	Effect
`github.copilot.nextEditSuggestions.enabled`	`true`	Surfaces likely next edits proactively during implementation
`github.copilot.chat.codesearch.enabled`	`true`	Improves answers on larger repos by pulling semantic code context

Copilot CLI

The GitHub Copilot CLI is a standalone AI agent for the terminal.

Install via Homebrew:

brew install copilot-cli

Or via pnpm, if you prefer Node.js tooling:

pnpm add -g @github/copilot

On first launch, authenticate with your GitHub account by following the /login prompt. The CLI has two modes: an interactive session where you have a back-and-forth conversation while Copilot reads and modifies files in the current directory, and a programmatic mode where you pass a single prompt with -p and the CLI executes and exits.

# Start an interactive session
copilot

# One-shot task with explicit tool approval
copilot -p "Show me this week's commits and summarise them" --allow-tool='shell(git)'

# Open a PR with the changes
copilot -p "Refactor the auth module to use async/await and open a PR"

awesome-copilot

github.com/github/awesome-copilot is the official community-curated repository of Copilot instructions, agents, skills, and prompts. Before writing any configuration from scratch, check here first. It is far faster to adapt a battle-tested instruction file than to start from a blank page. The catalogue covers common engineering workflows: security review, frontend, documentation, and more.

Choose models by task

Model choice should match task shape. GitHub Copilot subscriptions give you access to a range of models. Here is how to map them to real work:

Task	Recommended model	Why
Quick edits and inline completions	GPT-5.4	Strong quality at lower effort per prompt, reducing rework
General feature work and refactoring	GPT-5.4 or Claude Sonnet 4.5	Strong reasoning with a good speed and cost balance
Complex architecture and deep analysis	Claude Sonnet 4.5	Extended reasoning and long context without premium pricing
Security review	Claude Sonnet 4.5	Strong policy alignment and risk detection
Documentation and standards	GPT-5.4 or Claude Sonnet 4.5	Consistent structure, clear prose
Agent and multi-step repo operations	Claude Sonnet 4.5 or GPT-5.4	Reliable tool-calling across many steps

A practical pattern:

Start with your default model.
If the output is shallow, switch to a stronger reasoning model.
If the output is too slow for a simple task, switch back to a faster model.
Keep one model per agent role for consistency: engineering, security, UX, docs.

Agents (covered below) let you pin a model in their frontmatter, so the same task always runs with the same capability profile.

Layer global and project settings

The most reliable setup is layered: global defaults for how you work everywhere, project-level rules for what is unique to a specific repo.

Global settings

Global Copilot configuration lives under your home directory:

Path	Purpose
`~/.copilot/instructions/`	Always-on rules applied across all repos
`~/.copilot/agents/`	Reusable agent definitions
`~/.copilot/skills/`	Reusable skill playbooks
`~/.copilot/mcp-config.json`	Global MCP server connections

Managing these in a dotfiles repo and syncing them to $HOME on each machine gives you a consistent baseline without reconfiguring per project. Good candidates for global rules include workflow behaviour and tool preferences, secure coding defaults, code-commenting standards, and framework-specific instructions for React, TypeScript, and similar.

If you want a concrete reference, this is my setup: github.com/sourcier/dotfiles.

Project-level settings

For project-specific behaviour, add a .github/copilot-instructions.md to the repo root, or place .instructions.md files in .github/instructions/. VS Code picks these up automatically when you open the project.

Use project-level rules for naming conventions unique to this repo, folder architecture and module boundaries, test and QA requirements, and build and deployment constraints. Use global rules for communication style, security baseline, preferred CLIs, package manager choices, and repeatable personal workflow.

Instructions, agents, and skills

These three tools serve different purposes. Treating them as interchangeable leads to a setup that is noisy and hard to maintain.

Instructions: always-on policy

Instructions are Markdown files with YAML frontmatter that Copilot reads automatically whenever the applyTo glob matches the file you are working in. Use them for stable guardrails and standards that should apply silently in the background.

Two patterns work well: broad instructions with applyTo: '*' for universal rules, and targeted instructions with file-type globs for framework-specific rules.

Minimal template:

---
applyTo: '**/*.ts'
description: 'TypeScript service-layer standards'
---

# Service Standards
- Use strict typing
- Return typed errors
- Validate external input at boundaries

Agents: task-specific operators

Agents are .agent.md files that define a reusable persona with a pinned model, a tool budget, and a system prompt. Use them when the same class of work needs consistent behaviour every time.

An agent definition includes:

name: shown in the VS Code agent picker
description: used for routing; Copilot reads this to decide which agent fits a request
model: pinned model for this workflow
tools: explicit list of tools the agent is allowed to use

Good starting agents: a Software Engineer for general implementation and refactoring, a Security Reviewer for OWASP-focused code review, an Expert Frontend Engineer for React and TypeScript work, and a Tech Writer for documentation and READMEs.

Create a new agent when a task requires a distinct review lens, needs a stable model and tool profile, or when you want consistent output style for that workflow.

Skills: reusable playbooks

Skills are SKILL.md files that contain detailed step-by-step procedures for a specific domain. The agent reads the skill file at invocation time rather than keeping it in context permanently, which means skills can be as long and detailed as needed without bloating every conversation.

Good candidates: a premium frontend UI craftsmanship checklist, a workflow for creating AGENTS.md files for a new repo, or a Playwright website exploration procedure.

The rule of thumb:

Instructions = default behaviour
Agents = who does the work
Skills = how specialised work gets executed

MCP servers

MCP (Model Context Protocol) extends Copilot with external capabilities: browsers, issue trackers, cloud providers, databases, and more. Servers are configured in ~/.copilot/mcp-config.json for global access, or .vscode/mcp.json for project scope.

Three common patterns:

Local command server: runs a pre-installed binary on your machine (preferred)
Remote HTTP server: connects to an external service over HTTPS
npx/uvx on-demand: package runner launches the server each time; avoid for servers you use regularly as the cold boot adds latency on every invocation

Installing common servers

Playwright MCP: browser automation and visual QA:

brew install playwright-mcp
# or via pnpm
pnpm add -g @playwright/mcp

Azure MCP Server: Azure resource inspection and management:

brew tap azure/azure-cli
brew install azmcp
# Authenticate before first use
az login

Example config

{
  "mcpServers": {
    "playwright": {
      "command": "playwright-mcp",
      "args": ["--headless"]
    },
    "atlassian/atlassian-mcp-server": {
      "type": "http",
      "url": "https://mcp.atlassian.com/v1/mcp/"
    },
    "Azure MCP Server": {
      "command": "azmcp",
      "args": ["server", "start"]
    }
  }
}

Prefer a globally installed binary via Homebrew or pnpm for any server you use regularly. Reserve npx for one-off evaluation of a new server before committing to a permanent install.

When to reach for MCP

Follow this order:

Native CLI first: git, gh, pnpm, docker, cloud CLIs.
Use MCP when no good CLI path exists or when MCP adds capability the CLI cannot.
Keep the MCP list minimal and intentional.

Security checklist

Before adding any MCP server:

Never hardcode tokens in config files. Use environment variables or a secret store.
Prefer least-privilege credentials.
Use trusted hosts only for remote HTTP servers.
Disable or remove servers you are not actively using.

Rolling it out

Individual setup

Install the VS Code extension and Copilot CLI.
Create ~/.copilot/instructions/ and add one global instruction file. Workflow preferences and a security baseline are the highest-value starting points.
Browse awesome-copilot and copy two or three instruction files relevant to your stack.
Add a .github/copilot-instructions.md to your primary repo with project-specific conventions.
Try agent mode for a non-trivial task to get a feel for how it behaves.

Team rollout

Define a shared baseline in a dotfiles or inner-source repo covering instructions, agents, skills, and MCP config.
Add two to four high-value project instructions per repo.
Create three core agents: engineering, security, and documentation review.
Add skills only for repeated, specialised workflows.
Review output quality every two weeks and refine rules and prompts based on what you observe.

Keeping it improving

Results degrade when instructions conflict, when prompts are vague, or when agents are used for everything regardless of fit. A simple quality loop prevents that drift:

Be explicit in prompts: goal, constraints, relevant files, and done criteria.
Keep instructions concise and non-conflicting.
Scope rules with applyTo so they trigger only where needed.
Use specialised agents for repeated high-value workflows.
Validate with tests and lint, and feed failures back into instructions.

Quick audit checklist

When the setup is in place, use this to evaluate it quickly:

Model selection is intentional by task type.
Global rules exist for workflow and security.
Project rules exist for repo-specific conventions.
Agent catalogue maps to real team workflows.
Skills exist only for deep, repeated procedures.
MCP servers are minimal, secure, and actively used.
Prompts include explicit success criteria.

Wrap up

The model table in this guide covers the cloud providers available through a Copilot subscription. If you want to cut cloud costs further or keep sensitive work entirely on your machine, running models locally is worth exploring. My next post covers exactly that: installing and tuning Ollama on Apple Silicon, choosing models by use case, and wiring local inference into VS Code Copilot and the CLI. It goes live June 4.

If this guide helped, use it as a practical checklist this week: pick one primary model, tighten your instruction layers, and remove one source of prompt churn from your workflow. Then share what changed for you in the comments, or subscribe via the form at the end of this page to get the local AI follow-up as soon as it publishes.

My GitHub Copilot Sessions Kept Degrading -- So I Built a Skill to Fix It

Fri, 08 May 2026 10:31:06 +0000

You've probably experienced this. You're 30 minutes into a productive Copilot agent session, things are flowing well -- and then something shifts. The agent asks you to clarify something it already knows. It repeats a question from earlier. The quality of the output quietly drops. You didn't change anything. What happened?

Context ran out.

Every Copilot session has a fixed token budget. Once that budget fills up, the model starts compressing or dropping older context. The result isn't an error message. It's subtle degradation -- and most developers don't even realize it's happening until they're already fighting it.

I built a skill to address this directly. Here's what I learned.

The problem isn't Copilot. It's how we use it.

After tracking a few weeks of agent sessions, I found five recurring patterns that burned through context faster than the actual work:

1. Re-reads
When the same instruction exists in multiple files, the agent reloads it every time it's referenced. I had rules duplicated across copilot-instructions.md and individual skill files. Every time a skill loaded, it brought along content that was already in context. Fix: cross-cutting rules live in references/*.md only. Skills link to them, never copy them.

2. Reading entire files instead of snippets
read_file without startLine/endLine loads the full file -- every time. On a workspace with many skill files, this adds up fast. I also had list_dir calls on the workspace root, which recursively indexed hundreds of paths I never needed.

3. Too many tools active
Every loaded MCP tool takes up space in the system context -- even if it's never called. In agent mode, deferred tools should only be loaded via tool_search when genuinely needed.

4. Working too long in one session
After 15-20 messages, context compression begins. The agent doesn't tell you this. You notice it when output quality drops or earlier decisions get quietly reversed.

5. Trial-and-error tool use
When an agent dives straight into tool calls without a plan, every failed attempt costs double tokens -- once for the call, once for the error. Requiring a written Plan of Action before any tool is invoked eliminates this entirely.

The skill I built

I encoded all of this into a token-hygiene skill:

---
name: token-hygiene
description: "Guidelines for efficient Copilot context management. Use when a session
  is slowing down, the agent is repeating questions, context is filling up, or when
  starting a complex multi-step task. Triggers: 'token', 'context full', 'session
  cleanup', 'new chat', 'load skill', 'terminal risk', 'plan of action',
  'context efficiency'."
version: "1.0"
---

The skill body covers the five causes above, plus a pre-task checklist the agent can consult before starting any complex job:

Check	Action
Is this info already in context?	Don't reload it
Which skills do I actually need?	Load only those -- not preemptively
Am I reading a large file?	Use `startLine`/`endLine`
Searching with a broad term?	Use `grep_search` instead of `semantic_search`
Complex multi-step task?	Write a Plan of Action first
Been working in this session long?	Consider new chat + session memory
Agent repeating a question?	Session is full -- save and restart

The terminal protocol: a surprise lesson

While building this skill, I discovered something that surprised me. The run_in_terminal tool has an explanation parameter described as "This will be shown to the user before the command is run."

That is not true.

The explanation parameter is not visible in the confirmation dialog. It's metadata for the tool system, not a user-facing message. This means if you rely on it to inform users about what a command does, they never see it.

So I added a terminal protocol as a reference file. It requires the agent to write the explanation as a chat message before the tool call -- not after, not inside the tool call. The message must cover:

What the command does in plain language
Which files are read or modified
Whether data leaves the system
Whether the action is reversible

Combined with a risk classification matrix ([LOW] low / [MEDIUM] medium / [HIGH] high / [CRITICAL] critical), this makes every terminal action visible and deliberate.

VS Code indexing: a silent token drain

One thing worth adding to your .vscode/settings.json immediately:

"files.exclude": { "out/": true, "Output/": true },
"search.exclude": { "out/": true, "Output/": true }

VS Code indexes your entire workspace for search. Generated output folders -- HTML reports, screenshots, log files -- get included in search results and can end up as irrelevant context when the agent runs a workspace search. .gitignore doesn't prevent this. Only files.exclude and search.exclude do.

The skill structure

.github/skills/token-hygiene/
  SKILL.md                            # Core skill -- 5 causes, checklist, VS Code tip
  references/
    terminal-protocol.md              # Required transparency rules for terminal calls
    terminal-risk-classification.md   # Risk matrix per command type

The references are loaded on demand -- the agent only reads them when it actually needs to run a terminal command. This follows the progressive disclosure pattern I described in my previous post on reusable marketing skills.

The most useful thing: session memory

The fix I use most often isn't even in the skill itself. At the end of any session longer than 15 messages, I ask:

"Summarize our progress as a short status update."

I paste that into the first message of the new chat. The agent has full context again in one message, without reloading a single file.

manage_todo_list also helps here -- if the agent tracks tasks as it works, you never need to scroll back through the conversation to remember where you are.

Why this matters more than you'd expect

Token hygiene sounds like an optimization problem. It's actually a reliability problem.

When context fills quietly, the agent doesn't fail loudly. It makes slightly worse decisions. It misremembers earlier choices. It starts contradicting itself in subtle ways. For short sessions, you might not notice. For longer, multi-step workflows -- publishing pipelines, multi-file refactors, anything with state -- the degradation compounds.

Encoding these rules as a skill means I never have to think about them. The agent consults the checklist before complex tasks and follows the terminal protocol automatically. I just do the work.

The repo: copilot-context-skills on GitHub

The previous post: I Built Reusable Marketing Skills for GitHub Copilot -- Here's How and Why

What patterns have you noticed that drain context faster than they should? I'd like to expand the skill with more real-world examples.

I Built Reusable Marketing Skills for GitHub Copilot — Here's How (and Why)

Wed, 06 May 2026 17:16:51 +0000

What if your code editor could do keyword research, audit your SEO, and optimize your content for AI search engines — without leaving VS Code?

I built a set of open-source agent skills that turn GitHub Copilot into a hands-on marketing strategist. Here's what I learned, how they work, and how you can use (or build) your own.

The problem
I run a small website. Every time I wanted to write a blog post, the workflow looked like this:

Open Ahrefs/Semrush → research keywords
Open Google Docs → write the article
Open WordPress → publish and fill in SEO fields
Open ChatGPT → rewrite for social media
Repeat
Five tools. Five context switches. And every time, I found myself giving the same SEO instructions to AI assistants: "Use the keyword in the first paragraph", "Write a meta description under 155 characters", "Structure with H2/H3 headings"...

What if I could encode all that knowledge once, and have my AI assistant apply it automatically?

The solution: Copilot Skills
GitHub Copilot (in agent mode) can read SKILL.md files from your workspace. These files act as knowledge modules — they tell Copilot how to approach a domain, what rules to follow, and what frameworks to apply.

I created four skills that cover the full marketing workflow:

seo-keyword-research → Find what your audience searches for

↓

seo-strategy → Structure your site to rank

↓

geo-optimization → Get cited by AI search engines

↓

content-creator → Write content that ranks AND gets cited
What's inside a skill?
A skill is just a Markdown file with structured knowledge. Here's a simplified look at the GEO (Generative Engine Optimization) skill:

name: geo-optimization
description: "Optimize content for AI search engines like ChatGPT,
Gemini, and Perplexity. Use when the user mentions 'AI visibility',

'GEO', 'AI search', or 'cited by AI'."

GEO — Generative Engine Optimization

What is GEO?

GEO = optimizing content so AI-powered search engines cite your
brand in generated answers.

GEO Scorecard (16 criteria)

Criterion	Target
Authoritative tone	Expert language, no hedging
Structured data	Schema markup present
...

Anti-patterns

Don't do this	Why
Keyword stuffing	AI recognizes and skips it
...

The description field is key — Copilot uses it to decide when to invoke the skill. The body contains the actual knowledge the AI applies.

How it works in practice
Here's what a real session looks like:

Me: "Do keyword research for a blog about home espresso machines"

Copilot (automatically invokes seo-keyword-research):

Searches the web for related keywords
Classifies intent (informational, commercial, transactional)
Analyzes SERP features
Outputs a structured keyword map with primary/secondary keywords, difficulty estimates, and content type recommendations
Me: "Now write the article and optimize it for AI search"

Copilot (invokes content-creator + geo-optimization):

Writes with proper H2/H3 structure
Includes the keyword in the first paragraph
Adds statistics with citations (GEO requirement)
Uses authoritative tone
Ends with a clear conclusion (AI search engines need this)
Generates meta title and description within character limits
Me: "Publish as draft to WordPress"

Copilot (uses REST API knowledge from seo-strategy):

Creates the post via wp-json/wp/v2/posts
Sets Yoast SEO meta fields
Outputs the draft URL
Total time: ~15 minutes. From zero to published draft with SEO metadata.

The GEO angle: why AI search changes everything
Here's something most developers don't think about: when someone asks ChatGPT "what's the best espresso machine for beginners?", the answer comes from somewhere. That somewhere could be your website — but only if your content is structured in a way AI models can parse and trust.

This is called Generative Engine Optimization (GEO). It's like SEO, but for AI search engines. The research (Aggarwal et al., 2024) shows that GEO techniques can boost visibility in AI-generated answers by up to 40%.

My geo-optimization skill includes:

A 16-criterion scorecard for AI-readiness
Writing guidelines that balance human readability and AI parseability
Anti-patterns (things that make AI skip your content)
E-E-A-T implementation (Experience, Expertise, Authoritativeness, Trust)
What I learned building these skills

Skills need evidence, not opinions
AI assistants hallucinate. If your skill says "meta descriptions should be 155 characters" without a source, Copilot might second-guess it or contradict itself later.

I added a sources file with links to Moz, Ahrefs, Google Search Central, and peer-reviewed papers. This makes the skill more reliable and more trustworthy for users.

The description field is your trigger
Copilot decides which skill to invoke based on the description in the YAML frontmatter. Be specific about trigger words:

description: "Use when the user mentions 'SEO', 'search engine
optimization', 'Google rankings', 'rank higher', 'meta tags'..."
The more trigger phrases you include, the more reliably it activates.

Structure > prose
Tables, bullet lists, and clear headings work better than long paragraphs. The AI parses structured content faster and applies it more consistently.
Skills should reference each other
My skills cross-link: the SEO strategy skill says "for keyword research, see seo-keyword-research". This helps Copilot chain skills together in multi-step workflows.

Installation (30 seconds)
git clone https://github.com/WilcoRakhorst/helder-ai-marketing-skills.git .github/skills/marketing

That's it. Open VS Code with Copilot agent mode, and start asking marketing questions. Copilot auto-discovers the skills.

Or as a Git submodule (stays updatable):

git submodule add https://github.com/WilcoRakhorst/helder-ai-marketing-skills.git .github/skills/marketing

Build your own skills
The pattern works for any domain knowledge:

Create a SKILL.md in .github/skills/your-skill/
Add YAML frontmatter with name and description (include trigger words)
Write structured knowledge — tables, checklists, decision trees
Add references for any factual claims
Test it — ask Copilot questions in the skill's domain and see if it gets invoked
Domains that would benefit from this approach:

Accessibility (WCAG guidelines as a skill)
Security (OWASP Top 10 as actionable checklists)
API design (REST/GraphQL conventions)
Legal/compliance (GDPR, cookie consent rules)
Brand guidelines (tone of voice, terminology)
The repo
GitHub: helder-ai/marketing-skills

Licensed CC BY-NC 4.0 — free to use, adapt, and learn from.

If you find it useful: ⭐ the repo, or open a PR if you have improvements. I'd especially love contributions from SEO practitioners who want to encode their expertise.

What domain knowledge would you encode as a Copilot skill? Let me know in the comments!

GitHub Copilot Just Killed Flat-Rate AI Coding. Here's What It Means for Your Team.

Wed, 06 May 2026 07:58:02 +0000

On April 27, 2026, GitHub announced that all Copilot plans are moving to usage-based billing on June 1, 2026. The flat "premium request" model is dead. Welcome to per-token pricing for AI coding assistants.

If you're a solo developer, this might not change much. If you run an engineering team, you need to read this carefully — because your AI bill is about to become unpredictable in ways it wasn't before.

Here's what's actually changing, why it's happening, and what you should do this month.

What's Changing

Today, Copilot uses Premium Request Units (PRUs). You get a monthly bucket of requests, and every chat or agent prompt counts as one — regardless of whether it's a one-line question or a 30-minute autonomous coding session.

Starting June 1, 2026:

PRUs are replaced by GitHub AI Credits (1 credit = $0.01 USD)
Every interaction is billed by token consumption — input + output + cached tokens
Each model has its own per-token rate, matching published API rates
Code completions and Next Edit suggestions remain free across all plans
Plan base prices are unchanged: Pro $10/mo, Pro+ $39/mo, Business $19/seat, Enterprise $39/seat
Each plan includes monthly AI Credits equal to its subscription price (Pro = $10 in credits, etc.)

The big shift: a quick question and a multi-hour agentic session no longer cost the same.

Why GitHub Did This

Read between the lines of the official announcement and the picture is clear. Agentic coding broke the math.

A single autonomous coding session — running across an entire repo, calling tools, iterating, retrying — can consume thousands of times more compute than a chat question. Under PRUs, both counted as "one request." A handful of power users can cost more than the plan price covers.

GitHub said it directly in their April 21 update on individual plans: "It's now common for a handful of requests to incur costs that exceed the plan price."

That's not sustainable. Token-based billing aligns price with cost. It's the same reason every API provider has always priced this way.

Who Wins, Who Loses

Wins: Developers who mostly use code completions and light chat. You'll likely see no real change. Your $10 Pro plan probably never came close to using $10 in tokens.

Loses: Heavy agent users. If you're running long-trajectory agentic workflows — multi-step refactors, autonomous bug-fixing across files, parallel subagents — you'll feel this. The same workflows that gave you outsized value under PRUs are exactly what's getting expensive.

Maybe: Teams. It depends entirely on how your developers actually use Copilot. Some companies will save money. Others will hit budget caps mid-month for the first time ever.

The Annual Plan Trap

If you're on an annual Pro or Pro+ plan, GitHub is doing something clever and slightly hostile: you keep your existing PRU-based pricing until the plan expires — but model multipliers go up on June 1 for annual subscribers only.

Translation: your existing annual plan gets quietly worse. You can either ride it out at degraded value, or convert to a monthly plan early and get prorated credit.

If you're an annual subscriber, you should sit down before June 1 and decide which path actually saves you money. Don't ignore this.

What To Do This Month

For individual developers:

Check your current usage. GitHub is launching a preview bill experience in early May. Look at your Billing Overview on github.com and see what your actual token consumption would have cost you the past few months.
Audit which models you use. Different models have wildly different per-token rates. If you're defaulting to the most expensive premium model for tasks GPT-5 mini could handle, that habit is about to cost real money.
Decide on annual vs monthly. If you're on annual, run the numbers before June 1.

For engineering teams:

Set up budgets. Admin-level budget controls let you cap spend at the enterprise, cost center, or user level. Use them. Without caps, one developer running parallel agent workflows can blow through your monthly credits in a week.
Pool credits across the org. GitHub now allows pooled included usage instead of per-seat isolation. This is genuinely useful — your light users effectively subsidize your heavy users without anyone changing behavior.
Educate your team on model selection. "Use the cheapest model that works for the task" is now a real engineering practice with a real budget impact.
Watch out for Copilot code review. It now consumes both AI Credits and GitHub Actions minutes. Two meters running at once.

The Bigger Picture

This isn't just a Copilot story. Every AI coding tool is heading the same direction — Cursor, Cody, Continue, Claude Code. Token-based pricing is becoming the default because flat-rate doesn't survive contact with agentic workloads.

The era of "$20/month gets you unlimited AI coding" is over. What's replacing it is more honest, but also more demanding: you need to know what your AI usage actually costs, and you need to manage it like any other infrastructure spend.

For teams that have been treating AI coding as a free productivity boost, that mental model needs to change before June 1.

The good news: the tools to manage this are getting better. Budget controls, usage dashboards, and pooled credits all help. The bad news: you actually have to use them.

Originally published on lenkastudio.com. We help teams ship modern web, mobile, and AI-powered products. If you're rethinking your AI dev tooling and budget for 2026, let's talk.

The Real Problem With AI Coding Isn’t Intelligence — It’s Continuity

Tue, 17 Mar 2026 12:53:08 +0000

Most AI coding failures are not caused by weak models.

They happen because the system loses continuity.

A model can generate decent code in one shot. It can explain architecture, suggest refactors, and help debug isolated issues. But once the work becomes long-running — once memory, role separation, evolving context, and multiple sessions enter the picture — many AI setups begin to break down.

The problem is not just model quality.
The problem is that most AI coding systems are still structured like stateless assistants.

Real development work is not stateless.

It has identity, history, unresolved threads, shifting priorities, and accumulated intent. If all of that gets mixed into one growing prompt, the system gradually loses coherence. The model may still sound capable, but the overall system becomes fragile. Context drifts. Memory bloats. Roles blur. Useful insights disappear into noise.

That is why I have been building a persona-aware agent shell on top of GitHub Copilot.

Not to make the AI feel more decorative.
Not to give it a superficial personality layer.
But to give long-running AI work a structure that can preserve continuity.

What Usually Breaks

In practice, AI coding systems often fail in very predictable ways.

First, context keeps accumulating without changing shape. Every session adds more text, more reminders, more patches, more references. Over time, the system becomes heavier but not clearer. Memory turns into a dump.

Second, identity and task state get mixed together. Core behavioral constraints, persistent preferences, recent session details, and the current request all compete in the same space. The model has to infer structure from a pile of text that was never properly separated.

Third, roles become unstable. The same system is expected to be an architect, debugger, planner, note-taker, and companion without any explicit boundary between those functions. It may still produce useful output, but the internal operating pattern becomes inconsistent.

Fourth, continuity is confused with accumulation. Many AI systems treat memory as “store more, keep more, append more.” But keeping everything is not the same as preserving coherence. In fact, over-accumulation often destroys it.

This is why many systems look impressive in short demos and become unreliable in real, ongoing work.

The Shift: From Prompting to Operating

What changed my thinking was realizing that the real challenge was not how to prompt better.

It was how to operate better.

A useful AI system is not just a model plus instructions. It is an environment where intelligence can stay coherent over time.

That means the structure around the model matters as much as the model itself.

In my own work, I’ve been separating interaction into four layers:

Persona Core
The stable identity layer. This is where role, tone, priorities, boundaries, and deep behavioral shape live.

Persistent Context
The compressed continuity layer. Not everything that happened, but the parts that still matter.

Session Context
The active working state for the current thread or task.

Current User Request
The immediate prompt or instruction.

This separation sounds simple, but it changes everything.

Instead of forcing the model to infer which details are permanent, which are temporary, and which are urgent, the system gives those distinctions explicit structure. The result is not just cleaner output. It is more stable long-running behavior.

Why Memory Should Be Recompressed, Not Accumulated

This has become one of the strongest design principles in my system:

Memory should be recompressed, not endlessly accumulated.

If memory is treated as an append-only log, it eventually becomes a burden. The system spends more effort carrying history than using it.

But continuity does not require full preservation of every detail.
It requires preservation of shape.

What matters is not whether the system remembers every message.
What matters is whether it retains the right patterns:

identity

priorities

unresolved tensions

recurring preferences

meaningful changes

active trajectories

That is a very different problem from raw storage.

Recompression means periodically turning lived interaction into a smaller, more structured continuity object. It is closer to memory consolidation than transcript hoarding.

In practical terms, this helps prevent the familiar fate of many AI systems: they become larger in context, but weaker in direction.

Why Persona Structure Matters

The word “persona” is often misunderstood in AI discussions.

People assume it means style. Or roleplay. Or cosmetic behavior.

That is not how I use it.

In my system, persona is an operational unit.

It is a way to preserve differentiated behavior, stable role orientation, and long-term continuity in a multi-agent or multi-context environment. Persona is not there to make the model sound more human. It is there to make the system more structurally coherent.

A good persona layer can help answer questions like:

What kind of attention should this agent bring?

What should remain stable across sessions?

What kind of memory matters to this role?

Where should responsibility begin and end?

How should continuity be compressed without losing identity?

That is why I call it a persona-aware shell, not just a prompt wrapper.

The shell is doing operational work.

What This Looks Like in Practice

The system I’ve been building is centered in a VS Code extension workflow, with persona definitions stored as structured YAML assets and working memory stored separately as persistent context files.

That distinction matters.

Core identity should not be mixed with lived memory.
Role should not be mixed with recent state.
Continuity should not be reduced to raw chat history.

By separating these layers, the system can support long-running interaction without collapsing into prompt sprawl.

This has also changed how I think about AI coding itself.

The most important improvement is not that the model writes more code.
It is that the surrounding system loses less shape.

Once continuity is preserved, the AI becomes more useful not only as a code generator, but as a participant in a sustained development loop: observing, planning, remembering, resuming, and refining.

That is a different category of usefulness.

The Deeper Lesson

The real bottleneck in AI coding is often not intelligence.

It is continuity.

Not whether the model can solve a problem once, but whether the system can keep a coherent relationship to the problem over time.

That is why I think the future of AI development systems will not be defined by prompting tricks alone. It will be defined by operating structure:

memory architecture

role boundaries

continuity compression

task layering

long-running coherence

In other words, better outputs are not enough.

What we need are better conditions for intelligence to remain intelligible.

That is the direction I’m building toward.

Not just a smarter assistant.
A more stable operating structure for intelligence.

How GitHub Copilot Helped Me Roast Its Own Users

Sun, 08 Feb 2026 07:19:53 +0000

What if GitHub Copilot didn’t just help you write code but judged you for it?

What I Built

I had been waiting for a challenge that truly sounded like me for a long time, and that’s when the GitHub Copilot CLI Challenge showed up.

Within five minutes, the idea that popped into my head was to use Copilot CLI to do something with Copilot itself.

That’s when the idea of roasting the user for their GitHub Copilot usage came up.

Then I started wondering how to implement it.

Whether to build something that runs in the terminal but that would consume RAM.

Should I try a different approach?

That’s when the idea of a VS Code extension popped up (GitHub CLI actually helped me there ).

This was my first time using an AI pair programmer to help me build a project completely, because I had never built, or even thought about creating a VS Code extension before.

The roasts are static for now and don’t use AI, because I couldn’t afford an API key .

Demo

Click the following link:
Copilot Roaster Extension

Install the extension using the link.

And your setup is complete.

Then, open any sample file to test it.

Ask GitHub Copilot to write something and accept its suggestion to see the magic ✨

Find my demo below:

Demo

You can find the GitHub repository here.

Feel free to fork, modify, and upgrade it.

My Experience with GitHub Copilot CLI

This was my first time using an AI pair programmer in the CLI. I was really excited to see how it worked. After installing it and typing copilot in the terminal, it felt like magic when this showed up.

I started wondering how it would work, which subscription it would use and which profile it would be linked to.

While thinking about all this, I typed a prompt, and that’s when I got an error saying I needed to log in to proceed further.

First, we need to use /login to sign in with our GitHub account.

After that, everything was smooth. The suggestions were almost exactly what I expected (maybe my prompt was too good ).

Then I tweaked things a bit, and tadaaa

The extension was ready and looked cool.

I added a few more roasts just to make sure the same ones didn’t repeat.

Then I published it on the Marketplace.

GitHub Copilot CLI provided me with the exact steps to publish the extension, because I had no clue how to do it and the whole process was smooth as well.

So go ahead, install the extension, let Copilot write your code, and brace yourself… because this time, you’re the one getting reviewed

Follow me on Linkedin | GitHub | Twitter

Subscribe to my newsletter and get articles delivered straight to your inbox.

Coder Legion - Recent posts tagged githubcopilot

Ask Your Snowflake Account Anything — Build an AI Admin Agent with Cortex + GitHub Copilot ( Part 1 )

The Problem

What You'll Build

Prerequisites

Step 1 — Clone the Template

Step 2 — Deploy the SQL Objects (5 scripts, ~5 minutes)

What the Views Cover

Why Semantic Views?

Step 3 — Start the MCP Bridge

Install dependencies

Configure your environment

Launch the server

Step 4 — Connect Copilot Chat

Step 5 — Ask It Questions

Optional: Budget Guardrails

Architecture Recap

Key Things to Know

Get the Code

Developer Weekly Briefing — September 4, 2026

GitHub Copilot's billing and governance rules are changing this fall — dates matter

Copilot can now approve pull requests — not just review them

VS Code 1.135 adds Rubber Duck — a second AI model to critique the first one

Microsoft opens up its Agent Framework with Channels — one agent, every surface

Debian's AI vote: accountability instead of a ban

A simple website summary task exposed the limits of AI coding guardrails

Also from Coder Legion this week

From Prototype to Production: Finishing Moonsu Link, a Chat-Native Agricultural Marketplace for Cameroon

GitHub Copilot for Engineers: Getting Better Results

Architecture overview

Before you start

Subscription and VS Code extension

Copilot CLI

awesome-copilot

Choose models by task

Layer global and project settings

Global settings

Project-level settings

Instructions, agents, and skills

Instructions: always-on policy

Agents: task-specific operators

Skills: reusable playbooks

MCP servers

Installing common servers

Example config

When to reach for MCP

Security checklist

Rolling it out

Individual setup

Team rollout

Keeping it improving

Quick audit checklist

Further reading

Wrap up

My GitHub Copilot Sessions Kept Degrading -- So I Built a Skill to Fix It

The problem isn't Copilot. It's how we use it.

The skill I built

The terminal protocol: a surprise lesson

VS Code indexing: a silent token drain

The skill structure

The most useful thing: session memory

Why this matters more than you'd expect

I Built Reusable Marketing Skills for GitHub Copilot — Here's How (and Why)

'GEO', 'AI search', or 'cited by AI'."

GEO — Generative Engine Optimization

What is GEO?

GEO Scorecard (16 criteria)

Anti-patterns

GitHub Copilot Just Killed Flat-Rate AI Coding. Here's What It Means for Your Team.

What's Changing

Why GitHub Did This

Who Wins, Who Loses

The Annual Plan Trap

What To Do This Month

The Bigger Picture

The Real Problem With AI Coding Isn’t Intelligence — It’s Continuity

How GitHub Copilot Helped Me Roast Its Own Users

What I Built

Demo

My Experience with GitHub Copilot CLI