agentleFS
Sign inStart free
Tetteh-Yaw-PreciousTetteh-Yaw-Precious/pm-setup/SKILL.md

pm-setup

Skill0 starsChanged 34 days agoMITView on GitHub

Set up project management framework on a GitHub repo: milestones, labels, and issue triage. Use when the user wants to organize issues, create milestones, set up PM structure, or triage a backlog.

1 other project uses a version of this.

Adopted by

Most recently taken up by

  • Other versions1 project uses a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 1

    1. teslanika/pm-second-brain★ 0same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

The file

Show its rules and text

We split this skill into the rules it gives an agent

16 rules. About 0 are common, 11 are distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈11

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    If empty, auto-detect the repo from the current git directory and run status

    line 16
  2. Distinctive:

    Run all steps: labels, milestones, then triage.

    line 21
  3. Distinctive:

    Ensure these labels exist on the repo (create if missing, skip if exists):

    line 24
  4. Distinctive:

    Do NOT delete or modify existing labels.

    line 38
  5. Distinctive:

    Ask the user what milestones they need.

    line 41
  6. Very specific:

    Create them via gh api repos/{owner}/{repo}/milestones.

    line 49
  7. Distinctive:

    When the user provides meeting notes or a list of action items:

    line 72
  8. Distinctive:

    Create approved issues and assign labels + milestone

    line 76
  9. Distinctive:

    If the user asks about workflow or process:

    line 80
  10. Very specific:

    Daily: Check P0 + bug issues, fix immediately

    line 82
  11. Very specific:

    End of week: Run /pm-setup status to review progress

    line 85
  12. Distinctive:

    Never delete or close issues without user confirmation

    line 89
  13. Distinctive:

    Never change existing label colors or descriptions

    line 90
  14. Distinctive:

    Always show the user what you're about to do before bulk operations

    line 91
  15. Very specific:

    Use gh CLI for all GitHub operations

    line 92
  16. Distinctive:

    If no repo is detected, ask the user which repo to use

    line 93

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

PM Framework Setup

You are setting up a lightweight project management framework on a GitHub repository. This is designed for early-stage startups (1-5 devs) who need structure without overhead.

Arguments

$ARGUMENTS may contain:

  • A GitHub repo name (e.g., owner/repo): use it for all gh commands
  • A specific action like triage, milestones, labels, full, or status
  • If empty, auto-detect the repo from the current git directory and run status

Actions

full (default first-time setup)

Run all steps: labels, milestones, then triage.

labels

Ensure these labels exist on the repo (create if missing, skip if exists):

Priority labels:

  • P0 (color: B60205): Drop everything, blocks users or pilot
  • P1 (color: D93F0B): Fix this week, degrades experience
  • P2 (color: FBCA04): Next milestone, important but not urgent
  • P3 (color: 0E8A16): Backlog, no timeline

Type labels:

  • bug (color: D73A4A): Something broken
  • feature (color: 0075CA): New capability
  • operations (color: E4E669): Impacts current customers
  • meeting-notes (color: C5DEF5): Came from a meeting

Do NOT delete or modify existing labels. Only create missing ones.

milestones

Ask the user what milestones they need. Suggest a structure like:

  1. A near-term goal (2-4 weeks out): tied to a real event/deadline
  2. A polish phase (after the goal): feedback and fixes
  3. A growth phase (no date): scaling, new customers
  4. Backlog (no date): someday ideas

For each milestone, ask for: title, description, and due date (if any). Create them via gh api repos/{owner}/{repo}/milestones.

triage

List all open issues and help the user assign:

  1. A priority label (P0-P3)
  2. A milestone

Present issues in batches of 5-10. For each batch, suggest assignments based on:

  • Issues with bug label → likely higher priority
  • Issues tied to active customers → operations + higher priority
  • Enhancement/UI polish → likely P2-P3
  • Issues without any labels → need triage

Let the user confirm or adjust before applying. Apply via gh issue edit.

status

Show a dashboard of the current state:

  • Milestone progress (open/closed counts, % complete)
  • P0 issues (if any; these need immediate attention)
  • Issues without a milestone or priority label (untriaged)
  • Summary table

create-from-notes

When the user provides meeting notes or a list of action items:

  1. Parse out actionable items
  2. For each item, draft: title, description, suggested priority, suggested milestone
  3. Present all drafts to the user for review
  4. Create approved issues and assign labels + milestone

Weekly Rhythm (reference for the user)

If the user asks about workflow or process:

  1. Daily: Check P0 + bug issues, fix immediately
  2. Weekly: Pick 3-5 issues from current milestone, highest priority first
  3. Meetings: New items get an issue + label + milestone, not immediately built
  4. End of week: Run /pm-setup status to review progress

Rules

  • Never delete or close issues without user confirmation
  • Never change existing label colors or descriptions
  • Always show the user what you're about to do before bulk operations
  • Use gh CLI for all GitHub operations
  • If no repo is detected, ask the user which repo to use

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free