mirror of
https://github.com/github/awesome-copilot.git
synced 2026-02-20 10:25:13 +00:00
feat: migrate learning-hub articles into Astro website
- Add Astro Content Collection for learning-hub articles - Move 5 fundamentals articles into website/src/content/learning-hub/ - Create ArticleLayout.astro for rendering markdown articles - Create index page listing all articles in recommended reading order - Create dynamic [slug].astro route for individual articles - Add Learning Hub to main navigation and homepage cards - Add article prose and index page CSS styles - Update internal links to use website URLs
This commit is contained in:
Aaron Powell
@@ -1593,3 +1593,224 @@ a:hover {
|
||||
background-color: rgba(210, 153, 34, 0.2);
|
||||
color: var(--color-warning);
|
||||
}
|
||||
|
||||
/* Learning Hub - Article Styles */
|
||||
.breadcrumb {
|
||||
margin-bottom: 16px;
|
||||
}
|
||||
|
||||
.breadcrumb a {
|
||||
color: var(--color-link);
|
||||
text-decoration: none;
|
||||
font-size: 14px;
|
||||
}
|
||||
|
||||
.breadcrumb a:hover {
|
||||
color: var(--color-link-hover);
|
||||
text-decoration: underline;
|
||||
}
|
||||
|
||||
.article-meta {
|
||||
display: flex;
|
||||
gap: 16px;
|
||||
margin-top: 12px;
|
||||
flex-wrap: wrap;
|
||||
}
|
||||
|
||||
.meta-item {
|
||||
font-size: 14px;
|
||||
color: var(--color-text-muted);
|
||||
}
|
||||
|
||||
.article-tags {
|
||||
display: flex;
|
||||
gap: 8px;
|
||||
margin-top: 12px;
|
||||
flex-wrap: wrap;
|
||||
}
|
||||
|
||||
.tag {
|
||||
font-size: 12px;
|
||||
padding: 4px 10px;
|
||||
border-radius: 12px;
|
||||
background-color: var(--color-glass);
|
||||
border: 1px solid var(--color-glass-border);
|
||||
color: var(--color-text-muted);
|
||||
}
|
||||
|
||||
/* Article prose content */
|
||||
.article-content {
|
||||
max-width: 780px;
|
||||
line-height: 1.75;
|
||||
font-size: 16px;
|
||||
color: var(--color-text);
|
||||
}
|
||||
|
||||
.article-content h2 {
|
||||
font-size: 24px;
|
||||
font-weight: 700;
|
||||
margin-top: 48px;
|
||||
margin-bottom: 16px;
|
||||
color: var(--color-text-emphasis);
|
||||
border-bottom: 1px solid var(--color-border);
|
||||
padding-bottom: 8px;
|
||||
}
|
||||
|
||||
.article-content h3 {
|
||||
font-size: 20px;
|
||||
font-weight: 600;
|
||||
margin-top: 32px;
|
||||
margin-bottom: 12px;
|
||||
color: var(--color-text-emphasis);
|
||||
}
|
||||
|
||||
.article-content h4 {
|
||||
font-size: 16px;
|
||||
font-weight: 600;
|
||||
margin-top: 24px;
|
||||
margin-bottom: 8px;
|
||||
color: var(--color-text-emphasis);
|
||||
}
|
||||
|
||||
.article-content p {
|
||||
margin-bottom: 16px;
|
||||
}
|
||||
|
||||
.article-content a {
|
||||
color: var(--color-link);
|
||||
text-decoration: none;
|
||||
}
|
||||
|
||||
.article-content a:hover {
|
||||
color: var(--color-link-hover);
|
||||
text-decoration: underline;
|
||||
}
|
||||
|
||||
.article-content ul,
|
||||
.article-content ol {
|
||||
margin-bottom: 16px;
|
||||
padding-left: 24px;
|
||||
}
|
||||
|
||||
.article-content li {
|
||||
margin-bottom: 6px;
|
||||
}
|
||||
|
||||
.article-content code {
|
||||
font-size: 14px;
|
||||
padding: 2px 6px;
|
||||
border-radius: 4px;
|
||||
background-color: var(--color-bg-tertiary);
|
||||
border: 1px solid var(--color-border);
|
||||
font-family: 'Monaspace Argon NF', monospace;
|
||||
}
|
||||
|
||||
.article-content pre {
|
||||
margin-bottom: 16px;
|
||||
padding: 16px;
|
||||
border-radius: 8px;
|
||||
background-color: var(--color-bg-secondary);
|
||||
border: 1px solid var(--color-border);
|
||||
overflow-x: auto;
|
||||
}
|
||||
|
||||
.article-content pre code {
|
||||
padding: 0;
|
||||
border: none;
|
||||
background: none;
|
||||
font-size: 14px;
|
||||
line-height: 1.6;
|
||||
}
|
||||
|
||||
.article-content blockquote {
|
||||
margin: 16px 0;
|
||||
padding: 12px 20px;
|
||||
border-left: 4px solid var(--color-accent);
|
||||
background-color: var(--color-glass);
|
||||
border-radius: 0 8px 8px 0;
|
||||
color: var(--color-text-muted);
|
||||
}
|
||||
|
||||
.article-content blockquote p {
|
||||
margin-bottom: 0;
|
||||
}
|
||||
|
||||
.article-content hr {
|
||||
margin: 32px 0;
|
||||
border: none;
|
||||
border-top: 1px solid var(--color-border);
|
||||
}
|
||||
|
||||
.article-content strong {
|
||||
color: var(--color-text-emphasis);
|
||||
}
|
||||
|
||||
/* Learning Hub - Index Page */
|
||||
.learning-hub-section h2 {
|
||||
font-size: 24px;
|
||||
font-weight: 700;
|
||||
margin-bottom: 8px;
|
||||
color: var(--color-text-emphasis);
|
||||
}
|
||||
|
||||
.section-description {
|
||||
font-size: 16px;
|
||||
color: var(--color-text-muted);
|
||||
margin-bottom: 24px;
|
||||
}
|
||||
|
||||
.article-list {
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: 16px;
|
||||
}
|
||||
|
||||
.article-card {
|
||||
display: flex;
|
||||
gap: 20px;
|
||||
padding: 20px;
|
||||
border-radius: 12px;
|
||||
background-color: var(--color-card-bg);
|
||||
border: 1px solid var(--color-glass-border);
|
||||
text-decoration: none;
|
||||
color: var(--color-text);
|
||||
transition: background-color 0.2s, border-color 0.2s;
|
||||
}
|
||||
|
||||
.article-card:hover {
|
||||
background-color: var(--color-card-hover);
|
||||
border-color: var(--color-accent);
|
||||
}
|
||||
|
||||
.article-number {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
width: 40px;
|
||||
height: 40px;
|
||||
border-radius: 50%;
|
||||
background: var(--gradient-accent);
|
||||
color: #fff;
|
||||
font-weight: 700;
|
||||
font-size: 16px;
|
||||
flex-shrink: 0;
|
||||
}
|
||||
|
||||
.article-info {
|
||||
flex: 1;
|
||||
min-width: 0;
|
||||
}
|
||||
|
||||
.article-info h3 {
|
||||
font-size: 18px;
|
||||
font-weight: 600;
|
||||
margin-bottom: 6px;
|
||||
color: var(--color-text-emphasis);
|
||||
}
|
||||
|
||||
.article-info p {
|
||||
font-size: 14px;
|
||||
color: var(--color-text-muted);
|
||||
margin-bottom: 8px;
|
||||
line-height: 1.5;
|
||||
}
|
||||
|
||||
20
website/src/content.config.ts
Normal file
20
website/src/content.config.ts
Normal file
@@ -0,0 +1,20 @@
|
||||
import { defineCollection, z } from "astro:content";
|
||||
import { glob } from "astro/loaders";
|
||||
|
||||
const learningHub = defineCollection({
|
||||
loader: glob({ pattern: "**/*.md", base: "./src/content/learning-hub" }),
|
||||
schema: z.object({
|
||||
title: z.string(),
|
||||
description: z.string(),
|
||||
authors: z.array(z.string()).optional(),
|
||||
lastUpdated: z.string().optional(),
|
||||
estimatedReadingTime: z.string().optional(),
|
||||
tags: z.array(z.string()).optional(),
|
||||
relatedArticles: z.array(z.string()).optional(),
|
||||
prerequisites: z.array(z.string()).optional(),
|
||||
}),
|
||||
});
|
||||
|
||||
export const collections = {
|
||||
"learning-hub": learningHub,
|
||||
};
|
||||
375
website/src/content/learning-hub/copilot-configuration-basics.md
Normal file
375
website/src/content/learning-hub/copilot-configuration-basics.md
Normal file
@@ -0,0 +1,375 @@
|
||||
---
|
||||
title: 'Copilot Configuration Basics'
|
||||
description: 'Learn how to configure GitHub Copilot at user, workspace, and repository levels to optimize your AI-assisted development experience.'
|
||||
authors:
|
||||
- GitHub Copilot Learning Hub Team
|
||||
lastUpdated: '2025-11-28'
|
||||
estimatedReadingTime: '10 minutes'
|
||||
tags:
|
||||
- configuration
|
||||
- setup
|
||||
- fundamentals
|
||||
relatedArticles:
|
||||
- ./what-are-agents-prompts-instructions.md
|
||||
- ./understanding-copilot-context.md
|
||||
prerequisites:
|
||||
- Basic familiarity with GitHub Copilot
|
||||
---
|
||||
|
||||
GitHub Copilot offers extensive configuration options that let you tailor its behavior to your personal preferences, project requirements, and team standards. Understanding these configuration layers helps you maximize productivity while maintaining consistency across teams. This article explains the configuration hierarchy, key settings, and how to set up repository-level customizations that benefit your entire team.
|
||||
|
||||
## Configuration Levels
|
||||
|
||||
GitHub Copilot uses a hierarchical configuration system where settings at different levels can override each other. Understanding this hierarchy helps you apply the right configuration at the right level.
|
||||
|
||||
### User Settings
|
||||
|
||||
User settings apply globally across all your projects and represent your personal preferences. These are stored in your IDE's user configuration and travel with your IDE profile.
|
||||
|
||||
**Common user-level settings**:
|
||||
- Enable/disable inline suggestions globally
|
||||
- Commit message style preferences
|
||||
- Default language preferences
|
||||
|
||||
**When to use**: For personal preferences that should apply everywhere you work, like keyboard shortcuts or whether you prefer inline suggestions vs chat.
|
||||
|
||||
### Repository Settings
|
||||
|
||||
Repository settings live in your codebase (typically in `.github/` although some editors allow customising the paths that Copilot will use) and are shared with everyone working on the project. These provide the highest level of customization and override both user and workspace settings.
|
||||
|
||||
**Common repository-level customizations**:
|
||||
- Custom instructions for coding conventions
|
||||
- Reusable prompts for common tasks
|
||||
- Specialized agents for project workflows
|
||||
- Custom agents for domain expertise
|
||||
|
||||
**When to use**: For repository-wide standards, project-specific best practices, and reusable customizations that should be version-controlled and shared.
|
||||
|
||||
### Organisation Settings (GitHub.com only)
|
||||
|
||||
Organisation settings allow administrators to enforce Copilot policies across all repositories within an organization. These settings can include defining custom agents, creating globally applied instructions, enabling or disabling Copilot, managing billing, and setting usage limits. These policies may not be enforced in the IDE, depending on the IDE's support for organization-level settings, but will apply to Copilot usage on GitHub.com.
|
||||
|
||||
**When to use**: For enforcing organization-wide policies, ensuring compliance, and providing shared resources across multiple repositories.
|
||||
|
||||
### Configuration Precedence
|
||||
|
||||
When multiple configuration levels define the same setting, GitHub Copilot applies them in this order (highest precedence first):
|
||||
|
||||
1. **Organisation settings** (if applicable)
|
||||
1. **Repository settings** (`.github/`)
|
||||
1. **User settings** (IDE global preferences)
|
||||
|
||||
**Example**: If your user settings disable Copilot for `.test.ts` files, but repository settings enable custom instructions for test files, the repository settings take precedence and Copilot remains active with the custom instructions applied.
|
||||
|
||||
## Key Configuration Options
|
||||
|
||||
These settings control GitHub Copilot's core behavior across all IDEs:
|
||||
|
||||
### Inline Suggestions
|
||||
|
||||
Control whether Copilot automatically suggests code completions as you type.
|
||||
|
||||
**VS Code example**:
|
||||
```json
|
||||
{
|
||||
"github.copilot.enable": {
|
||||
"*": true,
|
||||
"plaintext": false,
|
||||
"markdown": false
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Why it matters**: Some developers prefer to invoke Copilot explicitly rather than seeing automatic suggestions. You can also enable it only for specific languages.
|
||||
|
||||
### Chat Availability
|
||||
|
||||
Control access to GitHub Copilot Chat in your IDE.
|
||||
|
||||
**VS Code example**:
|
||||
```json
|
||||
{
|
||||
"github.copilot.chat.enabled": true
|
||||
}
|
||||
```
|
||||
|
||||
**Why it matters**: Chat provides a conversational interface for asking questions and getting explanations, complementing inline suggestions.
|
||||
|
||||
### Suggestion Trigger Behavior
|
||||
|
||||
Configure how and when Copilot generates suggestions.
|
||||
|
||||
**VS Code example**:
|
||||
```json
|
||||
{
|
||||
"editor.inlineSuggest.enabled": true,
|
||||
"github.copilot.editor.enableAutoCompletions": true
|
||||
}
|
||||
```
|
||||
|
||||
**Why it matters**: Control whether suggestions appear automatically or only when explicitly requested, balancing helpfulness with potential distraction.
|
||||
|
||||
### Language-Specific Settings
|
||||
|
||||
Enable or disable Copilot for specific programming languages.
|
||||
|
||||
**VS Code example**:
|
||||
```json
|
||||
{
|
||||
"github.copilot.enable": {
|
||||
"typescript": true,
|
||||
"javascript": true,
|
||||
"python": true,
|
||||
"markdown": false
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Why it matters**: You may want Copilot active for code files but not for documentation or configuration files.
|
||||
|
||||
### Excluded Files and Directories
|
||||
|
||||
Prevent Copilot from accessing specific files or directories.
|
||||
|
||||
**VS Code example**:
|
||||
```json
|
||||
{
|
||||
"github.copilot.advanced": {
|
||||
"debug.filterLogCategories": [],
|
||||
"excludedFiles": [
|
||||
"**/secrets/**",
|
||||
"**/*.env",
|
||||
"**/node_modules/**"
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Why it matters**: Exclude sensitive files, generated code, or dependencies from Copilot's context to improve suggestion relevance and protect confidential information.
|
||||
|
||||
## Repository-Level Configuration
|
||||
|
||||
The `.github/` directory in your repository enables team-wide customizations that are version-controlled and shared across all contributors.
|
||||
|
||||
### Directory Structure
|
||||
|
||||
A well-organized Copilot configuration directory looks like this:
|
||||
|
||||
```
|
||||
.github/
|
||||
├── agents/
|
||||
│ ├── terraform-expert.agent.md
|
||||
│ └── api-reviewer.agent.md
|
||||
├── prompts/
|
||||
│ ├── generate-test.prompt.md
|
||||
│ └── refactor-component.prompt.md
|
||||
└── instructions/
|
||||
├── typescript-conventions.instructions.md
|
||||
└── api-design.instructions.md
|
||||
```
|
||||
|
||||
### Custom Agents
|
||||
|
||||
Agents are specialized assistants for specific workflows. Place agent definition files in `.github/agents/`.
|
||||
|
||||
**Example agent** (`terraform-expert.agent.md`):
|
||||
```markdown
|
||||
---
|
||||
description: 'Terraform infrastructure-as-code specialist'
|
||||
tools: ['filesystem', 'terminal']
|
||||
name: 'Terraform Expert'
|
||||
---
|
||||
|
||||
You are an expert in Terraform and cloud infrastructure.
|
||||
Guide users through creating, reviewing, and deploying infrastructure code.
|
||||
```
|
||||
|
||||
**When to use**: Create agents for domain-specific tasks like infrastructure management, API design, or security reviews.
|
||||
|
||||
### Reusable Prompts
|
||||
|
||||
Prompts are reusable templates for common tasks. Store them in `.github/prompts/`.
|
||||
|
||||
**Example prompt** (`generate-test.prompt.md`):
|
||||
```markdown
|
||||
---
|
||||
mode: 'agent'
|
||||
description: 'Generate comprehensive unit tests for a component'
|
||||
---
|
||||
|
||||
Generate unit tests for the selected code that:
|
||||
- Cover all public methods and edge cases
|
||||
- Use our testing conventions from @testing-utils.ts
|
||||
- Include descriptive test names
|
||||
```
|
||||
|
||||
**When to use**: For repetitive tasks your team performs regularly, like generating tests, creating documentation, or refactoring patterns.
|
||||
|
||||
### Instructions Files
|
||||
|
||||
Instructions provide persistent context that applies automatically when working in specific files or directories. Store them in `.github/instructions/`.
|
||||
|
||||
**Example instruction** (`typescript-conventions.instructions.md`):
|
||||
```markdown
|
||||
---
|
||||
description: 'TypeScript coding conventions for this project'
|
||||
applyTo: '**.ts, **.tsx'
|
||||
---
|
||||
|
||||
When writing TypeScript code:
|
||||
- Use strict type checking
|
||||
- Prefer interfaces over type aliases for object types
|
||||
- Always handle null/undefined with optional chaining
|
||||
- Use async/await instead of raw promises
|
||||
```
|
||||
|
||||
**When to use**: For project-wide coding standards, architectural patterns, or technology-specific conventions that should influence all suggestions.
|
||||
|
||||
## Setting Up Team Configuration
|
||||
|
||||
Follow these steps to establish effective team-wide Copilot configuration:
|
||||
|
||||
### 1. Create the Configuration Structure
|
||||
|
||||
Start by creating the `.github/` directory in your repository root:
|
||||
|
||||
```bash
|
||||
mkdir -p .github/{agents,prompts,instructions}
|
||||
```
|
||||
|
||||
### 2. Document Your Conventions
|
||||
|
||||
Create instructions that capture your team's coding standards:
|
||||
|
||||
```markdown
|
||||
<!-- .github/instructions/team-conventions.instructions.md -->
|
||||
---
|
||||
description: 'Team coding conventions and best practices'
|
||||
applyTo: '**'
|
||||
---
|
||||
|
||||
Our team follows these practices:
|
||||
- Write self-documenting code with clear names
|
||||
- Add comments only for complex logic
|
||||
- Prefer composition over inheritance
|
||||
- Keep functions small and focused
|
||||
```
|
||||
|
||||
### 3. Build Reusable Prompts
|
||||
|
||||
Identify repetitive tasks and create prompts for them:
|
||||
|
||||
```markdown
|
||||
<!-- .github/prompts/add-error-handling.prompt.md -->
|
||||
---
|
||||
mode: 'agent'
|
||||
description: 'Add comprehensive error handling to existing code'
|
||||
---
|
||||
|
||||
Add error handling to the selected code:
|
||||
- Catch and handle potential errors
|
||||
- Log errors with context
|
||||
- Provide meaningful error messages
|
||||
- Follow our error handling patterns from @error-utils.ts
|
||||
```
|
||||
|
||||
### 4. Version Control Best Practices
|
||||
|
||||
- **Commit all `.github/` files** to your repository
|
||||
- **Use descriptive commit messages** when adding or updating customizations
|
||||
- **Review changes** to ensure they align with team standards
|
||||
- **Document** each customization with clear descriptions and examples
|
||||
|
||||
### 5. Onboard New Team Members
|
||||
|
||||
Make Copilot configuration part of your onboarding process:
|
||||
|
||||
1. Point new members to your `.github/` directory
|
||||
2. Explain which agents and prompts exist and when to use them
|
||||
3. Encourage exploration and contributions
|
||||
4. Include example usage in your project README
|
||||
|
||||
## IDE-Specific Configuration
|
||||
|
||||
While repository-level customizations work across all IDEs, you may also need IDE-specific settings:
|
||||
|
||||
### VS Code
|
||||
|
||||
Settings file: `.vscode/settings.json` or global user settings
|
||||
|
||||
```json
|
||||
{
|
||||
"github.copilot.enable": {
|
||||
"*": true
|
||||
},
|
||||
"github.copilot.chat.enabled": true,
|
||||
"editor.inlineSuggest.enabled": true
|
||||
}
|
||||
```
|
||||
|
||||
### Visual Studio
|
||||
|
||||
Settings: Tools → Options → GitHub Copilot
|
||||
|
||||
- Configure inline suggestions
|
||||
- Set keyboard shortcuts
|
||||
- Manage language-specific enablement
|
||||
|
||||
### JetBrains IDEs
|
||||
|
||||
Settings: File → Settings → Tools → GitHub Copilot
|
||||
|
||||
- Enable/disable for specific file types
|
||||
- Configure suggestion behavior
|
||||
- Customize keyboard shortcuts
|
||||
|
||||
### GitHub Copilot CLI
|
||||
|
||||
Configuration file: `~/.copilot-cli/config.json`
|
||||
|
||||
```json
|
||||
{
|
||||
"editor": "vim",
|
||||
"suggestions": true
|
||||
}
|
||||
```
|
||||
|
||||
## Common Questions
|
||||
|
||||
**Q: How do I disable Copilot for specific files?**
|
||||
|
||||
A: Use the `excludedFiles` setting in your IDE configuration or create a workspace setting that disables Copilot for specific patterns:
|
||||
|
||||
```json
|
||||
{
|
||||
"github.copilot.advanced": {
|
||||
"excludedFiles": [
|
||||
"**/secrets/**",
|
||||
"**/*.env",
|
||||
"**/test/fixtures/**"
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Q: Can I have different settings per project?**
|
||||
|
||||
A: Yes! Use workspace settings (`.vscode/settings.json`) for project-specific preferences that don't need to be shared, or use repository settings (`.github/copilot/`) for team-wide customizations that should be version-controlled.
|
||||
|
||||
**Q: How do team settings override personal settings?**
|
||||
|
||||
A: Repository settings in `.github/copilot/` have the highest precedence, followed by workspace settings, then user settings. This means team-defined instructions and agents will apply even if your personal settings differ, ensuring consistency across the team.
|
||||
|
||||
**Q: Where should I put customizations that apply to all my projects?**
|
||||
|
||||
A: Use user-level settings in your IDE for personal preferences that should apply everywhere. For customizations specific to a technology or framework (like React conventions), consider creating a collection in the awesome-copilot-hub repository that you can reference across multiple projects.
|
||||
|
||||
## Next Steps
|
||||
|
||||
Now that you understand Copilot configuration, explore how to create powerful customizations:
|
||||
|
||||
- **[What are Agents, Prompts, and Instructions](../learning-hub/what-are-agents-prompts-instructions/)** - Understand the customization types you can configure
|
||||
- **[Understanding Copilot Context](../learning-hub/understanding-copilot-context/)** - Learn how configuration affects context usage
|
||||
- **[Defining Custom Instructions](../learning-hub/defining-custom-instructions/)** - Create persistent context for your projects
|
||||
- **[Creating Effective Prompts](../learning-hub/creating-effective-prompts/)** - Build reusable task templates
|
||||
- **Building Custom Agents** _(coming soon)_ - Develop specialized assistants
|
||||
425
website/src/content/learning-hub/creating-effective-prompts.md
Normal file
425
website/src/content/learning-hub/creating-effective-prompts.md
Normal file
@@ -0,0 +1,425 @@
|
||||
---
|
||||
title: 'Creating Effective Prompts'
|
||||
description: 'Master the art of writing reusable, shareable prompt templates that deliver consistent results across your team.'
|
||||
authors:
|
||||
- GitHub Copilot Learning Hub Team
|
||||
lastUpdated: '2025-12-02'
|
||||
estimatedReadingTime: '9 minutes'
|
||||
tags:
|
||||
- prompts
|
||||
- customization
|
||||
- fundamentals
|
||||
relatedArticles:
|
||||
- ./what-are-agents-prompts-instructions.md
|
||||
- ./defining-custom-instructions.md
|
||||
- ./building-custom-agents.md
|
||||
prerequisites:
|
||||
- Basic understanding of GitHub Copilot chat
|
||||
---
|
||||
|
||||
Prompts are reusable templates that package specific tasks into shareable chat commands. They enable teams to standardize common workflows tasks like generating tests, reviewing code, or creating documentation, ensuring consistent, high-quality results across all team members.
|
||||
|
||||
This article shows you how to design, structure, and optimize prompts that solve real development challenges.
|
||||
|
||||
## What Are Prompts?
|
||||
|
||||
Prompts (`*.prompt.md`) are markdown files that define:
|
||||
|
||||
- **Command name**: How users invoke the prompt (e.g., `/code-review`)
|
||||
- **Task description**: What the prompt accomplishes
|
||||
- **Execution mode**: Whether it acts as an agent or simple ask
|
||||
- **Tool requirements**: Which Copilot capabilities it needs (codebase search, terminal, etc.)
|
||||
- **Message template**: The actual instructions Copilot executes
|
||||
|
||||
**Key Points**:
|
||||
- Prompts require explicit invocation (unlike instructions which apply automatically)
|
||||
- They capture proven workflows as reusable templates
|
||||
- They can accept user input variables for customization
|
||||
- They work across different codebases without modification
|
||||
|
||||
### How Prompts Differ from Other Customizations
|
||||
|
||||
**Prompts vs Instructions**:
|
||||
- Prompts are invoked explicitly; instructions apply automatically
|
||||
- Prompts drive specific tasks; instructions provide ongoing context
|
||||
- Use prompts for workflows you trigger on demand; use instructions for standards that always apply
|
||||
|
||||
**Prompts vs Agents**:
|
||||
- Prompts are task-focused templates; agents are specialized personas
|
||||
- Prompts work with standard Copilot tools; agents may require MCP servers or custom integrations
|
||||
- Use prompts for repeatable tasks; use agents for complex multi-step workflows
|
||||
|
||||
## Anatomy of a Prompt
|
||||
|
||||
Every effective prompt has three parts: frontmatter configuration, task description, and execution instructions.
|
||||
|
||||
**Example - Simple Prompt**:
|
||||
|
||||
```markdown
|
||||
---
|
||||
description: 'Generate unit tests for the selected code'
|
||||
tools: ['codebase']
|
||||
---
|
||||
|
||||
Generate comprehensive unit tests for the selected code.
|
||||
|
||||
Requirements:
|
||||
- Cover happy path, edge cases, and error conditions
|
||||
- Use the testing framework already present in the codebase
|
||||
- Follow existing test file naming conventions
|
||||
- Include descriptive test names explaining what is being tested
|
||||
- Add assertions for all expected behaviors
|
||||
```
|
||||
|
||||
**Why This Works**:
|
||||
- Clear description tells users what the prompt does
|
||||
- `tools` array specifies codebase access is needed
|
||||
- Requirements provide specific, actionable guidance
|
||||
- Template is generic enough to work across different projects
|
||||
|
||||
## Frontmatter Configuration
|
||||
|
||||
The YAML frontmatter controls how Copilot executes your prompt.
|
||||
|
||||
### Essential Fields
|
||||
|
||||
**agent**: Execution mode for the prompt
|
||||
```yaml
|
||||
agent: 'agent' # Full agent capabilities with tools
|
||||
# OR
|
||||
agent: 'ask' # Simple question/answer without tool execution
|
||||
# OR
|
||||
agent: 'My Custom Agent' # Use a specific custom agent
|
||||
```
|
||||
|
||||
**description**: Brief summary of what the prompt does
|
||||
```yaml
|
||||
description: 'Generate conventional commit messages from staged changes'
|
||||
```
|
||||
|
||||
**tools**: Array of capabilities the prompt needs
|
||||
```yaml
|
||||
tools: ['codebase', 'runCommands', 'edit']
|
||||
```
|
||||
|
||||
**model**: Preferred AI model (optional but recommended)
|
||||
```yaml
|
||||
model: Claude Sonnet 4
|
||||
```
|
||||
|
||||
### Common Tool Combinations
|
||||
|
||||
**Code Generation**:
|
||||
```yaml
|
||||
tools: ['codebase', 'edit', 'search']
|
||||
```
|
||||
|
||||
**Testing**:
|
||||
```yaml
|
||||
tools: ['codebase', 'runCommands', 'testFailure']
|
||||
```
|
||||
|
||||
**Git Operations**:
|
||||
```yaml
|
||||
tools: ['runCommands/runInTerminal', 'changes']
|
||||
```
|
||||
|
||||
**Documentation**:
|
||||
```yaml
|
||||
tools: ['codebase', 'search', 'edit', 'fetch']
|
||||
```
|
||||
|
||||
**Code Review**:
|
||||
```yaml
|
||||
tools: ['changes', 'codebase', 'problems', 'search']
|
||||
```
|
||||
|
||||
## Real Examples from the Repository
|
||||
|
||||
The awesome-copilot-hub repository includes over 110 prompt files demonstrating production patterns.
|
||||
|
||||
### Conventional Commits
|
||||
|
||||
See [conventional-commit.prompt.md](https://github.com/github/awesome-copilot/blob/main/prompts/conventional-commit.prompt.md) for automating commit messages:
|
||||
|
||||
```markdown
|
||||
---
|
||||
description: 'Generate conventional commit messages from staged changes'
|
||||
tools: ['runCommands/runInTerminal', 'runCommands/getTerminalOutput']
|
||||
---
|
||||
|
||||
### Workflow
|
||||
|
||||
Follow these steps:
|
||||
|
||||
1. Run `git status` to review changed files
|
||||
2. Run `git diff --cached` to inspect changes
|
||||
3. Construct commit message using Conventional Commits format
|
||||
4. Execute commit command automatically
|
||||
|
||||
### Commit Message Structure
|
||||
|
||||
<type>(scope): description
|
||||
|
||||
Types: feat|fix|docs|style|refactor|perf|test|build|ci|chore
|
||||
|
||||
### Examples
|
||||
|
||||
- feat(parser): add ability to parse arrays
|
||||
- fix(ui): correct button alignment
|
||||
- docs: update README with usage instructions
|
||||
```
|
||||
|
||||
This prompt automates a repetitive task (writing commit messages) with a proven template.
|
||||
|
||||
### Specification Creation
|
||||
|
||||
See [create-specification.prompt.md](https://github.com/github/awesome-copilot/blob/main/prompts/create-specification.prompt.md) for structured documentation:
|
||||
|
||||
```markdown
|
||||
---
|
||||
mode: 'agent'
|
||||
description: 'Create a new specification file optimized for AI consumption'
|
||||
tools: ['codebase', 'search', 'edit', 'fetch']
|
||||
---
|
||||
|
||||
Your goal is to create a specification file for ${input:SpecPurpose}.
|
||||
|
||||
The specification must:
|
||||
- Use precise, unambiguous language
|
||||
- Follow structured formatting for easy parsing
|
||||
- Define all acronyms and domain terms
|
||||
- Include examples and edge cases
|
||||
- Be self-contained without external dependencies
|
||||
|
||||
Save in /spec/ directory as: spec-[purpose].md
|
||||
```
|
||||
|
||||
This prompt uses a variable (`${input:SpecPurpose}`) to customize each invocation.
|
||||
|
||||
### Code Review Automation
|
||||
|
||||
See [review-and-refactor.prompt.md](https://github.com/github/awesome-copilot/blob/main/prompts/review-and-refactor.prompt.md) for systematic code analysis:
|
||||
|
||||
```markdown
|
||||
---
|
||||
mode: 'agent'
|
||||
description: 'Comprehensive code review and refactoring suggestions'
|
||||
tools: ['changes', 'codebase', 'problems', 'search']
|
||||
model: Claude Sonnet 4
|
||||
---
|
||||
|
||||
Review the current changes or selected code for:
|
||||
|
||||
1. **Code Quality**: Readability, maintainability, complexity
|
||||
2. **Best Practices**: Language idioms, framework patterns
|
||||
3. **Performance**: Algorithm efficiency, resource usage
|
||||
4. **Security**: Input validation, authentication, sensitive data
|
||||
5. **Testing**: Test coverage, edge cases, error handling
|
||||
|
||||
Provide specific refactoring suggestions with code examples.
|
||||
```
|
||||
|
||||
This prompt combines multiple analysis dimensions into a single repeatable workflow.
|
||||
|
||||
## Writing Effective Prompt Templates
|
||||
|
||||
### Structure Your Prompts
|
||||
|
||||
**1. Start with clear objectives**:
|
||||
```markdown
|
||||
Your goal is to [specific task] for [specific target].
|
||||
```
|
||||
|
||||
**2. Define requirements explicitly**:
|
||||
```markdown
|
||||
Requirements:
|
||||
- Must follow [standard/pattern]
|
||||
- Should include [specific element]
|
||||
- Avoid [anti-pattern]
|
||||
```
|
||||
|
||||
**3. Provide examples**:
|
||||
```markdown
|
||||
### Good Example
|
||||
[Show desired output]
|
||||
|
||||
### What to Avoid
|
||||
[Show problematic patterns]
|
||||
```
|
||||
|
||||
**4. Specify output format**:
|
||||
```markdown
|
||||
Output format:
|
||||
- File location: [path pattern]
|
||||
- Naming convention: [format]
|
||||
- Structure: [expected sections]
|
||||
```
|
||||
|
||||
### Use Variables for Customization
|
||||
|
||||
Prompts can accept user input through variables:
|
||||
|
||||
**Simple variable**:
|
||||
```markdown
|
||||
Generate a ${input:ComponentType} component named ${input:ComponentName}.
|
||||
```
|
||||
|
||||
**Variable with context**:
|
||||
```markdown
|
||||
Create tests for ${selection} using the ${input:TestFramework} framework.
|
||||
```
|
||||
|
||||
**Referencing files**:
|
||||
```markdown
|
||||
Update the documentation in ${file:README.md} based on changes in ${selection}.
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
- **One purpose per prompt**: Focus on a single task or workflow
|
||||
- **Make it generic**: Write prompts that work across different projects
|
||||
- **Be explicit**: Avoid ambiguous language; specify exact requirements
|
||||
- **Include context**: Reference patterns, standards, or examples from the codebase
|
||||
- **Name descriptively**: Use clear, action-oriented names: `generate-tests.prompt.md`, not `helper.prompt.md`
|
||||
- **Test thoroughly**: Verify prompts work with different inputs and codebases
|
||||
- **Document tools needed**: Specify all required Copilot capabilities
|
||||
- **Version your prompts**: Update lastUpdated when making changes
|
||||
|
||||
### Writing Style Guidelines
|
||||
|
||||
**Use imperative mood**:
|
||||
- ✅ "Generate unit tests for the selected function"
|
||||
- ❌ "You should generate some tests"
|
||||
|
||||
**Be specific about requirements**:
|
||||
- ✅ "Use Jest with React Testing Library"
|
||||
- ❌ "Use whatever testing framework"
|
||||
|
||||
**Provide guardrails**:
|
||||
- ✅ "Do not modify existing test files; create new ones"
|
||||
- ❌ "Update tests as needed"
|
||||
|
||||
**Structure complex prompts**:
|
||||
```markdown
|
||||
## Step 1: Analysis
|
||||
[Analyze requirements]
|
||||
|
||||
## Step 2: Generation
|
||||
[Generate code]
|
||||
|
||||
## Step 3: Validation
|
||||
[Check output]
|
||||
```
|
||||
|
||||
## Common Patterns
|
||||
|
||||
### Agent Mode with Multi-Step Workflow
|
||||
|
||||
```markdown
|
||||
---
|
||||
mode: 'agent'
|
||||
description: 'Scaffold new feature with tests and documentation'
|
||||
tools: ['codebase', 'edit', 'search']
|
||||
---
|
||||
|
||||
Create a complete feature implementation:
|
||||
|
||||
1. **Analyze**: Review existing patterns in codebase
|
||||
2. **Generate**: Create implementation files following project structure
|
||||
3. **Test**: Generate comprehensive test coverage
|
||||
4. **Document**: Add inline comments and update relevant docs
|
||||
5. **Validate**: Check for common issues and anti-patterns
|
||||
|
||||
Use the existing code style and conventions found in the codebase.
|
||||
```
|
||||
|
||||
### Ask Mode for Quick Questions
|
||||
|
||||
```markdown
|
||||
---
|
||||
mode: 'ask'
|
||||
description: 'Explain code architecture and design patterns'
|
||||
---
|
||||
|
||||
Analyze the selected code and explain:
|
||||
|
||||
1. Overall architecture and design patterns used
|
||||
2. Key components and their responsibilities
|
||||
3. Data flow and dependencies
|
||||
4. Potential improvements or concerns
|
||||
|
||||
Keep explanations concise and developer-focused.
|
||||
```
|
||||
|
||||
### Terminal Automation
|
||||
|
||||
```markdown
|
||||
---
|
||||
description: 'Run test suite and report failures'
|
||||
tools: ['runCommands/runInTerminal', 'testFailure']
|
||||
---
|
||||
|
||||
Execute the project's test suite:
|
||||
|
||||
1. Identify the test command from package.json or build files
|
||||
2. Run tests in the integrated terminal
|
||||
3. Parse test output for failures
|
||||
4. Summarize failed tests with relevant file locations
|
||||
5. Suggest potential fixes based on error messages
|
||||
```
|
||||
|
||||
## Common Questions
|
||||
|
||||
**Q: How do I invoke a prompt?**
|
||||
|
||||
A: In VS Code, open Copilot Chat and type the filename without extension. For example, `/code-review` invokes `code-review.prompt.md`. Alternatively, use the Copilot prompt picker UI.
|
||||
|
||||
**Q: Can prompts modify multiple files?**
|
||||
|
||||
A: Yes, if the prompt uses `agent: 'agent'` and includes the `edit` tool. The prompt can analyze, generate, and apply changes across multiple files.
|
||||
|
||||
**Q: How do I share prompts with my team?**
|
||||
|
||||
A: Store prompts in your repository's `.github/prompts/` directory. They're automatically available to all team members with Copilot access when working in that repository.
|
||||
|
||||
**Q: Can I chain multiple prompts together?**
|
||||
|
||||
A: Not directly, but you can create a comprehensive prompt that incorporates multiple steps. For complex workflows spanning many operations, consider creating a custom agent instead.
|
||||
|
||||
**Q: Should prompts include code examples?**
|
||||
|
||||
A: Yes, for clarity. Show examples of desired output format, patterns to follow, or anti-patterns to avoid. Keep examples focused and relevant.
|
||||
|
||||
## Common Pitfalls to Avoid
|
||||
|
||||
- ❌ **Too generic**: "Review this code" doesn't provide enough guidance
|
||||
✅ **Instead**: Specify what to review: quality, security, performance, style
|
||||
|
||||
- ❌ **Too specific**: Hardcoding file paths, names, or project-specific details
|
||||
✅ **Instead**: Use variables and pattern matching: `${input:FileName}`, `${selection}`
|
||||
|
||||
- ❌ **Missing tools**: Prompt needs codebase access but doesn't declare it
|
||||
✅ **Instead**: Explicitly list all required tools in frontmatter
|
||||
|
||||
- ❌ **Ambiguous language**: "Fix issues if you find any"
|
||||
✅ **Instead**: "Identify code smells and suggest specific refactorings with examples"
|
||||
|
||||
- ❌ **No examples**: Abstract requirements without concrete guidance
|
||||
✅ **Instead**: Include "Good Example" and "What to Avoid" sections
|
||||
|
||||
## Next Steps
|
||||
|
||||
Now that you understand effective prompts, you can:
|
||||
|
||||
- **Explore Repository Examples**: Browse [Prompts Directory](../prompts/) - Over 110 production prompts for diverse workflows
|
||||
- **Learn About Agents**: Building Custom Agents _(coming soon)_ - When to upgrade from prompts to full agents
|
||||
- **Understand Instructions**: [Defining Custom Instructions](../learning-hub/defining-custom-instructions/) - Complement prompts with automatic context
|
||||
- **Decision Framework**: Choosing the Right Customization _(coming soon)_ - When to use prompts vs other types
|
||||
|
||||
**Suggested Reading Order**:
|
||||
1. This article (creating effective prompts)
|
||||
2. Building Custom Agents _(coming soon)_ - More sophisticated workflows
|
||||
3. Choosing the Right Customization _(coming soon)_ - Decision guidance
|
||||
|
||||
---
|
||||
317
website/src/content/learning-hub/defining-custom-instructions.md
Normal file
317
website/src/content/learning-hub/defining-custom-instructions.md
Normal file
@@ -0,0 +1,317 @@
|
||||
---
|
||||
title: 'Defining Custom Instructions'
|
||||
description: 'Learn how to create persistent, context-aware instructions that guide GitHub Copilot automatically across your codebase.'
|
||||
authors:
|
||||
- GitHub Copilot Learning Hub Team
|
||||
lastUpdated: '2025-12-02'
|
||||
estimatedReadingTime: '8 minutes'
|
||||
tags:
|
||||
- instructions
|
||||
- customization
|
||||
- fundamentals
|
||||
relatedArticles:
|
||||
- ./what-are-agents-prompts-instructions.md
|
||||
- ./creating-effective-prompts.md
|
||||
- ./copilot-configuration-basics.md
|
||||
prerequisites:
|
||||
- Basic understanding of GitHub Copilot features
|
||||
---
|
||||
|
||||
Custom instructions are persistent configuration files that automatically guide GitHub Copilot's behavior when working with specific files or directories in your codebase. Unlike prompts that require explicit invocation, instructions work silently in the background, ensuring Copilot consistently follows your team's standards, conventions, and architectural decisions.
|
||||
|
||||
This article explains how to create effective custom instructions, when to use them, and how they integrate with your development workflow.
|
||||
|
||||
## What Are Custom Instructions?
|
||||
|
||||
Custom instructions are markdown files (`.instructions.md`) that contain:
|
||||
|
||||
- **Coding standards**: Naming conventions, formatting rules, style guidelines
|
||||
- **Framework-specific guidance**: Best practices for your tech stack
|
||||
- **Architecture decisions**: Project structure, design patterns, conventions
|
||||
- **Compliance requirements**: Security policies, regulatory constraints
|
||||
|
||||
**Key Points**:
|
||||
- Instructions apply automatically when Copilot works on matching files
|
||||
- They persist across all chat sessions and inline completions
|
||||
- They can be scoped globally, per language, or per directory using glob patterns
|
||||
- They help Copilot understand your codebase's unique context without manual prompting
|
||||
|
||||
### How Instructions Differ from Other Customizations
|
||||
|
||||
**Instructions vs Prompts**:
|
||||
- Instructions are always active for matching files; prompts require explicit invocation
|
||||
- Instructions provide passive context; prompts drive specific tasks
|
||||
- Use instructions for standards that apply repeatedly; use prompts for one-time operations
|
||||
|
||||
**Instructions vs Agents**:
|
||||
- Instructions are lightweight context; agents are specialized personas with tool access
|
||||
- Instructions work with any Copilot interaction; agents require explicit selection
|
||||
- Use instructions for coding standards; use agents for complex workflows with tooling needs
|
||||
|
||||
## Creating Your First Custom Instruction
|
||||
|
||||
Custom instructions follow a simple structure with YAML frontmatter and markdown content.
|
||||
|
||||
**Example**:
|
||||
|
||||
````markdown
|
||||
---
|
||||
description: 'TypeScript coding standards for React components'
|
||||
applyTo: '**/*.tsx, **/*.ts'
|
||||
---
|
||||
|
||||
# TypeScript React Development
|
||||
|
||||
Use functional components with TypeScript interfaces for all props.
|
||||
|
||||
## Naming Conventions
|
||||
|
||||
- Component files: PascalCase (e.g., `UserProfile.tsx`)
|
||||
- Hook files: camelCase with `use` prefix (e.g., `useAuth.ts`)
|
||||
- Type files: PascalCase with descriptive names (e.g., `UserTypes.ts`)
|
||||
|
||||
## Component Structure
|
||||
|
||||
Always define prop interfaces explicitly:
|
||||
|
||||
```typescript
|
||||
interface UserProfileProps {
|
||||
userId: string;
|
||||
onUpdate: (user: User) => void;
|
||||
}
|
||||
|
||||
export function UserProfile({ userId, onUpdate }: UserProfileProps) {
|
||||
// Implementation
|
||||
}
|
||||
```
|
||||
````
|
||||
|
||||
## Best Practices
|
||||
|
||||
- Export types separately for reuse across components
|
||||
- Use React.FC only when children typing is needed
|
||||
- Prefer named exports over default exports
|
||||
|
||||
**Why This Works**:
|
||||
- The `applyTo` glob pattern targets TypeScript/TSX files specifically
|
||||
- Copilot reads these instructions whenever it generates or suggests code for matching files
|
||||
- Standards are enforced consistently without developers needing to remember every rule
|
||||
- New team members benefit from institutional knowledge automatically
|
||||
|
||||
## Scoping Instructions Effectively
|
||||
|
||||
The `applyTo` field determines which files receive the instruction's guidance.
|
||||
|
||||
### Common Scoping Patterns
|
||||
|
||||
**All TypeScript files**:
|
||||
```yaml
|
||||
applyTo: '**/*.ts, **/*.tsx'
|
||||
```
|
||||
|
||||
**Specific directory**:
|
||||
```yaml
|
||||
applyTo: 'src/components/**/*.tsx'
|
||||
```
|
||||
|
||||
**Test files only**:
|
||||
```yaml
|
||||
applyTo: '**/*.test.ts, **/*.spec.ts'
|
||||
```
|
||||
|
||||
**Single technology**:
|
||||
```yaml
|
||||
applyTo: '**/*.py'
|
||||
```
|
||||
|
||||
**Entire project**:
|
||||
```yaml
|
||||
applyTo: '**'
|
||||
```
|
||||
|
||||
**Expected Result**:
|
||||
When you work on a file matching the pattern, Copilot incorporates that instruction's context into suggestions and chat responses automatically.
|
||||
|
||||
## Real Examples from the Repository
|
||||
|
||||
The awesome-copilot-hub repository includes over 120 instruction files demonstrating real-world patterns.
|
||||
|
||||
### Security Standards
|
||||
|
||||
See [security-and-owasp.instructions.md](https://github.com/github/awesome-copilot/blob/main/instructions/security-and-owasp.instructions.md) for comprehensive security guidance:
|
||||
|
||||
```markdown
|
||||
---
|
||||
description: 'OWASP Top 10 security practices for all code'
|
||||
applyTo: '**'
|
||||
---
|
||||
|
||||
# Security and OWASP Best Practices
|
||||
|
||||
Always validate and sanitize user input before processing.
|
||||
|
||||
## Input Validation
|
||||
|
||||
- Whitelist acceptable input patterns
|
||||
- Reject unexpected formats early
|
||||
- Never trust client-side validation alone
|
||||
- Use parameterized queries for database operations
|
||||
```
|
||||
|
||||
This instruction applies to all files (`applyTo: '**'`), ensuring security awareness in every suggestion.
|
||||
|
||||
### Framework-Specific Guidance
|
||||
|
||||
See [reactjs.instructions.md](https://github.com/github/awesome-copilot/blob/main/instructions/reactjs.instructions.md) for React-specific patterns:
|
||||
|
||||
```markdown
|
||||
---
|
||||
description: 'React development best practices and patterns'
|
||||
applyTo: '**/*.jsx, **/*.tsx'
|
||||
---
|
||||
|
||||
# React Development Guidelines
|
||||
|
||||
Use functional components with hooks for all new components.
|
||||
|
||||
## State Management
|
||||
|
||||
- Use `useState` for local component state
|
||||
- Use `useContext` for shared state across components
|
||||
- Consider Redux only for complex global state
|
||||
- Avoid prop drilling beyond 2-3 levels
|
||||
```
|
||||
|
||||
This instruction targets only React component files, providing context-specific guidance.
|
||||
|
||||
### Testing Standards
|
||||
|
||||
See [playwright-typescript.instructions.md](https://github.com/github/awesome-copilot/blob/main/instructions/playwright-typescript.instructions.md) for test automation patterns:
|
||||
|
||||
````markdown
|
||||
---
|
||||
description: 'Playwright test automation with TypeScript'
|
||||
applyTo: '**/*.spec.ts, **/tests/**/*.ts'
|
||||
---
|
||||
|
||||
# Playwright Testing Standards
|
||||
|
||||
Write descriptive test names that explain the expected behavior.
|
||||
|
||||
## Test Structure
|
||||
|
||||
```typescript
|
||||
test('should display error message when login fails', async ({ page }) => {
|
||||
await page.goto('/login');
|
||||
await page.fill('#username', 'invalid');
|
||||
await page.fill('#password', 'invalid');
|
||||
await page.click('#submit');
|
||||
|
||||
await expect(page.locator('.error')).toBeVisible();
|
||||
});
|
||||
```
|
||||
````
|
||||
|
||||
This instruction applies only to test files, ensuring test-specific context.
|
||||
|
||||
## Structuring Instruction Content
|
||||
|
||||
### Effective Organization
|
||||
|
||||
A well-structured instruction file includes:
|
||||
|
||||
1. **Clear title and overview**: What this instruction covers
|
||||
2. **Specific guidelines**: Actionable rules, not vague suggestions
|
||||
3. **Code examples**: Working snippets showing correct patterns
|
||||
4. **Explanations**: Why certain approaches are preferred
|
||||
|
||||
### Writing Style Best Practices
|
||||
|
||||
- **Be specific**: "Use PascalCase for component names" instead of "name components well"
|
||||
- **Show examples**: Include working code snippets demonstrating patterns
|
||||
- **Explain reasoning**: Brief context helps Copilot understand intent
|
||||
- **Stay concise**: Focus on what matters most; avoid exhaustive documentation
|
||||
|
||||
**Example - Vague vs Specific**:
|
||||
|
||||
❌ **Vague**: "Handle errors properly"
|
||||
|
||||
✅ **Specific**:
|
||||
````markdown
|
||||
## Error Handling
|
||||
|
||||
Wrap async operations in try-catch blocks and log errors:
|
||||
|
||||
```typescript
|
||||
try {
|
||||
const data = await fetchUser(userId);
|
||||
return data;
|
||||
} catch (error) {
|
||||
logger.error('Failed to fetch user', { userId, error });
|
||||
throw new UserNotFoundError(userId);
|
||||
}
|
||||
```
|
||||
````
|
||||
|
||||
## Common Questions
|
||||
|
||||
**Q: How many instructions should I create?**
|
||||
|
||||
A: Start with 3-5 core instructions covering your most important standards (naming, structure, security). Add more as patterns emerge. Having 10-20 instructions for a medium-sized project is reasonable. Awesome Copilot repository contains over 120 to demonstrate the range of possibilities.
|
||||
|
||||
**Q: Do instructions slow down Copilot?**
|
||||
|
||||
A: No. Instructions are processed efficiently as part of Copilot's context window. Keep individual files focused (under 500 lines) for best results, and ensure that they are scoped appropriately.
|
||||
|
||||
**Q: Can instructions contradict each other?**
|
||||
|
||||
A: If multiple instructions apply to the same file, Copilot considers all of them. Avoid contradictions by keeping instructions focused and using specific `applyTo` patterns. More specific patterns take precedence mentally, but it's best to design complementary instructions.
|
||||
|
||||
**Q: How do I know if my instructions are working?**
|
||||
|
||||
A: Test by asking Copilot to generate code matching your patterns. If it follows your standards without explicit prompting, the instructions are effective. You can also reference the instruction explicitly in chat: "Following the TypeScript standards in my instructions, create a user component."
|
||||
|
||||
**Q: Should I document everything in instructions?**
|
||||
|
||||
A: No. Instructions are for persistent standards that apply repeatedly. Document one-off decisions in code comments. Use instructions for patterns you want Copilot to follow automatically.
|
||||
|
||||
## Best Practices
|
||||
|
||||
- **One purpose per file**: Create separate instructions for different concerns (security, testing, styling)
|
||||
- **Use clear naming**: Name files descriptively: `react-component-standards.instructions.md`, not `rules.instructions.md`
|
||||
- **Include examples**: Every guideline should have at least one code example
|
||||
- **Keep it current**: Review instructions when dependencies or frameworks update
|
||||
- **Test your instructions**: Generate code and verify Copilot follows the patterns
|
||||
- **Link to documentation**: Reference official docs for detailed explanations
|
||||
- **Use tables for rules**: Tabular format works well for naming conventions and comparisons
|
||||
|
||||
## Common Pitfalls to Avoid
|
||||
|
||||
- ❌ **Too generic**: "Write clean code" doesn't give Copilot actionable guidance
|
||||
✅ **Instead**: Provide specific patterns: "Extract functions longer than 20 lines into smaller, named functions"
|
||||
|
||||
- ❌ **Too verbose**: Including entire documentation pages overwhelms the context window
|
||||
✅ **Instead**: Distill key patterns and link to full documentation
|
||||
|
||||
- ❌ **Contradictory rules**: Different instructions suggesting opposite approaches
|
||||
✅ **Instead**: Design complementary instructions with clear scopes
|
||||
|
||||
- ❌ **Outdated patterns**: Instructions referencing deprecated APIs or old versions
|
||||
✅ **Instead**: Review and update instructions when dependencies change
|
||||
|
||||
- ❌ **Missing scope**: Using `applyTo: '**'` for language-specific guidelines
|
||||
✅ **Instead**: Scope to relevant files: `applyTo: '**/*.py'` for Python-specific rules
|
||||
|
||||
## Next Steps
|
||||
|
||||
Now that you understand custom instructions, you can:
|
||||
|
||||
- **Explore Repository Examples**: Browse [Instructions Directory](../instructions/) - Over 120 real-world examples covering frameworks, languages, and domains
|
||||
- **Learn About Prompts**: [Creating Effective Prompts](../learning-hub/creating-effective-prompts/) - Discover when to use prompts instead of instructions
|
||||
- **Understand Agents**: Building Custom Agents _(coming soon)_ - See how agents complement instructions for complex workflows
|
||||
- **Configuration Basics**: [Copilot Configuration Basics](../learning-hub/copilot-configuration-basics/) - Learn how to organize and manage your customizations
|
||||
|
||||
**Suggested Reading Order**:
|
||||
1. This article (defining custom instructions)
|
||||
2. [Creating Effective Prompts](../learning-hub/creating-effective-prompts/) - Learn complementary customization type
|
||||
3. Choosing the Right Customization _(coming soon)_ - Decision framework for when to use each type
|
||||
@@ -0,0 +1,172 @@
|
||||
---
|
||||
title: 'Understanding Copilot Context'
|
||||
description: 'Learn how GitHub Copilot uses context from your code, workspace, and conversation to generate relevant suggestions.'
|
||||
authors:
|
||||
- GitHub Copilot Learning Hub Team
|
||||
lastUpdated: '2025-11-28'
|
||||
estimatedReadingTime: '8 minutes'
|
||||
tags:
|
||||
- context
|
||||
- fundamentals
|
||||
- how-it-works
|
||||
relatedArticles:
|
||||
- ./what-are-agents-prompts-instructions.md
|
||||
---
|
||||
|
||||
Context is the foundation of how GitHub Copilot generates relevant, accurate suggestions. Understanding what Copilot "sees" and how it uses that information helps you write better prompts, get higher-quality completions, and work more effectively with AI assistance. This article explains the types of context Copilot uses and how to optimize your development environment for better results.
|
||||
|
||||
## What Copilot Sees
|
||||
|
||||
When GitHub Copilot generates a suggestion or responds to a chat message, it analyzes multiple sources of information from your development environment:
|
||||
|
||||
**Open Files**: Copilot can access content from files currently open in your editor. Having relevant files visible gives Copilot important context about your codebase structure, naming conventions, and coding patterns.
|
||||
|
||||
**Current Cursor Position**: The exact location of your cursor matters. Copilot considers the surrounding code—what comes before and after—to understand your current intent and generate contextually appropriate suggestions.
|
||||
|
||||
**Related Files**: Through imports, references, and dependencies, Copilot identifies files related to your current work. For example, if you're editing a component that imports a utility function, Copilot may reference that utility file to understand available functionality.
|
||||
|
||||
**Chat Conversation History**: In GitHub Copilot Chat, previous messages in your conversation provide context for follow-up questions. This allows for natural, iterative problem-solving where each response builds on earlier exchanges.
|
||||
|
||||
**Workspace Structure**: The organization of your project—directory structure, configuration files, and patterns—helps Copilot understand the type of project you're working on and follow appropriate conventions.
|
||||
|
||||
## Types of Context
|
||||
|
||||
GitHub Copilot leverages four distinct types of context to inform its suggestions:
|
||||
|
||||
### Editor Context
|
||||
|
||||
Editor context includes the active files displayed in your editor and the specific code visible on screen. When you have multiple files open in tabs or split views, Copilot can reference all of them to provide more informed suggestions.
|
||||
|
||||
**Example**: If you're writing a function that calls methods from a class defined in another open file, Copilot can suggest the correct method names and parameter types by referencing that class definition.
|
||||
|
||||
### Semantic Context
|
||||
|
||||
Semantic context goes beyond raw text to understand the meaning and relationships in your code. This includes function signatures, type definitions, interface contracts, class hierarchies, and inline comments that explain complex logic.
|
||||
|
||||
**Example**: When you're implementing an interface, Copilot uses the interface definition as semantic context to suggest correct method signatures with appropriate parameter types and return values.
|
||||
|
||||
### Conversation Context
|
||||
|
||||
In GitHub Copilot Chat, conversation context includes all previous messages, questions, and responses in the current chat session. This enables contextual follow-ups where you can ask "What about error handling?" and Copilot understands you're referring to the code discussed earlier.
|
||||
|
||||
**Example**: After asking Copilot to generate a database query function, you can follow up with "Add error handling and logging" without repeating the full context—Copilot remembers the previous exchange.
|
||||
|
||||
### Workspace Context
|
||||
|
||||
Workspace context includes project-level information like your directory structure, configuration files (`.gitignore`, `package.json`, `tsconfig.json`), and overall repository organization. This helps Copilot understand your project type, dependencies, and conventions.
|
||||
|
||||
**Example**: If your workspace contains a `package.json` with TypeScript and React dependencies, Copilot recognizes this is a TypeScript React project and generates suggestions using appropriate patterns and types.
|
||||
|
||||
## How Context Influences Suggestions
|
||||
|
||||
Context directly impacts the relevance, accuracy, and usefulness of GitHub Copilot's suggestions. More context generally leads to better suggestions.
|
||||
|
||||
### Example: Code Completion with Context
|
||||
|
||||
**Without Context** (only the current file open):
|
||||
|
||||
```typescript
|
||||
// user.ts
|
||||
function getUserById(id: string) {
|
||||
// Copilot might suggest generic database code
|
||||
const user = db.query('SELECT * FROM users WHERE id = ?', [id]);
|
||||
return user;
|
||||
}
|
||||
```
|
||||
|
||||
**With Context** (database utility file also open):
|
||||
|
||||
```typescript
|
||||
// database.ts (open in another tab)
|
||||
export async function queryOne<T>(sql: string, params: any[]): Promise<T | null> {
|
||||
// ... implementation
|
||||
}
|
||||
|
||||
// user.ts (current file)
|
||||
function getUserById(id: string) {
|
||||
// Copilot now suggests using the existing utility
|
||||
return queryOne<User>('SELECT * FROM users WHERE id = ?', [id]);
|
||||
}
|
||||
```
|
||||
|
||||
By having the `database.ts` file open, Copilot recognizes the existing utility function and suggests using it instead of generating generic database code.
|
||||
|
||||
### Example: Chat with File References
|
||||
|
||||
**Without @-mention**:
|
||||
|
||||
```
|
||||
You: How do I handle validation?
|
||||
|
||||
Copilot: Here's a general approach to validation...
|
||||
[provides generic validation code]
|
||||
```
|
||||
|
||||
**With #-mention**:
|
||||
|
||||
```
|
||||
You: How do I handle validation in #user-service.ts?
|
||||
|
||||
Copilot: Based on your UserService class, you can add validation like this...
|
||||
[provides code specific to your UserService implementation]
|
||||
```
|
||||
|
||||
Using `#` to reference specific files gives Copilot precise context about which code you're asking about.
|
||||
|
||||
### Token Limits and Context Prioritization
|
||||
|
||||
GitHub Copilot has a maximum token limit for how much context it can process at once. When you have many files open or a long chat history, Copilot prioritizes:
|
||||
|
||||
1. **Closest proximity**: Code immediately surrounding your cursor
|
||||
2. **Explicitly referenced files**: Files you @-mention in chat
|
||||
3. **Recently modified files**: Files you've edited recently
|
||||
4. **Direct dependencies**: Files imported by your current file
|
||||
|
||||
Understanding this prioritization helps you optimize which files to keep open and when to use explicit references.
|
||||
|
||||
## Context Best Practices
|
||||
|
||||
Maximize GitHub Copilot's effectiveness by providing clear, relevant context:
|
||||
|
||||
**Keep related files open**: If you're working on a component, keep its test file, related utilities, and type definitions open in tabs or split views.
|
||||
|
||||
**Use descriptive names**: Choose clear variable names, function names, and class names that convey intent. `getUserProfile()` provides more context than `getData()`.
|
||||
|
||||
**Add clarifying comments**: For complex algorithms or business logic, write comments explaining the "why" behind the code. Copilot uses these to understand your intent.
|
||||
|
||||
**Structure your workspace logically**: Organize files in meaningful directories that reflect your application architecture. Clear structure helps Copilot understand relationships between components.
|
||||
|
||||
**Use #-mentions in chat**: When asking questions, explicitly reference files with `#filename` to ensure Copilot analyzes the exact code you're discussing.
|
||||
|
||||
**Provide examples in prompts**: When asking Copilot to generate code, include examples of your existing patterns and conventions.
|
||||
|
||||
## Common Questions
|
||||
|
||||
**Q: Does Copilot see my entire repository?**
|
||||
|
||||
A: No, Copilot doesn't automatically analyze all files in your repository. It focuses on open files, recently modified files, and files directly referenced by your current work. For large codebases, this selective approach ensures fast response times while still providing relevant context.
|
||||
|
||||
**Q: How do I know what context Copilot is using?**
|
||||
|
||||
A: In GitHub Copilot Chat, you can see which files are being referenced in responses. When Copilot generates suggestions, it's primarily using your currently open files and the code immediately surrounding your cursor. Using `#workspace` in chat explicitly searches across your entire repository.
|
||||
|
||||
**Q: Can I control what context is included?**
|
||||
|
||||
A: Yes, you have several ways to control context:
|
||||
- Open/close files to change what's available to Copilot
|
||||
- Use `#` mentions to explicitly reference specific files, symbols or functions
|
||||
- Configure `.gitignore` to exclude files from workspace context
|
||||
- Use instructions and prompts to provide persistent context for specific scenarios
|
||||
|
||||
**Q: Does closing a file remove it from context?**
|
||||
|
||||
A: Yes, closing a file can remove it from Copilot's active context. However, files you've recently worked with may still influence suggestions briefly. For a clean context reset, you can restart your editor or start a new chat session.
|
||||
|
||||
## Next Steps
|
||||
|
||||
Now that you understand how context works in GitHub Copilot, explore these related topics:
|
||||
|
||||
- **[What are Agents, Prompts, and Instructions](../learning-hub/what-are-agents-prompts-instructions/)** - Learn about customization types that provide persistent context
|
||||
- **[Copilot Configuration Basics](../learning-hub/copilot-configuration-basics/)** - Configure settings to optimize context usage
|
||||
- **[Creating Effective Prompts](../learning-hub/creating-effective-prompts/)** - Use context effectively in your prompts
|
||||
- **Common Pitfalls and Solutions** _(coming soon)_ - Avoid context-related mistakes
|
||||
@@ -0,0 +1,81 @@
|
||||
---
|
||||
title: 'What are Agents, Prompts, and Instructions'
|
||||
description: 'Understand the primary customization primitives that extend GitHub Copilot for specific workflows.'
|
||||
authors:
|
||||
- GitHub Copilot Learning Hub Team
|
||||
lastUpdated: '2025-11-25'
|
||||
estimatedReadingTime: '7 minutes'
|
||||
---
|
||||
|
||||
Building great experiences with GitHub Copilot starts with understanding the core primitives that shape how Copilot behaves in different contexts. This article clarifies what each artifact does, how it is packaged inside this repository, and when to use it.
|
||||
|
||||
## Agents
|
||||
|
||||
Agents are configuration files (`*.agent.md`) that describe:
|
||||
|
||||
- The tasks they specialize in (for example, "Terraform Expert" or "LaunchDarkly Flag Manager").
|
||||
- Which tools or MCP servers they can invoke.
|
||||
- Optional instructions that guide the conversation style or guardrails.
|
||||
|
||||
When you assign an issue to Copilot or open the **Agents** panel in VS Code, these configurations let you swap in a specialized assistant. Each agent in this repo lives under `agents/` and includes metadata about the tools it depends on.
|
||||
|
||||
### When to reach for an agent
|
||||
|
||||
- You have a recurring workflow that benefits from deep tooling integrations.
|
||||
- You want Copilot to proactively execute commands or fetch context via MCP.
|
||||
- You need persona-level guardrails that persist throughout a coding session.
|
||||
|
||||
## Prompts
|
||||
|
||||
Prompts (`*.prompt.md`) capture reusable chat macros. They define:
|
||||
|
||||
- A short name (used as `/command` in VS Code Chat).
|
||||
- Optional mode and model hints (for example, `plan` vs `code` or `gpt-4.1-mini`).
|
||||
- Recommended tools to enable before running the prompt.
|
||||
- The actual message template Copilot should execute.
|
||||
|
||||
Prompts shine when you want consistency across teammates—think "Create release notes" or "Audit accessibility". Store them in `prompts/` and trigger them directly from VS Code.
|
||||
|
||||
### When to reach for a prompt
|
||||
|
||||
- You want to standardize how Copilot responds to a task.
|
||||
- You prefer to drive the conversation, but with guardrails.
|
||||
- You do not need Copilot to maintain long-lived state beyond a single invocation.
|
||||
|
||||
## Instructions
|
||||
|
||||
Instructions (`*.instructions.md`) provide background context that Copilot reads whenever it works on matching files. They often contain:
|
||||
|
||||
- Coding standards or style guides (naming conventions, testing strategy).
|
||||
- Framework-specific hints (Angular best practices, .NET analyzers to suppress).
|
||||
- Repository-specific rules ("never commit secrets", "feature flags must live in `flags/`").
|
||||
|
||||
Instructions sit under `instructions/` and can be scoped globally, per language, or per directory using glob patterns. They help Copilot align with your engineering playbook automatically.
|
||||
|
||||
### When to reach for instructions
|
||||
|
||||
- You need persistent guidance that applies across many sessions.
|
||||
- You are codifying architecture decisions or compliance requirements.
|
||||
- You want Copilot to understand patterns without manually pasting context.
|
||||
|
||||
## How the artifacts work together
|
||||
|
||||
Think of these artifacts as complementary layers:
|
||||
|
||||
1. **Instructions** lay the groundwork with long-lived guardrails.
|
||||
2. **Prompts** let you trigger quick workflows or templates on demand.
|
||||
3. **Agents** bring the most opinionated behavior, bundling tools and instructions into a single persona.
|
||||
|
||||
By combining all three, teams can achieve:
|
||||
|
||||
- Consistent onboarding for new developers.
|
||||
- Repeatable operations tasks with reduced context switching.
|
||||
- Tailored experiences for specialized domains (security, infrastructure, data science, etc.).
|
||||
|
||||
## Next steps
|
||||
|
||||
- Explore the rest of the **Fundamentals** track for deeper dives on chat modes, collections, and MCP servers.
|
||||
- Browse the [Awesome Agents](../agents/), [Prompts](../prompts/), and [Instructions](../instructions/) directories for inspiration.
|
||||
- Try generating your own artifacts, then add them to the repo to keep the Learning Hub evolving.
|
||||
|
||||
---
|
||||
47
website/src/layouts/ArticleLayout.astro
Normal file
47
website/src/layouts/ArticleLayout.astro
Normal file
@@ -0,0 +1,47 @@
|
||||
---
|
||||
import BaseLayout from './BaseLayout.astro';
|
||||
|
||||
interface Props {
|
||||
title: string;
|
||||
description?: string;
|
||||
estimatedReadingTime?: string;
|
||||
lastUpdated?: string;
|
||||
tags?: string[];
|
||||
}
|
||||
|
||||
const { title, description, estimatedReadingTime, lastUpdated, tags } = Astro.props;
|
||||
const base = import.meta.env.BASE_URL;
|
||||
---
|
||||
|
||||
<BaseLayout title={title} description={description} activeNav="learning-hub">
|
||||
<main id="main-content">
|
||||
<div class="page-header">
|
||||
<div class="container">
|
||||
<nav class="breadcrumb" aria-label="Breadcrumb">
|
||||
<a href={`${base}learning-hub/`}>← Learning Hub</a>
|
||||
</nav>
|
||||
<h1>{title}</h1>
|
||||
{description && <p>{description}</p>}
|
||||
<div class="article-meta">
|
||||
{estimatedReadingTime && <span class="meta-item">📖 {estimatedReadingTime}</span>}
|
||||
{lastUpdated && <span class="meta-item">Updated: {lastUpdated}</span>}
|
||||
</div>
|
||||
{tags && tags.length > 0 && (
|
||||
<div class="article-tags">
|
||||
{tags.map((tag) => (
|
||||
<span class="tag">{tag}</span>
|
||||
))}
|
||||
</div>
|
||||
)}
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="page-content">
|
||||
<div class="container">
|
||||
<article class="article-content">
|
||||
<slot />
|
||||
</article>
|
||||
</div>
|
||||
</div>
|
||||
</main>
|
||||
</BaseLayout>
|
||||
@@ -99,6 +99,10 @@ try {
|
||||
href={`${base}samples/`}
|
||||
class:list={[{ active: activeNav === "samples" }]}>Samples</a
|
||||
>
|
||||
<a
|
||||
href={`${base}learning-hub/`}
|
||||
class:list={[{ active: activeNav === "learning-hub" }]}>Learning Hub</a
|
||||
>
|
||||
</nav>
|
||||
<div class="header-actions">
|
||||
<button
|
||||
|
||||
@@ -73,6 +73,13 @@ const base = import.meta.env.BASE_URL;
|
||||
</div>
|
||||
<div class="card-count" data-count="tools" aria-label="Tool count">-</div>
|
||||
</a>
|
||||
<a href={`${base}learning-hub/`} class="card" id="card-learning-hub">
|
||||
<div class="card-icon" aria-hidden="true">📚</div>
|
||||
<div class="card-content">
|
||||
<h3>Learning Hub</h3>
|
||||
<p>Articles and guides to master GitHub Copilot</p>
|
||||
</div>
|
||||
</a>
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
25
website/src/pages/learning-hub/[slug].astro
Normal file
25
website/src/pages/learning-hub/[slug].astro
Normal file
@@ -0,0 +1,25 @@
|
||||
---
|
||||
import ArticleLayout from '../../layouts/ArticleLayout.astro';
|
||||
import { getCollection, render } from 'astro:content';
|
||||
|
||||
export async function getStaticPaths() {
|
||||
const articles = await getCollection('learning-hub');
|
||||
return articles.map((article) => ({
|
||||
params: { slug: article.id },
|
||||
props: { article },
|
||||
}));
|
||||
}
|
||||
|
||||
const { article } = Astro.props;
|
||||
const { Content } = await render(article);
|
||||
---
|
||||
|
||||
<ArticleLayout
|
||||
title={article.data.title}
|
||||
description={article.data.description}
|
||||
estimatedReadingTime={article.data.estimatedReadingTime}
|
||||
lastUpdated={article.data.lastUpdated}
|
||||
tags={article.data.tags}
|
||||
>
|
||||
<Content />
|
||||
</ArticleLayout>
|
||||
66
website/src/pages/learning-hub/index.astro
Normal file
66
website/src/pages/learning-hub/index.astro
Normal file
@@ -0,0 +1,66 @@
|
||||
---
|
||||
import BaseLayout from '../../layouts/BaseLayout.astro';
|
||||
import { getCollection } from 'astro:content';
|
||||
|
||||
const base = import.meta.env.BASE_URL;
|
||||
const articles = await getCollection('learning-hub');
|
||||
|
||||
const recommendedOrder = [
|
||||
'what-are-agents-prompts-instructions',
|
||||
'understanding-copilot-context',
|
||||
'copilot-configuration-basics',
|
||||
'defining-custom-instructions',
|
||||
'creating-effective-prompts',
|
||||
];
|
||||
|
||||
const sortedArticles = articles.sort((a, b) => {
|
||||
const aIndex = recommendedOrder.indexOf(a.id);
|
||||
const bIndex = recommendedOrder.indexOf(b.id);
|
||||
const aOrder = aIndex === -1 ? recommendedOrder.length : aIndex;
|
||||
const bOrder = bIndex === -1 ? recommendedOrder.length : bIndex;
|
||||
return aOrder - bOrder;
|
||||
});
|
||||
---
|
||||
|
||||
<BaseLayout title="Learning Hub" description="Curated articles and walkthroughs to help you unlock everything you can do with GitHub Copilot" activeNav="learning-hub">
|
||||
<main id="main-content">
|
||||
<div class="page-header">
|
||||
<div class="container">
|
||||
<h1>📚 Learning Hub</h1>
|
||||
<p>Curated articles, walkthroughs, and reference material to help you unlock everything you can do with GitHub Copilot</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="page-content">
|
||||
<div class="container">
|
||||
<section class="learning-hub-section">
|
||||
<h2>Fundamentals</h2>
|
||||
<p class="section-description">Essential concepts to tailor GitHub Copilot beyond its default experience.</p>
|
||||
<div class="article-list">
|
||||
{sortedArticles.map((article, index) => (
|
||||
<a href={`${base}learning-hub/${article.id}/`} class="article-card">
|
||||
<div class="article-number" aria-hidden="true">{index + 1}</div>
|
||||
<div class="article-info">
|
||||
<h3>{article.data.title}</h3>
|
||||
<p>{article.data.description}</p>
|
||||
<div class="article-meta">
|
||||
{article.data.estimatedReadingTime && (
|
||||
<span class="meta-item">📖 {article.data.estimatedReadingTime}</span>
|
||||
)}
|
||||
{article.data.tags && article.data.tags.length > 0 && (
|
||||
<span class="meta-item">
|
||||
{article.data.tags.map((tag) => (
|
||||
<span class="tag">{tag}</span>
|
||||
))}
|
||||
</span>
|
||||
)}
|
||||
</div>
|
||||
</div>
|
||||
</a>
|
||||
))}
|
||||
</div>
|
||||
</section>
|
||||
</div>
|
||||
</div>
|
||||
</main>
|
||||
</BaseLayout>
|
||||
Reference in New Issue
Block a user