How to create a Claude Skill for weekly project reports
Set up the report format once, then supply new notes each week. Follow the recorded workflow and inspect the original outputs, including a budget check that needs correcting.
Create a Claude Skill that turns weekly project notes into a branded Word report and a matching PDF. Give it your report brief and template once, then supply fresh notes with a short request each week. This guide includes the files, prompts and checks to try the same workflow.
In the recorded walkthrough, I used two weeks of fictional project notes. Both reports kept the main layout and updated the project details. One of the checking rules also raised an unnecessary budget warning, which I explain below. The original PDFs are included so you can inspect the result.
Watch the walkthrough: Claude Skills: Stop Rewriting Your Weekly Report
Download the starter files (ZIP, 282 KB). Free, with no sign-up. Includes the brief, branded template, two weeks of notes, prompts and the original report PDFs. This is the material for creating your skill, not an installable skill ZIP.
What is a Claude Skill?
A skill is a set of instructions and reference files you save in Claude for a particular job. It lets you reuse the same method without explaining it again in every chat. Skills can also include scripts that carry out parts of the task.
Anthropic’s explanation of skills describes how Claude loads relevant instructions and resources when it needs them.
For this report, the skill holds the writing rules, Word template and PDF reference. Each new chat supplies the current project facts. The workflow here starts when you ask for a report; it does not collect your meeting notes or send a weekly email for you.
If you write this report occasionally, attaching a brief and template each time may be enough. A skill is useful when keeping those instructions and files together makes a repeated job easier.
Before you start
Use Claude with file creation enabled and access to custom skills. In an individual account, check Settings > Capabilities for Code execution and file creation, also called Create and edit files in the updated layout. Work accounts may need an administrator to enable the relevant features.
Check Claude’s current setup instructions if the settings or upload option are missing. Interface labels can change.
Use the fictional files while learning. Before substituting real project notes, check what your employer permits you to upload. You will also need a way to open the resulting Word document and PDF.
1. Define the report you want
Open 03-Example-Report.pdf. It shows the intended layout: a navy title panel, status strip, progress and risks, decision panel, action table and a reviewer checklist. The example is the fictional Westbridge room booking pilot. Its names and facts must stay out of reports about the North Quay project.
Then read 01-Report-Brief.txt. It defines the rules behind the layout:
The download also contains 02-Example-Report.docx, the editable template. Use the Word file for document structure and the PDF as the visual reference. This gives Claude something specific to reproduce.
- Use only the current run’s notes as evidence. Preserve the supplied status and any uncertainty.
- Keep agreed dates separate from proposed dates. A request remains a request until approval is stated.
- Keep actual spend, commitments, forecast total and approved budget separate.
- Leave missing owners and dates visible. Do not turn a discussion into an assigned action.
- Produce editable Word and PDF files. Keep text readable and allow a second page when needed.
2. Ask Claude to create the skill
Start a fresh chat and attach 01-Report-Brief.txt, 02-Example-Report.docx and 03-Example-Report.pdf. Keep both weeks of source notes out of this chat. They belong in the later report runs.
I initially forgot to attach the brief during recording and had to supply it. Check the attachments before sending the request, especially when the prompt refers to a file by name.
Review the returned file list and SKILL.md before installing. The name and description help Claude identify when to use the skill. The instructions underneath tell it what to do. Check that the brief and both reference files are included, with no weekly project facts baked into the instructions.
In my run, Claude also produced a Python script to fill the template and convert the result to PDF. I did not write that script myself. A script is still part of the workflow to review: it can preserve formatting and repeat a bad checking rule just as consistently.
Anthropic’s How to create custom skills covers the instruction file, supporting resources and ZIP packaging.
Create a reusable Claude Skill named weekly-project-report from the attached brief, Word template and PDF visual reference.
The skill must turn new weekly project notes into an editable branded Word report and a matching PDF. Use the Word template as the starting document and the PDF to check the layout. Preserve the branding, status strip, decision panel, action table and reviewer checklist. Adapt the status colour to the supplied status. Use only the new notes for project facts; the example supplies layout and tone only.
Create a downloadable ZIP with one top-level folder named weekly-project-report. Include:
- SKILL.md with YAML name and description fields. Keep the description under 200 characters and say what this skill does and when to use it.
- references/report-brief.txt containing the attached brief.
- assets/example-report.docx containing the attached Word template.
- assets/example-report.pdf containing the attached visual reference.
Make SKILL.md explicitly read the brief and use both assets. Allow local code and document tools to create and check DOCX and PDF files. Preserve the embedded fonts where possible. Keep all evidence rules from the brief, including missing owners, unapproved requests and the distinction between forecast total and approved budget. Do not instruct the skill to browse for facts, send messages or update external systems.
A forecast total may exceed actual spend plus commitments because future costs may not yet be committed. Do not label that difference an error merely because it exists. Ask for a breakdown only if needed for a decision; do not invent one. Apply that rule to any script checks as well as the written instructions.
Do not include weekly source notes, a prewritten North Quay report or expected test answers. Do not package this conversation or the recording guide. Include any small supporting script only if it is needed for this document workflow; it must work with new project facts.
Show me the file list and SKILL.md text for review, and provide the skill ZIP to download. Do not claim it has been installed or tested in my account.3. Upload and enable it
Download the skill ZIP Claude created. Go to Customize > Skills, choose +, then Create skill and Upload a skill. Upload that ZIP without unpacking it, and enable weekly-project-report. Do not upload the starter-files ZIP from this page; it contains the learning materials.
If you have an older version with the same name, disable it so you know which version you are testing. Keep the same visible model setting and skill version for the next two runs.
4. Run the first week in a fresh chat
Start a new chat and attach only 04-Week-1-Notes.txt. Select weekly-project-report if your interface offers a skill picker, then use this request:
Open both files Claude returns. Check the layout against the example and the facts against the notes. In the recorded first run:
Open the original Week 1 PDF. The sponsor report fits on page 1; the private reviewer checklist is on page 2.
- The status stayed Amber. Eighteen of 20 acceptance checks passed, with two defects still open.
- The report kept written shared-mailbox confirmation as an outstanding dependency.
- Staff cover for training remained requested, with no approval invented.
- The approved budget was £18,000 and the forecast total was £16,400, including spend and commitments.
Use weekly-project-report to create this week's sponsor report from the attached notes. Return the branded Word document and matching PDF.5. Give it a different week
Start another new chat, attach only 05-Week-2-Notes.txt and use the same request. You should not need to reattach the template or rewrite the reporting rules.
The second set of notes changes the situation. Check that your report follows those changes:
The recorded second report kept those distinctions. It used two pages, with the action table and reviewer checklist on page 2. The main branded structure carried over, while the status colour and content changed.
- The status is Red. All 20 checks pass, and the earlier defects and mailbox permission issue are closed.
- 24 November remains the approved pilot date. 27 November is the supplier’s earliest possible production window, not an agreed replacement date.
- Training cover is now approved. The extra £1,200 of funding is still awaiting approval.
- The forecast total is £19,200 against an approved budget of £18,000.
- Updating the support rota has no named owner or calendar due date. The relative deadline is before the pilot.
Open the original Week 2 PDF to inspect both pages, including the budget warning discussed next.
A checking rule I would change
The Week 2 reviewer checklist flags that the £19,200 forecast is £4,700 above spend plus commitments: £10,100 + £4,400 = £14,500. It asks for confirmation that the difference is estimated remaining cost.
During recording, I described this as the forecast not adding up. That was too strong. A forecast can include future costs that are not yet committed. The notes do not break down that £4,700, but the difference alone does not establish an error. The actual budget issue is the £1,200 above the approved £18,000, which still needs a decision.
The generated SKILL.md describes a warning whenever forecast differs from spend plus commitments. I would correct that rule in both the instructions and any supporting script before using it routinely. The original PDFs remain unchanged here.
The starter brief and build prompt above now include that clarification. It was added after review of the recording; a new run using those revised instructions has not been verified. If your generated skill contains the same bad check, use this repair request in the build chat, with the skill, original report and relevant notes attached:
Review the change, install the revised skill and rerun both weeks in fresh chats. Keep the original outputs so you can compare them. A promise that the rule is fixed is not the same as a corrected report.
Review the attached skill, original report and source notes. The checking rule must not treat forecast total minus spend and commitments as an error merely because the difference is non-zero. Future costs may not yet be committed.
Find and correct that rule in both SKILL.md and any supporting script. Preserve the separate check comparing forecast total with approved budget, and keep all approval and missing-owner rules. Do not hardcode the demonstration project's figures.
Show the changed rule and provide a revised skill ZIP. Test with fictional cases where forecast is above spend plus commitments but within budget, and where it exceeds the approved budget. Report what you actually checked. Do not claim this is verified in my account.Check the report before sending it
Trace the important claims back to the notes: status, dates, budget figures, approvals and action owners. Check that Word and PDF agree and that the layout has no clipped text or broken tables. The reviewer checklist also needs judgement, as the budget example shows.
Review and remove the section marked FOR THE REPORT AUTHOR before sharing the sponsor report. For the Week 2 example, keep the action table that appears above that section on page 2.
For a broader review method, use How to check AI output before using it at work.
Adapt it to your own report
Replace the example with an approved report format you already use. Adjust the brief to match your headings, status rules and audience. Keep the recurring method inside the skill and supply current facts separately each time.
Try a second set of notes that changes an approval, closes an issue or leaves an owner missing. Those changes tell you more about the workflow than generating the same report twice. A skill saves you repeating the setup; you remain responsible for the report you send.
If you want to try building a small app next, follow Build your first task tracker with Claude Code.
Files and evidence
The starter folder contains 00-START-HERE.txt, the report brief, Word and PDF examples, Week 1 and Week 2 notes, 06-Prompts.txt, and both original report PDFs. It contains no prebuilt skill. The prompts are available on this page as well as in the download.
Updated 9 November 2026 with the recorded walkthrough and its two fictional report outputs. These examples show the layout and handling of the supplied facts; they do not establish a general reliability rate or a measured time saving. The source notes, original PDFs and generated skill text informed this review.
Source: Anthropic, What are skills?. Definition and use of instructions, resources and scripts. Checked 9 November 2026.
Source: Anthropic, Use skills in Claude. Setup, upload and enabling. Checked 9 November 2026.
Source: Anthropic, How to create custom skills. Packaging and review. Checked 9 November 2026.