{"id":213228,"date":"2025-10-14T17:38:16","date_gmt":"2025-10-14T17:38:16","guid":{"rendered":"https:\/\/www.newsbeep.com\/au\/213228\/"},"modified":"2025-10-14T17:38:16","modified_gmt":"2025-10-14T17:38:16","slug":"how-to-build-reliable-ai-workflows-with-agentic-primitives-and-context-engineering","status":"publish","type":"post","link":"https:\/\/www.newsbeep.com\/au\/213228\/","title":{"rendered":"How to build reliable AI workflows with agentic primitives and context engineering"},"content":{"rendered":"

Many developers begin their AI explorations with a prompt. Perhaps you started the same way: You opened GitHub Copilot<\/a>, started asking questions in natural language, and hoped for a usable output. This approach can work for simple fixes and code suggestions, but as your needs get more complex\u2014or as your work gets more collaborative\u2014you\u2019re going to need a more foolproof strategy.\u00a0<\/p>\n

This guide will introduce you to a three-part framework that transforms this ad-hoc style of AI experimentation into a repeatable and reliable engineering practice. At its core are two concepts: agentic primitives, which are reusable, configurable building blocks that enable AI agents to work systematically; and context engineering, which ensures your AI agents always focus on the right information. By familiarizing yourself with these concepts, you\u2019ll be able to build AI systems that can not only code independently, but do so reliably, predictably, and consistently.<\/p>\n

\"AnThe AI-native development framework
Markdown prompt engineering + agent primitives + context engineering = reliability<\/p>\n

Whether you\u2019re new to AI-native development or looking to bring deeper reliability to your agent workflows, this guide will give you the foundation you need to build, scale, and share intelligent systems that learn and improve with every use.<\/p>\n

\ud83e\udde0 Try it yourself: Build and run agentic workflows with GitHub Copilot CLI<\/p>\n

Bring your agent primitives to life right from your terminal. The new GitHub Copilot CLI lets you run, debug, and automate AI workflows locally\u2014no setup scripts, no context loss. It connects directly to your repositories, pull requests, and issues through GitHub MCP, giving your agents the same context they\u2019d have in your IDE.\u00a0<\/p>\n

\ud83d\udc49 Get started with GitHub Copilot CLI ><\/a><\/p>\n

What are agent primitives?\u00a0<\/p>\n

The three-layer framework below turns ad-hoc AI experimentation into a reliable, repeatable process. It does this by combining the structure of Markdown; the power of agent primitives, simple building blocks that give your AI agents clear instructions and capabilities; and smart context management, so your agents always get the right information (not just more information).\u00a0<\/p>\n

Layer 1: Use Markdown for more strategic prompt engineering<\/p>\n

We\u2019ve written about the importance of prompt engineering<\/a>. But here\u2019s what you need to know: The clearer, more precise, more context-rich your prompt, the better, more accurate your outcome. This is where Markdown comes in. With Markdown\u2019s structure (its headers, lists, and links), you can naturally guide AI\u2019s reasoning, making outputs more predictable and consistent.\u00a0<\/p>\n

To provide a strong foundation for your prompt engineering, try these techniques with Markdown as your guide:\u00a0<\/p>\n

Context loading: [Review existing patterns](.\/src\/patterns\/). In this case, links become context injection points that pull in relevant information, either from files or websites.<\/p>\n

Structured thinking: Use headers and bullets to create clear reasoning pathways for the AI to follow.<\/p>\n

Role activation: Use phrases like \u201cYou are an expert [in this role].\u201d This triggers specialized knowledge domains and will focus the AI\u2019s responses.<\/p>\n

Tool integration: Use MCP tool tool-name. This lets your AI agent run code in a controlled, repeatable, and predictable way on MCP servers<\/a>.<\/p>\n

Precise language: Eliminate ambiguity through specific instructions.<\/p>\n

Validation gates: \u201cStop and get user approval.\u201d Make sure there is always human oversight at critical decision points.<\/p>\n

For example, instead of saying, Find and fix the bug, use the following:<\/p>\n

You are an expert debugger, specialized in debugging complex programming issues.<\/p>\n

You are particularly great at debugging this project, which architecture and quirks can be consulted in the [architecture document](.\/docs\/architecture.md). <\/p>\n

Follow these steps:<\/p>\n

1. Review the [error logs](.\/logs\/error.log) and identify the root cause. <\/p>\n

2. Use the `azmcp-monitor-log-query` MCP tool to retrieve infrastructure logs from Azure. <\/p>\n

3. Once you find the root cause, think about 3 potential solutions with trade-offs<\/p>\n

4. Present your root cause analysis and suggested solutions with trade-offs to the user and seek validation before proceeding with fixes – do not change any files.<\/p>\n

Once you\u2019re comfortable with structured prompting, you\u2019ll quickly realize that manually crafting perfect prompts for every task is unsustainable. (Who has the time?) This is where the second step comes in: turning your prompt engineering insights into reusable, configurable systems.<\/p>\n

Layer 2: Agentic primitives: Deploying your new prompt engineering techniques<\/p>\n

Now it\u2019s time to implement all of your new strategies more systematically, instead of prompting ad hoc. These configurable tools will help you do just that.<\/p>\n

Core agent primitives<\/p>\n

When it comes to AI-native development, a core agent primitive<\/a> refers to a simple, reusable file or module that provides a specific capability or rule for an agent.\u00a0<\/p>\n

Here are some examples:<\/p>\n

Instructions files: Deploy structured guidance through modular .instructions.md files with targeted scope. At GitHub, we offer custom instructions<\/a> to give Copilot repository-specific guidance and preferences.\u00a0<\/p>\n

Chat modes: Deploy role-based expertise through .chatmode.md files with MCP tool boundaries that prevent security breaches and cross-domain interference. For example, professional licenses that keep architects from building and engineers from planning.<\/p>\n

Agentic workflows: Deploy reusable prompts through .prompt.md files with built-in validation.<\/p>\n

Specification files: Create implementation-ready blueprints through .spec.md files that ensure repeatable results, whether the work is done by a person or by AI.<\/p>\n

Agent memory files: Preserve knowledge across sessions through .memory.md files.<\/p>\n

Context helper files: Optimize information retrieval through .context.md files.<\/p>\n

How using a core agent primitive can transform a prompt and its outcome<\/p>\n

Technique: Using Markdown prompt engineering, your prompt can be: \u201cImplement secure user authentication system\u201d\u00a0<\/p>\n

Primitives: You\u2019ll select backend-dev chat mode \u2192 Auto-triggers security.instructions.md via applyTo: “auth\/**” \u2192 Loads context from [Previous auth patterns](.memory.md#security) and [API Security Standards](api-security.context.md#rest) \u2192 Generates user-auth.spec.md using structured templates \u2192 Executes implement-from-spec.prompt.md workflow with validation gates.<\/p>\n

Outcome: Developer-driven knowledge accumulation where you capture implementation failures in .memory.md, document successful patterns in .instructions.md, and refine workflows in .prompt.md files\u2014creating compound intelligence that improves through your iterative refinement.<\/p>\n

This transformation might seem complex, but notice the pattern: What started as an ad-hoc request became a systematic workflow with clear handoff points, automatic context loading, and built-in validation.\u00a0<\/p>\n

When you use these files and modules, you can keep adjusting and improving how your AI agent works at every step. Every time you iterate, you make your agent a little more reliable and consistent. And this isn\u2019t just random trial and error \u2014 you\u2019re following a structured, repeatable approach that helps you get better and more predictable results every time you use the AI.<\/p>\n

\ud83d\udca1 Native VS Code support: While VS Code natively supports .instructions.md, .prompt.md, and .chatmode.md files, this framework takes things further with .spec.md, .memory.md, and .context.md patterns that unlock even more exciting possibilities AI-powered software development.<\/p>\n

With your prompts structured and your agentic primitives set up, you may encounter a new challenge: Even the best prompts and primitives can fail when they\u2019re faced with irrelevant context or they\u2019re competing for limited AI attention. The third layer, which we\u2019ll get to next, addresses this through strategic context management.<\/p>\n

Layer 3: Context engineering: Helping your AI agents focus on what matters<\/p>\n

Just like people, LLMs have finite limited memory (context windows), and can sometimes be forgetful. If you can be strategic about the context you give them, you can help them focus on what\u2019s relevant and enable them to get started and work quicker. This helps them preserve valuable context window space and improve their reliability and effectiveness.<\/p>\n

Here are some techniques to make sure they get the right context\u2014this is called context engineering:\u00a0<\/p>\n

Session splitting: Use distinct agent sessions for different development phases and tasks. For example, use one session for planning, one for implementation, and one for testing. If an agent has fresh context, it\u2019ll have better focus. It\u2019s always better to have a fresh context window for complex tasks.\u00a0<\/p>\n

Modular and custom rules and instructions: Apply only relevant instructions through targeted .instructions.md files using applyTo YAML frontmatter syntax. This preserves context space for actual work and reduces irrelevant suggestions.\u00a0<\/p>\n

Memory-driven development: Leverage agent memory through .memory.md files to maintain project knowledge and decisions across sessions and time.<\/p>\n

Context optimization: Use .context.md context helper files strategically to accelerate information retrieval and reduce cognitive load.\u00a0<\/p>\n

Cognitive focus optimization: Use chat modes in .chatmode.md files to keep the AI\u2019s attention on relevant domains and prevent cross-domain interference. Less context pollution means you\u2019ll have more consistent and accurate outputs.\u00a0<\/p>\n

Agentic workflows: The complete system in action<\/p>\n

Now that you understand all three layers, you can see how they combine into agentic workflows\u2014complete, systematic processes where all of your agentic primitives are working together, understanding your prompts, and using only the context they need.\u00a0\u00a0<\/p>\n

These agentic workflows can be implemented as .prompt.md files that coordinate multiple agentic primitives into processes, designed to work whether executed locally in your IDE, in your terminal or in your CI pipelines.<\/p>\n

Need a recap?\u00a0<\/p>\n

Markdown prompt engineering provides the structural foundation for predictable AI interactions.<\/p>\n

Agent primitives are your configurable tools that scale and systematize these techniques.<\/p>\n

Context engineering optimizes AI cognitive performance within memory constraints.<\/p>\n

Agentic workflows in Markdown apply prompt and context engineering that leverages agent primitives to implement complete, reliable agentic processes.<\/p>\n

This framework creates compound intelligence that improves as you continue to iterate.<\/p>\n

Now that you understand the three-layer framework and that the agentic primitives are essentially executable software written in natural language, the question is: How can you scale these Markdown files beyond your individual development workflow?<\/p>\n

Natural language as code<\/p>\n

The answer mirrors every programming ecosystem\u2019s evolution. Just like JavaScript evolved from browser scripts to using Node.js runtimes, package managers, and deployment tooling, agent primitives need similar infrastructure to reach their full potential.<\/p>\n

This isn\u2019t just a metaphor: These .prompt.md and .instructions.md files represent a genuine new form of software development that requires proper tooling infrastructure.<\/p>\n

Here\u2019s what we mean: Think of your agent primitives as real pieces of software, just written in natural language instead of code. They have all the same qualities: You can break complex tasks into smaller pieces (modularity), use the same instructions in multiple places (reusability), rely on other tools or files (dependencies), keep improving and updating them (evolution), and share them across teams (distribution).<\/p>\n

That said, your natural language programs are going to need the same infrastructure support as any other software.\u00a0\u00a0<\/p>\n

Agent CLI runtimes<\/p>\n

Most developers start by creating and running agent primitives directly in VS Code with GitHub Copilot, which is ideal for interactive development, debugging, and refining daily workflows. However, when you want to move beyond the editor\u2014to automate your workflows, schedule them, or integrate them into larger systems\u2014you need agent CLI runtimes like Copilot CLI<\/a>.\u00a0<\/p>\n

These runtimes let you execute your agent primitives from the command line and tap into advanced model capabilities. This shift unlocks automation, scaling, and seamless integration into production environments, taking your natural language programs from personal tools to powerful, shareable solutions.\u00a0<\/p>\n

Inner loop vs. outer loop<\/a><\/p>\n

Inner loop (VS Code and GitHub Copilot): Interactive development, testing, and workflow refinement<\/p>\n

Outer loop (agent CLI runtimes): Reproducible execution, CI\/CD integration, and production deployment<\/p>\n

Agent CLI Runtimes transform your agent primitives from IDE-bound files into independently executable workflows that run consistently across any environment. They provide command-line execution, CI\/CD integration, environment consistency, and native support for MCP servers, which bridge your development work to production reality.<\/p>\n

TL;DR: Use the inner loop for rapid, interactive work and the outer loop for reliable, repeatable automation and deployment.<\/p>\n

Runtime management<\/p>\n

While VS Code and GitHub Copilot handle individual development, some teams may want additional infrastructure for sharing, versioning, and productizing their agent primitives. Managing multiple Agent CLI runtimes can become complex quickly, with different installation procedures, configuration requirements, and compatibility matrices.<\/p>\n

APM (Agent Package Manager)<\/a> solves this by providing unified runtime management and package distribution. Instead of manually installing and configuring each vendor CLI, APM handles the complexity while preserving your existing VS Code workflow.<\/p>\n

Here\u2019s how runtime management works in practice:<\/p>\n

# Install APM once
\ncurl -sSL https:\/\/raw.githubusercontent.com\/danielmeppiel\/apm\/main\/install.sh | sh<\/p>\n

# Optional: setup your GitHub PAT to use GitHub Copilot CLI
\nexport GITHUB_COPILOT_PAT=your_token_here<\/p>\n

# APM manages runtime installation for you
\napm runtime setup copilot # Installs GitHub Copilot CLI
\napm runtime setup codex # Installs OpenAI Codex CLI<\/p>\n

# Install MCP dependencies (like npm install)
\napm install<\/p>\n

# Compile Agent Primitive files to Agents.md files
\napm compile<\/p>\n

# Run workflows against your chosen runtime
\n# This will trigger ‘copilot -p security-review.prompt.md’ command
\n# Check the example apm.yml file a bit below in this guide
\napm run copilot-sec-review –param pr_id=123<\/p>\n

As you can see, your daily development stays exactly the same in VS Code, APM installs and configures runtimes automatically, your workflows run regardless of which runtime is installed, and the same apm run command works consistently across all runtimes.<\/p>\n

Distribution and packaging<\/p>\n

Agent primitives\u2019 similarities to traditional software become most apparent when you get to the point of wanting to share them with your team or deploying them into production\u2014when you start to require things like package management, dependency resolution, version control, and distribution mechanisms.<\/p>\n

Here\u2019s the challenge: You\u2019ve built powerful agent primitives in VS Code and your team wants to use them, but distributing Markdown files and ensuring consistent MCP dependencies across different environments becomes unwieldy. You need the equivalent of npm for natural language programs.<\/p>\n

APM<\/a> provides this missing layer. It doesn\u2019t replace your VS Code workflow\u2014it extends it by creating distributable packages of agent primitives complete with dependencies, configuration, and runtime compatibility that teams can share, just like npm packages.<\/p>\n

Package management in practice<\/a><\/p>\n

# Initialize new APM project (like npm init)
\napm init security-review-workflow<\/p>\n

# Develop and test your workflow locally
\ncd security-review-workflow
\napm compile && apm install
\napm run copilot-sec-review –param pr_id=123<\/p>\n

# Package for distribution (future: apm publish)
\n# Share apm.yml and Agent Primitive files with team
\n# Team members can install and use your primitives
\ngit clone your-workflow-repo
\ncd your-workflow-repo && apm compile && apm install
\napm run copilot-sec-review –param pr_id=456<\/p>\n

The benefits compound quickly: You can distribute tested workflows as versioned packages with dependencies, automatically resolve and install required MCP servers, track workflow evolution and maintain compatibility across updates, build on (and contribute to) shared libraries from the community, and ensure everyone\u2019s running the same thing.<\/p>\n

Project configuration<\/a><\/p>\n

The following\u00a0 apm.yml configuration file serves as the package.json equivalent for agent primitives, defining scripts, dependencies, and input parameters:<\/p>\n

# apm.yml – Project configuration (like package.json)
\nname: security-review-workflow
\nversion: 1.2.0
\ndescription: Comprehensive security review process with GitHub integration<\/p>\n

scripts:
\n copilot-sec-review: “copilot –log-level all –log-dir copilot-logs –allow-all-tools -p security-review.prompt.md”
\n codex-sec-review: “codex security-review.prompt.md”
\n copilot-debug: “copilot –log-level all –log-dir copilot-logs –allow-all-tools -p security-review.prompt.md”<\/p>\n

dependencies:
\n mcp:
\n – ghcr.io\/github\/github-mcp-server<\/p>\n

With this, your agent primitives can now be packaged as distributable software with managed dependencies.<\/p>\n

Production deployment<\/p>\n

The final piece of the tooling ecosystem enables continuous AI: packaged agent primitives can now run automatically in the same CI\/CD pipelines you use every day, bringing your carefully developed workflows into your production environment.<\/p>\n

Using APM GitHub Action<\/a>, and building on the security-review-workflow package example above, here\u2019s how the same APM project deploys to production with multi-runtime flexibility:<\/p>\n

# .github\/workflows\/security-review.yml
\nname: AI Security Review Pipeline
\non:
\n pull_request:
\n types: [opened, synchronize]<\/p>\n

jobs:
\n security-analysis:
\n runs-on: ubuntu-latest
\n strategy:
\n matrix:
\n # Maps to apm.yml scripts
\n script: [copilot-sec-review, codex-sec-review, copilot-debug]
\n permissions:
\n models: read
\n pull-requests: write
\n contents: read<\/p>\n

steps:
\n – uses: actions\/checkout@v4<\/p>\n

– name: Run Security Review (${{ matrix.script }})
\n uses: danielmeppiel\/action-apm-cli@v1
\n with:
\n script: ${{ matrix.script }}
\n parameters: |
\n {
\n “pr_id”: “${{ github.event.pull_request.number }}”
\n }
\n env:
\n GITHUB_COPILOT_PAT: ${{ secrets.COPILOT_CLI_PAT }}<\/p>\n

Key connection: The matrix.script values (copilot-sec-review, codex-sec-review, copilot-debug) correspond exactly to the scripts defined in the apm.yml configuration above. APM<\/a> automatically installs the MCP dependencies (ghcr.io\/github\/github-mcp-server) and passes the input parameters (pr_id) to your security-review.prompt.md workflow.<\/p>\n

Here\u2019s why this matters:\u00a0<\/p>\n

Automation: Your AI workflows now run on their own, without anyone needing to manually trigger them.<\/p>\n

Reliability: They run with the same consistency and reproducibility as traditional code deployments.<\/p>\n

Flexibility: You can run different versions or types of analysis (mapped to different scripts) as needed.<\/p>\n

Integration: These workflows become part of your organization\u2019s standard CI\/CD pipelines, just like regular software quality checks.<\/p>\n

This setup ultimately means your agent primitives are no longer just local experiments\u2014they are fully automated tools that you can rely on as part of your software delivery process, running in CI\/CD whenever needed, with all dependencies and parameters managed for you.<\/p>\n

Ecosystem evolution<\/p>\n

This progression follows the same predictable pattern as every successful programming ecosystem. Understanding this pattern helps you see where AI-native development is heading and how to position your work strategically.<\/p>\n

The evolution happens in four stages:<\/p>\n

Raw Code \u2192 agent primitives (.prompt.md, .instructions.md files)<\/p>\n

Runtime environments \u2192 Agent CLI runtimes\u00a0<\/p>\n

Package management \u2192 APM<\/a> (distribution and orchestration layer)<\/p>\n

Thriving ecosystem \u2192 Shared libraries, tools, and community packages<\/p>\n

Just as npm enabled JavaScript\u2019s explosive growth by solving the package distribution problem, APM<\/a> enables the agent primitive ecosystem to flourish by providing the missing infrastructure layer that makes sharing and scaling natural language programs practical.<\/p>\n

The transformation is profound: what started as individual Markdown files in your editor becomes a systematic software development practice with proper tooling, distribution, and production deployment capabilities.<\/p>\n

Key takeaways<\/p>\n

Agent primitives are software: Your .prompt.md and .instructions.md files represent executable natural language programs that deserve professional tooling infrastructure.<\/p>\n

Runtime diversity enables scale: Agent CLI runtimes provide the execution environments that bridge development to production.<\/p>\n

Package management is critical: APM<\/a> provides the npm-equivalent layer that makes agent primitives truly portable and shareable.<\/p>\n

Production ready today: This tooling stack enables automated AI workflows in CI\/CD pipelines with enterprise-grade reliability.<\/p>\n

Ecosystem growth pattern: Package management infrastructure creates the foundation for thriving ecosystems of shared workflows, tools, and community libraries.<\/p>\n

How to get started with building your first agent primitive<\/p>\n

Now it\u2019s time to build your first agent primitives. Here\u2019s the plan:\u00a0<\/p>\n

Start with instructions: Write clear instructions that tell the AI exactly what you want it to do and how it should behave.<\/p>\n

Add chat modes: Set up special rules (chat modes) to create safe boundaries for the AI, making sure it interacts in the way you want and avoids unwanted behavior.<\/p>\n

Build reusable prompts: Create prompt templates for tasks you do often, so you don\u2019t have to start from scratch each time. These templates help the AI handle common jobs quickly and consistently.<\/p>\n

Create specification templates: Make templates that help you plan out what you want your AI to accomplish, then turn those plans into actionable steps the AI can follow.<\/p>\n

Instructions architecture<\/p>\n

Instructions form the bedrock of reliable AI behavior: They\u2019re the rules that guide the agent without cluttering your immediate context. Rather than repeating the same guidance in every conversation, instructions embed your team\u2019s knowledge directly into the AI\u2019s reasoning process.<\/p>\n

The key insight is modularity: instead of one massive instruction file that applies everywhere, you can create targeted files that activate only when working with specific technologies or file types. This context engineering approach keeps your AI focused and your guidance relevant.<\/p>\n

\u2705 Quick actions:<\/p>\n

\ud83d\udd27 Tools and files:<\/a><\/p>\n

.github\/
\n\u251c\u2500\u2500 copilot-instructions.md # Global repository rules
\n\u2514\u2500\u2500 instructions\/
\n \u251c\u2500\u2500 frontend.instructions.md # applyTo: “**\/*.{jsx,tsx,css}”
\n \u251c\u2500\u2500 backend.instructions.md # applyTo: “**\/*.{py,go,java}”
\n \u2514\u2500\u2500 testing.instructions.md # applyTo: “**\/test\/**”<\/p>\n

Example: Markdown prompt engineering in Instructions with frontend.instructions.md<\/a>:<\/p>\n

—
\napplyTo: “**\/*.{ts,tsx}”
\ndescription: “TypeScript development guidelines with context engineering”
\n—
\n# TypeScript Development Guidelines<\/p>\n

## Context Loading
\nReview [project conventions](..\/docs\/conventions.md) and
\n[type definitions](..\/types\/index.ts) before starting.<\/p>\n

## Deterministic Requirements
\n– Use strict TypeScript configuration
\n– Implement error boundaries for React components
\n– Apply ESLint TypeScript rules consistently<\/p>\n

## Structured Output
\nGenerate code with:
\n– [ ] JSDoc comments for all public APIs
\n– [ ] Unit tests in `__tests__\/` directory
\n– [ ] Type exports in appropriate index files<\/p>\n

\u26a0\ufe0f Checkpoint: Instructions are context-efficient and non-conflicting.<\/p>\n

Chat modes configuration<\/p>\n

With your instruction architecture in place, you still need a way to enforce domain boundaries and prevent AI agents from overstepping their expertise. Chat modes solve this by creating professional boundaries similar to real-world licensing. For example, you\u2019d want your architect to plan a bridge and not build it themself.\u00a0<\/p>\n

Here\u2019s how to set those boundaries:\u00a0<\/p>\n

Define domain-specific custom chat modes<\/a> with MCP tool boundaries.<\/p>\n

Encapsulate tech stack knowledge and guidelines per mode.<\/p>\n

Define the most appropriate LLM model<\/a> for your chat mode.<\/p>\n

Configure secure MCP tool access<\/a> to prevent cross-domain security breaches.<\/p>\n

\ud83d\udca1 Security through MCP tool boundaries: Each chat mode receives only the specific MCP tools needed for their domain. Giving each chat mode only the tools it needs keeps your AI workflows safe, organized, and professionally separated\u2014just like real-world roles and permissions.<\/p>\n

\ud83d\udd27 Tools and files:<\/a><\/p>\n

.github\/
\n\u2514\u2500\u2500 chatmodes\/
\n \u251c\u2500\u2500 architect.chatmode.md # Planning specialist – designs, cannot execute
\n \u251c\u2500\u2500 frontend-engineer.chatmode.md # UI specialist – builds interfaces, no backend access
\n \u251c\u2500\u2500 backend-engineer.chatmode.md # API specialist – builds services, no UI modification
\n \u2514\u2500\u2500 technical-writer.chatmode.md # Documentation specialist – writes docs, cannot run code<\/p>\n

Example: Creating MCP tool boundaries with backend-engineer.chatmode.md<\/a>:<\/p>\n

—
\ndescription: ‘Backend development specialist with security focus’
\ntools: [‘changes’, ‘codebase’, ‘editFiles’, ‘runCommands’, ‘runTasks’,
\n ‘search’, ‘problems’, ‘testFailure’, ‘terminalLastCommand’]
\nmodel: Claude Sonnet 4
\n—
\nYou are a backend development specialist focused on secure API development, database design, and server-side architecture. You prioritize security-first design patterns and comprehensive testing strategies.<\/p>\n

## Domain Expertise
\n– RESTful API design and implementation
\n– Database schema design and optimization
\n– Authentication and authorization systems
\n– Server security and performance optimization<\/p>\n

You master the backend of this project thanks to you having read all [the backend docs](..\/..\/docs\/backend).<\/p>\n

## Tool Boundaries
\n– **CAN**: Modify backend code, run server commands, execute tests
\n– **CANNOT**: Modify client-side assets<\/p>\n

You can also create security and professional boundaries<\/a>, including:<\/p>\n

Architect mode: Allow access to research tools only, so they can\u2019t execute destructive commands or modify production code.<\/p>\n

Frontend engineer mode: Allow access to UI development tools only, so they can\u2019t access databases or backend services.<\/p>\n

Backend engineer mode: Allow access to API and database tools only, so they can\u2019t modify user interfaces or frontend assets.<\/p>\n

Technical writer mode: Allow access to documentation tools only, so they can\u2019t run code, deploy, or access sensitive systems.<\/p>\n

\u26a0\ufe0f Checkpoint: Each mode has clear boundaries and tool restrictions.<\/p>\n

Agentic workflows<\/p>\n

Agentic workflows can be implemented as reusable .prompt.md files that orchestrate all your primitives into systematic, repeatable end-to-end processes. These can be executed locally or delegated to independent agents. Here\u2019s how to get started:\u00a0<\/p>\n

Create .prompt.md files<\/a> for complete development processes.<\/p>\n

Build in mandatory human reviews.<\/p>\n

Design workflows for both local execution and independent delegation.<\/p>\n

\ud83d\udd27 Tools and files:<\/a><\/p>\n

.github\/prompts\/
\n\u251c\u2500\u2500 code-review.prompt.md # With validation checkpoints
\n\u251c\u2500\u2500 feature-spec.prompt.md # Spec-first methodology
\n\u2514\u2500\u2500 async-implementation.prompt.md # GitHub Coding Agent delegation<\/p>\n

Example: Complete agentic workflow with feature-spec.prompt.md<\/a>:<\/p>\n

—
\nmode: agent
\nmodel: gpt-4
\ntools: [‘file-search’, ‘semantic-search’, ‘github’]
\ndescription: ‘Feature implementation workflow with validation gates’
\n—
\n# Feature Implementation from Specification<\/p>\n

## Context Loading Phase
\n1. Review [project specification](${specFile})
\n2. Analyze [existing codebase patterns](.\/src\/patterns\/)
\n3. Check [API documentation](.\/docs\/api.md)<\/p>\n

## Deterministic Execution
\nUse semantic search to find similar implementations
\nUse file search to locate test patterns: `**\/*.test.{js,ts}`<\/p>\n

## Structured Output Requirements
\nCreate implementation with:
\n– [ ] Feature code in appropriate module
\n– [ ] Comprehensive unit tests (>90% coverage)
\n– [ ] Integration tests for API endpoints
\n– [ ] Documentation updates<\/p>\n

## Human Validation Gate
\n\ud83d\udea8 **STOP**: Review implementation plan before proceeding to code generation.
\nConfirm: Architecture alignment, test strategy, and breaking change impact.<\/p>\n

\u26a0\ufe0f Checkpoint: As you can see, these prompts include explicit validation gates.<\/p>\n

Specification templates<\/p>\n

There\u2019s often a gap between planning (coming up with what needs to be built) and implementation (actually building it). Without a clear, consistent way to document requirements, things can get lost in translation, leading to mistakes, misunderstandings, or missed steps. This is where specification templates come in. These templates ensure that both people and AI agents can take a concept (like a new feature or API) and reliably implement it.\u00a0<\/p>\n

Here\u2019s what these templates help you accomplish:\u00a0<\/p>\n

Standardize the process: You create a new specification for each feature, API endpoint, or component.<\/p>\n

Provide blueprints for implementation: These specs include everything a developer (or an AI agent) needs to know to start building: the problem, the approach, required components, validation criteria, and a checklist for handoff.<\/p>\n

Make handoff deterministic: By following a standard, the transition from planning to doing is clear and predictable.<\/p>\n

\ud83d\udd27 Tools and files:<\/a>\u00a0<\/p>\n

Spec-kit<\/a> is a neat tool that fully implements a specification-driven approach to agentic coding. It allows you to easily get started with creating specs (spec.md), an implementation plan (plan.md) and splitting that into actual tasks (tasks.md) ready for developers or coding agents to work on.<\/p>\n

\u26a0\ufe0f \ufe0fCheckpoint: Specifications are split into tasks that are implementation-ready before delegation.<\/p>\n

Ready to go? Here\u2019s a quickstart checklist<\/p>\n

You now have a complete foundation for systematic AI development. The checklist below walks through the implementation sequence, building toward creating complete agentic workflows.<\/p>\n

Conceptual foundation<\/a><\/p>\n

Understand Markdown prompt engineering principles (semantic structure, precision, and tools).<\/p>\n

Grasp context engineering fundamentals (context window optimization and session strategy).<\/p>\n

Implementation steps<\/a><\/p>\n

Create .github\/copilot-instructions.md<\/a> with basic project guidelines (context engineering: global rules).<\/p>\n

Set up domain-specific .instructions.md files<\/a> with applyTo patterns (context engineering: selective loading).<\/p>\n

Configure chat modes<\/a> for your tech stack domains (context engineering: domain boundaries).<\/p>\n

Create your first .prompt.md agentic workflow<\/a>.<\/p>\n

Build your first .spec.md template for feature specifications (you can use spec-kit<\/a> for this).<\/p>\n

Practice a spec-driven approach with session splitting: plan<\/a> first, split into tasks<\/a>, and lastly, implement<\/a>.<\/p>\n

Take this with you<\/p>\n

Working with AI agents shouldn\u2019t have to be unpredictable. With the right planning and tools, these agents can quickly become a reliable part of your workflow and processes\u2014boosting not only your own productivity, but your team\u2019s too.\u00a0<\/p>\n

Ready for the next phase of multi-agent coordination delegation? Try GitHub Copilot CLI to get started >\u00a0<\/a><\/p>\n

\t\tWritten by\t<\/p>\n

\t\t\t\t\t\"Daniel<\/p>\n

Daniel Meppiel is a software global black belt at Microsoft where he focuses on helping developers achieve more through AI.<\/p>\n","protected":false},"excerpt":{"rendered":"Many developers begin their AI explorations with a prompt. Perhaps you started the same way: You opened GitHub…\n","protected":false},"author":2,"featured_media":213229,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20],"tags":[256,254,255,64,63,105],"class_list":{"0":"post-213228","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-artificial-intelligence","8":"tag-ai","9":"tag-artificial-intelligence","10":"tag-artificialintelligence","11":"tag-au","12":"tag-australia","13":"tag-technology"},"_links":{"self":[{"href":"https:\/\/www.newsbeep.com\/au\/wp-json\/wp\/v2\/posts\/213228","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.newsbeep.com\/au\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.newsbeep.com\/au\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/au\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/au\/wp-json\/wp\/v2\/comments?post=213228"}],"version-history":[{"count":0,"href":"https:\/\/www.newsbeep.com\/au\/wp-json\/wp\/v2\/posts\/213228\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/au\/wp-json\/wp\/v2\/media\/213229"}],"wp:attachment":[{"href":"https:\/\/www.newsbeep.com\/au\/wp-json\/wp\/v2\/media?parent=213228"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.newsbeep.com\/au\/wp-json\/wp\/v2\/categories?post=213228"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.newsbeep.com\/au\/wp-json\/wp\/v2\/tags?post=213228"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}