Generate an ORG.md mapping team roles and decision rights from git history and artifacts.
npx skills add https://github.com/nmrtn/nanopm --skill pm-org
Please help me install this Agent Skill. Skill: pm-org Source: https://github.com/nmrtn/nanopm/tree/main/pm-org Command: npx skills add https://github.com/nmrtn/nanopm --skill pm-org
Org knowledge is often scattered, making it hard for new PMs to understand who owns what, who decides, and how the team actually works. This Skill maps roles, decision rights, and operating rhythms into a single, shareable ORG.md.
Run /pm-org to generate ORG.md for your project, documenting who does what and how decisions get made.
High-intent search queries and answers about installing and using this skill.
Map team decision rights and stakeholders by reverse-engineering git history, repo artifacts, and public pages to draft an ORG.md. This single document defines ownership, decision rights, team structure, and operating rhythms to accelerate PM onboarding and alignment.
An ORG.md file documents team structure by consolidating scattered org knowledge into defined ownership, decision rights, and ways of working. It surfaces who’s who and who decides what, making it easier for product squads to maintain alignment.
Reverse-engineer an org map from git history by collecting evidence from repo contributors, commit history, and public team pages. This evidence drafts a comprehensive ORG.md mapping roles, decision rights, and operating rhythms for teams lacking clear organizational documentation.
Yes, you can document ways of working for small to mid-sized product teams lacking clear org maps. The Skill applies to small to mid-sized teams or projects, reverse-engineering artifacts to define operating rhythms and team shape within a shareable ORG.md file.
The best way to generate an org map for a project lacking clear documentation is to run /pm-org, which collects evidence from repo history, contributors, public pages, and internal notes to draft an ORG.md with defined ownership, decision rights, and team structure.
You should not use reverse-engineering to map stakeholders and decision rights if your team's git history, repo artifacts, and public pages lack sufficient evidence to accurately determine ownership, team structure, and operating rhythms for a reliable ORG.md.
26mitch26Analyze Git commit history to generate engineering retrospective reports.
hamzashakoor119Establishes Hackathon II Todo project scope, roles, and operating model for spec-driven development.
i3ringitAnalyze git history to trace file evolution, contributors, and change patterns.
hulusi-tuncGenerates stakeholder maps, RACI matrices, decision frameworks, and communication plans for projects.
