Copilot for Engineers & Project Teams
A self-paced course for people who deliver: patching schedules, implementation plans, CAB submissions, RAID logs, customer reporting and the endless admin around all of it.
How this course works
- Work through the modules in order — later modules build on the prompt techniques in Module 02.
- Each module ends with a short knowledge check. Answer it correctly to complete the module — there's no skip button. Clear all 12 checks to unlock your certificate.
- Every example prompt has a Copy button. Keep Copilot open in a second window and try them as you go — reading about prompts teaches you 10% of what using them does.
- Your progress is saved in this browser, so you can stop after any module and pick up where you left off — as long as you return in the same browser and don't clear its data.
Use Microsoft 365 Copilot signed in with your work account for anything involving company or customer data. Module 10 covers the rules — if you only remember one thing from this course, make it that module.
What AI actually does (and doesn't)
Most people think Copilot is "Google that talks". It isn't — and using it like a search engine is why most first attempts disappoint.
What it's genuinely good at
| Capability | What that means for us |
|---|---|
| Summarisation | 40-email chain → half a page of decisions and actions |
| Transformation | Messy meeting notes → formal RAID log; tech detail → customer-friendly update |
| Pattern spotting | Clashing change windows, double-booked engineers, missing rollback steps |
| First drafts | CAB submissions, method statements, status decks — 80% drafts in minutes |
| Data commentary | "Explain what this Excel tracker is telling me" in plain English |
What it's not
- Not a source of truth. It can be confidently wrong about firmware versions, dates and technical facts. It generates plausible text, not verified fact.
- Not aware of anything you don't give it. If the CAB approval isn't in the document you attached, Copilot doesn't know it exists.
- Not accountable. You are. AI accelerates work; it never signs it off.
Treat Copilot like a fast, tireless graduate engineer: brilliant at drafting, summarising and formatting, but everything it produces needs a senior review before it leaves the building. You wouldn't let a new starter send a customer completion report unchecked — same rule here.
Open Copilot, paste in any recent project update (or a page of notes), and run this:
Summarise this project update as: - 5 bullet points for the delivery team - 3 risks with a Red/Amber/Green rating - 3 achievements - An executive summary under 100 words for a customer director Keep each section clearly separated.
Notice how one input becomes four audience-specific outputs. That's the core skill: different audiences need different versions of the same truth, and Copilot makes producing them nearly free.
Copilot tells you a patch resolves CVE-2026-1234 on a specific switch model. What should you do?
Writing better prompts
Most "AI failures" are prompt failures. This module is the highest-value 15 minutes in the course — everything after it depends on it.
The RTCF pattern
Every strong work prompt has four parts. You won't always need all four, but when output disappoints, one of these is usually missing:
| Part | Example | |
|---|---|---|
| R | Role — who should it act as? | "Act as a senior infrastructure engineer reviewing a change" |
| T | Task — the specific job | "Identify risks, missing dependencies and resource conflicts" |
| C | Context — what it needs to know | "This is a customer-facing migration with a 4-hour window on Saturday night" |
| F | Format — what the output should look like | "Table with severity ratings, most severe first" |
Fill in the parts and watch a strong prompt assemble. This is the whole skill — do it here, then copy it into Copilot for the real answer.
Fill in the fields above and your prompt appears here…
Bad vs good — same task
Fix this
No role, no task definition, no context, no format. Copilot will guess — and its guess is generic.
Act as a senior infrastructure engineer. Review the attached patching schedule and identify: - Missing dependencies - Resource conflicts - Rollback concerns - Maintenance window risks Present findings as a table with Red/Amber/Green severity, most severe first.
Three habits that transform output quality
- Iterate — don't restart. The first answer is a draft. Reply with "shorter", "more formal", "put that in a table", "focus only on the risks". Refining beats re-prompting from scratch.
- Give it an example. "Here's last month's customer report — write this month's in the same structure and tone" outperforms any description of what you want.
- Tell it the audience. "For a customer director with no technical background" and "for the engineer doing the work" produce completely different — and correctly different — documents.
Take a document you're working on. Prompt Copilot twice: first with a one-line request ("review this"), then with a full RTCF prompt. Compare the two outputs side by side. This contrast is the whole lesson.
Copilot's draft customer email is technically accurate but far too technical. Best next move?
Email & Outlook
Most of us spend 2–4 hours a day in Outlook. This is where Copilot pays for itself first.
The three email superpowers
1 · Summarise long threads
Summarise this email chain. List: - Every decision made, with who made it - Anything still unresolved - The current position in one sentence
2 · Extract actions
From this email chain, build an action register as a table: Action | Owner | Due date | Priority | Source (which email) If an owner or date isn't stated, mark it "UNCONFIRMED" — do not guess.
Left to itself, AI will invent plausible owners and dates to fill a table. Explicitly telling it to flag gaps turns a risk into a feature: the UNCONFIRMED rows become your chase list.
3 · Draft responses
Draft a reply to this email confirming the works completed last night, the validation checks performed, and the next scheduled activity. Professional, warm, under 150 words. Do not commit to any dates that aren't in the thread.
Handling an escalation
Customer escalations are high-stakes and time-pressured — exactly where a structured prompt helps most:
This is a customer escalation. Produce three things: 1. Executive summary of the complaint and its history (5 bullets) 2. Timeline of what happened and when, from the thread 3. A draft holding response that acknowledges the issue, commits to an owner and a response time, and does NOT admit fault or speculate about cause
Find the longest email thread in your inbox from the past fortnight. Run the thread-summary prompt, then the action-register prompt. Check the output against your own memory of the thread — where did it nail it, and where did it miss nuance?
In an extracted action register, three rows say "UNCONFIRMED" for owner. What does that tell you?
Meetings & Teams
Use Copilot before, during and after meetings — the "after" alone can hand you back hours a week.
Before: walk in prepared
Prepare me for my next meeting about [project]. From the invite, recent emails and the attached notes, summarise: - Key stakeholders and what each of them cares about - Open actions from the last session, with owners - Live risks I should be ready to speak to - Decisions this meeting needs to land
During: recap when you join late
Joined 20 minutes in? In a transcribed Teams meeting, ask Copilot "Recap what I've missed and whether anything was assigned to me" — quietly, without derailing the call.
After: minutes in minutes
From this meeting transcript, create formal minutes: - Attendees and apologies - Decisions made (with who made them) - Actions: table of Action | Owner | Due date - Risks or issues raised - Items parked for next time Flag anything ambiguous as [CHECK] rather than guessing.
AI minutes are drafts. Review them while the meeting is still fresh — transcription mishears names, merges speakers, and occasionally attributes an action to the wrong person. Five minutes of review straight after beats twenty minutes of confusion next week.
Take your next transcribed meeting (or a page of handwritten notes typed up) and produce three artefacts from the one source: formal minutes, a RAID update, and a 3-sentence exec summary. One meeting, three outputs, one prompt each.
Copilot's minutes attribute a commitment to the customer that you don't remember them making. What now?
Patching Schedules, Port Assignment & Cable Lengths
This section is not about generic change-window risk reviews. For our work, a patching schedule is a build document: it turns drawings, rack elevations, VLAN/service requirements and client standards into something an installer can actually patch, label, dress and hand over without guessing.
The earlier wording treated a patching schedule like a CAB or maintenance-window document. That was wrong. The real value here is using Copilot to clean, challenge and explain the schedule while you remain responsible for the engineering judgement: port allocation, service grouping, left/right routing, cable category, switch quirks and whether the output will make sense on site.
What a patching schedule actually needs to prove
A good schedule answers five practical questions before anyone starts patching:
| Question | What Copilot can help check | What the engineer still owns |
|---|---|---|
| What cable is this? | Missing/duplicate cable labels, inconsistent naming, spare rows removed by mistake | Whether the label format is correct for the client and whether field changes have been captured |
| Where does it land? | Rack/cabinet names, patch-panel RU, panel port, switch name, blade/port fields and blank destinations | Whether the cabinet elevation and drawings are current enough to trust |
| What service is it? | User, WAP/AP, Security, MEP, AV, printer, phone, UPS/PDU/NVR/ATS/iSTAR style groupings | Which services need redundancy, same-switch logic, side-specific patching or customer/client-standard treatment |
| Will it physically patch cleanly? | Outlier lengths, left/right imbalance, rows that look out of pattern, same-side vs cross-side runs | Whether the install will be tidy, serviceable and sensible in the actual IDF/comms room |
| Can the installer follow it? | Ambiguous notes, missing instructions, unexplained exceptions, unclear colour/category requirements | Final issue, site walk-through, and any instruction that affects what happens on the floor |
The real workflow
Use Copilot as a second pair of eyes at each stage, not as the person deciding the design.
- Collect the inputs: drawings, rack elevations, cabinet names, switch model/port numbering, client standards, service requirements and the draft pull/patching schedule.
- Clean the schedule: remove merged-cell problems, keep every row including spares, standardise column headings, and make sure cable labels can be copied straight into the tool without losing alignment.
- Check service logic: confirm WAP/AP, Security, MEP, AV, printer, phone, UPS, PDU, ATS, NVR and iSTAR style requirements before assigning switch ports. Copilot can flag inconsistencies, but it will not know client intent unless you provide it.
- Configure the tool: define cabinets, switch locations, switch names, blade layout, port start number, patch-panel size, entry/exit side rules, slack and cable managers/tray routing.
- Assign ports: use balanced or outside-in logic where appropriate, but check that the result matches the design intent. The tool can prevent mechanical overlap; it cannot decide whether the customer's APs, security or MEP devices should be treated differently unless you tell it.
- Bulk-calculate lengths: paste the schedule data in the expected format, generate the cable-length output, then paste the results back into the schedule without changing row order.
- Human review: spot-check the longest runs, unusual cable lengths, side-to-side routing, service exceptions and anything that changed on site.
- Issue for use: colour-code or note exceptions, clearly identify anything still unconfirmed, and produce an installer-ready version plus any cable-length/material summary.
Pass 1 — clean the source data
The first Copilot pass should be boring and mechanical. You are not asking it to design the patching. You are asking it to find the problems that make the tool output misalign or make an installer guess.
Act as a detail-focused LVC project support engineer. Review this draft pull / patching schedule before I use it for port assignment and cable-length calculation. Check for: - Missing cable labels - Duplicate cable labels - Blank rack, cabinet, patch-panel, RU or port fields - Merged-cell style issues or rows that may not copy cleanly - Spares accidentally removed or not clearly marked - Inconsistent service naming, e.g. WAP vs AP, MEP vs AC/UPS/PDU - Patch-panel ports or switch ports that look out of range - Rows that look out of pattern compared with the rest of the schedule Return a table: Row / Cable Label | Issue | Why it matters | Suggested correction | Needs human confirmation? Do not assign new ports or invent missing values. Mark unknowns as UNCONFIRMED.
Pass 2 — check the engineering logic
This is where the section now needs to be much closer to your actual role. Copilot should challenge whether the schedule matches the design rules you give it: service type, port range, redundancy, side routing and client quirks.
Act as a senior LVC / network infrastructure reviewer. Using the attached patching schedule and the rules below, check whether the service-to-port allocation looks sensible. Rules / assumptions for this project: - [Paste client or project rules here] - [Example: WAP/AP ports are dual patched for redundancy] - [Example: security should sit on right-hand-side switch ports unless otherwise stated] - [Example: MEP/UPS/PDU/NVR/ATS/iSTAR need dedicated clearly labelled ports] - [Example: Juniper switch ports start at 0, not 1] - [Example: patching should run outside-in to keep left/right side dressing clean] Check for: - Services assigned to the wrong VLAN/port group - AP/WAP, security, MEP, AV, phone or printer rows that break the stated rules - Switch-port numbering issues, especially port 0 vs port 1 assumptions - Ports allocated to the wrong side of the switch for clean dressing - Cross-cabinet or cross-side patching that could be avoided - Any row where the schedule says one thing but the notes imply another Return only checkable findings. Reference the row or cable label for every finding.
Pass 3 — prepare for Patch Logic / bulk calculation
For your workflow, the schedule often needs to feed directly into Patch Logic. That means row order matters. Copilot should be told not to “tidy” the data in a way that breaks the copy/paste workflow.
Prepare this schedule for use in Patch Logic bulk calculation. Expected input format: Rack, PP (RU), Port, Cable Label, Switch, [Blade if used], Switch Port Check whether each row has the required fields. Do not reorder rows. Do not remove spare rows. Do not invent rack names, switch names, blade numbers or ports. Create two outputs: 1. A readiness checklist with PASS / FAIL / CHECK 2. A corrected import table where only obvious formatting issues are fixed Anything requiring judgement must be marked CHECK rather than corrected.
Pass 4 — review the generated cable lengths
Once Patch Logic has generated lengths, Copilot is useful for sanity-checking the output: biggest lengths, odd lengths, repeated lengths that should not repeat, rows with unexpected routing, and anything that may affect material ordering.
Review this Patch Logic cable-length output against the original patching schedule. Look for: - Rows where cable label alignment appears broken - Unexpectedly long or short recommended lengths - Same-cabinet patches that look too long - Cross-cabinet runs that look too short - Left/right entry or exit side mismatches - Missing recommended length values - Cable counts by length for ordering - Rows that need a manual spot-check in the rack visualiser Return: - Top 10 rows to manually verify - Cable count summary by recommended length - Any rows where the output should not be trusted until checked Do not change any lengths. This is a review, not a recalculation.
What “good” looks like
Cable 03-AP06 is listed as WAP/AP but only appears once. Project rule says APs should be dual patched. Needs confirmation: second port missing, or this AP is an exception.
Consider checking the schedule for errors. No row, no cable label, no reason, no action. This is noise.
Common real-world mistakes to catch
- Port numbering assumptions: some switch schedules use port 0; others do not. Treat this as a hard check before assigning ports.
- Spare rows removed: if the original schedule includes spares, keep them in the same row order so outputs paste back correctly.
- Cat6 vs Cat6A confusion: site reality, cable colour, jack type and schedule wording may not all agree. Flag it instead of guessing.
- Left/right dressing: a technically valid allocation can still be ugly or awkward to maintain if everything crosses sides.
- Client-specific service rules: WAP/AP redundancy, security, MEP, AV, UPS/PDU/NVR/ATS/iSTAR logic changes by client and project.
- Changed field conditions: a clean schedule means very little if the rack elevation, drawings or on-site install has moved on.
Copilot cannot see the rack, the colour of the cable in your hand, the actual switch model installed, the Velcro mess on the right-hand side, or whether someone changed a port on site. It can make the review more consistent; it cannot replace the site-aware judgement that makes the schedule usable.
Use a recent completed schedule. Give everyone the same source schedule and the same project rules. Run the clean-up prompt, then the service/port logic review prompt. Compare outputs against what actually happened on site. The aim is not to prove Copilot is perfect — it is to learn which mistakes it catches reliably and which ones still need engineer judgement.
Copilot says a schedule is clean, but you know the AP rules changed during the project. What is the correct next step?
Documentation & CAB
Method statements, change requests, customer reports — the documents nobody enjoys writing and everybody needs. Copilot gets you to a strong first draft in minutes.
Method statements
Create a method statement for replacing a core switch in a customer data centre. Structure: - Purpose and scope - Pre-requisites and pre-checks - Step-by-step implementation with estimated timings - Validation and testing steps - Rollback procedure with decision points - Communication plan Leave [PLACEHOLDER] markers for anything site-specific (hostnames, IPs, contacts) rather than inventing values.
"Leave placeholders rather than inventing values" is one of the most useful lines you can add to any documentation prompt. It stops the AI fabricating hostnames and IPs that look real — the most dangerous kind of error, because it survives a skim-read.
Change requests / CAB submissions
From the attached implementation plan, draft a change request for CAB including: - Change description and business justification - Risk assessment and impact (systems and users affected) - Implementation window and duration - Rollback plan and rollback decision point - Validation / success criteria - Communication plan Write the risk section cautiously — do not understate impact.
Customer-facing reports
Using the attached engineer notes, write a customer-facing completion report: - What was done and when (plain English, no internal jargon) - Validation performed and results - Any deviations from plan, honestly and calmly stated - Next steps and any customer actions Tone: professional, confident, transparent. Audience: the customer's service delivery manager.
Take the roughest engineer notes you can find from a recent change. Turn them into a customer completion report with the prompt above. Then verify every fact in the output against the notes — count how many things you had to correct. That number is your review budget for this document type.
Why ask for [PLACEHOLDER] markers instead of letting Copilot fill in hostnames and IPs?
Word & documentation basics
Use Copilot in Word to turn rough notes into useful documents: customer updates, completion reports, method statements, SOW sections, handover notes and internal process guides.
What Word + Copilot is best for
| Task | How Copilot helps | Human check |
|---|---|---|
| Rough notes to report | Turns bullet notes into a structured, professional update | Dates, commitments, client-facing wording |
| Document clean-up | Improves tone, removes repetition, restructures sections | Technical accuracy and scope boundaries |
| Method statements | Creates a controlled first draft with headings and placeholders | Steps, rollback, validation and safety assumptions |
| Meeting notes to RAID | Extracts candidate risks, assumptions, issues and dependencies | Final ownership, RAG rating and whether it belongs in the log |
| Compare versions | Summarises what changed between two drafts | Whether changes create technical, commercial or delivery risk |
Basic Word prompts
Rewrite these engineer notes into a customer-facing completion report. Use sections: - Summary - Works completed - Validation performed - Open items / customer actions - Next steps Tone: professional and clear. Do not add technical claims that are not in the notes. Mark missing information as [CHECK].
Improve this document for clarity and readability. Keep the meaning the same. Do not remove technical detail. Use headings, short paragraphs and bullet points where helpful. List any sections that still need technical review.
Create a method statement skeleton for [task]. Include: - Purpose and scope - Pre-requisites - Tools / access / approvals needed - Step-by-step method - Validation checks - Rollback approach - Risks and controls - Customer communication points Use [PLACEHOLDER] for project-specific information.
RAID from notes
Keeping RAID as a documentation workflow makes more sense than treating it as a separate AI theory topic. Copilot should extract candidates; you decide what is real.
Convert these notes into RAID candidates. Return a table: Type | Description | Impact | Suggested owner | Suggested action | RAG | Evidence Rules: - Mark owners as UNCONFIRMED if not clearly stated. - Do not invent due dates. - Separately list anything that needs human judgement.
Paste a rough set of engineer notes into Word/Copilot. Produce a customer completion report, then run a second prompt asking Copilot to list every assumption it made. Correct the output before treating it as usable.
Copilot drafts a method statement and fills in a switch hostname you never provided. What should you do?
Excel basics with Copilot
Use Copilot to clean, understand and summarise Excel data without needing to be the spreadsheet expert. This is useful for trackers, patching schedules, BOM checks, cable counts and project status data.
Basic things Copilot can help with in Excel
| Need | Example |
|---|---|
| Explain a formula | What does this formula do, in plain English? |
| Create a formula | Flag duplicate cable labels or missing values |
| Clean data | Find blank rows, inconsistent labels or unexpected values |
| Summarise data | Group counts by manufacturer, cable length, service type or status |
| Create report commentary | Turn tracker data into a short management update |
Explain this Excel formula in plain English. Tell me: - What it checks - What result it returns - What assumptions it depends on - When it might give the wrong answer - A simple test row I can use to validate it
Create a formula or conditional formatting rule to highlight duplicate cable labels in column [X]. Explain how to apply it. Also give me a quick test with 3 example labels so I can confirm it works.
Review this tracker and summarise: - Items overdue - Items due in the next 7 days - Blank owners or missing dates - Rows that look out of pattern - A short management update based on the data Reference specific rows for every finding.
Review this BOM-style table. Check for: - Duplicate part numbers - Missing quantities - Missing manufacturer or description - Quantities that look unusual compared with similar rows - Items that may need clarification before ordering Return a table of findings and mark anything uncertain as CHECK.
Use a real tracker or schedule. Ask Copilot to find blanks, duplicates and inconsistent values. Then manually verify five of its findings. The goal is to learn what it catches well and what still needs your eye.
Copilot gives you a formula for duplicate cable labels. What is the safest next step?
PowerPoint basics with Copilot
Use Copilot to turn technical notes into clear slides. The aim is not pretty slides for the sake of it — it is faster project reporting and clearer customer communication.
Good deck workflow
- Prepare the content first: notes, tracker summary, risks and decisions.
- Ask for an outline before slides: check the story before generating the deck.
- One message per slide: avoid dumping paragraphs onto slides.
- Refine slide by slide: use Copilot to shorten, simplify or add speaker notes.
- Verify numbers: Copilot can carry source errors into a deck very confidently.
Create an 8-slide project update deck from these notes. Audience: customer or senior management. Slides: 1. Executive summary 2. Current status / RAG 3. Progress since last update 4. Key milestones 5. Risks and mitigations 6. Open decisions / asks 7. Next steps 8. Summary Rules: - One message per slide - Bullet points, not paragraphs - Include speaker notes for each slide - Mark missing facts as [CHECK]
Review this slide. Tell me: - The single message the audience should remember - What should be removed - What should be moved to speaker notes - A stronger slide title - A version with no more than 5 bullets
Turn these technical notes into one executive summary slide. Audience: non-technical senior stakeholder. Include: - What changed - Why it matters - Current risk level - Decision or action needed Keep it concise and avoid acronyms unless explained.
Take a recent project update, tracker summary or meeting note. Create a short deck outline first, then generate/shape the slides. Review whether the deck tells a story or just lists facts.
Copilot produces a slide with a budget number from your notes. What should you do before sending it?
Microsoft 365 Copilot as your digital coworker
This is the bit most people underuse: Copilot can help you catch up, prepare, search across work context and turn scattered information into actions. Treat it like a coworker who can read quickly, draft quickly and organise quickly — but still needs checking.
What to use it for
| Scenario | Example ask |
|---|---|
| Catch-up after leave | Summarise important emails, meetings, actions and risks from a date range |
| Meeting prep | Pull together related files, emails and previous actions before a call |
| Find work context | Search for what has been discussed about a project, customer or tool |
| Action extraction | Turn emails, chats and meeting notes into a task list |
| Drafting support | Create replies, summaries, handovers and updates from existing context |
I was out of office from [date] to [date]. Catch me up on: - Important emails - Meeting decisions - Actions assigned to me - Risks or blockers I need to know about - Anything urgent for today Group by project or topic and include sources where possible.
Prepare me for my next meeting about [project/customer/topic]. Summarise: - Why the meeting is happening - Recent relevant emails, files or meeting notes - Open actions - Likely questions or concerns - Decisions we need from the meeting - Anything I should read before joining
Find what we know about [customer/project/topic]. Look for relevant emails, files, meetings and chats. Return: - Summary of what has been discussed - Key people involved - Important decisions - Open actions - Links/sources I should review
Review these emails, chats and meeting notes. Create a task list with: Task | Owner | Due date | Priority | Source | Status Rules: - Do not invent owners or due dates. - Use UNCONFIRMED where unclear. - Put tasks assigned to me at the top.
Copilot as a coworker is most useful when you ask follow-up questions. Start broad, then narrow: “show only my actions”, “make this customer-facing”, “what changed since last week”, “what should I prioritise today?”.
Ask Copilot to prepare you for a real upcoming meeting. Then compare the prep notes against what you already know. Add two follow-up prompts to improve the result.
Copilot says a task is assigned to you, but the source is unclear. What should you do?
Verification & safe use
Everything before this made you faster. This module keeps the output safe, accurate and suitable to send.
Rule 1 · Never trust, always verify
Before AI output leaves your hands, verify:
| Always check | Because |
|---|---|
| Technical facts — versions, models, compatibility | AI generates plausible text; plausible does not mean true |
| Numbers and calculations | It can carry source errors or create new ones |
| Dates and times | Wrong windows and deadlines cause real problems |
| Names, owners, approvals | Misassigned actions or phantom sign-offs are dangerous |
| Commitments | Drafts can promise things nobody agreed to |
Rule 2 · Right tool, right data
Customer data, credentials, network configs and commercially sensitive information should only be used in approved work tools. Do not paste confidential material into consumer AI tools or unapproved browser extensions.
The 60-second review habit
- Facts: check every date, number, name and version.
- Fabrication: remove anything that appears in the output but not the source.
- Commitments: check anything the draft promises.
- Tone: make sure it is appropriate for the audience.
- Gaps: mark anything missing as [CHECK].
Review this AI-generated output before I send it. List: - Claims that need source checking - Dates, numbers or names to verify - Possible invented details - Commitments or promises in the wording - Tone risks - Missing information marked [CHECK] Do not rewrite it yet. First tell me what needs checking.
What is the safest way to use AI-generated customer-facing content?
Final assessment: working day scenario
Use the tools together. This assessment mirrors a real project-support day: schedule checks, document drafting, Excel clean-up, slide creation and Copilot catch-up.
The aim is not to prove Copilot can do everything. The aim is to use it for the first draft, the first pass, the first summary and the first check — then spend your saved time on judgement, verification and improving the final output.
What is the best overall way to use Copilot in your day-to-day work?
Prompt library
50 prompts for the work we actually do. Every one has a copy button — adapt the [BRACKETED] parts to your project and go.
Certificate
Complete all 13 modules to unlock your certificate. Progress so far: 0 / 12.
Still to do: