Claude Skills for Project Management

The Claude skills that pay off in project management are the jobs you already do every week in the same way: the status update, triage of new reports, turning meeting notes into tasks, release notes, and chasing work that has gone quiet. Write each one down once as a skill, connect Claude to your board so it can read and change the tasks, and the job runs the same way every time instead of depending on how well you phrased the request that morning. Below are the five, one in full, with the rules that make them safe to run. If you are still deciding between a skill and an MCP server, MCP vs Claude skills covers that; this article assumes you want both.

Where your skills will live

In the Claude apps, a custom skill is a folder with a SKILL.md in it, zipped and uploaded. Anthropic’s help article on using skills in Claude↗ (opens in a new tab) puts it under Customize, Skills: press the plus button, Create skill, then Upload a skill. Skills need code execution switched on, and on Team and Enterprise plans an owner has to enable both first. In Claude Code, a skill is the same folder placed in ~/.claude/skills/ for you, or .claude/skills/ in a repository for everyone who works in it.

The two share in one direction only, and Anthropic’s pages differ on it. The Agent Skills overview↗ (opens in a new tab) states that custom skills do not sync across surfaces, but the Claude Code documentation says that from v2.1.273 a Claude Code session signed in with a claude.ai account downloads the skills enabled on that account into ~/.claude/skills/synced/. Nothing goes the other way: a skill you write in Claude Code is not in the Claude app until you upload it. Keep the folders in one place you control and upload from there.

What every skill needs

In the Claude apps and the API, two frontmatter fields are required; in Claude Code every field is optional and only description is recommended. name is at most 64 characters of lowercase letters, numbers and hyphens, and may not contain “claude” or “anthropic”. description may run to 1,024 characters through the API, but the help article on creating custom skills↗ (opens in a new tab) caps it at 200 for uploads to the Claude apps. Either way it must say what the skill does and when to use it, because the description is the only part Claude reads until the skill is triggered. A description that only says “weekly status” will be missed; one that lists the phrases people actually use will not.

1. The weekly status

This is the one to write first, because it is the most repetitive and the easiest to check. The skill below assumes Claude is connected to a fenbs board; the tool names are fenbs’s, and any board with an MCP server will have its own.

---
name: weekly-status
description: Writes the weekly project status from the task board. Use when asked for a
  weekly update, status report, "where are we", or a summary of the week for a client
  or manager.
---

# Weekly status

1. Call fenbs_whoami, then fenbs_get_context with the project named in the request.
2. Call fenbs_list_items for each lane: done, doing, next. Keep "done" to tasks
   updated in the last 7 days.
3. Write four short sections, in this order:
   - Finished this week: one line per task, in plain words, with its ref.
   - In progress: one line each, saying what is left if the latest comment says so.
   - Next up: the top five by priority.
   - Needs a decision: tasks whose latest comment asks a question nobody answered.
4. Rules:
   - Only state what a task or its comments say. Never estimate dates.
   - No customer names. No internal refs if the reader is a client; ask if unsure.
   - Under 250 words. No adjectives about how well it went.
5. End with the refs you used, so the reader can check any line.
6. Do not change the board. This skill only reads.

Rule 6 matters more than it looks. A status skill that also “tidies up” as it goes is a skill that moves cards while you think it is reading them. Keep reading skills and writing skills separate, and you can let the reading ones run without watching.

2. Triage of new reports

The job: take what arrived in To Do since the last triage, and make each task something the team can act on. The steps worth writing into the skill:

• For each new task, fenbs_search its key words first. If an open task already covers it, comment on the older one and say which is the duplicate, rather than closing anything yourself.
• Check the kind. A report that something is broken is a bug; a request for something new is a feature; a change to something that works is an enhancement.
• Suggest a priority on the 1 to 10 scale with one line of why, as a comment. Let a person set it.
• Flag anything that looks urgent with fenbs_flag_item, so a person sees it first, and say why in a comment.
• Finish with a list: what was triaged, what looks like a duplicate, what was flagged.

3. Meeting notes to tasks

Paste the notes, name the project, and the skill sorts every line into one of three piles. Actions become tasks with fenbs_create_item, each with a note saying what was agreed and who asked. Decisions go to the board’s decisions log with fenbs_add_decision: recorded as decided only when a named person decided it in the meeting, otherwise added as open questions for someone to answer. Everything else is left in the summary, not filed.

Two rules stop this skill from filling a board with noise. It must show you the list of proposed tasks and wait for a yes before creating any, and it must file nothing for a line that has no owner or no clear action. fenbs also holds back a new task that looks like an open or recently finished one and returns the likely matches instead; tell the skill to comment on the match when that happens.

4. Release notes

List what reached Completed since the last release, group it by kind into new, improved and fixed, write one plain sentence each for the reader, and keep a separate list of anything untested or too vague to describe. The full method, including what to leave out and how to stop a task appearing in two releases, is in generating release notes with AI from finished tasks. As a skill, it is those steps plus your house style: tense, length, and whether refs appear.

5. The stale-work nudge

List In Progress, find tasks not updated for a set number of days, and comment on each one asking what is blocking it. The comment is the whole action, which makes this a good first writing skill: comments add information and move nothing. Have the skill end with the list of tasks it nudged, so you can follow up in person where a comment will not be enough.

Making them trigger, and not trigger

• Put the words people say in the description: “status”, “update”, “where are we”, “what shipped”. The description is matched against the request.
• In Claude Code, each skill can also be run on purpose as /weekly-status. For skills that write to the board, Anthropic’s Claude Code skills documentation↗ (opens in a new tab) describes disable-model-invocation: true, which means only you can start it.
• Test with a request that should not trigger it. A triage skill that wakes up when someone asks “what is triage?” needs a narrower description.
• Write the description in the third person (“Writes the weekly status…”), keep the body short, and name MCP tools with their server, as in fenbs:fenbs_list_items, so Claude finds the right one when several servers are connected. All three come from Anthropic’s skill authoring best practices↗ (opens in a new tab), which also suggest keeping SKILL.md under 500 lines and moving reference material into separate files.

Why the board connection still matters

A skill is instructions. It cannot stop Claude doing something; it can only ask it not to. What makes the writing skills safe is that the board enforces its own rules: the connection holds your role, narrowed by what you ticked when you approved it, so a skill that tries to move tasks through a connection that may only read and comment gets a refusal naming the missing permission. Every change the skills make is recorded in the board’s History under the assistant’s name. The skill gives consistency; the connection gives limits and a record.

There is a second place for know-how on fenbs: AI context, notes kept on the board that any assistant reads with fenbs_get_context. Put team facts there (“releases go out on Tuesdays”, “the client is called Acme in notes, never by name in reports”), and keep the skill for the procedure. Then Claude, ChatGPT and Cursor all read the same facts, and only the procedure is Claude-specific.

Sharing them with the team

On Team and Enterprise plans, a skill in the Claude app can be shared with named colleagues from its menu, or submitted to be published to the whole organisation. In Claude Code, commit the folder to .claude/skills/ and everyone who opens the repository has it. Either way, treat a shared skill like shared code: one owner, changes reviewed, and nobody installing a skill from a source they have not read.