# Documentation (/docs) # Documentation [#documentation] Browse the published docs for our kits and workflows. This hub keeps the catalog, install commands, and external references in one place. ## Kits [#kits] Ship a polished React + shadcn prototype in an afternoon, without writing code. Works with Gemini CLI, Claude Code, and OpenCode. Draft PMBOK and Scrum artifacts with AI, anchored to canonical sources. Works with Claude Code and Gemini CLI. Run a two-phase planning plus spec-driven development workflow for AI-assisted engineering. Documentation lives on the dedicated SpecSafe site. ## Quick install [#quick-install] ### Prototype Kit [#prototype-kit] ```bash # Claude Code /plugin marketplace add Agentic-Engineering-Agency/prototype-kit /plugin install prototype-kit@prototype-kit # Gemini CLI gemini extensions install --consent https://github.com/Agentic-Engineering-Agency/prototype-kit # OpenCode npx @agentic-engineering/prototype-kit init ``` ### PM Kit [#pm-kit] ```bash # Claude Code /plugin marketplace add Agentic-Engineering-Agency/agentic-pm-kit /plugin install agentic-pm-kit@agentic-engineering-agency # Gemini CLI gemini extensions install --consent https://github.com/Agentic-Engineering-Agency/agentic-pm-kit # Universal npx agentic-pm-kit install ``` ### SpecSafe [#specsafe] ```bash # Recommended install npm install -g @specsafe/cli # Alternative pnpm install -g @specsafe/cli # Claude Code support specsafe install claude-code # Gemini support specsafe install gemini ``` **AI agents:** Fetch [`/llms-full.txt`](/llms-full.txt) for the complete machine-readable version of all published documentation. # Installation (/docs/pm-kit/01-install) # Installation [#installation] One line starts the interactive installer that sets up your project-management Agent Skills: ```bash npx agentic-pm-kit install ``` The installer asks you **10 questions**, writes the files into your project, and records your answers in `.pm-kit.config.json`. There is no telemetry, and no network calls during installation beyond the initial npm package download. **Requirement:** Node.js 18 or later (Bun 1.0+ also works). Check with `node --version`. *** ## The install walkthrough: 10 questions [#the-install-walkthrough-10-questions]

Question 1 — Install target directory

The installer proposes your current working directory as the destination and asks if you want to use it. If you answer "No," it prompts for the absolute path to your project directory. **When to change it:** when you want to install into a repository subdirectory or a project that is not the current directory. ***

Question 2 — Project name

Free-form text. The name is used to generate the `docs/pm-kit/README.md` for your project and is stored in the config. **Example of a good answer:** `BookSwap Campus` ***

Question 3 — Project description

One sentence describing your project. Also used in the generated README and gives the skills context when you invoke them. **Example of a good answer:** `Peer-to-peer used-textbook marketplace for university students in Mexico` ***

Question 4 — Agent target(s)

Multi-select. The options are **Claude Code** and **Gemini CLI**; both are checked by default. You can choose only one if you don't use the other. **Why it matters:** the install paths are different for each agent (see [On-disk layout](#on-disk-layout) below). If you select Gemini CLI, skills are installed in a user-global location that is shared across all your Gemini projects. ***

Question 5 — Agent communication language

Free-form text. Type the language you want the agent to speak during facilitation. **Example of a good answer:** `English` Other valid options: `español`, `português`, `français`, `kichwa` — any natural language you type is stored verbatim in the config and the agent honors it. ***

Question 6 — Artifact output language

Free-form text. The language in which the agent should draft the final artifacts (charters, WBS, risk matrices, etc.). If you leave it blank, it defaults to the same language as the communication language. **When to differ:** if you want the agent to walk you through the process in Spanish but deliver artifacts in English because your client requires it, type `English` here and `español` in the previous question. ***

Question 7 — Modules to install

Multi-select. All are checked by default. The available modules are: | Module | Skills included | | -------------- | --------------------------------------------------------------------------------------------------- | | **Ideation** | Brainstorming lab with PM-curated strategies | | **Initiation** | Project charter, stakeholder register, product brief | | **Planning** | PRD, WBS, schedule/Gantt, cost estimation, risk matrix, communications, quality, and resource plans | | **Execution** | Sprint planning, story execution, standup prep, sprint review | | **Closing** | Retrospective, post-mortem, project closure report | If you only need one phase of the lifecycle, uncheck the rest. ***

Question 8 — Brainstorming deck

Single-select. The options are: * **Curated 20** (recommended): the 20 strategies optimized for PM context. This is the default. * **Full 60**: includes the 20 curated strategies plus \~40 general-purpose strategies that are not PM-specific. In v1 this option installs the curated 20-strategy deck while the additional strategies are being authored. Passing the `--full-deck` flag to the command skips this question and uses the full deck. In v1, the full deck falls back to the curated 20. ***

Question 9 — Authoritative-source mode

Single-select. The options are: * **Offline (default):** skills use only the bundled sources — the Scrum Guide 2020 and the Agile Manifesto in English and Latin American Spanish — plus the agent's general knowledge of PMBOK concepts. No network calls on each skill invocation. Predictable, no runtime network dependency, and the right choice for most use cases. * **Online (opt-in):** skills instruct the agent to fetch the relevant canonical URLs before drafting. This gives access to public PMI pages and other up-to-date sources. It does not solve access to paywalled content (full PMBOK, ISO 21500), but for users who want maximum grounding in current sources it is the right option. Passing the `--online-mode` flag to the command skips this question and enables online mode. ***

Question 10 — Install summary and final confirmation

Before writing any files, the installer shows a complete summary of all your answers: target directory, project name and description, selected agents, the paths where skills will be written, languages, modules, brainstorming deck, and source mode. You confirm with "Yes" to proceed or "No" to cancel with no changes. *** ## On-disk layout [#on-disk-layout] The installer always writes these files per project, regardless of which agents you selected: ``` / ├── docs/ │ └── pm-kit/ │ ├── README.md ← generated with your project name and description │ ├── checklists/ ← one acceptance checklist per installed artifact │ ├── templates/ ← blank starter templates per artifact │ └── outputs/ ← your agent-generated artifacts land here ├── vendor/ │ └── pm-kit/ │ ├── scrum-guide-en.md ← Scrum Guide 2020 in English (CC BY-SA 4.0) │ ├── scrum-guide-es.md ← Scrum Guide 2020 in Latin American Spanish │ ├── agile-manifesto.md ← full text + copyright notice │ └── sources-index.json ← PMI/ISO URLs with freshness dates │ └── bmad/ │ └── LICENSE ← MIT license for vendored open-source content └── .pm-kit.config.json ← your install answers; base for subsequent runs ``` The skill paths depend on which agent(s) you selected:

Claude Code only

Claude Code auto-discovers skills from the project root. No additional configuration required. ``` / └── .claude/ └── skills/ └── pm-kit/ ├── brainstorming-five-whys/ │ └── SKILL.md ├── brainstorming-question-storming/ │ └── SKILL.md ├── ... (up to 20 brainstorming strategies) ├── charter/ │ └── SKILL.md ├── stakeholder-register/ │ └── SKILL.md ├── prd/ │ └── SKILL.md └── ... (skills for installed modules) ```

Gemini CLI only

Gemini CLI discovers extensions from `~/.gemini/extensions/` at the user level, not from the project directory. This means pm-kit skills **are shared across all your Gemini CLI projects**. The installer creates an extension with a `gemini-extension.json` manifest and places skills under `~/.gemini/extensions/pm-kit/skills/`. ``` ~/ (user home directory) └── .gemini/ └── extensions/ └── pm-kit/ ├── gemini-extension.json ← extension manifest └── skills/ ├── brainstorming-five-whys/ │ └── SKILL.md ├── brainstorming-question-storming/ │ └── SKILL.md ├── ... (up to 20 brainstorming strategies) ├── charter/ │ └── SKILL.md ├── stakeholder-register/ │ └── SKILL.md └── ... (skills for installed modules) ``` **Gemini CLI is user-global.** If you have multiple Gemini CLI projects, they all share the same pm-kit installation. Reinstalling with a different config updates the global skills. If you need separate configurations per project, use Claude Code which installs per-project.

Claude Code + Gemini CLI

When you select both agents, the installer writes both trees: ``` / ├── .claude/ │ └── skills/ │ └── pm-kit/ │ └── ... (per-project skills for Claude Code) ├── docs/ │ └── pm-kit/ (always per-project) ├── vendor/ (always per-project) └── .pm-kit.config.json ~/ (user home directory) └── .gemini/ └── extensions/ └── pm-kit/ ├── gemini-extension.json └── skills/ └── ... (user-global skills for Gemini CLI) ``` *** ## Languages [#languages]

Free-form language input

The language fields accept any text string you type — there is no fixed menu. The value is stored verbatim in `.pm-kit.config.json` and passed to the agent as-is. **Languages with best coverage in bundled sources:** English and Latin American Spanish (the Scrum Guide ships in both). For any other language the agent translates on demand; quality depends on the agent's own translation capability.

`language.communication` vs `language.output`

The config stores two separate language fields: * **`language.communication`** — the language the agent uses when speaking to you during facilitation: asking questions, explaining steps, confirming decisions. This is "the agent's voice." * **`language.output`** — the language used to draft the final artifacts. This is the language of the charter, WBS, risk matrix, etc. You can set them to the same value (most common) or to different values. Example: communication in Spanish, artifacts in English for an international client. *** ## Source mode [#source-mode]

Offline (default)

Skills use only the bundled sources: the Scrum Guide 2020 (English and Latin American Spanish) and the Agile Manifesto. For PMBOK references, skills instruct the agent to cite concepts at the level of named principles and performance domains, without fabricating page numbers, direct quotations, or invented structural details. When the agent is uncertain about a specific PMBOK fact, it says so explicitly and points the reader to the canonical URL in `vendor/pm-kit/sources-index.json`. This mode is predictable, requires no per-invocation network connection, and is the right choice for most use cases.

Online (opt-in)

In online mode, skills also instruct the agent to fetch the relevant canonical URLs before drafting. This gives access to public PMI pages, the available online PMBOK table of contents, and other up-to-date sources. It does not solve access to paywalled content, but for users who want maximum grounding in current sources it is the right option. Enable it at question 9 in the installer, or pass `--online-mode` to the command: ```bash npx agentic-pm-kit install --online-mode ``` You can switch modes after the initial install through the subsequent-run menu. *** ## Subsequent runs [#subsequent-runs] When you run `npx agentic-pm-kit` (without the `install` subcommand) inside a directory that already has `.pm-kit.config.json`, the installer detects the existing installation and opens a menu with the following options: * **Add / remove modules** — install or uninstall lifecycle modules without reinstalling everything. * **Change language** — update the communication or artifact output language. * **Switch source mode** — toggle between offline and online. * **Reinstall** — refresh all skills and vendor files to the current package version (useful after `npm update`). * **Uninstall** — remove `.claude/skills/pm-kit/`, the Gemini CLI global extension, `docs/pm-kit/`, `vendor/pm-kit/`, and the config file. Artifacts you have generated in `docs/pm-kit/outputs/` are **not touched** during a reinstall; they are removed during a full uninstall. *** ## Troubleshooting [#troubleshooting]

The `npx agentic-pm-kit` command is not found

The installer requires **Node.js 18 or later**. Check your version: ```bash node --version ``` If `node` is not installed or the version is below 18, download Node.js from [nodejs.org](https://nodejs.org) (choose the LTS version). Bun 1.0+ also works: ```bash bun --version bunx agentic-pm-kit install ``` If `node` is installed but `npx` can't find the package, ensure the npm `bin` directory is in your `PATH`.

Permission errors on the Gemini CLI global install path

If the installer fails when writing to `~/.gemini/extensions/pm-kit/`, the most likely cause is that the `~/.gemini/` directory was previously created by another process running as root. To verify and fix: ```bash ls -la ~/.gemini/ # If the owner is not you, run: sudo chown -R $USER:$USER ~/.gemini/ ```

How to restart with a clean config

To run the installer from scratch as if it were the first time: ```bash rm .pm-kit.config.json npx agentic-pm-kit install ``` This removes the existing config and launches the full 10-question interactive flow. Existing skill and vendor files are overwritten with the new installation. Artifacts you have generated in `docs/pm-kit/outputs/` are not modified.

How to uninstall

```bash npx agentic-pm-kit ``` The subsequent-run menu appears automatically when `.pm-kit.config.json` is detected. Select **Uninstall** to remove: * `/.claude/skills/pm-kit/` (if Claude Code was installed) * `~/.gemini/extensions/pm-kit/` (if Gemini CLI was installed) * `/docs/pm-kit/` * `/vendor/pm-kit/` * `/.pm-kit.config.json` Artifacts in `docs/pm-kit/outputs/` are removed along with the rest during a full uninstall. Move them before uninstalling if you want to keep them. *** ## Command-line flags [#command-line-flags] | Flag | Effect | | ----------------- | ------------------------------------------------------------------------------------ | | `--full-deck` | Skips question 8 and uses the full 60-strategy deck (falls back to curated 20 in v1) | | `--online-mode` | Skips question 9 and enables online source mode | | `--help`, `-h` | Prints command help | | `--version`, `-v` | Prints the package version | The next step is to invoke your first skill. Start with the Ideation module to develop your project concept before drafting the charter. # Ideation — Brainstorming Lab (/docs/pm-kit/02-ideation) # Phase 0 — Ideation [#phase-0--ideation] Ideation is the work that happens *before* the charter. You don't yet have an approved project name, a sponsor signing paperwork, or a budget. What you have is a situation: an unsolved problem, an opportunity to explore, or a question the team hasn't been able to answer. The ideation phase converts that vague situation into a concept clear enough to start a project on solid footing. In the project management lifecycle, ideation feeds directly into the initiation phase. A well-structured concept makes the charter easier to draft, the stakeholder register more accurate, and the product brief more honest. If you skip ideation or do it superficially, every phase that follows pays the cost: the team re-debates decisions that should already be made. ## When this phase begins [#when-this-phase-begins] The ideation phase begins when someone — a sponsor, a teacher, a team — identifies a need or opportunity without a formal project existing yet. It ends when the team produces a **concept memo** that the sponsor can read and, if convinced, use as input for the charter. ***

Artifact: Brainstorming Lab

| | | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Skill** | `brainstorming-lab` | | **Type** | Router / meta-skill | | **When to use** | The team wants structured brainstorming but doesn't know which technique to use. The Lab asks diagnostic questions and recommends one or two strategies from the curated deck of 20. | | **Acceptance checklist** | `docs/pm-kit/checklists/brainstorming-lab.md` inside your installed project | **Invocation pattern.** Open your agent (Claude Code or Gemini CLI) in your project directory and instruct: > *Invoke the `brainstorming-lab` skill.* The agent first asks you to name the goal of your session. If your goal matches its shortcut table, the recommendation is immediate. If not, it falls back to up to three diagnostic questions covering problem type, team size, and available time, then recommends the most appropriate strategy. Once the selection is ready, the agent saves the rationale to `docs/pm-kit/outputs/brainstorming-lab/`. ***

How to pick the right strategy

The Brainstorming Lab is the correct entry point when you're not sure which technique to apply. But if you already know your situation, you can invoke any of the 20 strategies directly. **Start by answering these two questions:** 1. Do you need to *expand* the solution space (generate more ideas) or *narrow* it (find the best path)? 2. Where are you in the project: early discovery, a specific blocker, or a decision among already-known options? If you don't have clear answers, invoke `brainstorming-lab` and let the agent run the diagnosis. ***

The 20 strategies in the curated deck

Each strategy is a standalone skill with a facilitation script included. Invoke whichever one the Lab recommends, or choose directly if you already know the technique you need.
Show all 20 strategies | Skill | When to use | | ----------------------------------------- | ------------------------------------------------------------------------------ | | `brainstorming-five-whys` | Root-cause analysis; best for convergent problem diagnosis | | `brainstorming-question-storming` | Generate questions before answers; best for early discovery | | `brainstorming-assumption-reversal` | Flip core assumptions; best for paradigm-shift moments | | `brainstorming-constraint-mapping` | Surface and challenge limitations; best for blocked planning | | `brainstorming-failure-analysis` | Learn from failures; best for risk identification | | `brainstorming-morphological-analysis` | Systematic parameter combinations; best for complex option spaces | | `brainstorming-six-thinking-hats` | Multi-perspective parallel thinking; best for teams needing structured debate | | `brainstorming-mind-mapping` | Visual idea branching; best for solo or small-team exploration | | `brainstorming-decision-tree-mapping` | Map decision paths and outcomes; best for choice evaluation | | `brainstorming-solution-matrix` | Grid of variables and approaches; best for systematic option comparison | | `brainstorming-resource-constraints` | Extreme limitation imposition; best for forcing creative priorities | | `brainstorming-role-playing` | Stakeholder perspective embodiment; best for empathy and stakeholder discovery | | `brainstorming-brain-writing-round-robin` | Silent written idea building in rotation; best for inclusive large groups | | `brainstorming-reverse-brainstorming` | Generate problems to reveal solutions; best for risk and opportunity discovery | | `brainstorming-what-if-scenarios` | Radical possibility exploration; best for breaking stuck thinking | | `brainstorming-first-principles-thinking` | Rebuild from fundamental truths; best for breakthrough innovation | | `brainstorming-values-archaeology` | Excavate deep motivating values; best for alignment and priority conflicts | | `brainstorming-alien-anthropologist` | Outsider's bewildered perspective; best for surfacing hidden assumptions | | `brainstorming-chaos-engineering` | Deliberate stress-testing; best for resilience and risk planning | | `brainstorming-anti-solution` | Generate ways to make the problem worse; best for revealing hidden assumptions |
*** **What ideation must get right** * **Don't skip the diagnosis.** Choosing the wrong strategy produces ideas that don't fit the problem type. The Lab's short diagnosis takes minutes and saves hours later. * **Capture the reasoning, not just the ideas.** The concept memo the Lab produces must explain why the team chose that angle, not just what ideas emerged. The charter will need it. * **One approved concept, not ten.** Ideation ends when there is a single concept clear enough for the sponsor to authorize. Two or three candidates without a decision is not an ideation deliverable — it's unfinished planning work. # Initiation — Charter, Stakeholders, and Business Case (/docs/pm-kit/03-initiation) # Phase 1 — Initiation [#phase-1--initiation] Initiation is the moment a project stops being an idea and becomes a formal commitment. The sponsor signs the charter. The team identifies everyone with a stake in the outcome. And the business case documents why the work is worth doing now. This phase is not bureaucracy: it is the first opportunity for the team to understand scope, constraints, and stakeholders before the pressure of execution begins. A solid initiation prevents the late conversations that sound like "why did nobody tell us that department had a vote?" The initiation phase begins when the ideated concept has the sponsor's go-ahead to become a formal project. It ends when the charter is signed, a first-version stakeholder register exists, and the product brief documents the business rationale. ## When this phase begins [#when-this-phase-begins] Initiation starts as soon as the concept memo (or any equivalent input) has enough buy-in for the team to invest time in formalization. It does not require that ideation followed the Brainstorming Lab process — it can begin from any sponsor instruction. It ends before detailed planning. ***

Artifact 1: Project Charter

| | | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Skill** | `charter` | | **Type** | Extension — originally authored for Agentic PM Kit | | **When to use** | The sponsor is ready to formally authorize the project and needs a single document that names the work, grants authority, and sets the quality bar for every downstream planning artifact. | | **Acceptance checklist** | `docs/pm-kit/checklists/charter.md` inside your installed project | **Invocation pattern.** Open your agent in your project directory and instruct: > *Invoke the `charter` skill.* The agent will collect available inputs (concept memo, product brief), capture the project identification data, SMART objectives, scope, milestones, high-level budget, constraints, assumptions, a preliminary risk summary, and the approval signatures block. The artifact is saved to `docs/pm-kit/outputs/charter/`. **Note on ordering.** The charter consumes the concept memo from the ideation phase and in turn feeds the stakeholder register. If the product brief does not exist yet, the skill can build the charter directly from the concept memo. ***

Artifact 2: Stakeholder Register

| | | | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Skill** | `stakeholder-register` | | **Type** | Extension — originally authored for Agentic PM Kit | | **When to use** | The charter exists and the team needs to systematically identify all parties with an interest or influence in the project outcome, classify them, and document how each relationship will be managed. | | **Acceptance checklist** | `docs/pm-kit/checklists/stakeholder-register.md` inside your installed project | **Invocation pattern.** Open your agent in your project directory and instruct: > *Invoke the `stakeholder-register` skill.* The skill internally runs a structured brainstorming strategy — defaulting to `brainstorming-role-playing` or `brainstorming-six-thinking-hats` — applied against the charter to surface all interested parties. It then classifies each stakeholder in the influence × interest grid (Manage Closely / Keep Satisfied / Keep Informed / Monitor) and documents channel, cadence, and relationship owner. The artifact is saved to `docs/pm-kit/outputs/stakeholder-register/`. ***

Artifact 3: Product Brief / Business Case

| | | | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Skill** | `product-brief` | | **Type** | Adapted from open-source MIT content. See `THIRD_PARTY_NOTICES.md`. | | **When to use** | The sponsor or steering committee requires a written rationale for the project before approving initiation; the team needs to sharpen a concept or brainstorming output into a structured, presentable 1–3 page brief. | | **Acceptance checklist** | `docs/pm-kit/checklists/product-brief.md` inside your installed project | **Invocation pattern.** Open your agent in your project directory and instruct: > *Invoke the `product-brief` skill.* The agent will collect the problem statement, target users, desired outcomes with metrics, key risks, and the high-level approach. The product brief may be produced before or in parallel with the charter — it acts as the business justification, not as a substitute for the charter. The artifact is saved to `docs/pm-kit/outputs/product-brief/`. *** **What initiation must get right** * **An unsigned charter is a draft.** A charter without the signatures block is not a charter — it is a draft. The formal sign-off by the sponsor, project manager, and any additional approvers is the act that authorizes the project. Without it, the team works without a mandate. * **Don't skip the stakeholder register.** Identifying stakeholders *after* the project is underway is too late. Groups overlooked during initiation return during execution as blockers, scope changes, or product rejection. * **The product brief does not replace the charter.** The brief is the business justification; the charter is the formal authorization. Both can coexist and complement each other. Producing only one of the two leaves a gap. # Planning — From PRD to Resource Plan (/docs/pm-kit/04-planning) # Phase 2 — Planning [#phase-2--planning] Planning converts the charter authorization into a set of concrete commitments. By the end of this phase, the team knows *what* it will deliver (PRD, WBS, epics and stories), *when* (schedule with Gantt), *how much it costs* (cost estimation), *what can go wrong* (risk matrix), *how information flows* (communications plan), *to what quality standard* (quality plan), and *with what team and budget* (resource plan). This is the moment where investing time yields the highest return: an incomplete plan generates decision debt that the team pays with interest during execution. ## When this phase begins [#when-this-phase-begins] Planning begins once the charter is signed and the stakeholder register has its first approved version. Not every planning artifact must be produced in the same order for all projects, but the PRD precedes the WBS, the WBS precedes the schedule, and epics and stories feed both the WBS and the schedule. ***

Artifact 1: PRD — Product Requirements Document

| | | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Skill** | `prd` | | **Type** | Adapted from open-source MIT content. See `THIRD_PARTY_NOTICES.md`. | | **When to use** | The sponsor has approved the charter and the team must now define functional and non-functional requirements before decomposing scope into a WBS or story backlog. | | **Acceptance checklist** | `docs/pm-kit/checklists/prd.md` inside your installed project | **Invocation pattern.** > *Invoke the `prd` skill.* The agent will build the PRD in ten steps: overview, goals and non-goals, target users and use cases, functional requirements (numbered FR-01, FR-02 …), non-functional requirements, constraints and dependencies, success metrics, and open questions. The artifact is saved to `docs/pm-kit/outputs/prd/`. ***

Artifact 2: Epics and Stories

| | | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Skill** | `epics-and-stories` | | **Type** | Adapted from open-source MIT content. See `THIRD_PARTY_NOTICES.md`. | | **When to use** | The PRD has been reviewed and baselined, and the team needs an actionable story backlog with acceptance criteria before sprint planning or WBS construction. | | **Acceptance checklist** | `docs/pm-kit/checklists/epics-and-stories.md` inside your installed project | **Invocation pattern.** > *Invoke the `epics-and-stories` skill.* The agent will group functional requirements into epics, decompose each epic into user stories in the format "As a ``, I want ``, so that ``", add acceptance criteria in Gherkin notation (Given / When / Then), assign priority (Must / Should / Could), and tag dependencies between stories. The artifact is saved to `docs/pm-kit/outputs/epics-and-stories/`. ***

Artifact 3: WBS — Work Breakdown Structure

| | | | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Skill** | `wbs` | | **Type** | Extension — originally authored for Agentic PM Kit | | **When to use** | The epics-and-stories backlog is reviewed and the team needs a deliverable-oriented view of scope — rather than a feature-oriented view — before building the schedule or assigning resources. | | **Acceptance checklist** | `docs/pm-kit/checklists/wbs.md` inside your installed project | **Invocation pattern.** > *Invoke the `wbs` skill.* The agent will construct the WBS across three levels: phases or major deliverables (Level 1), sub-deliverables (Level 2), and work packages (Level 3). It will produce a Mermaid `graph TD` diagram with Level 1 and Level 2 nodes plus a representative Level 3 sample, a work-package detail table with WBS code, owner, estimated duration, and dependencies, and a WBS dictionary for the most critical or ambiguous packages. The artifact is saved to `docs/pm-kit/outputs/wbs/`. ***

Artifact 4: Schedule / Gantt

| | | | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Skill** | `schedule-gantt` | | **Type** | Extension — originally authored for Agentic PM Kit | | **When to use** | The WBS is complete and effort estimates exist; the team needs a schedule baseline with dependencies and critical path identified, in Gantt diagram format. | | **Acceptance checklist** | `docs/pm-kit/checklists/schedule-gantt.md` inside your installed project | **Invocation pattern.** > *Invoke the `schedule-gantt` skill.* The agent will assign task IDs, map dependencies, calculate the critical path, identify key milestones, and produce a Mermaid `gantt` block with sections aligned to the WBS. It will complete the task-detail table, critical-path narrative, and schedule assumptions and risks. The artifact is saved to `docs/pm-kit/outputs/schedule-gantt/`. ***

Artifact 5: Cost Estimation

| | | | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Skill** | `cost-estimation` | | **Type** | Human-led skill — the agent teaches and facilitates; the team estimates | | **When to use** | The backlog contains unsized stories or tasks and sprint planning is imminent, or a documented total estimate with a confidence range is required for a planning gate. | | **Acceptance checklist** | `docs/pm-kit/checklists/cost-estimation.md` inside your installed project | **Invocation pattern.** > *Invoke the `cost-estimation` skill.* The agent will teach three complementary techniques: **Planning Poker** (for user stories requiring team agreement, using the Fibonacci sequence), **T-shirt sizing** (for epics or features where numeric precision is not yet warranted: S / M / L / XL), and **three-point / PERT estimation** (for tasks where uncertainty warrants a probabilistic range, using the formula `E = (O + 4M + P) / 6`). The agent facilitates each round and records the values the team produces — it does not fabricate figures. The artifact is saved to `docs/pm-kit/outputs/cost-estimation/`. ***

Artifact 6: Risk Matrix

| | | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Skill** | `risk-matrix` | | **Type** | Extension — originally authored for Agentic PM Kit | | **When to use** | A planning gate or milestone review requires a formal risk register before approval; the charter is signed and the team must surface risks before execution begins. | | **Acceptance checklist** | `docs/pm-kit/checklists/risk-matrix.md` inside your installed project | **Invocation pattern.** > *Invoke the `risk-matrix` skill.* The agent will invert the project's success criteria to generate failure modes, stress-test the plan across four categories (technical, external, organizational, project management), consolidate candidates as "If `` occurs, then `` may impact ``", score each risk on probability × impact (1–5 per axis), assign a PMBOK response strategy (avoid / mitigate / transfer / accept), and produce the top-5 priority risks with concrete response plans. The artifact is saved to `docs/pm-kit/outputs/risk-matrix/`. ***

Artifact 7: Communications Plan

| | | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Skill** | `communication-plan` | | **Type** | Extension — originally authored for Agentic PM Kit | | **When to use** | The stakeholder register is complete and the project needs a formal plan governing how project information flows to each audience — who sends what, when, and through which channel. | | **Acceptance checklist** | `docs/pm-kit/checklists/communication-plan.md` inside your installed project | **Invocation pattern.** > *Invoke the `communication-plan` skill.* The agent will build a communication matrix (stakeholder × information type × cadence × channel × sender), document escalation paths for technical blockers, scope-change requests, budget variances, and stakeholder disputes, list the recurring meeting cadence (standup, sprint review, retrospective, steering committee), and document information-hygiene rules. The artifact is saved to `docs/pm-kit/outputs/communication-plan/`. ***

Artifact 8: Quality Plan

| | | | ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Skill** | `quality-plan` | | **Type** | Extension — originally authored for Agentic PM Kit | | **When to use** | The sponsor or PMO requires a written quality standard as a gate before execution approval; the team has no shared definition of what "done" or "acceptable" means for the project's deliverables. | | **Acceptance checklist** | `docs/pm-kit/checklists/quality-plan.md` inside your installed project | **Invocation pattern.** > *Invoke the `quality-plan` skill.* The agent will capture quality objectives across three dimensions (user-visible output quality, internal process quality, documentation quality), establish measurable metrics with minimum acceptable targets, define assurance activities (prevention) and control activities (detection), and identify applicable external standards (ISO, WCAG, domain regulations). The artifact is saved to `docs/pm-kit/outputs/quality-plan/`. ***

Artifact 9: Resource Plan

| | | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Skill** | `resource-plan` | | **Type** | Extension — originally authored for Agentic PM Kit | | **When to use** | The WBS and schedule are established and the sponsor needs to authorize the budget before execution begins; the team roster has open roles that must be documented. | | **Acceptance checklist** | `docs/pm-kit/checklists/resource-plan.md` inside your installed project | **Invocation pattern.** > *Invoke the `resource-plan` skill.* The agent will build the team roster with roles, assigned people (or "TBD"), allocation percentage, and join and release dates; identify equipment, software licenses, and infrastructure; produce the budget summary in four categories (people, tools and software, travel and expenses, contingency reserve); document external vendor and shared-team dependencies; and record the hiring or onboarding timeline for unfilled roles. The artifact is saved to `docs/pm-kit/outputs/resource-plan/`. *** **What planning must get right** * **Artifact order matters.** The PRD feeds epics and stories; epics and stories feed the WBS; the WBS feeds the schedule; the schedule and WBS together feed cost estimation and the resource plan. Skipping a link creates inconsistencies that become expensive to fix in execution. * **Cost estimation is done by the team, not the agent.** The cost-estimation skill teaches the techniques and facilitates the rounds, but the numbers come from the team. An agent that "estimates alone" produces figures with no owner — and without an owner there is no commitment. * **The risk matrix is not a formality.** The goal-inversion exercise and the four-category stress test are designed to surface the risks the team does not yet see. If the matrix contains only the obvious risks, the exercise is not finished. # Phase 3: Execution (/docs/pm-kit/05-execution) # Phase 3 — Execution [#phase-3--execution] The execution phase is where the plan becomes deliverable increments. Each sprint has four key moments: planning the work, executing the stories, maintaining daily synchronization, and reviewing what was built with stakeholders. This phase covers the four skills that serve those moments. The kit's three principles apply here with particular force: the agent is a drafter and facilitator, you are the PM who reviews and approves; each skill loads its authoritative source (the 2020 Scrum Guide) before facilitating; and every artifact ends at a binary acceptance checklist — **PASS** or **FAIL**. **Invocation convention.** For any skill in this phase, tell your agent: *Invoke the \ skill.* The agent will load the installed skill, read your `.pm-kit.config.json`, and begin facilitation in your configured language. ## Execution phase skills [#execution-phase-skills]

Sprint Planning

**Identifier:** `sprint-planning` — Adapted from open-source methodology (MIT). See `THIRD_PARTY_NOTICES.md`. **When to use it.** At the start of each sprint, before any delivery work begins. The Product Backlog has been refined, the Product Owner has candidates for the sprint goal, and the team needs to commit to a concrete Sprint Backlog. Do not invoke it for backlog refinement, retrospectives, or mid-sprint replanning — those events have their own skills. **How to invoke it.** Tell your agent: *Invoke the sprint-planning skill.* The agent guides you in sequence through: gathering inputs (velocity, team availability, prioritized backlog), drafting the sprint goal, calculating team capacity, selecting Sprint Backlog items, identifying risks and dependencies, confirming the Definition of Done, and producing the complete artifact. **Generated artifact.** `docs/pm-kit/outputs/sprint-planning/.md` **Acceptance checklist.** `docs/pm-kit/checklists/sprint-planning.md` ***

Story Execution (optional)

**Identifier:** `story-execution` — Adapted from open-source methodology (MIT). See `THIRD_PARTY_NOTICES.md`. **This skill is optional.** It is for teams whose project has a code-producing component — an application, a script, an integration, a data pipeline. Teams working on planning-only or research projects can skip it without losing any other execution-phase capability. **When to use it.** When a team member begins active work on a user story that involves software implementation. The story is already in the Sprint Backlog, has clear acceptance criteria, and is assigned to someone. Do not invoke it for sprint planning, standup prep, or sprint review. **How to invoke it.** Tell your agent: *Invoke the story-execution skill.* The agent guides you through: confirming the story and its acceptance criteria, defining the implementation plan, recording the tests that will verify each criterion, capturing the review outcome, verifying the Definition of Done item by item, and recording lessons learned from that story. **Generated artifact.** `docs/pm-kit/outputs/story-execution/.md` **Acceptance checklist.** `docs/pm-kit/checklists/story-execution.md` ***

Standup Prep

**Identifier:** `standup-prep` — Original Agentic PM Kit skill (MIT). **Preparation, not replacement.** This skill helps you draft your personal three-bullet note in approximately two minutes, right before walking into the Daily Scrum. It does not conduct or substitute for the Daily Scrum itself — that is a team event that happens separately, in person or over video, with the full Scrum Team present. **When to use it.** In the two minutes before your Daily Scrum meeting, when you want to quickly organize your thoughts — especially if the previous day was fragmented or a blocker has emerged that you need to articulate clearly. Do not invoke it for sprint planning, sprint review, or retrospective. **How to invoke it.** Tell your agent: *Invoke the standup-prep skill.* The agent asks you about the current sprint and sprint goal, what you finished or meaningfully advanced yesterday (connected to the sprint goal), what you are committing to today, and whether anything is blocking you or at risk of blocking you. **Generated artifact.** `docs/pm-kit/outputs/standup-prep/.md` **Acceptance checklist.** `docs/pm-kit/checklists/standup-prep.md` ***

Sprint Review

**Identifier:** `sprint-review` — Adapted from open-source methodology (MIT). See `THIRD_PARTY_NOTICES.md`. **When to use it.** At the end of the sprint, after the work is done and before the retrospective begins. The team is ready to demo the increment to stakeholders and capture their feedback systematically. Do not invoke it for mid-sprint status checks, retrospectives, or sprint planning. **How to invoke it.** Tell your agent: *Invoke the sprint-review skill.* The agent guides you through: gathering sprint inputs, reviewing whether the sprint goal was met, recording completed and incomplete stories with their reasons, capturing demo feedback organized by theme, recording decisions made during the session, and documenting signals for the next sprint's planning. **Generated artifact.** `docs/pm-kit/outputs/sprint-review/.md` **Acceptance checklist.** `docs/pm-kit/checklists/sprint-review.md` *** ## Tips for the execution phase [#tips-for-the-execution-phase] **standup-prep does not replace the Daily Scrum.** The note it generates is your personal input to the team event — not an official record and not a substitute for the live conversation. Bring your note to the Daily Scrum and use it as a guide for what to say, not as the event itself. **Run sprint-review before the retrospective.** The 2020 Scrum Guide defines the Sprint Review as the inspect-the-increment event with stakeholders, and the retrospective as the inspect-the-team-and-process event. Running them in order lets you bring review signals into the retrospective as context. **story-execution is per story, not per sprint.** Invoke it once for each story the team begins — not once at the start of the sprint for the entire Sprint Backlog. The artifact it produces is the implementation and review record for that individual story. # Phase 4: Closing (/docs/pm-kit/06-closing) # Phase 4 — Closing [#phase-4--closing] Closing is not the end of work; it is the beginning of learning. This phase groups three skills that transform the team's accumulated experience into formal artifacts: the retrospective that inspects and adapts at the sprint cadence, the post-mortem that analyzes serious incidents with a blameless posture, and the closure report that formally signs off the project before sponsors and stakeholders. Knowing which skill to invoke — retrospective or post-mortem — matters. Confusing the two produces documents ill-suited for either purpose. This page draws that distinction clearly. **Invocation convention.** For any skill in this phase, tell your agent: *Invoke the \ skill.* The agent will load the installed skill, read your `.pm-kit.config.json`, and begin facilitation in your configured language. ## Closing phase skills [#closing-phase-skills]

Retrospective

**Identifier:** `retrospective` — Adapted from open-source methodology (MIT). See `THIRD_PARTY_NOTICES.md`. **When to use it.** At the end of a sprint or iteration, when the team needs a structured inspect-and-adapt session focused on the next sprint. Also use it when recurring impediments suggest the team's working agreements need revisiting, or when a new team member has joined and a reset on norms is due. **When NOT to use it.** Do not invoke this skill for serious incidents or for retrospectives that span multiple sprints or the entire project — use the `post-mortem` skill for those. The difference is one of scale and purpose: the retrospective operates at the sprint cadence, inspects the team's process, and produces actions for the next cycle. The post-mortem operates when the damage was greater than what a sprint retro can address. **How to invoke it.** Tell your agent: *Invoke the retrospective skill.* The agent opens the session with the correct framing: "This retrospective exists to improve the next sprint, not to evaluate individuals. Describe systems, processes, and conditions — not the people who operated them." It then guides you through: capturing metadata and context, collecting what went well, what didn't go well (rewriting any bullet that points to an individual so it describes the system instead), lessons learned, and action items. Every action item must have an owner (role or team), a due date, and an observable success criterion — no "TBD" and no whole-team ownership. The agent also asks for follow-up on the previous retrospective, if one exists. The default lens is **Start / Stop / Continue**. If the team prefers, it accepts **Glad / Sad / Mad**, **4Ls**, or **Sailboat**; the agent records the choice in the artifact. **Generated artifact.** `docs/pm-kit/outputs/retrospective/.md` **Acceptance checklist.** `docs/pm-kit/checklists/retrospective.md` ***

Post-mortem

**Identifier:** `post-mortem` — Original Agentic PM Kit skill (MIT). **When to use it.** When the learning surface is larger than a single sprint: a serious incident that breached an SLA or caused customer-visible impact; a near-miss whose mechanism is worth studying; a project-level retrospective spanning multiple sprints; a release that produced outcomes materially worse than forecast; or a review required by an audit finding, a regulatory notice, or a customer escalation. **When NOT to use it.** Do not invoke this skill for the regular inspect-and-adapt session at the end of each sprint — use `retrospective`. Do not use it for root-cause analysis of an isolated defect — use `brainstorming-five-whys`. And do not use it to assign individual performance consequences: this skill is blameless by contract and refuses that framing. **The blameless posture.** This skill follows the blameless post-mortem tradition from Google SRE. The agent opens the session with the literal statement: *"This is a blameless post-mortem. We are here to make the system better, not to blame the people who operated it. Human error is a starting point for analysis, not an endpoint."* Every participant must acknowledge this posture before any data is gathered. If someone cannot accept the posture, the skill instructs the facilitator to pause the session and escalate before continuing — a post-mortem held without a blameless contract will harm the team and produce shallow findings. **Root cause analysis.** The skill applies the Five Whys pattern or an equivalent multi-layered analysis. **It rejects "human error," "operator mistake," "developer oversight," and any equivalent as a terminal root cause.** If the causal chain reaches a person, the agent asks the next why: why did the system, process, training, tooling, documentation, alerting, or incentive structure allow that person to make that error at that moment? The chain terminates only at a systemic cause the team can change. **How to invoke it.** Tell your agent: *Invoke the post-mortem skill.* The agent guides you through: declaring the blameless posture, capturing metadata, drafting an executive summary readable by someone not on the incident call, building the chronological timeline, quantifying impact (internal and external), performing root cause analysis while rejecting superficial causes, documenting contributing factors, recording what went well and what could have gone better, building the action-item table (each row requires: owner, category Prevent / Detect / Mitigate, due date, success criterion, and cross-reference to a root cause or contributing factor), and recording follow-up commitments — including where the document will be published and who oversees progress on the action items. **Generated artifact.** `docs/pm-kit/outputs/post-mortem/.md` **Acceptance checklist.** `docs/pm-kit/checklists/post-mortem.md` ***

Project Closure Report

**Identifier:** `closure-report` — Original Agentic PM Kit skill (MIT). **When to use it.** When the entire project has reached the end of its execution phase and formal closure is required: all planned deliverables have been accepted by named stakeholders, the sponsor or governance body has requested a formal closure record, lessons from retrospectives and post-mortems need to be consolidated into a single organizational artifact, the team is being reassigned and resources must be formally released, or the project record must be archived for audit, contractual, or institutional purposes. Do not invoke this skill for individual sprint retrospectives or mid-project reviews. Invoke it only when the entire project is being closed, not a single phase. **How to invoke it.** Tell your agent: *Invoke the closure-report skill.* The agent guides you through: gathering source documents (approved charter, final planned-vs-actual schedule, budget summary, scope-change records, stakeholder acceptance records, retrospective and post-mortem notes), capturing project metadata, drafting the executive summary, recording deliverables with acceptance dates and the name of the person who accepted each one, comparing objectives to actual outcomes and planned versus actual dates and budget, consolidating scope changes and lessons learned grouped into four themes (process, technical, organizational, stakeholder), documenting outstanding items and resource release, confirming artifact archival locations, and preparing the formal sign-off block for the sponsor and PM. **Generated artifact.** `docs/pm-kit/outputs/closure-report/.md` **Acceptance checklist.** `docs/pm-kit/checklists/closure-report.md` *** ## Tips for the closing phase [#tips-for-the-closing-phase] **Retrospective vs. post-mortem: choose with intention.** The retrospective is the regular event at the sprint cadence — it inspects the team's process and produces actions for the next cycle. The post-mortem is for when something went badly enough to warrant systemic analysis: serious incidents, near-misses, and project-level retrospectives. Using the retrospective for a serious incident produces shallow analysis; using the post-mortem for every sprint close produces process overload. Know the difference and choose accordingly. **A post-mortem without a blameless contract produces theater, not learning.** If the session begins without every participant explicitly acknowledging the blameless posture, the skill instructs the facilitator to pause. This is not a formality: it is the condition that lets people say what actually happened. Without it, the findings will look the same as always and the action items will never close. **The closure report consolidates, it does not duplicate.** Its value is integrating the lessons from all of the project's retrospectives and post-mortems into a single artifact readable by the sponsor. Gather your previous artifacts before invoking it — the agent asks for them in the first step of the facilitation. # Reference (/docs/pm-kit/07-reference) # Reference [#reference] This page is the complete index of the kit: all skills grouped by phase, all acceptance checklists, the MIT license summary, and the full attribution for sources and third-party trademarks. ***

1\. Skill catalog

The kit ships with 40 skills in total: 21 brainstorming skills (individual strategies plus the lab router), 10 original extension artifacts, 7 artifacts adapted from open-source sources, and 2 human-led facilitation skills. Classifications: * **\[BMad-vendored]** — content adapted from the BMad-Method repository (MIT, © 2025 BMad Code, LLC) with attribution * **\[Extension]** — original content authored specifically for Agentic PM Kit * **\[Human-led]** — the agent teaches and facilitates; the human team produces the deliverables Source links point to the Agentic Engineering Agency GitHub repository. The repository is the canonical reference; URLs are updated on each release.

Phase 0 — Ideation

| Skill | Description | Classification | | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | | `brainstorming-lab` | Routes the user to the right brainstorming strategy by asking 3–5 diagnostic questions and recommending one or two techniques from the curated 20. Invoke when the user wants to brainstorm but does not know which technique to use. | \[BMad-vendored] | | `brainstorming-five-whys` | Facilitates a Five Whys root-cause analysis. Invoke when an impediment, schedule slip, recurring defect, or stakeholder dissatisfaction signal needs root cause. | \[BMad-vendored] | | `brainstorming-question-storming` | Facilitates a Question Storming session that generates a structured question bank before any solutions are proposed. Invoke when the team suspects it is solving the wrong problem. | \[BMad-vendored] | | `brainstorming-assumption-reversal` | Facilitates an Assumption Reversal session that surfaces hidden constraints by inverting core beliefs about a challenge. Invoke to break out of conventional solution space. | \[BMad-vendored] | | `brainstorming-constraint-mapping` | Facilitates a Constraint Mapping session that identifies, categorizes, and evaluates all constraints bearing on a challenge. Invoke to distinguish real from imagined limitations. | \[BMad-vendored] | | `brainstorming-failure-analysis` | Facilitates a Failure Analysis session that extracts lessons from past failures to prevent recurrence. Invoke when the team needs to learn from an incident or failed deliverable. | \[BMad-vendored] | | `brainstorming-morphological-analysis` | Facilitates a Morphological Analysis to systematically explore parameter combinations in a complex design problem. Invoke for comprehensive solution-space mapping. | \[BMad-vendored] | | `brainstorming-six-thinking-hats` | Facilitates a Six Thinking Hats session that examines a decision from six structured perspectives. Invoke to evaluate a significant decision without collapsing into debate. | \[BMad-vendored] | | `brainstorming-mind-mapping` | Facilitates a Mind Mapping session to visually organize ideas radiating from a central concept. Invoke to structure an open-ended topic or capture a brainstorm before converging. | \[BMad-vendored] | | `brainstorming-decision-tree-mapping` | Facilitates a Decision Tree Mapping session to visualize all paths, outcomes, and risks of a complex decision. Invoke when a multi-branch decision has not been fully mapped. | \[BMad-vendored] | | `brainstorming-solution-matrix` | Facilitates a Solution Matrix session to score and rank competing options against weighted criteria. Invoke when choosing among two or more alternatives requires structured multi-criteria evaluation. | \[BMad-vendored] | | `brainstorming-resource-constraints` | Facilitates an ideation session under explicit resource constraints to generate creative options within budget, time, or capacity limits. | \[BMad-vendored] | | `brainstorming-role-playing` | Facilitates a Role Playing session to generate solutions and surface blind spots by viewing the project through multiple stakeholder perspectives. | \[BMad-vendored] | | `brainstorming-brain-writing-round-robin` | Facilitates a Brain Writing Round Robin in which participants contribute silently and sequentially to build on each other's ideas. Invoke for inclusive idea generation from distributed teams. | \[BMad-vendored] | | `brainstorming-reverse-brainstorming` | Facilitates a Reverse Brainstorming session to surface hidden risks by deliberately ideating how to cause the problem, then inverting the results. | \[BMad-vendored] | | `brainstorming-what-if-scenarios` | Facilitates a What If Scenarios session to explore plausible futures and stress-test plans. Invoke for contingency planning around changes in key assumptions. | \[BMad-vendored] | | `brainstorming-first-principles-thinking` | Facilitates a First Principles Thinking session that strips assumptions and rebuilds understanding from verified foundational truths. | \[BMad-vendored] | | `brainstorming-values-archaeology` | Facilitates a Values Archaeology session that excavates unstated values and basic assumptions driving a team's or stakeholder's decisions. | \[BMad-vendored] | | `brainstorming-alien-anthropologist` | Facilitates an Alien Anthropologist session in which the team examines its own project through the eyes of a completely uninitiated outside observer. | \[BMad-vendored] | | `brainstorming-chaos-engineering` | Facilitates a Chaos Engineering session that stress-tests a project plan by hypothesizing worst-case failures. Invoke for risk registers and pre-mortem analysis. | \[BMad-vendored] | | `brainstorming-anti-solution` | Facilitates an Anti-Solution session that generates ways to worsen the problem, then inverts those findings into overlooked solution paths. Invoke when the team is stuck on a single solution frame. | \[BMad-vendored] |

Phase 1 — Initiation

| Skill | Description | Classification | | ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | | `charter` | Drafts a PMBOK-shaped project charter from a concept memo or product brief. Invoke when the user needs a charter for initiation-phase documentation. | \[Extension] | | `stakeholder-register` | Identifies, classifies, and documents project stakeholders by running a structured brainstorming strategy against the project charter, then emits the complete register. Invoke when initiating a project or when the stakeholder landscape needs a systematic refresh. | \[Extension] | | `product-brief` | Drafts a concise business-case document covering problem statement, target users, success metrics, key risks, and high-level approach. Invoke for business documentation before or during project initiation. | \[BMad-vendored] |

Phase 2 — Planning

| Skill | Description | Classification | | -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | | `prd` | Drafts a simplified, PMBOK-compatible Product Requirements Document from a product brief and charter. Invoke when the planning phase begins before decomposing scope into a WBS or epics. | \[BMad-vendored] | | `wbs` | Constructs a PMBOK-shaped Work Breakdown Structure from the project's epic-and-story hierarchy. Invoke for scope decomposition before building a schedule or assigning resources. | \[Extension] | | `epics-and-stories` | Decomposes a PRD into Epics and INVEST-shaped User Stories with acceptance criteria and priority. Invoke when the PRD is baselined and the team needs an actionable backlog. | \[BMad-vendored] | | `schedule-gantt` | Produces a Mermaid-Gantt schedule diagram and narrative from a WBS and effort estimates. Invoke when the team needs a time-phased plan with task dependencies and critical path identification. | \[Extension] | | `cost-estimation` | Teaches three complementary estimation techniques — Planning Poker, T-shirt sizing, and three-point (PERT) — and records the estimates the team produces. The agent teaches and facilitates; the team estimates. | \[Human-led] | | `risk-matrix` | Produces a probability × impact risk matrix with PMBOK-style response strategies. Invoke before a planning gate, milestone review, or go/no-go decision. | \[Extension] | | `communication-plan` | Produces a PMBOK-shaped communication matrix, escalation paths, and meeting cadence. Invoke when the team needs a formal plan governing how project information flows to each audience. | \[Extension] | | `quality-plan` | Produces a concise quality plan defining quality objectives, measurable metrics, assurance activities, and control checkpoints. Invoke before entering execution. | \[Extension] | | `resource-plan` | Produces a concise resource plan covering team roster, equipment, budget rollup, external dependencies, and hiring timeline. Invoke when the team needs an explicit record of commitments. | \[Extension] |

Phase 3 — Execution

| Skill | Description | Classification | | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | | `sprint-planning` | Facilitates a Scrum Sprint Planning event, producing a sprint goal and a committed Sprint Backlog drawn from the prioritized Product Backlog. Invoke at the start of each sprint. | \[BMad-vendored] | | `story-execution` | Facilitates the execution and review of a single user story through implementation, testing, and acceptance. Invoke when a developer or team is ready to begin work on a backlog story with a code component. | \[BMad-vendored] | | `standup-prep` | Helps the user prepare a concise three-bullet standup note covering yesterday, today, and blockers before the Daily Scrum. Does not replace the standup; it prepares it. | \[Human-led] | | `sprint-review` | Facilitates a Scrum Sprint Review event, capturing what was built, stakeholder feedback from the demo, and decisions about the path forward. Invoke when the sprint has concluded. | \[BMad-vendored] |

Phase 4 — Closing

| Skill | Description | Classification | | ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | | `retrospective` | Facilitates a sprint or iteration retrospective that surfaces real learnings and produces owned, dated action items. Invoke when a sprint or iteration has closed. | \[BMad-vendored] | | `post-mortem` | Facilitates a blameless post-mortem for a serious incident, near-miss, or project-level retrospective. Invoke when a failure significant enough to warrant system-level learning has occurred, or when an entire project closes. | \[Extension] | | `closure-report` | Produces a PMBOK-shaped project closure report suitable for sponsor signature, consolidating charter, final schedule, final budget, retrospectives, post-mortems, and stakeholder acceptance records. Invoke at formal project closure. | \[Extension] | ***

2\. Acceptance checklists

Every artifact skill has a paired acceptance checklist installed at `docs/pm-kit/checklists/` inside your project directory. These are local paths in the installed project — they are not URLs on this site. | Artifact | Summary | Install path | | ------------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- | | Brainstorming Lab | Verifies the session produced a clear concept ready to feed the charter | `docs/pm-kit/checklists/brainstorming-lab.md` | | Five Whys | Verifies real root cause was reached (5 levels), not just a symptom | `docs/pm-kit/checklists/brainstorming-five-whys.md` | | Question Storming | Verifies the questions reframe the problem before solutions are proposed | `docs/pm-kit/checklists/brainstorming-question-storming.md` | | Assumption Reversal | Verifies inverted assumptions generated at least 3 new solution paths | `docs/pm-kit/checklists/brainstorming-assumption-reversal.md` | | Constraint Mapping | Verifies constraints are prioritized and at least one is actionable | `docs/pm-kit/checklists/brainstorming-constraint-mapping.md` | | Failure Analysis | Verifies failure patterns are documented with preventive actions | `docs/pm-kit/checklists/brainstorming-failure-analysis.md` | | Morphological Analysis | Verifies the matrix covers all relevant parameters and the chosen combination is justified | `docs/pm-kit/checklists/brainstorming-morphological-analysis.md` | | Six Thinking Hats | Verifies all six hats were covered and perspectives are kept separate | `docs/pm-kit/checklists/brainstorming-six-thinking-hats.md` | | Mind Mapping | Verifies the map captures all key topics with at least two levels of depth | `docs/pm-kit/checklists/brainstorming-mind-mapping.md` | | Decision Tree Mapping | Verifies all main branches are mapped with estimated probabilities and outcomes | `docs/pm-kit/checklists/brainstorming-decision-tree-mapping.md` | | Solution Matrix | Verifies criteria are weighted, options are scored, and the recommendation is defensible | `docs/pm-kit/checklists/brainstorming-solution-matrix.md` | | Resource Constraints | Verifies generated solutions explicitly respect the declared constraints | `docs/pm-kit/checklists/brainstorming-resource-constraints.md` | | Role Playing | Verifies at least three distinct stakeholder perspectives were represented | `docs/pm-kit/checklists/brainstorming-role-playing.md` | | Brain Writing Round Robin | Verifies all participants contributed and ideas were built across rounds | `docs/pm-kit/checklists/brainstorming-brain-writing-round-robin.md` | | Reverse Brainstorming | Verifies identified risks were inverted into concrete mitigation strategies | `docs/pm-kit/checklists/brainstorming-reverse-brainstorming.md` | | What If Scenarios | Verifies scenarios cover at least an optimistic, base, and pessimistic case | `docs/pm-kit/checklists/brainstorming-what-if-scenarios.md` | | First Principles Thinking | Verifies all inherited assumptions were questioned and rebuilt from evidence | `docs/pm-kit/checklists/brainstorming-first-principles-thinking.md` | | Values Archaeology | Verifies underlying values are documented and the root conflict is identified | `docs/pm-kit/checklists/brainstorming-values-archaeology.md` | | Alien Anthropologist | Verifies observations are in outsider voice without internal terminology | `docs/pm-kit/checklists/brainstorming-alien-anthropologist.md` | | Chaos Engineering | Verifies mapped failure scenarios feed directly into the risk register | `docs/pm-kit/checklists/brainstorming-chaos-engineering.md` | | Anti-Solution | Verifies identified anti-patterns were inverted into at least 3 actionable solutions | `docs/pm-kit/checklists/brainstorming-anti-solution.md` | | Charter | Verifies the charter names sponsor, objective, scope, milestones, and success criteria with PMBOK shape | `docs/pm-kit/checklists/charter.md` | | Stakeholder Register | Verifies each stakeholder has influence, interest, and engagement strategy documented | `docs/pm-kit/checklists/stakeholder-register.md` | | Product Brief | Verifies the business case covers problem, users, metrics, risks, and approach | `docs/pm-kit/checklists/product-brief.md` | | PRD | Verifies requirements are measurable, traceable to the charter, and prioritized | `docs/pm-kit/checklists/prd.md` | | WBS | Verifies the WBS covers 100% of scope with work packages at the appropriate level | `docs/pm-kit/checklists/wbs.md` | | Epics and Stories | Verifies each story meets INVEST criteria and has measurable acceptance criteria | `docs/pm-kit/checklists/epics-and-stories.md` | | Schedule / Gantt | Verifies the Mermaid diagram renders and the critical path is identified | `docs/pm-kit/checklists/schedule-gantt.md` | | Cost Estimation | Verifies team estimates are recorded with technique, range, and confidence level | `docs/pm-kit/checklists/cost-estimation.md` | | Risk Matrix | Verifies each risk has probability, impact, score, and response documented | `docs/pm-kit/checklists/risk-matrix.md` | | Communication Plan | Verifies each stakeholder has a channel, frequency, and communication owner assigned | `docs/pm-kit/checklists/communication-plan.md` | | Quality Plan | Verifies quality objectives are measurable and checkpoints are on the schedule | `docs/pm-kit/checklists/quality-plan.md` | | Resource Plan | Verifies the roster is complete, external dependencies documented, and budget summarized | `docs/pm-kit/checklists/resource-plan.md` | | Sprint Planning | Verifies the sprint goal is agreed and the Sprint Backlog is committed by the team | `docs/pm-kit/checklists/sprint-planning.md` | | Story Execution | Verifies the story has definition of done, tests, and Product Owner acceptance | `docs/pm-kit/checklists/story-execution.md` | | Standup Prep | Verifies the three bullets (yesterday / today / blockers) are concise and actionable | `docs/pm-kit/checklists/standup-prep.md` | | Sprint Review | Verifies the increment was demonstrated, feedback recorded, and backlog updated | `docs/pm-kit/checklists/sprint-review.md` | | Retrospective | Verifies action items have an owner, date, and team agreement | `docs/pm-kit/checklists/retrospective.md` | | Post-Mortem | Verifies the timeline is complete, contributing factors identified without blame, and systemic actions assigned | `docs/pm-kit/checklists/post-mortem.md` | | Closure Report | Verifies the report consolidates objectives vs. results, sponsor signature, and lessons learned | `docs/pm-kit/checklists/closure-report.md` | ***

3\. License

The `agentic-pm-kit` package is distributed under the **MIT License**. Summary of terms: Permission is granted, free of charge, to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the software, provided that the copyright notice and permission notice appear in all copies or substantial portions. The full license text is in the [`LICENSE`](https://github.com/agentic-engineering-agency/agentic-pm-kit/blob/main/LICENSE) file at the package repository root. ***

4\. Third-party attribution

The authoritative attribution document is [`THIRD_PARTY_NOTICES.md`](https://github.com/agentic-engineering-agency/agentic-pm-kit/blob/main/THIRD_PARTY_NOTICES.md) at the repository root. What follows is a summary for quick reference.

BMad-Method (MIT)

**Copyright:** © 2025 BMad Code, LLC **Source repository:** [https://github.com/bmad-code-org/BMAD-METHOD](https://github.com/bmad-code-org/BMAD-METHOD) **License:** MIT. Full license text: `vendor/bmad/LICENSE` (included in the package). The following skills in `agentic-pm-kit` adapt brainstorming strategies, templates, and facilitation patterns from BMad-Method under the MIT license: * The 21 brainstorming skills (individual strategies plus the lab router) * Product Brief * PRD (Product Requirements Document) * Epics and Stories * Sprint Planning * Sprint Review * Retrospective * Story Execution (optional, for teams with a code component) Each adapted skill file includes a header line of the form: `> Adapted from bmad-method: (MIT, © 2025 BMad Code, LLC). See THIRD_PARTY_NOTICES.md.`

Scrum Guide 2020 (CC BY-SA 4.0)

**Authors:** Ken Schwaber and Jeff Sutherland **Source URL:** [https://scrumguides.org/scrum-guide.html](https://scrumguides.org/scrum-guide.html) **License:** Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) [https://creativecommons.org/licenses/by-sa/4.0/legalcode](https://creativecommons.org/licenses/by-sa/4.0/legalcode) **Bundled versions:** * English: `vendor/pm-kit/scrum-guide-en.md` * Latin American Spanish: `vendor/pm-kit/scrum-guide-es.md` (translated by Lucho Salazar and Marcelo Lopez; canonical PDF URL: [https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Spanish-Latin-South-American.pdf](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Spanish-Latin-South-American.pdf)) The CC BY-SA 4.0 attribution block appears at the top of each bundled file. Downstream distributors who redistribute the bundled Scrum Guide must maintain these same terms.

Agile Manifesto (© 2001)

**Authors:** Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas **Source URLs:** [https://agilemanifesto.org/](https://agilemanifesto.org/) and [https://agilemanifesto.org/principles.html](https://agilemanifesto.org/principles.html) **Copyright notice:** © 2001, the above authors. **Reproduction terms:** "This declaration may be freely copied in any form, but only in its entirety through this notice." Bundled at: `vendor/pm-kit/agile-manifesto.md`. The file contains the complete Manifesto text — the four values, all twelve principles, the full signatories list, and the original copyright notice. ***

5\. Trademark notice

"BMad", "BMad Method", and "BMad Core" are trademarks of BMad Code, LLC (per `TRADEMARK.md` in the BMad repository). The MIT license covers source code and content; it does not grant trademark rights. Agentic PM Kit is **built on open-source methodology from BMad-Method (MIT)**. References to BMad-Method in this package are for compatibility attribution only, consistent with BMad Code, LLC's published trademark policy. The package name `agentic-pm-kit` contains no BMad trademark. Adapted skills have been renamed (for example, `bmad-product-brief` → `product-brief`); the origin is credited in the skill file's header line, not in the skill name. We do not use "BMad for PMs", "BMad PM edition", or similar formulations. Compatibility attribution appears in the skill headers and in this reference document only. ***

6\. Canonical sources

The `vendor/pm-kit/sources-index.json` file in your installation directory is the authoritative source URL registry. The table below reflects that file's contents so readers can audit where each skill anchors its content. | Key | URL | | -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `scrumGuide` | [https://scrumguides.org/scrum-guide.html](https://scrumguides.org/scrum-guide.html) | | `scrumGuideEs` | [https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Spanish-Latin-South-American.pdf](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Spanish-Latin-South-American.pdf) | | `agileManifesto` | [https://agilemanifesto.org/](https://agilemanifesto.org/) | | `agileManifestoPrinciples` | [https://agilemanifesto.org/principles.html](https://agilemanifesto.org/principles.html) | | `pmbok` | [https://www.pmi.org/standards/pmbok](https://www.pmi.org/standards/pmbok) | | `pmiTwelvePrinciples` | [https://www.pmi.org/-/media/pmi/documents/public/pdf/pmbok-standards/12-project-management-principles.pdf](https://www.pmi.org/-/media/pmi/documents/public/pdf/pmbok-standards/12-project-management-principles.pdf) | | `iso21500` | [https://www.iso.org/standard/74947.html](https://www.iso.org/standard/74947.html) | | `iso21502` | [https://www.iso.org/standard/74947.html](https://www.iso.org/standard/74947.html) | | `fiveWhys` | [https://www.lean.org/lexicon-terms/5-whys/](https://www.lean.org/lexicon-terms/5-whys/) | | `questionStorming` | [https://rightquestion.org/what-is-the-qft/](https://rightquestion.org/what-is-the-qft/) | | `assumptionReversal` | [https://en.wikipedia.org/wiki/Lateral\_thinking](https://en.wikipedia.org/wiki/Lateral_thinking) | | `constraintMapping` | [https://en.wikipedia.org/wiki/Theory\_of\_constraints](https://en.wikipedia.org/wiki/Theory_of_constraints) | | `failureAnalysis` | [https://en.wikipedia.org/wiki/Failure\_analysis](https://en.wikipedia.org/wiki/Failure_analysis) | | `morphologicalAnalysis` | [https://www.swemorph.com/ma.html](https://www.swemorph.com/ma.html) | | `sixThinkingHats` | [https://www.debonogroup.com/services/core-programs/six-thinking-hats/](https://www.debonogroup.com/services/core-programs/six-thinking-hats/) | | `mindMapping` | [https://en.wikipedia.org/wiki/Mind\_map](https://en.wikipedia.org/wiki/Mind_map) | | `decisionTreeMapping` | [https://en.wikipedia.org/wiki/Decision\_tree](https://en.wikipedia.org/wiki/Decision_tree) | | `solutionMatrix` | [https://en.wikipedia.org/wiki/Decision\_matrix](https://en.wikipedia.org/wiki/Decision_matrix) | | `resourceConstraints` | [https://en.wikipedia.org/wiki/Theory\_of\_constraints](https://en.wikipedia.org/wiki/Theory_of_constraints) | | `rolePlaying` | [https://dschool.stanford.edu/resources/design-thinking-bootleg](https://dschool.stanford.edu/resources/design-thinking-bootleg) | | `brainWritingRoundRobin` | [https://en.wikipedia.org/wiki/6-3-5\_Brainwriting](https://en.wikipedia.org/wiki/6-3-5_Brainwriting) | | `reverseBrainstorming` | [https://en.wikipedia.org/wiki/Reverse\_brainstorming](https://en.wikipedia.org/wiki/Reverse_brainstorming) | | `whatIfScenarios` | [https://en.wikipedia.org/wiki/Scenario\_planning](https://en.wikipedia.org/wiki/Scenario_planning) | | `firstPrinciplesThinking` | [https://plato.stanford.edu/entries/aristotle-logic/](https://plato.stanford.edu/entries/aristotle-logic/) | | `valuesArchaeology` | [https://en.wikipedia.org/wiki/Edgar\_Schein](https://en.wikipedia.org/wiki/Edgar_Schein) | | `alienAnthropologist` | [https://www.nngroup.com/articles/field-studies/](https://www.nngroup.com/articles/field-studies/) | | `chaosEngineering` | [https://principlesofchaos.org/](https://principlesofchaos.org/) | | `antiSolution` | [https://fs.blog/inversion/](https://fs.blog/inversion/) | | `brainstormingLab` | [https://en.wikipedia.org/wiki/Brainstorming](https://en.wikipedia.org/wiki/Brainstorming) | | `charter` | [https://www.pmi.org/-/media/pmi/documents/public/pdf/pmbok-standards/12-project-management-principles.pdf](https://www.pmi.org/-/media/pmi/documents/public/pdf/pmbok-standards/12-project-management-principles.pdf) | | `stakeholderRegister` | [https://en.wikipedia.org/wiki/Stakeholder\_analysis](https://en.wikipedia.org/wiki/Stakeholder_analysis) | | `productBrief` | [https://leanstack.com/lean-canvas](https://leanstack.com/lean-canvas) | | `prd` | [https://en.wikipedia.org/wiki/Product\_requirements\_document](https://en.wikipedia.org/wiki/Product_requirements_document) | | `wbs` | [https://en.wikipedia.org/wiki/Work\_breakdown\_structure](https://en.wikipedia.org/wiki/Work_breakdown_structure) | | `epicsAndStories` | [https://www.agilealliance.org/glossary/user-story](https://www.agilealliance.org/glossary/user-story) | | `scheduleGantt` | [https://en.wikipedia.org/wiki/Gantt\_chart](https://en.wikipedia.org/wiki/Gantt_chart) | | `costEstimation` | [https://en.wikipedia.org/wiki/Three-point\_estimation](https://en.wikipedia.org/wiki/Three-point_estimation) | | `riskMatrix` | [https://en.wikipedia.org/wiki/Risk\_matrix](https://en.wikipedia.org/wiki/Risk_matrix) | | `communicationPlan` | [https://en.wikipedia.org/wiki/Communications\_management](https://en.wikipedia.org/wiki/Communications_management) | | `qualityPlan` | [https://en.wikipedia.org/wiki/Quality\_management](https://en.wikipedia.org/wiki/Quality_management) | | `resourcePlan` | [https://en.wikipedia.org/wiki/Resource\_management](https://en.wikipedia.org/wiki/Resource_management) | | `sprintPlanning` | [https://scrumguides.org/scrum-guide.html](https://scrumguides.org/scrum-guide.html) | | `storyExecution` | [https://en.wikipedia.org/wiki/User\_story](https://en.wikipedia.org/wiki/User_story) | | `standupPrep` | [https://scrumguides.org/scrum-guide.html](https://scrumguides.org/scrum-guide.html) | | `sprintReview` | [https://scrumguides.org/scrum-guide.html](https://scrumguides.org/scrum-guide.html) | | `retrospective` | [https://scrumguides.org/scrum-guide.html](https://scrumguides.org/scrum-guide.html) | | `postMortem` | [https://sre.google/sre-book/postmortem-culture/](https://sre.google/sre-book/postmortem-culture/) | | `closureReport` | [https://en.wikipedia.org/wiki/Project\_management](https://en.wikipedia.org/wiki/Project_management) | # PM Kit (/docs/pm-kit) # Turn your AI agent into a competent drafter of PM artifacts. [#turn-your-ai-agent-into-a-competent-drafter-of-pm-artifacts] Welcome to **pm-kit** — a collection of Agent Skills your AI agent uses to draft real project-management artifacts: charters, stakeholder registers, WBS, schedules, risk matrices, retrospectives, and more. Every skill ships with its authoritative source attached and a binary acceptance checklist, so the output is anchored in PMBOK and Scrum rather than invented. Works with Claude Code and Gemini CLI. **AI agents:** Fetch [`/llms-full.txt`](/llms-full.txt) for the complete machine-readable version of this playbook. ## The thesis: three governing principles [#the-thesis-three-governing-principles] These three principles are the method of the playbook. They appear on the first page, on every chapter header, and inside every skill. ### 1. Enhance, never replace [#1-enhance-never-replace] The human PM signs the artifact. The agent drafts; you review, edit, and approve. AI is an assistant to the practitioner, never a substitute. This stance protects students from over-trusting hallucinated content, and protects working PMs from the anxiety that AI is "coming for the job." Neither: AI here is a drafting tool. ### 2. Summon the SME — automatically [#2-summon-the-sme--automatically] Any agent working on a PM artifact must be anchored to the authoritative source for that artifact (the Scrum Guide, PMBOK 7/8, domain regulations). In practice users don't have the habit of attaching documentation, so the kit does it for them: every skill carries, as a bundled or linked reference, the canonical source for the artifact it produces. The agent reads the source before drafting and cites it in the output. ### 3. Binary verification: PASS or FAIL [#3-binary-verification-pass-or-fail] Every artifact ships with a short acceptance checklist embedded in its skill. The human reviewer runs it and marks **PASS** or **FAIL**. A **FAIL** loops back to the skill with the failure notes. This discipline comes straight from the SpecSafe development methodology and ports as-is to PM artifacts: same five-step rigor, different output type. ## The lifecycle in five phases [#the-lifecycle-in-five-phases] The playbook follows the full project lifecycle, from ideation to closing. Each phase groups several artifacts; each artifact is a skill with its template and its acceptance checklist. Before the charter: the brainstorming lab guides concept selection through structured strategies. Project charter, stakeholder identification and register, business case. PRD, WBS, schedule with Gantt, cost estimation, risk matrix, communications, quality, and resource plans. Sprint planning, story execution, standup prep, sprint review. Retrospective, post-mortem, project closure report. ## Who it's for [#who-its-for] This kit was built first for PMs in training and in practice across Latin America — in particular for the *Desarrollo y Administración de Proyectos* community: teachers who need a reusable classroom asset, and students whose deliverables are graded against PMBOK and Scrum artifacts. It also serves PMs who already work with AI agents and want PMBOK-shaped outputs by default, without having to remind the agent of the source on every invocation. It is explicitly not for product managers in the digital-product sense — that space is already well served. This is for project management as taught in business, engineering, and management programs: a different and broader use case. ## What's included [#whats-included] * **20 brainstorming strategies** with facilitation scripts (with the option to install the full deck of 60). * **Charter, stakeholder register, and business case** for the initiation phase. * **PRD, WBS, schedule with Mermaid Gantt** plus communications, quality, and resource plans. * **Risk matrix** generated using Reverse Brainstorming and Chaos Engineering strategies. * **Cost estimation** via planning poker, t-shirt sizing, and three-point estimation. * **Sprint planning, sprint review, and retrospective** aligned to Scrum. * **Post-mortem and closure report** for project closing. Each artifact ships with its output template and its acceptance checklist. Outputs land in `docs/pm-kit/outputs/` inside your project. ## Languages [#languages] The installer accepts any natural language you type into the prompt — write `español`, `English`, `português`, `français`, `kichwa`, or whatever you prefer, and the agent communicates in that language. The bundled authoritative sources (the Scrum Guide and the Agile Manifesto) ship in English and in Latin American Spanish. For output in other languages the agent translates on the fly; quality depends on the agent's own translation capability. ## Install [#install] One line to start: ```bash npx agentic-pm-kit install ``` The interactive installer prompts for the target directory, the agents (Claude Code, Gemini CLI, or both), the communication language, the output language, the modules to install, and the source mode (offline by default, online opt-in). The full step-by-step walkthrough lives on the install page. ## License and attribution [#license-and-attribution] MIT. The reference page collects the full list of sources and third-party attributions. ## Phase detail [#phase-detail] The five cards above link to the playbook chapters. The [full skills catalog](/docs/pm-kit/07-reference) is available as the companion reference page.

Ideation

Brainstorming lab with 20 strategies curated for PM context (Five Whys, Question Storming, Six Thinking Hats, Role Playing, Reverse Brainstorming, Chaos Engineering, among others). The lab skill walks you through selecting the right strategy for your problem, runs the facilitation, and emits a concept memo ready to feed the charter.

Initiation

* **Project charter.** Consumes the concept memo and emits a PMBOK-shaped charter. * **Stakeholder identification and register.** Runs a brainstorming strategy (Role Playing or Six Thinking Hats) over the charter to enumerate stakeholders, and emits the register. * **Business case / product brief.** Adapted for a PM audience.

Planning

* **PRD** simplified for a PM audience. * **WBS** that consumes the epic-and-story hierarchy and emits the PMBOK-shaped breakdown. * **Epics and stories** with acceptance criteria. * **Schedule / Gantt** with a Mermaid diagram and narrative. * **Cost estimation** that teaches planning poker, t-shirt sizing, and three-point estimation with worked examples. * **Risk matrix** with probability × impact. * **Communications, quality, and resource plans.**

Execution

* **Sprint planning** and **sprint review** aligned to Scrum. * **Story execution** (optional, for teams whose project includes a code component). * **Standup prep** that helps you draft your three bullets (yesterday / today / blockers). Explicitly does not replace the standup; it prepares it.

Closing

* **Retrospective** for the sprint or the project. * **Post-mortem** for serious incidents or project-level retrospectives. * **Project closure report** with PMBOK shape as the final sign-off artifact. # Step 1: Install Gemini CLI (/docs/prototype-kit/01-install-agent) # Step 1: Install Gemini CLI [#step-1-install-gemini-cli] Gemini CLI is a free, open-source AI coding agent from Google. It runs in your terminal and can read your project files, write code, and execute commands on your behalf. **Quota:** The free tier gives you 60 model requests per minute and 1,000 requests per day — more than enough for building a prototype. See [Gemini CLI quota docs](https://ai.google.dev/gemini-api/docs/rate-limits) for current limits. ## Install Node.js first [#install-nodejs-first] Gemini CLI requires Node.js 18 or later. Check your version: ```bash # macOS / Linux node --version ``` ```powershell # Windows PowerShell node --version ``` If `node` is not found or the version is below 18, download and install Node.js from [https://nodejs.org](https://nodejs.org) (choose the LTS version). ## Install Gemini CLI [#install-gemini-cli] ```bash # macOS / Linux npm install -g @google/gemini-cli ``` ```powershell # Windows PowerShell npm install -g @google/gemini-cli ``` ## Verify the installation [#verify-the-installation] ```bash # macOS / Linux gemini --version ``` ```powershell # Windows PowerShell gemini --version ``` Expected output: a version string such as `0.x.x`. ## Sign in with your Google account [#sign-in-with-your-google-account] Launch `gemini` for the first time: ```bash # macOS / Linux gemini ``` ```powershell # Windows PowerShell gemini ``` The CLI opens a browser tab — sign in with any personal Google account. No paid plan required. Once you are signed in, the terminal shows the interactive prompt. Type `/quit` to exit and return to your shell. **Headless machines (no browser):** export a `GEMINI_API_KEY` from [Google AI Studio](https://aistudio.google.com/apikey) before launching `gemini`. If you are an AI agent reading this page, the next step is `/docs/prototype-kit/02-install-mcps`. # Step 2: Install prototype-kit (/docs/prototype-kit/02-install-mcps) # Step 2: Install prototype-kit [#step-2-install-prototype-kit] prototype-kit is a Gemini CLI extension maintained by Agentic Engineering Agency. It adds the `/prototype-from-docs` command to the agent and configures it to scaffold React + Vite + shadcn/ui projects. ## Install via Gemini CLI extensions [#install-via-gemini-cli-extensions] ```bash # macOS / Linux gemini extensions install --consent https://github.com/Agentic-Engineering-Agency/prototype-kit ``` ```powershell # Windows PowerShell gemini extensions install --consent https://github.com/Agentic-Engineering-Agency/prototype-kit ``` The `--consent` flag skips the interactive confirmation prompt. Without it, the install silently no-ops when stdin is piped (e.g., in a script). The agent will download the extension and register it automatically. You should see: ``` Extension 'prototype-kit' installed successfully. ``` ## Verify the extension is registered [#verify-the-extension-is-registered] ```bash # macOS / Linux gemini extensions list ``` ```powershell # Windows PowerShell gemini extensions list ``` Expected output includes: ``` prototype-kit v0.x.x Agentic Engineering Agency ``` ## Confirm the install on disk [#confirm-the-install-on-disk] `gemini extensions list` only renders inside an interactive `gemini` session. If you want a scriptable check, list the directory directly: ```bash # macOS / Linux ls ~/.gemini/extensions/prototype-kit/gemini-extension.json ``` ```powershell # Windows PowerShell Get-Item $HOME\.gemini\extensions\prototype-kit\gemini-extension.json ``` A file listing means the install succeeded. "No such file" means it didn't — re-run the install command with the `--consent` flag. ## Manual fallback (behind a proxy or air-gapped) [#manual-fallback-behind-a-proxy-or-air-gapped] If the GitHub URL install fails on your network (corporate proxy, captive portal, etc.), clone the repo and run the bundled installer: ```bash git clone https://github.com/Agentic-Engineering-Agency/prototype-kit.git cd prototype-kit node bin/install.js ``` The installer detects Gemini CLI, Claude Code, and OpenCode on your PATH and writes their respective configs. If you are an AI agent reading this page, the next step is `/docs/prototype-kit/03-prepare-docs`. # Step 3: Prepare your product docs (/docs/prototype-kit/03-prepare-docs) # Step 3: Prepare your product docs [#step-3-prepare-your-product-docs] The agent builds what you describe. Three documents are required. They do not need to be long — clear and specific beats long and vague every time. Create a `docs/` folder inside your project and put all three files there. The agent looks for this folder by default; any extras you drop in (screenshots, reference mockups, a PDF PRD) also get read. ```bash # macOS / Linux mkdir -p ~/my-prototype/docs touch ~/my-prototype/docs/product-brief.md ~/my-prototype/docs/ux-vibes.md ~/my-prototype/docs/screens.md ``` ```powershell # Windows PowerShell New-Item -ItemType Directory -Force $HOME\my-prototype\docs | Out-Null New-Item $HOME\my-prototype\docs\product-brief.md, $HOME\my-prototype\docs\ux-vibes.md, $HOME\my-prototype\docs\screens.md -ItemType File ``` ## Document 1: `product-brief.md` [#document-1-product-briefmd] Explain the problem, who has it, and what your app does about it. Keep it to half a page. **Template — copy and fill in the blanks:** ```markdown # Product Brief ## Problem [Describe the problem in 2-3 sentences. Be specific: who feels this problem, when, and why current solutions fall short.] ## Target user [One sentence: who is this for? Age, context, technical level.] ## Core value [One sentence: what does your app do that nothing else does as simply?] ## MVP features - [Feature 1] - [Feature 2] - [Feature 3] ``` **Example:** ```markdown # Product Brief ## Problem University students in Mexico lose track of small daily expenses — coffee, transport, tacos — and arrive at month-end with no savings and no idea where the money went. Existing budgeting apps are complex and aimed at salaried professionals. ## Target user Mexican university students aged 18-25 with irregular income and no accounting knowledge. ## Core value Log an expense in under 5 seconds with a single tap, get a weekly summary in plain Spanish. ## MVP features - Quick-log a transaction (amount + category) - Weekly spending summary - Budget goal per category ``` ## Document 2: `ux-vibes.md` [#document-2-ux-vibesmd] Describe the look and feel in plain words. The agent will translate this into color choices, typography, and component style. **Template:** ```markdown # UX Vibes ## Tone [3-5 sentences describing the mood. Example: "Clean and minimal, like a well-organized notebook. Friendly but not playful. Trusting, like a bank — but warmer."] ## Reference sites 1. [URL] — [what you like about it] 2. [URL] — [what you like about it] 3. [URL] — [what you like about it] ## Colors [Optional: mention specific colors or just describe them. Example: "Deep navy primary, warm white background, green for positive amounts, red for negative."] ## Typography [Optional: "Large numbers, thin font weight. Body text at comfortable reading size."] ``` ## Document 3: `screens.md` [#document-3-screensmd] List every screen your prototype needs. For each screen, list its purpose and the main elements it contains. **Template:** ```markdown # Screens ## Screen: [Screen name] **Purpose:** [One sentence: what does the user do here?] **Elements:** - [Element 1] - [Element 2] - [Element 3] ``` **Example:** ```markdown # Screens ## Screen: Home / Dashboard **Purpose:** Show the user their spending at a glance. **Elements:** - Current balance (large number) - This week's spending vs. budget (progress bar) - Last 5 transactions (list) - Floating "+" button to log a new expense ## Screen: Log Expense **Purpose:** Record a new transaction quickly. **Elements:** - Amount input (large numpad) - Category selector (icon grid: food, transport, entertainment, other) - Optional note field - Save button ## Screen: Weekly Summary **Purpose:** Review spending by category for the current week. **Elements:** - Bar chart: spending per category - Total spent vs. total budget - Biggest expense this week ``` If you are an AI agent reading this page, the next step is `/docs/prototype-kit/04-run-prompt`. # Step 4: Run the prototype prompt (/docs/prototype-kit/04-run-prompt) # Step 4: Run the prototype prompt [#step-4-run-the-prototype-prompt] With your three documents ready, you are ready to let the agent build. ## Open Gemini CLI in your project folder [#open-gemini-cli-in-your-project-folder] ```bash # macOS / Linux cd ~/my-prototype gemini ``` ```powershell # Windows PowerShell cd $HOME\my-prototype gemini ``` You will see a prompt that looks like: ``` Gemini CLI v1.x.x — type /help for available commands > ``` ## Run the prototype command [#run-the-prototype-command] ``` /prototype-from-docs ``` The agent will read your three documents and then ask you a series of clarifying questions. Answer each one in plain language — do not worry about technical terms. ## Clarifying questions the agent will ask [#clarifying-questions-the-agent-will-ask] The agent asks these five questions — in this order — before it touches any code. Have your answers ready. **1. Primary user persona — who is the main person using this product?** Strong answer: `"University student in Mexico, 18-25 years old, using the app on their phone between classes."` — names who, where, and when. Weak answer: `"Everyone."` — no persona = generic UI. **2. Three must-have screens — which three views must exist for the prototype to be demonstrable?** Strong answer: `"Home dashboard, Log expense, Weekly summary."` — three concrete screens the jury can click through. Weak answer: `"All the screens in screens.md."` — forces the agent to pick and probably pick wrong. **3. Brand vibe — pick two adjectives that describe the visual tone.** Strong answer: `"Minimal and authoritative."` or `"Warm and playful."` or `"Dark and technical."` Weak answer: `"Modern and clean."` — those words mean nothing; every default UI claims them. **4. Live data or mocked?** Strong answer: `"Mocked — realistic peso amounts, fake transaction history."` — makes the demo self-contained. Weak answer: `"Real if possible."` — unless you already have an API, this slows the agent down. **5. Any existing assets?** Strong answer: `"Logo at ./assets/logo.svg, primary color #1A237E, font is Inter."` or `"No assets yet, pick something."` Weak answer: Skipping the question — the agent will invent something and you may not like it. ## What happens after you answer [#what-happens-after-you-answer] The agent will generate: 1. A `prototype/` folder with the full React + Vite project 2. All screen components in `prototype/src/screens/` 3. A `prototype/README.md` with instructions to run it This takes 2-5 minutes depending on the number of screens. If you are an AI agent reading this page, the next step is `/docs/prototype-kit/05-open-prototype`. # Step 5: Open the prototype (/docs/prototype-kit/05-open-prototype) # Step 5: Open the prototype [#step-5-open-the-prototype] The agent has generated a `prototype/` folder. Now let's run it. ## Start the dev server [#start-the-dev-server] ```bash # macOS / Linux cd ~/my-prototype/prototype npm install npm run dev ``` ```powershell # Windows PowerShell cd $HOME\my-prototype\prototype npm install npm run dev ``` You should see: ``` VITE v6.x.x ready in 800ms ➜ Local: http://localhost:5173/ ➜ Network: use --host to expose ``` ## Open the prototype [#open-the-prototype] Open your browser and navigate to: ``` http://localhost:5173 ``` You will see your prototype running with all the screens you listed in `screens.md`. Use the navigation to move between screens. ## What a complete prototype looks like [#what-a-complete-prototype-looks-like] * A landing or home screen as the entry point * Sidebar or bottom navigation linking to all screens * Realistic placeholder data (numbers, names, dates) * shadcn/ui components styled to your brand colors * Responsive layout that works on mobile viewport sizes ## Troubleshooting [#troubleshooting] ### Port conflict: something is already running on port 5173 [#port-conflict-something-is-already-running-on-port-5173] ```bash # macOS / Linux npm run dev -- --port 5174 ``` ```powershell # Windows PowerShell npm run dev -- --port 5174 ``` Then open `http://localhost:5174` instead. ### Missing dependencies error [#missing-dependencies-error] If you see errors like `Cannot find module 'xxx'`, run: ```bash # macOS / Linux cd ~/my-prototype/prototype rm -rf node_modules package-lock.json npm install ``` ```powershell # Windows PowerShell cd $HOME\my-prototype\prototype Remove-Item -Recurse -Force node_modules, package-lock.json npm install ``` ### Wrong Node version [#wrong-node-version] The prototype requires Node.js 18+. If you see an error about the Node version: ```bash # macOS / Linux node --version ``` ```powershell # Windows PowerShell node --version ``` If the output is below `v18.0.0`, update Node.js from [https://nodejs.org](https://nodejs.org). ### Blank screen with no errors [#blank-screen-with-no-errors] Open your browser DevTools (F12), check the Console tab for errors, and paste the full error message into the Gemini CLI session. The agent can fix it. You have built a working prototype without writing a single line of code. Share the `http://localhost:5173` URL with your team, record a demo video, and use it to gather feedback. If you are an AI agent reading this page, you have reached the end of the guide. The full machine-readable version is available at `/llms-full.txt`. # Prototype Kit (/docs/prototype-kit) # Ship a polished prototype in an afternoon. Without writing code. [#ship-a-polished-prototype-in-an-afternoon-without-writing-code] Welcome to **prototype-kit** — a step-by-step guide for teams who want to build real React + shadcn/ui prototypes using a free AI coding agent. Works with Gemini CLI, Claude Code, and OpenCode. **AI agents:** Fetch [`/llms-full.txt`](/llms-full.txt) for the complete machine-readable version of this guide. It includes all five pages concatenated with titles and URLs as separators. ## What you will build [#what-you-will-build] A working web prototype with real screens, navigation, and styled components — generated from your product docs in about 60 minutes. ## The five steps [#the-five-steps] Install Gemini CLI on your machine and authenticate with your free Google account. Add the prototype-kit extension so the agent knows how to scaffold React projects. Write three short documents that tell the agent what to build. Open the agent, run one command, and answer its clarifying questions. Start the dev server and see your prototype in the browser. # Documentación (/es/docs) # Documentación [#documentación] Consulta la documentacion publicada de nuestros kits y flujos. Este indice mantiene en un solo lugar el catalogo, los comandos de instalacion y las referencias externas. ## Kits [#kits] Construye un prototipo pulido con React + shadcn en una tarde, sin escribir codigo. Funciona con Gemini CLI, Claude Code y OpenCode. Redacta artefactos PMBOK y Scrum con IA, anclados a fuentes canonicas. Funciona con Claude Code y Gemini CLI. Corre un flujo de planeacion e implementacion guiada por especificaciones para ingenieria asistida por IA. La documentacion vive en el sitio dedicado de SpecSafe. ## Instalacion rapida [#instalacion-rapida] ### Prototype Kit [#prototype-kit] ```bash # Claude Code /plugin marketplace add Agentic-Engineering-Agency/prototype-kit /plugin install prototype-kit@prototype-kit # Gemini CLI gemini extensions install --consent https://github.com/Agentic-Engineering-Agency/prototype-kit # OpenCode npx @agentic-engineering/prototype-kit init ``` ### PM Kit [#pm-kit] ```bash # Claude Code /plugin marketplace add Agentic-Engineering-Agency/agentic-pm-kit /plugin install agentic-pm-kit@agentic-engineering-agency # Gemini CLI gemini extensions install --consent https://github.com/Agentic-Engineering-Agency/agentic-pm-kit # Universal npx agentic-pm-kit install ``` ### SpecSafe [#specsafe] ```bash # Instalacion recomendada npm install -g @specsafe/cli # Alternativa pnpm install -g @specsafe/cli # Soporte para Claude Code specsafe install claude-code # Soporte para Gemini specsafe install gemini ``` **Agentes de IA:** Descarga [`/llms-full.txt`](/llms-full.txt) para obtener la version completa en formato legible por maquinas de toda la documentacion publicada. # Instalación (/es/docs/pm-kit/01-install) # Instalación [#instalación] Una sola línea pone en marcha el instalador interactivo que configura tus Agent Skills de gestión de proyectos: ```bash npx agentic-pm-kit install ``` El instalador te hace **10 preguntas**, escribe los archivos en tu proyecto y registra tus respuestas en `.pm-kit.config.json`. No hay telemetría, ni llamadas de red durante la instalación excepto la descarga inicial del paquete desde npm. **Requisito:** Node.js 18 o superior (Bun 1.0+ también funciona). Verifica con `node --version`. *** ## El recorrido de instalación: 10 preguntas [#el-recorrido-de-instalación-10-preguntas]

Pregunta 1 — Directorio de instalación

El instalador propone el directorio actual como destino y pregunta si quieres usarlo. Si respondes "No", te pide la ruta absoluta al directorio donde vive tu proyecto. **Cuándo cambiarlo:** cuando quieres instalar en un subdirectorio del repositorio o en un proyecto que no está en el directorio actual. ***

Pregunta 2 — Nombre del proyecto

Texto libre. El nombre se usa para generar el `docs/pm-kit/README.md` de tu proyecto y queda registrado en el config. **Ejemplo de buena respuesta:** `BookSwap Campus` ***

Pregunta 3 — Descripción del proyecto

Una oración que describa tu proyecto. También se usa en el README generado y sirve de contexto a los skills cuando los invocas. **Ejemplo de buena respuesta:** `Marketplace de libros de texto usados para estudiantes universitarios en México` ***

Pregunta 4 — Agente(s) destino

Selección múltiple. Las opciones son **Claude Code** y **Gemini CLI**; ambas vienen marcadas por defecto. Puedes elegir solo uno si no usas el otro. **Por qué importa:** los paths de instalación son distintos para cada agente (ver [Resultado en disco](#resultado-en-disco) más adelante). Si seleccionas Gemini CLI, los skills se instalan en una ubicación global de usuario, compartida entre todos tus proyectos de Gemini. ***

Pregunta 5 — Idioma de comunicación del agente

Texto libre. Escribe el idioma en el que quieres que el agente te hable durante la facilitación. **Ejemplo de buena respuesta:** `español` Otras opciones válidas: `English`, `português`, `français`, `kichwa` — cualquier idioma natural que escribas se almacena textualmente en la config y el agente lo respeta. ***

Pregunta 6 — Idioma de salida de los artefactos

Texto libre. Idioma en el que el agente debe redactar los artefactos finales (charters, WBS, matrices de riesgo, etc.). Si lo dejas en blanco, adopta el mismo idioma de comunicación. **Cuándo diferir:** si quieres que el agente te explique el proceso en español pero entregue los artefactos en inglés porque tu cliente así lo requiere, escribe `English` aquí y `español` en la pregunta anterior. ***

Pregunta 7 — Módulos a instalar

Selección múltiple. Todos vienen marcados por defecto. Los módulos disponibles son: | Módulo | Skills incluidos | | -------------- | ---------------------------------------------------------------------------------------------------------------- | | **Ideación** | Laboratorio de brainstorming con estrategias curadas para PM | | **Inicio** | Charter del proyecto, registro de stakeholders, product brief | | **Planeación** | PRD, WBS, cronograma/Gantt, estimación de costos, matriz de riesgo, planes de comunicaciones, calidad y recursos | | **Ejecución** | Sprint planning, ejecución de historias, preparación de standup, sprint review | | **Cierre** | Retrospectiva, post-mortem, reporte de cierre del proyecto | Si solo necesitas una fase del ciclo de vida, desmarca las demás. ***

Pregunta 8 — Mazo de brainstorming

Selección simple. Las opciones son: * **Curado 20** (recomendado): las 20 estrategias optimizadas para contexto PM. Esta es la opción por defecto. * **Completo 60**: incluye las 20 curadas más \~40 estrategias de propósito general que no son específicas de PM. En v1 esta opción instala el mazo curado de 20 mientras las estrategias adicionales se terminan de autorear. Si pasas la bandera `--full-deck` al comando, se omite esta pregunta y el instalador usa el mazo completo. En v1, el mazo completo cae de vuelta al curado de 20. ***

Pregunta 9 — Modo de fuentes autoritativas

Selección simple. Las opciones son: * **Offline (por defecto):** los skills usan exclusivamente las fuentes empaquetadas — la Guía Scrum 2020 y el Manifiesto Ágil en inglés y español latinoamericano — más el conocimiento general del agente sobre conceptos de PMBOK. No hay llamadas de red en cada invocación de un skill. Predecible, sin dependencias de red, y la opción correcta para la mayoría de los casos de uso. * **Online (opt-in):** los skills instruyen al agente para que obtenga las URLs canónicas relevantes antes de redactar. Esto da acceso a las páginas públicas de PMI y otras fuentes actualizadas. No soluciona el acceso a contenido detrás de paywall (PMBOK completo, ISO 21500), pero maximiza el anclaje a fuentes actuales para quienes lo necesitan. Si pasas la bandera `--online-mode` al comando, se omite esta pregunta y el instalador activa el modo online. ***

Pregunta 10 — Resumen de instalación y confirmación final

Antes de escribir cualquier archivo, el instalador muestra un resumen completo con todas tus respuestas: directorio destino, nombre y descripción del proyecto, agentes seleccionados, paths donde se escribirán los skills, idiomas, módulos, mazo de brainstorming y modo de fuentes. Confirmas con "Sí" para proceder o "No" para cancelar sin cambios. *** ## Resultado en disco [#resultado-en-disco] El instalador siempre escribe estos archivos por proyecto, sin importar los agentes que hayas seleccionado: ``` / ├── docs/ │ └── pm-kit/ │ ├── README.md ← generado con el nombre y descripción del proyecto │ ├── checklists/ ← una lista de aceptación por artefacto instalado │ ├── templates/ ← plantillas en blanco por artefacto │ └── outputs/ ← aquí caen los artefactos que el agente genera ├── vendor/ │ └── pm-kit/ │ ├── scrum-guide-en.md ← Guía Scrum 2020 en inglés (CC BY-SA 4.0) │ ├── scrum-guide-es.md ← Guía Scrum 2020 en español latinoamericano │ ├── agile-manifesto.md ← texto completo + aviso de copyright │ └── sources-index.json ← URLs de PMI/ISO con fechas de actualización │ └── bmad/ │ └── LICENSE ← licencia MIT de las fuentes de código abierto vendorizadas └── .pm-kit.config.json ← tus respuestas de instalación; base de ejecuciones subsecuentes ``` Los paths de los skills dependen del agente que hayas seleccionado:

Solo Claude Code

Claude Code descubre los skills automáticamente desde la raíz del proyecto. No se requiere ninguna configuración adicional. ``` / └── .claude/ └── skills/ └── pm-kit/ ├── brainstorming-five-whys/ │ └── SKILL.md ├── brainstorming-question-storming/ │ └── SKILL.md ├── ... (hasta 20 estrategias de brainstorming) ├── charter/ │ └── SKILL.md ├── stakeholder-register/ │ └── SKILL.md ├── prd/ │ └── SKILL.md └── ... (skills de los módulos instalados) ```

Solo Gemini CLI

Gemini CLI descubre extensiones desde `~/.gemini/extensions/` a nivel de usuario, no desde el directorio del proyecto. Esto significa que los skills de pm-kit **se comparten entre todos tus proyectos de Gemini CLI**. El instalador crea una extensión con su manifiesto `gemini-extension.json` y pone los skills bajo `~/.gemini/extensions/pm-kit/skills/`. ``` ~/ (directorio home del usuario) └── .gemini/ └── extensions/ └── pm-kit/ ├── gemini-extension.json ← manifiesto de la extensión └── skills/ ├── brainstorming-five-whys/ │ └── SKILL.md ├── brainstorming-question-storming/ │ └── SKILL.md ├── ... (hasta 20 estrategias de brainstorming) ├── charter/ │ └── SKILL.md ├── stakeholder-register/ │ └── SKILL.md └── ... (skills de los módulos instalados) ``` **Gemini CLI es global de usuario.** Si tienes varios proyectos de Gemini CLI, todos compartirán la misma instalación de pm-kit. Reinstalar con una config diferente actualiza los skills globales. Si necesitas configuraciones distintas por proyecto, usa Claude Code que sí instala por proyecto.

Claude Code + Gemini CLI

Cuando seleccionas ambos agentes, el instalador escribe los dos árboles: ``` / ├── .claude/ │ └── skills/ │ └── pm-kit/ │ └── ... (skills por proyecto para Claude Code) ├── docs/ │ └── pm-kit/ (siempre por proyecto) ├── vendor/ (siempre por proyecto) └── .pm-kit.config.json ~/ (directorio home del usuario) └── .gemini/ └── extensions/ └── pm-kit/ ├── gemini-extension.json └── skills/ └── ... (skills globales para Gemini CLI) ``` *** ## Idiomas [#idiomas]

Entrada de idioma libre

Los campos de idioma aceptan cualquier cadena de texto que escribas — no hay un menú fijo. El valor se almacena textualmente en `.pm-kit.config.json` y se pasa al agente tal como lo escribiste. **Idiomas con mejor cobertura en las fuentes empaquetadas:** inglés y español latinoamericano (la Guía Scrum está disponible en ambos). Para cualquier otro idioma el agente traduce bajo demanda; la calidad depende de la capacidad de traducción del agente.

`language.communication` vs `language.output`

El config guarda dos campos de idioma separados: * **`language.communication`** — el idioma en el que el agente te habla durante la facilitación: hace preguntas, explica pasos, confirma decisiones. Es la "voz del agente". * **`language.output`** — el idioma en el que se redactan los artefactos finales. Es el idioma del charter, del WBS, de la matriz de riesgo, etc. Puedes tenerlos iguales (lo más común) o distintos. Ejemplo: comunicación en español, artefactos en inglés para un cliente internacional. *** ## Modo de fuentes [#modo-de-fuentes]

Offline (por defecto)

Los skills usan únicamente las fuentes empaquetadas: la Guía Scrum 2020 (inglés y español latinoamericano) y el Manifiesto Ágil. Para referencias de PMBOK, los skills instruyen al agente a citar conceptos al nivel de principios nombrados y dominios de desempeño, sin fabricar números de página, citas textuales directas ni detalles estructurales inventados. Cuando el agente no está seguro de un hecho específico de PMBOK, lo dice explícitamente y apunta al lector a la URL canónica en `vendor/pm-kit/sources-index.json`. Este modo es predecible, no requiere conexión de red por invocación y es el correcto para la mayoría de los casos de uso.

Online (opt-in)

En modo online, los skills también instruyen al agente para que obtenga las URLs canónicas relevantes antes de redactar. Esto da acceso a páginas públicas de PMI, la tabla de contenidos de PMBOK disponible en línea y otras fuentes actualizadas. No soluciona el acceso a contenido detrás de paywall, pero para usuarios que quieren el máximo anclaje a fuentes actuales es la opción correcta. Actívalo en la pregunta 9 del instalador, o pasa `--online-mode` en el comando: ```bash npx agentic-pm-kit install --online-mode ``` Puedes cambiar el modo después de la instalación inicial mediante el menú de ejecuciones subsecuentes. *** ## Ejecuciones subsecuentes [#ejecuciones-subsecuentes] Cuando corres `npx agentic-pm-kit` (sin el subcomando `install`) dentro de un directorio que ya tiene `.pm-kit.config.json`, el instalador detecta la instalación existente y abre un menú con las siguientes opciones: * **Agregar / quitar módulos** — instala o desinstala módulos del ciclo de vida sin tener que reinstalar todo. * **Cambiar idioma** — actualiza el idioma de comunicación o de artefactos. * **Cambiar modo de fuentes** — alterna entre offline y online. * **Reinstalar** — refresca todos los skills y archivos de vendor a la versión actual del paquete (útil para actualizar después de `npm update`). * **Desinstalar** — elimina `.claude/skills/pm-kit/`, la extensión global de Gemini CLI, `docs/pm-kit/`, `vendor/pm-kit/` y el archivo de config. Los artefactos que hayas generado en `docs/pm-kit/outputs/` **no se tocan** durante una reinstalación; sí se eliminan en una desinstalación completa. *** ## Solución de problemas [#solución-de-problemas]

El comando `npx agentic-pm-kit` no se encuentra

El instalador requiere **Node.js 18 o superior**. Verifica tu versión: ```bash node --version ``` Si `node` no está instalado o la versión es menor a 18, descarga Node.js desde [nodejs.org](https://nodejs.org) (elige la versión LTS). Bun 1.0+ también funciona: ```bash bun --version bunx agentic-pm-kit install ``` Si `node` está instalado pero `npx` no lo reconoce, asegúrate de que el directorio `bin` de npm esté en tu `PATH`.

Problemas de permisos en la ruta global de Gemini CLI

Si el instalador falla al escribir en `~/.gemini/extensions/pm-kit/`, lo más probable es que el directorio `~/.gemini/` haya sido creado previamente por otro proceso con permisos de root. Para verificar y corregir: ```bash ls -la ~/.gemini/ # Si el propietario no eres tú, ejecuta: sudo chown -R $USER:$USER ~/.gemini/ ```

Cómo reiniciar con una config limpia

Para correr el instalador desde cero como si fuera la primera vez: ```bash rm .pm-kit.config.json npx agentic-pm-kit install ``` Esto elimina la config existente y lanza el flujo interactivo completo de 10 preguntas. Los archivos de skills y vendor existentes se sobreescriben con los de la nueva instalación. Los artefactos que hayas generado en `docs/pm-kit/outputs/` no se modifican.

Cómo desinstalar

```bash npx agentic-pm-kit ``` El menú de ejecuciones subsecuentes aparece automáticamente cuando se detecta `.pm-kit.config.json`. Selecciona **Desinstalar** para eliminar: * `/.claude/skills/pm-kit/` (si Claude Code estaba instalado) * `~/.gemini/extensions/pm-kit/` (si Gemini CLI estaba instalado) * `/docs/pm-kit/` * `/vendor/pm-kit/` * `/.pm-kit.config.json` Los artefactos en `docs/pm-kit/outputs/` se eliminan junto con el resto en una desinstalación completa. Si quieres conservarlos, muévelos antes de desinstalar. *** ## Banderas de línea de comandos [#banderas-de-línea-de-comandos] | Bandera | Efecto | | ----------------- | ---------------------------------------------------------------------------------------- | | `--full-deck` | Omite la pregunta 8 y usa el mazo completo de 60 estrategias (en v1 cae al curado de 20) | | `--online-mode` | Omite la pregunta 9 y activa el modo online | | `--help`, `-h` | Muestra la ayuda del comando | | `--version`, `-v` | Muestra la versión del paquete | El siguiente paso es invocar tu primer skill. Empieza con el módulo de Ideación para desarrollar el concepto de tu proyecto antes de redactar el charter. # Ideación — Laboratorio de Brainstorming (/es/docs/pm-kit/02-ideation) # Fase 0 — Ideación [#fase-0--ideación] La ideación es el trabajo que ocurre *antes* del charter. No tienes todavía un nombre de proyecto aprobado, ni un patrocinador firmando papeles, ni un presupuesto. Lo que tienes es una situación: un problema sin resolver, una oportunidad a explorar, o una pregunta que el equipo no ha sabido responder. La fase de ideación convierte esa situación vaga en un concepto suficientemente claro para iniciar el proyecto con confianza. En el ciclo de vida de gestión de proyectos, la ideación alimenta directamente la fase de inicio. Un concepto bien estructurado hace que el charter sea más fácil de redactar, que el registro de stakeholders sea más preciso y que el product brief sea más honesto. Si te saltas la ideación o la haces de forma superficial, todas las fases que siguen pagan el costo: el equipo vuelve a debatir lo que ya debería estar decidido. ## Cuándo comienza esta fase [#cuándo-comienza-esta-fase] La fase de ideación comienza cuando alguien — un patrocinador, un docente, un equipo — identifica una necesidad o una oportunidad sin que todavía exista un proyecto formal. Termina cuando el equipo produce un **memorando de concepto** que el patrocinador puede leer y, si está convencido, usar como insumo para el charter. ***

Artefacto: Laboratorio de Brainstorming

| | | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Skill** | `brainstorming-lab` | | **Tipo** | Enrutador / meta-skill | | **Cuándo usarlo** | El equipo quiere hacer brainstorming estructurado pero no sabe qué técnica usar. El Laboratorio hace las preguntas de diagnóstico y recomienda una o dos estrategias del mazo curado de 20. | | **Lista de aceptación** | `docs/pm-kit/checklists/brainstorming-lab.md` dentro de tu proyecto instalado | **Patrón de invocación.** Abre tu agente (Claude Code o Gemini CLI) en el directorio de tu proyecto e instruye: > *Invoca el skill `brainstorming-lab`.* El agente primero te pide que nombres el objetivo de tu sesión. Si el objetivo coincide con su tabla de atajos, la recomendación es inmediata. Si no, recurre a un máximo de tres preguntas de diagnóstico sobre el tipo de problema, el tamaño del equipo y el tiempo disponible, y al final recomienda la estrategia más apropiada. Cuando la selección esté lista, el agente guardará el razonamiento en `docs/pm-kit/outputs/brainstorming-lab/`. ***

Cómo elegir la estrategia correcta

El Laboratorio de Brainstorming es el punto de entrada correcto cuando no tienes claro cuál técnica aplicar. Pero si ya conoces tu situación, puedes invocar cualquiera de las 20 estrategias directamente. **Primero responde estas dos preguntas:** 1. ¿Necesitas *expandir* el espacio de soluciones (generar más ideas) o *reducirlo* (encontrar el mejor camino)? 2. ¿Dónde estás en el proyecto: descubrimiento temprano, una restricción específica, o una decisión entre opciones ya conocidas? Si no tienes respuestas claras, invoca `brainstorming-lab` y deja que el agente conduzca el diagnóstico. ***

Las 20 estrategias del mazo curado

Cada estrategia es un skill autónomo con un guion de facilitación incluido. Invoca la que el Laboratorio recomiende, o elige directamente si ya conoces la técnica que necesitas.
Ver las 20 estrategias | Skill | Cuándo usar | | ----------------------------------------- | ------------------------------------------------------------------------------------------------------- | | `brainstorming-five-whys` | Análisis de causa raíz; mejor para diagnóstico convergente | | `brainstorming-question-storming` | Generar preguntas antes de respuestas; mejor para descubrimiento temprano | | `brainstorming-assumption-reversal` | Invertir supuestos centrales; mejor para momentos de cambio de paradigma | | `brainstorming-constraint-mapping` | Visibilizar y cuestionar restricciones; mejor para planificación bloqueada | | `brainstorming-failure-analysis` | Aprender de fracasos; mejor para identificación de riesgos | | `brainstorming-morphological-analysis` | Combinaciones sistemáticas de parámetros; mejor para espacios de opciones complejos | | `brainstorming-six-thinking-hats` | Pensamiento paralelo desde múltiples perspectivas; mejor para equipos que necesitan debate estructurado | | `brainstorming-mind-mapping` | Ramificación visual de ideas; mejor para exploración individual o en equipo pequeño | | `brainstorming-decision-tree-mapping` | Mapear caminos de decisión y resultados; mejor para evaluación de opciones | | `brainstorming-solution-matrix` | Cuadrícula de variables y enfoques; mejor para comparación sistemática de opciones | | `brainstorming-resource-constraints` | Imposición de limitaciones extremas; mejor para forzar prioridades creativas | | `brainstorming-role-playing` | Encarnar perspectivas de stakeholders; mejor para empatía y descubrimiento de partes interesadas | | `brainstorming-brain-writing-round-robin` | Construcción escrita y silenciosa de ideas en ronda; mejor para grupos grandes e inclusivos | | `brainstorming-reverse-brainstorming` | Generar problemas para revelar soluciones; mejor para descubrimiento de riesgos y oportunidades | | `brainstorming-what-if-scenarios` | Exploración radical de posibilidades; mejor para romper el pensamiento estancado | | `brainstorming-first-principles-thinking` | Reconstruir desde verdades fundamentales; mejor para innovación disruptiva | | `brainstorming-values-archaeology` | Excavar valores motivadores profundos; mejor para conflictos de alineación y prioridades | | `brainstorming-alien-anthropologist` | Perspectiva desconcertada del forastero; mejor para descubrir supuestos ocultos | | `brainstorming-chaos-engineering` | Prueba de estrés deliberada; mejor para resiliencia y planificación de riesgos | | `brainstorming-anti-solution` | Generar formas de empeorar el problema; mejor para revelar supuestos ocultos |
*** **Lo que no debe faltar en la ideación** * **No te saltes el diagnóstico.** Elegir la estrategia equivocada produce ideas que no encajan con el tipo de problema. El breve diagnóstico del Laboratorio sólo toma minutos y ahorra horas después. * **Registra el razonamiento, no sólo las ideas.** El memorando de concepto que produce el Laboratorio debe capturar por qué el equipo eligió ese ángulo, no sólo qué ideas surgieron. El charter lo necesitará. * **Un concepto aprobado, no diez.** La ideación termina cuando hay un solo concepto lo suficientemente claro para que el patrocinador lo autorice. Dos o tres candidatos sin decisión no es un entregable de ideación — es trabajo de planeación sin terminar. # Inicio — Charter, Stakeholders y Business Case (/es/docs/pm-kit/03-initiation) # Fase 1 — Inicio [#fase-1--inicio] El inicio es el momento en que el proyecto deja de ser una idea y se convierte en un compromiso formal. El patrocinador firma el charter. El equipo identifica a todos los actores que tienen interés o influencia en el resultado. Y el business case documenta por qué el trabajo vale hacerse ahora. Esta fase no es burocracia: es la primera oportunidad para que el equipo conozca el alcance, las restricciones y los stakeholders antes de que comience la presión de la ejecución. Un inicio sólido evita las conversaciones tardías del estilo "¿por qué nadie nos dijo que ese departamento tenía voto?". La fase de inicio comienza cuando el concepto ideado tiene el visto bueno del patrocinador para convertirse en un proyecto formal. Termina cuando el charter está firmado, el registro de stakeholders existe en su primera versión, y el product brief documenta la justificación del negocio. ## Cuándo comienza esta fase [#cuándo-comienza-esta-fase] El inicio arranca en cuanto el memorando de concepto (o cualquier entrada equivalente) tiene la aprobación suficiente para que el equipo invierta tiempo en formalizar. No requiere que la ideación haya seguido el proceso del Laboratorio de Brainstorming — puede comenzar con cualquier instrucción del patrocinador. Termina antes de la planeación detallada. ***

Artefacto 1: Charter del Proyecto

| | | | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Skill** | `charter` | | **Tipo** | Extension — originalmente desarrollado para Agentic PM Kit | | **Cuándo usarlo** | El patrocinador está listo para autorizar formalmente el proyecto y necesita un documento único que nombre el trabajo, otorgue autoridad y fije el estándar de calidad para todos los artefactos de planeación posteriores. | | **Lista de aceptación** | `docs/pm-kit/checklists/charter.md` dentro de tu proyecto instalado | **Patrón de invocación.** Abre tu agente en el directorio de tu proyecto e instruye: > *Invoca el skill `charter`.* El agente recopilará los insumos disponibles (memorando de concepto, product brief), capturará los datos de identificación del proyecto, objetivos SMART, alcance, hitos, presupuesto de alto nivel, restricciones, supuestos, un resumen preliminar de riesgos y el bloque de firmas de aprobación. El artefacto se guarda en `docs/pm-kit/outputs/charter/`. **Nota sobre el orden.** El charter consume el memorando de concepto de la fase de ideación y a su vez alimenta el registro de stakeholders. Si el product brief no existe todavía, el skill puede construir el charter directamente desde el memorando de concepto. ***

Artefacto 2: Registro de Stakeholders

| | | | ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Skill** | `stakeholder-register` | | **Tipo** | Extension — originalmente desarrollado para Agentic PM Kit | | **Cuándo usarlo** | El charter existe y el equipo necesita identificar sistemáticamente a todas las partes con interés o influencia en el resultado del proyecto, clasificarlas y documentar cómo se gestionará cada relación. | | **Lista de aceptación** | `docs/pm-kit/checklists/stakeholder-register.md` dentro de tu proyecto instalado | **Patrón de invocación.** Abre tu agente en el directorio de tu proyecto e instruye: > *Invoca el skill `stakeholder-register`.* El skill ejecuta internamente una estrategia de brainstorming estructurada — por defecto `brainstorming-role-playing` o `brainstorming-six-thinking-hats` — aplicada sobre el charter para aflorar todas las partes interesadas. Después clasifica a cada stakeholder en la cuadrícula influencia × interés (Gestionar de cerca / Mantener satisfechos / Mantener informados / Monitorear) y documenta canal, cadencia y responsable de la relación. El artefacto se guarda en `docs/pm-kit/outputs/stakeholder-register/`. ***

Artefacto 3: Product Brief / Business Case

| | | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Skill** | `product-brief` | | **Tipo** | Adaptado de contenido MIT de fuente abierta. Ver `THIRD_PARTY_NOTICES.md`. | | **Cuándo usarlo** | El patrocinador o el comité de dirección requiere una justificación escrita del proyecto antes de aprobar el inicio; el equipo necesita convertir un concepto o salida de brainstorming en un brief estructurado y presentable de 1 a 3 páginas. | | **Lista de aceptación** | `docs/pm-kit/checklists/product-brief.md` dentro de tu proyecto instalado | **Patrón de invocación.** Abre tu agente en el directorio de tu proyecto e instruye: > *Invoca el skill `product-brief`.* El agente recopilará el problema, los usuarios objetivo, los resultados deseados con métricas, los riesgos clave y el enfoque de alto nivel. El product brief puede producirse antes o en paralelo al charter — actúa como justificación del negocio, no como sustituto del charter. El artefacto se guarda en `docs/pm-kit/outputs/product-brief/`. *** **Lo que no debe faltar en el inicio** * **El charter sin firma no es un charter.** Un charter no firmado es un borrador. El bloque de firmas — patrocinador, gerente de proyecto, aprobadores adicionales — es el acto formal que autoriza el proyecto. Sin él, el equipo trabaja sin mandato. * **No te saltes el registro de stakeholders.** Identificar stakeholders *después* de que el proyecto está en marcha es tarde. Los grupos de interés omitidos en el inicio regresan en la ejecución como bloqueos, cambios de alcance o rechazo del producto. * **El product brief no reemplaza al charter.** El brief es la justificación del negocio; el charter es la autorización formal. Ambos pueden coexistir y se complementan. Producir sólo uno de los dos deja un vacío. # Planeación — Del PRD al Plan de Recursos (/es/docs/pm-kit/04-planning) # Fase 2 — Planeación [#fase-2--planeación] La planeación convierte la autorización del charter en un conjunto de compromisos concretos. Al final de esta fase, el equipo sabe *qué* va a entregar (PRD, WBS, épicas e historias), *cuándo* (cronograma con Gantt), *cuánto cuesta* (estimación de costos), *qué puede salir mal* (matriz de riesgo), *cómo fluye la información* (plan de comunicaciones), *con qué estándar de calidad* (plan de calidad) y *con qué equipo y presupuesto* (plan de recursos). Este es el momento en el que invertir tiempo produce el mayor retorno: un plan incompleto genera deuda de decisión que el equipo paga con intereses durante la ejecución. ## Cuándo comienza esta fase [#cuándo-comienza-esta-fase] La planeación comienza una vez que el charter está firmado y el registro de stakeholders tiene su primera versión aprobada. No es necesario que todos los artefactos de planeación se produzcan en el mismo orden para todos los proyectos, pero el PRD precede al WBS, el WBS precede al cronograma, y las épicas e historias alimentan tanto al WBS como al cronograma. ***

Artefacto 1: PRD — Documento de Requisitos del Producto

| | | | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Skill** | `prd` | | **Tipo** | Adaptado de contenido MIT de fuente abierta. Ver `THIRD_PARTY_NOTICES.md`. | | **Cuándo usarlo** | El patrocinador aprobó el charter y el equipo debe definir los requisitos funcionales y no funcionales antes de descomponer el alcance en un WBS o un backlog de historias. | | **Lista de aceptación** | `docs/pm-kit/checklists/prd.md` dentro de tu proyecto instalado | **Patrón de invocación.** > *Invoca el skill `prd`.* El agente construirá el PRD en diez pasos: descripción general, metas y no-metas, usuarios y casos de uso, requisitos funcionales (numerados FR-01, FR-02 …), requisitos no funcionales, restricciones y dependencias, métricas de éxito y preguntas abiertas. El artefacto se guarda en `docs/pm-kit/outputs/prd/`. ***

Artefacto 2: Épicas e Historias

| | | | ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Skill** | `epics-and-stories` | | **Tipo** | Adaptado de contenido MIT de fuente abierta. Ver `THIRD_PARTY_NOTICES.md`. | | **Cuándo usarlo** | El PRD está revisado y aprobado, y el equipo necesita un backlog de historias accionables con criterios de aceptación antes del sprint planning o la construcción de la WBS. | | **Lista de aceptación** | `docs/pm-kit/checklists/epics-and-stories.md` dentro de tu proyecto instalado | **Patrón de invocación.** > *Invoca el skill `epics-and-stories`.* El agente agrupará los requisitos funcionales en épicas, descompondrá cada épica en historias con formato "Como ``, quiero ``, para que ``", añadirá criterios de aceptación en notación Gherkin (Dado / Cuando / Entonces), asignará prioridad (Debe / Debería / Podría) y marcará dependencias entre historias. El artefacto se guarda en `docs/pm-kit/outputs/epics-and-stories/`. ***

Artefacto 3: WBS — Estructura de Desglose del Trabajo

| | | | ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Skill** | `wbs` | | **Tipo** | Extension — originalmente desarrollado para Agentic PM Kit | | **Cuándo usarlo** | El backlog de épicas e historias está revisado y el equipo necesita una vista orientada a entregables del alcance — en lugar de una vista orientada a funcionalidades — antes de construir el cronograma o asignar recursos. | | **Lista de aceptación** | `docs/pm-kit/checklists/wbs.md` dentro de tu proyecto instalado | **Patrón de invocación.** > *Invoca el skill `wbs`.* El agente construirá la WBS en tres niveles: fases o entregables principales (Nivel 1), sub-entregables (Nivel 2) y paquetes de trabajo (Nivel 3). Producirá un diagrama Mermaid `graph TD` con los nodos de Nivel 1 y Nivel 2 más una muestra representativa del Nivel 3, una tabla de detalle de paquetes de trabajo con código WBS, propietario, duración estimada y dependencias, y un diccionario WBS para los paquetes más críticos o ambiguos. El artefacto se guarda en `docs/pm-kit/outputs/wbs/`. ***

Artefacto 4: Cronograma / Gantt

| | | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Skill** | `schedule-gantt` | | **Tipo** | Extension — originalmente desarrollado para Agentic PM Kit | | **Cuándo usarlo** | La WBS está completa y las estimaciones de esfuerzo existen; el equipo necesita un cronograma base con dependencias y ruta crítica identificada, en formato de diagrama Gantt. | | **Lista de aceptación** | `docs/pm-kit/checklists/schedule-gantt.md` dentro de tu proyecto instalado | **Patrón de invocación.** > *Invoca el skill `schedule-gantt`.* El agente asignará IDs de tarea, mapeará dependencias, calculará la ruta crítica, identificará hitos clave y producirá un bloque `gantt` de Mermaid con secciones alineadas a la WBS. Completará la tabla de detalle de tareas, la narrativa de ruta crítica y los supuestos y riesgos del cronograma. El artefacto se guarda en `docs/pm-kit/outputs/schedule-gantt/`. ***

Artefacto 5: Estimación de Costos

| | | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Skill** | `cost-estimation` | | **Tipo** | Skill liderado por el equipo — el agente enseña y facilita; el equipo estima | | **Cuándo usarlo** | El backlog tiene historias o tareas sin dimensionar y el sprint planning es inminente, o se requiere una estimación total documentada con rango de confianza para una puerta de planeación. | | **Lista de aceptación** | `docs/pm-kit/checklists/cost-estimation.md` dentro de tu proyecto instalado | **Patrón de invocación.** > *Invoca el skill `cost-estimation`.* El agente enseñará tres técnicas complementarias: **Planning Poker** (para historias de usuario con acuerdo de equipo, usando la secuencia de Fibonacci), **talla de camiseta** (para épicas o funcionalidades donde la precisión numérica no es todavía pertinente: S / M / L / XL) y **estimación de tres puntos / PERT** (para tareas donde la incertidumbre justifica un rango probabilístico, con fórmula `E = (O + 4M + P) / 6`). El agente facilita cada ronda y registra los valores producidos por el equipo — no fabrica cifras. El artefacto se guarda en `docs/pm-kit/outputs/cost-estimation/`. ***

Artefacto 6: Matriz de Riesgo

| | | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Skill** | `risk-matrix` | | **Tipo** | Extension — originalmente desarrollado para Agentic PM Kit | | **Cuándo usarlo** | Una puerta de planeación o revisión de hito requiere un registro formal de riesgos antes de la aprobación; el charter está firmado y el equipo debe aflorar riesgos antes de que comience la ejecución. | | **Lista de aceptación** | `docs/pm-kit/checklists/risk-matrix.md` dentro de tu proyecto instalado | **Patrón de invocación.** > *Invoca el skill `risk-matrix`.* El agente invertirá los criterios de éxito del proyecto para generar modos de falla, tensionará el plan en cuatro categorías (técnica, externa, organizacional, gestión de proyecto), consolidará candidatos en forma de "Si `` ocurre, entonces `` puede impactar ``", puntuará cada riesgo en probabilidad × impacto (1–5 cada eje), asignará una estrategia de respuesta PMBOK (evitar / mitigar / transferir / aceptar) y producirá la lista de los cinco riesgos de mayor prioridad con planes de respuesta concretos. El artefacto se guarda en `docs/pm-kit/outputs/risk-matrix/`. ***

Artefacto 7: Plan de Comunicaciones

| | | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Skill** | `communication-plan` | | **Tipo** | Extension — originalmente desarrollado para Agentic PM Kit | | **Cuándo usarlo** | El registro de stakeholders está completo y el proyecto necesita un plan formal que rija cómo fluye la información del proyecto hacia cada audiencia — quién envía, qué, cuándo y por qué canal. | | **Lista de aceptación** | `docs/pm-kit/checklists/communication-plan.md` dentro de tu proyecto instalado | **Patrón de invocación.** > *Invoca el skill `communication-plan`.* El agente construirá una matriz de comunicaciones (stakeholder × tipo de información × cadencia × canal × propietario del envío), documentará las rutas de escalación para bloqueos técnicos, solicitudes de cambio de alcance, variaciones de presupuesto y disputas entre stakeholders, listará la cadencia de reuniones recurrentes (standup, sprint review, retrospectiva, comité directivo) y documentará las reglas de higiene de la información. El artefacto se guarda en `docs/pm-kit/outputs/communication-plan/`. ***

Artefacto 8: Plan de Calidad

| | | | ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Skill** | `quality-plan` | | **Tipo** | Extension — originalmente desarrollado para Agentic PM Kit | | **Cuándo usarlo** | El patrocinador o la PMO requieren un estándar de calidad escrito como puerta antes de la aprobación de ejecución; el equipo no tiene una definición compartida de qué significa "listo" o "aceptable" para los entregables del proyecto. | | **Lista de aceptación** | `docs/pm-kit/checklists/quality-plan.md` dentro de tu proyecto instalado | **Patrón de invocación.** > *Invoca el skill `quality-plan`.* El agente capturará objetivos de calidad en tres dimensiones (calidad visible para el usuario, calidad interna del proceso, calidad de la documentación), establecerá métricas medibles con metas mínimas aceptables, definirá actividades de aseguramiento (preventivas) y de control (de detección), e identificará los estándares externos aplicables (ISO, WCAG, regulaciones del dominio). El artefacto se guarda en `docs/pm-kit/outputs/quality-plan/`. ***

Artefacto 9: Plan de Recursos

| | | | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Skill** | `resource-plan` | | **Tipo** | Extension — originalmente desarrollado para Agentic PM Kit | | **Cuándo usarlo** | La WBS y el cronograma están establecidos y el patrocinador necesita autorizar el presupuesto antes de que comience la ejecución; el roster del equipo tiene vacantes que deben documentarse. | | **Lista de aceptación** | `docs/pm-kit/checklists/resource-plan.md` dentro de tu proyecto instalado | **Patrón de invocación.** > *Invoca el skill `resource-plan`.* El agente construirá el roster del equipo con roles, personas asignadas (o "Por definir"), porcentaje de dedicación y fechas de incorporación y liberación; identificará equipo, licencias de software e infraestructura; producirá el resumen de presupuesto en cuatro categorías (personas, herramientas y software, viajes y gastos, reserva de contingencia); documentará las dependencias externas de proveedores y equipos compartidos; y registrará la línea de tiempo de contratación para los roles no cubiertos. El artefacto se guarda en `docs/pm-kit/outputs/resource-plan/`. *** **Lo que no debe faltar en la planeación** * **El orden de los artefactos importa.** El PRD alimenta las épicas e historias; las épicas e historias alimentan el WBS; el WBS alimenta el cronograma; el cronograma y el WBS alimentan la estimación de costos y el plan de recursos. Saltarte un eslabón crea inconsistencias que se vuelven costosas de corregir en ejecución. * **La estimación de costos la hace el equipo, no el agente.** El skill de estimación enseña las técnicas y facilita las rondas, pero los números los produce el equipo. Un agente que "estima solo" produce cifras sin responsable — y sin responsable no hay compromiso. * **La matriz de riesgo no es un trámite.** El ejercicio de inversión de metas y el tensionado en cuatro categorías está diseñado para aflorar los riesgos que el equipo *no* ve todavía. Si la matriz sólo tiene los riesgos obvios, el ejercicio no terminó. # Fase 3: Ejecución (/es/docs/pm-kit/05-execution) # Fase 3 — Ejecución [#fase-3--ejecución] La fase de ejecución es donde el plan se convierte en incrementos entregables. Cada sprint tiene cuatro momentos clave: planear el trabajo, ejecutar las historias, mantener la sincronización diaria y revisar lo construido con los stakeholders. Esta fase cubre los cuatro skills que cubren esos momentos. Los tres principios del kit aplican aquí con especial fuerza: el agente es un redactor y facilitador, tú eres la PM que revisa y aprueba; cada skill carga su fuente autoritativa (la Guía Scrum 2020) antes de facilitar; y cada artefacto termina en una lista de aceptación binaria — **APROBADO** o **RECHAZADO**. **Convención de invocación.** Para cualquiera de los skills de esta fase, dile a tu agente: *Invoca el skill \.* El agente cargará el skill instalado, leerá tu `.pm-kit.config.json` y comenzará la facilitación en tu idioma configurado. ## Skills de la fase de ejecución [#skills-de-la-fase-de-ejecución]

Sprint Planning

**Identificador:** `sprint-planning` — Adaptado de metodología open-source (MIT). Ver `THIRD_PARTY_NOTICES.md`. **Cuándo usarlo.** Al inicio de cada sprint, antes de que comience cualquier trabajo de entrega. El Product Backlog ya está refinado, el Product Owner tiene candidatos para el sprint goal y el equipo necesita comprometerse con un Sprint Backlog concreto. No lo invoques para refinamiento de backlog, retrospectivas ni replaneación a mitad del sprint — esos eventos tienen sus propios skills. **Cómo invocarlo.** Dile a tu agente: *Invoca el skill sprint-planning.* El agente te guiará en secuencia por: reunir entradas (velocidad, disponibilidad, backlog priorizado), redactar el sprint goal, calcular la capacidad del equipo, seleccionar los ítems del Sprint Backlog, identificar riesgos y dependencias, confirmar la Definición de Terminado y producir el artefacto completo. **Artefacto generado.** `docs/pm-kit/outputs/sprint-planning/.md` **Lista de aceptación.** `docs/pm-kit/checklists/sprint-planning.md` ***

Ejecución de historias (opcional)

**Identificador:** `story-execution` — Adaptado de metodología open-source (MIT). Ver `THIRD_PARTY_NOTICES.md`. **Este skill es opcional.** Está dirigido a equipos cuyo proyecto de semestre incluye un componente de código — una aplicación, un script, una integración, un pipeline de datos. Los equipos que trabajan en proyectos de planeación pura o investigación pueden omitirlo sin perder ninguna otra capacidad de la fase de ejecución. **Cuándo usarlo.** Cuando un miembro del equipo comienza el trabajo activo sobre una historia de usuario que implica implementación de software. La historia ya está en el Sprint Backlog, tiene criterios de aceptación claros y está asignada a alguien. No lo invoques para sprint planning, preparación de standup ni sprint review. **Cómo invocarlo.** Dile a tu agente: *Invoca el skill story-execution.* El agente te guiará en: confirmar la historia y sus criterios de aceptación, definir el plan de implementación, registrar los tests que verificarán cada criterio, capturar el resultado de la revisión, verificar la Definición de Terminado ítem por ítem y registrar las lecciones aprendidas de esa historia. **Artefacto generado.** `docs/pm-kit/outputs/story-execution/.md` **Lista de aceptación.** `docs/pm-kit/checklists/story-execution.md` ***

Preparación de standup

**Identificador:** `standup-prep` — Skill original de Agentic PM Kit (MIT). **Preparación, no reemplazo.** Este skill te ayuda a redactar tu nota personal de tres viñetas en aproximadamente dos minutos, justo antes de entrar al Daily Scrum. No conduce ni sustituye la reunión de Daily Scrum en sí — esa es un evento de equipo que ocurre por separado, en persona o por videoconferencia, con todos los miembros del Scrum Team presentes. **Cuándo usarlo.** En los dos minutos previos a tu reunión de Daily Scrum, cuando quieras organizar tus pensamientos rápidamente — especialmente si el día anterior fue fragmentado o ha emergido algún bloqueo que necesitas articular con claridad. No lo invoques para sprint planning, sprint review ni retrospectiva. **Cómo invocarlo.** Dile a tu agente: *Invoca el skill standup-prep.* El agente te preguntará por el sprint y el sprint goal actual, lo que terminaste o avanzaste significativamente ayer (conectado al sprint goal), a qué te comprometes hoy y si hay algo que te esté bloqueando o en riesgo de bloquearte. **Artefacto generado.** `docs/pm-kit/outputs/standup-prep/.md` **Lista de aceptación.** `docs/pm-kit/checklists/standup-prep.md` ***

Sprint Review

**Identificador:** `sprint-review` — Adaptado de metodología open-source (MIT). Ver `THIRD_PARTY_NOTICES.md`. **Cuándo usarlo.** Al final del sprint, después de que el trabajo esté listo y antes de la retrospectiva. El equipo está listo para demostrar el incremento a los stakeholders y capturar su retroalimentación sistemáticamente. No lo invoques para chequeos de estatus a mitad del sprint, retrospectivas ni sprint planning. **Cómo invocarlo.** Dile a tu agente: *Invoca el skill sprint-review.* El agente te guiará en: reunir los insumos del sprint, revisar si se logró el sprint goal, registrar historias completadas y no completadas con sus razones, capturar la retroalimentación de la demo por tema, registrar las decisiones tomadas durante la sesión y documentar señales para la planeación del siguiente sprint. **Artefacto generado.** `docs/pm-kit/outputs/sprint-review/.md` **Lista de aceptación.** `docs/pm-kit/checklists/sprint-review.md` *** ## Consejos para la fase de ejecución [#consejos-para-la-fase-de-ejecución] **El standup-prep no reemplaza el Daily Scrum.** La nota que genera es un insumo tuyo para el evento de equipo — no un registro oficial ni un sustituto de la conversación en vivo. Lleva tu nota al Daily Scrum y úsala como guía para hablar, no como el evento en sí. **Termina el sprint-review antes de la retrospectiva.** La Guía Scrum 2020 define el Sprint Review como el evento de inspección del incremento con stakeholders, y la retrospectiva como el evento de inspección del equipo y del proceso. Ejecutarlos en orden te permite llevar las señales del review a la retrospectiva como material de contexto. **story-execution es por historia, no por sprint.** Invócalo una vez por cada historia que el equipo comience — no una vez al inicio del sprint para todo el Sprint Backlog. El artefacto que produce es el registro de implementación y revisión de esa historia individual. # Fase 4: Cierre (/es/docs/pm-kit/06-closing) # Fase 4 — Cierre [#fase-4--cierre] El cierre no es el final del trabajo; es el inicio del aprendizaje. Esta fase agrupa tres skills que transforman la experiencia acumulada del equipo en artefactos formales: la retrospectiva que inspecciona y adapta al ritmo del sprint, el post-mortem que analiza incidentes serios con una postura sin culpa, y el reporte de cierre que firma la conclusión formal del proyecto ante los patrocinadores y stakeholders. Saber cuál skill invocar — retrospectiva o post-mortem — importa. La confusión entre los dos produce documentos inadecuados para ambos propósitos. Esta página los distingue con claridad. **Convención de invocación.** Para cualquiera de los skills de esta fase, dile a tu agente: *Invoca el skill \.* El agente cargará el skill instalado, leerá tu `.pm-kit.config.json` y comenzará la facilitación en tu idioma configurado. ## Skills de la fase de cierre [#skills-de-la-fase-de-cierre]

Retrospectiva

**Identificador:** `retrospective` — Adaptado de metodología open-source (MIT). Ver `THIRD_PARTY_NOTICES.md`. **Cuándo usarlo.** Al final de un sprint o iteración, cuando el equipo necesita una sesión estructurada de inspección y adaptación enfocada en el próximo sprint. Úsalo también cuando los impedimentos recurrentes sugieren que los acuerdos de trabajo del equipo necesitan revisión, o cuando se integra un nuevo miembro y corresponde una actualización de normas. **Cuándo NO usarlo.** No invoques este skill para incidentes serios ni para retrospectivas que abarcan múltiples sprints o el proyecto completo — para esos casos, usa el skill `post-mortem`. La diferencia es de escala y de propósito: la retrospectiva opera al ritmo del sprint, inspecciona el proceso del equipo y produce acciones para el siguiente ciclo. El post-mortem opera cuando el daño fue mayor que lo que puede resolver una retro de sprint. **Cómo invocarlo.** Dile a tu agente: *Invoca el skill retrospective.* El agente abre la sesión con el encuadre correcto: "Esta retrospectiva existe para mejorar el próximo sprint, no para evaluar individuos. Describe sistemas, procesos y condiciones, no las personas que los operaron." Luego te guía en: capturar metadatos y contexto, recoger lo que salió bien, lo que no salió bien (reescribiendo cualquier viñeta que señale a un individuo para que describa el sistema), las lecciones aprendidas y los ítems de acción. Cada ítem de acción debe tener dueño (rol o equipo), fecha límite y criterio de éxito observable — sin "TBD" ni equipos enteros como dueños. El agente también solicita el seguimiento de la retrospectiva anterior, si existe. La lente por defecto es **Empezar / Detener / Continuar**. Si el equipo prefiere, acepta **Glad / Sad / Mad**, **4Ls** o **Sailboat**; el agente registra la elección en el artefacto. **Artefacto generado.** `docs/pm-kit/outputs/retrospective/.md` **Lista de aceptación.** `docs/pm-kit/checklists/retrospective.md` ***

Post-mortem

**Identificador:** `post-mortem` — Skill original de Agentic PM Kit (MIT). **Cuándo usarlo.** Cuando la superficie de aprendizaje es mayor que un sprint: un incidente serio que incumplió un SLA o causó impacto visible a usuarios o clientes; un cuasi-accidente cuyo mecanismo merece estudiarse; una retrospectiva de proyecto completo que abarca múltiples sprints; una entrega que produjo resultados materialmente peores que lo proyectado; o una revisión requerida por un hallazgo de auditoría, una notificación regulatoria o una escalación de cliente. **Cuándo NO usarlo.** No invoques este skill para la inspección regular al final de cada sprint — usa `retrospective`. Tampoco lo uses para el análisis de causa raíz de un defecto aislado — usa `brainstorming-five-whys`. Y no lo uses para asignar consecuencias de desempeño individuales: este skill es sin culpa por contrato y rechaza ese encuadre. **La postura sin culpa.** Este skill sigue la tradición del post-mortem sin culpa de Google SRE. El agente abre la sesión con el enunciado literal: *"Este es un post-mortem sin culpa. Estamos aquí para mejorar el sistema, no para culpar a las personas que lo operaron. El error humano es un punto de partida para el análisis, no un punto de llegada."* Cada participante debe reconocer esta postura antes de que se recopile cualquier dato. Si alguien no puede aceptarla, el skill indica pausar la sesión y escalar antes de continuar — un post-mortem conducido sin contrato de no culpa dañará al equipo y producirá hallazgos superficiales. **Análisis de causa raíz.** El skill aplica el patrón de los Cinco Porqués o un análisis multicapa equivalente. **Rechaza "error humano", "descuido del operador", "error del desarrollador" y cualquier equivalente como causa raíz terminal.** Si la cadena causal llega a una persona, el agente pregunta el siguiente porqué: ¿por qué el sistema, el proceso, la capacitación, las herramientas, la documentación, las alertas o la estructura de incentivos permitieron que esa persona cometiera ese error en ese momento? La cadena termina solo en una causa sistémica que el equipo puede cambiar. **Cómo invocarlo.** Dile a tu agente: *Invoca el skill post-mortem.* El agente te guía en: declarar la postura sin culpa, capturar metadatos, redactar el resumen ejecutivo legible por alguien ajeno al incidente, construir la línea de tiempo cronológica, cuantificar el impacto (interno y externo), realizar el análisis de causa raíz rechazando causas superficiales, documentar factores contribuyentes, registrar lo que funcionó bien y lo que pudo haber funcionado mejor, construir la tabla de ítems de acción (cada fila requiere: dueño, categoría Prevenir / Detectar / Mitigar, fecha límite, criterio de éxito y referencia cruzada a una causa raíz o factor contribuyente), y registrar los compromisos de seguimiento — incluyendo dónde se publicará el documento y quién supervisa el avance de las acciones. **Artefacto generado.** `docs/pm-kit/outputs/post-mortem/.md` **Lista de aceptación.** `docs/pm-kit/checklists/post-mortem.md` ***

Reporte de cierre del proyecto

**Identificador:** `closure-report` — Skill original de Agentic PM Kit (MIT). **Cuándo usarlo.** Cuando el proyecto completo ha llegado al final de su fase de ejecución y se requiere cierre formal: todos los entregables han sido aceptados por stakeholders nombrados, el patrocinador o el órgano de gobierno solicita un registro formal de cierre, las lecciones de las retrospectivas y post-mortems necesitan consolidarse en un solo artefacto organizacional, el equipo se prepara para ser reasignado y los recursos deben liberarse formalmente, o el expediente del proyecto debe archivarse para auditoría, fines contractuales o institucionales. No invoques este skill para retrospectivas individuales de sprint ni para revisiones a mitad del proyecto. Invócalo solo cuando se esté cerrando el proyecto completo, no una fase. **Cómo invocarlo.** Dile a tu agente: *Invoca el skill closure-report.* El agente te guia en reunir los documentos fuente (charter aprobado, cronograma final planificado vs. real, resumen de presupuesto, registros de cambio de alcance, registros de aceptación de stakeholders, notas de retrospectivas y post-mortems), capturar metadatos del proyecto, redactar el resumen ejecutivo, registrar entregables con fecha de aceptación y el nombre de la persona que aceptó, comparar objetivos con resultados reales y fechas y presupuesto planificados contra reales, consolidar cambios de alcance y lecciones aprendidas agrupadas en cuatro temas (proceso, técnico, organizacional, stakeholders), documentar ítems pendientes y la liberación de recursos, confirmar las ubicaciones de archivo de artefactos y preparar el bloque de firma formal del patrocinador y la PM. **Artefacto generado.** `docs/pm-kit/outputs/closure-report/.md` **Lista de aceptación.** `docs/pm-kit/checklists/closure-report.md` *** ## Consejos para la fase de cierre [#consejos-para-la-fase-de-cierre] **Retrospectiva vs. post-mortem: elige con intención.** La retrospectiva es el evento regular al ritmo del sprint — inspecciona el proceso del equipo y produce acciones para el siguiente ciclo. El post-mortem es para cuando algo salió suficientemente mal como para merecer un análisis sistémico: incidentes serios, cuasi-accidentes y retrospectivas de proyecto completo. Usar la retrospectiva para un incidente serio produce un análisis superficial; usar el post-mortem para el cierre de cada sprint produce sobrecarga de proceso. Conoce la diferencia y elige en consecuencia. **El post-mortem sin postura sin culpa produce teatro, no aprendizaje.** Si la sesión comienza sin que todos los participantes reconozcan explícitamente la postura sin culpa, el skill indica pausar. Esta no es una formalidad: es la condición que permite que las personas digan lo que realmente pasó. Sin ella, los hallazgos serán los mismos de siempre y las acciones nunca se cerrarán. **El reporte de cierre consolida, no duplica.** Su valor es integrar las lecciones de todas las retrospectivas y post-mortems del proyecto en un solo artefacto legible por el patrocinador. Reúne tus artefactos anteriores antes de invocarlo; el agente te preguntará por ellos en el primer paso de la facilitación. # Referencia (/es/docs/pm-kit/07-reference) # Referencia [#referencia] Esta página es el índice completo del kit: todos los skills agrupados por fase, todas las listas de aceptación, la licencia MIT, y la atribución completa de fuentes y marcas de terceros. *** El kit incluye 40 skills en total: 21 de brainstorming (estrategias individuales + el enrutador de laboratorio), 10 artefactos de extensión originales, 7 artefactos adaptados de fuentes de código abierto, y 2 skills facilitadas por el humano. Las clasificaciones son: * **\[BMad-vendored]** — contenido adaptado del repositorio BMad-Method (MIT, © 2025 BMad Code, LLC) con atribución * **\[Extension]** — contenido original, creado específicamente para Agentic PM Kit * **\[Human-led]** — el agente enseña y facilita; el equipo humano produce los entregables Los enlaces a código fuente usan el repositorio de GitHub de Agentic Engineering Agency. El repositorio es el punto de referencia canónico; las URLs se actualizan en los lanzamientos.

Fase 0 — Ideación

| Skill | Descripción | Clasificación | | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | | `brainstorming-lab` | Enruta al usuario hacia la estrategia de brainstorming adecuada haciendo 3–5 preguntas diagnósticas. Invocar cuando el usuario quiere hacer brainstorming pero no sabe qué técnica usar. | \[BMad-vendored] | | `brainstorming-five-whys` | Facilita un análisis de causa raíz con los Cinco Porqués. Invocar cuando un impedimento, desviación de cronograma, defecto recurrente o señal de insatisfacción de stakeholder necesita causa raíz. | \[BMad-vendored] | | `brainstorming-question-storming` | Facilita una sesión de Question Storming que genera un banco estructurado de preguntas antes de proponer soluciones. Invocar cuando el equipo sospecha que está resolviendo el problema equivocado. | \[BMad-vendored] | | `brainstorming-assumption-reversal` | Facilita una sesión de Inversión de Supuestos que superficie restricciones ocultas invirtiendo creencias centrales sobre un desafío. Invocar para romper el espacio de solución convencional. | \[BMad-vendored] | | `brainstorming-constraint-mapping` | Facilita una sesión de Mapeo de Restricciones que identifica, categoriza y evalúa todas las restricciones de un desafío. Invocar para distinguir limitaciones reales de imaginadas. | \[BMad-vendored] | | `brainstorming-failure-analysis` | Facilita una sesión de Análisis de Fallas que extrae lecciones de fracasos pasados para prevenir recurrencias. Invocar cuando el equipo necesita aprender de un incidente o entregable fallido. | \[BMad-vendored] | | `brainstorming-morphological-analysis` | Facilita un Análisis Morfológico para explorar sistemáticamente combinaciones de parámetros en un problema de diseño complejo. Invocar para mapeo integral del espacio de solución. | \[BMad-vendored] | | `brainstorming-six-thinking-hats` | Facilita una sesión de los Seis Sombreros para el Pensar que examina una decisión desde seis perspectivas estructuradas. Invocar para evaluar una decisión significativa sin colapsar en debate. | \[BMad-vendored] | | `brainstorming-mind-mapping` | Facilita una sesión de Mind Mapping para organizar visualmente ideas que irradian desde un concepto central. Invocar para estructurar un tema abierto o capturar un brainstorming antes de converger. | \[BMad-vendored] | | `brainstorming-decision-tree-mapping` | Facilita una sesión de Árbol de Decisión para visualizar caminos, resultados y riesgos de una decisión compleja. Invocar cuando una decisión multi-rama no ha sido mapeada en su totalidad. | \[BMad-vendored] | | `brainstorming-solution-matrix` | Facilita una sesión de Matriz de Solución para puntuar y rankear opciones contra criterios ponderados. Invocar cuando se debe elegir entre dos o más alternativas con evaluación multi-criterio. | \[BMad-vendored] | | `brainstorming-resource-constraints` | Facilita una sesión de ideación bajo Restricciones de Recursos para generar opciones creativas con limitaciones explícitas de presupuesto, tiempo o capacidad. | \[BMad-vendored] | | `brainstorming-role-playing` | Facilita una sesión de Role Playing para generar soluciones y superficie puntos ciegos viendo el proyecto desde múltiples perspectivas de stakeholders. | \[BMad-vendored] | | `brainstorming-brain-writing-round-robin` | Facilita un Brain Writing Round Robin en que los participantes contribuyen silenciosamente y secuencialmente para construir sobre ideas de otros. Invocar para generación inclusiva de ideas en equipos distribuidos. | \[BMad-vendored] | | `brainstorming-reverse-brainstorming` | Facilita un Reverse Brainstorming para superficie riesgos ocultos ideando deliberadamente cómo causar el problema, luego invirtiendo los resultados. | \[BMad-vendored] | | `brainstorming-what-if-scenarios` | Facilita una sesión de Escenarios "¿Qué Pasaría Si?" para explorar futuros plausibles y estresar los planes. Invocar para contingencias ante cambios en supuestos clave. | \[BMad-vendored] | | `brainstorming-first-principles-thinking` | Facilita una sesión de Pensamiento desde Primeros Principios que elimina supuestos y reconstruye el entendimiento desde verdades fundamentales verificadas. | \[BMad-vendored] | | `brainstorming-values-archaeology` | Facilita una Arqueología de Valores que excava valores no declarados y supuestos básicos que impulsan las decisiones de un equipo o stakeholder. | \[BMad-vendored] | | `brainstorming-alien-anthropologist` | Facilita una sesión de Antropólogo Alienígena en la que el equipo examina su propio proyecto a través de los ojos de un observador externo completamente ajeno. | \[BMad-vendored] | | `brainstorming-chaos-engineering` | Facilita una sesión de Chaos Engineering que estressa un plan de proyecto hipotizando deliberadamente fallas de peor caso. Invocar para registros de riesgo y análisis pre-mortem. | \[BMad-vendored] | | `brainstorming-anti-solution` | Facilita una sesión de Anti-Solución que genera formas de empeorar el problema, luego invierte esos hallazgos. Invocar cuando el equipo está atrapado en un único marco de solución. | \[BMad-vendored] |

Fase 1 — Inicio

| Skill | Descripción | Clasificación | | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | | `charter` | Redacta un charter de proyecto con forma PMBOK desde un memorando de concepto o product brief. Invocar cuando se necesita documentación de la fase de inicio. | \[Extension] | | `stakeholder-register` | Identifica, clasifica y documenta stakeholders del proyecto corriendo una estrategia de brainstorming estructurada contra el charter, luego emite el registro. Invocar al iniciar un proyecto o cuando el panorama de stakeholders necesita actualización sistemática. | \[Extension] | | `product-brief` | Redacta un documento conciso de business case cubriendo planteamiento del problema, usuarios objetivo, métricas de éxito, riesgos clave y enfoque de alto nivel. Invocar para documentación de negocio antes o durante el inicio. | \[BMad-vendored] |

Fase 2 — Planeación

| Skill | Descripción | Clasificación | | -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | | `prd` | Redacta un Documento de Requisitos del Producto simplificado y compatible con PMBOK desde un product brief y charter. Invocar al inicio de la fase de planeación antes de descomponer el alcance. | \[BMad-vendored] | | `wbs` | Construye una Estructura de Desglose del Trabajo (EDT) con forma PMBOK desde la jerarquía de épicas e historias del proyecto. Invocar para descomposición del alcance antes del cronograma y asignación de recursos. | \[Extension] | | `epics-and-stories` | Descompone un PRD en Épicas e Historias de Usuario con forma INVEST con criterios de aceptación y prioridad. Invocar cuando el PRD está en baseline y el equipo necesita un backlog accionable. | \[BMad-vendored] | | `schedule-gantt` | Produce un diagrama Mermaid-Gantt y narrativa de cronograma desde una EDT y estimaciones de esfuerzo. Invocar cuando el equipo necesita un plan temporal con dependencias y ruta crítica. | \[Extension] | | `cost-estimation` | Enseña tres técnicas complementarias de estimación — Planning Poker, talla de camiseta y tres puntos (PERT) — y registra las estimaciones que produce el equipo. El agente enseña y facilita; el equipo estima. | \[Human-led] | | `risk-matrix` | Produce una matriz de riesgo probabilidad × impacto con estrategias de respuesta estilo PMBOK. Invocar antes de una compuerta de planeación, revisión de hito o decisión go/no-go. | \[Extension] | | `communication-plan` | Produce una matriz de comunicación con forma PMBOK, rutas de escalación y cadencia de reuniones. Invocar cuando el equipo necesita un plan formal de flujo de información a cada audiencia. | \[Extension] | | `quality-plan` | Produce un plan de calidad conciso que define objetivos de calidad, métricas medibles, actividades de aseguramiento y puntos de control. Invocar antes de entrar a ejecución. | \[Extension] | | `resource-plan` | Produce un plan de recursos conciso cubriendo roster del equipo, equipamiento, resumen de presupuesto, dependencias externas y cronograma de contratación. Invocar cuando el equipo necesita un registro explícito de compromisos. | \[Extension] |

Fase 3 — Ejecución

| Skill | Descripción | Clasificación | | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------- | | `sprint-planning` | Facilita un evento de Sprint Planning de Scrum, produciendo un sprint goal y un Sprint Backlog comprometido desde el Product Backlog priorizado. Invocar al inicio de cada sprint. | \[BMad-vendored] | | `story-execution` | Facilita la ejecución y revisión de una historia de usuario individual a través de implementación, pruebas y aceptación. Invocar cuando un desarrollador o equipo está listo para trabajar en una historia con componente de código. | \[BMad-vendored] | | `standup-prep` | Ayuda al usuario a preparar una nota de standup concisa de tres viñetas cubriendo ayer, hoy y bloqueos antes del Daily Scrum. No reemplaza el standup; lo prepara. | \[Human-led] | | `sprint-review` | Facilita un evento de Sprint Review de Scrum, capturando lo construido, retroalimentación de stakeholders del demo y decisiones sobre el camino a seguir. Invocar cuando el sprint ha concluido. | \[BMad-vendored] |

Fase 4 — Cierre

| Skill | Descripción | Clasificación | | ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | | `retrospective` | Facilita una retrospectiva de sprint o iteración que surfacea aprendizajes reales y produce ítems de acción con dueño y fecha. Invocar cuando un sprint o iteración ha cerrado. | \[BMad-vendored] | | `post-mortem` | Facilita un post-mortem sin culpa para un incidente serio, casi-falla, o retrospectiva a nivel de proyecto. Invocar cuando una falla significativa ha ocurrido o el proyecto completo cierra. | \[Extension] | | `closure-report` | Produce un reporte de cierre del proyecto con forma PMBOK adecuado para firma del patrocinador, consolidando charter, cronograma final, presupuesto final, retrospectivas, post-mortems y registros de aceptación. Invocar al cierre formal del proyecto. | \[Extension] | ***

2\. Listas de aceptación

Cada skill de artefacto tiene una lista de aceptación pareada instalada en `docs/pm-kit/checklists/` dentro del directorio de tu proyecto. Estas rutas son locales al proyecto instalado — no son URLs del sitio. | Artifact | Resumen | Ruta de instalación | | ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- | | Brainstorming Lab | Verifica que la sesión produjo un concepto claro listo para alimentar al charter | `docs/pm-kit/checklists/brainstorming-lab.md` | | Five Whys | Verifica que se alcanzó causa raíz real (5 niveles), no solo síntoma | `docs/pm-kit/checklists/brainstorming-five-whys.md` | | Question Storming | Verifica que las preguntas reencuadran el problema antes de proponer soluciones | `docs/pm-kit/checklists/brainstorming-question-storming.md` | | Assumption Reversal | Verifica que los supuestos invertidos generaron al menos 3 caminos nuevos | `docs/pm-kit/checklists/brainstorming-assumption-reversal.md` | | Constraint Mapping | Verifica que las restricciones están priorizadas y al menos una es accionable | `docs/pm-kit/checklists/brainstorming-constraint-mapping.md` | | Failure Analysis | Verifica que los patrones de falla están documentados con acciones preventivas | `docs/pm-kit/checklists/brainstorming-failure-analysis.md` | | Morphological Analysis | Verifica que la matriz cubre todos los parámetros relevantes y la combinación elegida está justificada | `docs/pm-kit/checklists/brainstorming-morphological-analysis.md` | | Six Thinking Hats | Verifica que los seis sombreros fueron cubiertos y las perspectivas están separadas | `docs/pm-kit/checklists/brainstorming-six-thinking-hats.md` | | Mind Mapping | Verifica que el mapa captura todos los temas clave con al menos dos niveles de profundidad | `docs/pm-kit/checklists/brainstorming-mind-mapping.md` | | Decision Tree Mapping | Verifica que todas las ramas principales están mapeadas con probabilidades y resultados estimados | `docs/pm-kit/checklists/brainstorming-decision-tree-mapping.md` | | Solution Matrix | Verifica que los criterios están ponderados, las opciones puntuadas y la recomendación es defendible | `docs/pm-kit/checklists/brainstorming-solution-matrix.md` | | Resource Constraints | Verifica que las soluciones generadas respetan explícitamente las restricciones declaradas | `docs/pm-kit/checklists/brainstorming-resource-constraints.md` | | Role Playing | Verifica que al menos tres perspectivas de stakeholder distintas fueron representadas | `docs/pm-kit/checklists/brainstorming-role-playing.md` | | Brain Writing Round Robin | Verifica que todos los participantes contribuyeron y las ideas fueron construidas en rondas | `docs/pm-kit/checklists/brainstorming-brain-writing-round-robin.md` | | Reverse Brainstorming | Verifica que los riesgos identificados fueron invertidos en estrategias de mitigación concretas | `docs/pm-kit/checklists/brainstorming-reverse-brainstorming.md` | | What If Scenarios | Verifica que los escenarios cubren al menos un caso optimista, uno base y uno pesimista | `docs/pm-kit/checklists/brainstorming-what-if-scenarios.md` | | First Principles Thinking | Verifica que todos los supuestos heredados fueron cuestionados y reconstruidos desde evidencia | `docs/pm-kit/checklists/brainstorming-first-principles-thinking.md` | | Values Archaeology | Verifica que los valores subyacentes están documentados y el conflicto de raíz identificado | `docs/pm-kit/checklists/brainstorming-values-archaeology.md` | | Alien Anthropologist | Verifica que las observaciones están en voz de observador externo sin términos internos | `docs/pm-kit/checklists/brainstorming-alien-anthropologist.md` | | Chaos Engineering | Verifica que los escenarios de falla mapeados alimentan directamente al registro de riesgos | `docs/pm-kit/checklists/brainstorming-chaos-engineering.md` | | Anti-Solution | Verifica que los anti-patrones identificados fueron invertidos en al menos 3 soluciones accionables | `docs/pm-kit/checklists/brainstorming-anti-solution.md` | | Charter | Verifica que el charter nombra sponsor, objetivo, alcance, hitos y criterios de éxito con forma PMBOK | `docs/pm-kit/checklists/charter.md` | | Stakeholder Register | Verifica que cada stakeholder tiene influencia, interés y estrategia de compromiso documentadas | `docs/pm-kit/checklists/stakeholder-register.md` | | Product Brief | Verifica que el business case cubre problema, usuarios, métricas, riesgos y enfoque | `docs/pm-kit/checklists/product-brief.md` | | PRD | Verifica que los requisitos son medibles, trazables al charter y priorizados | `docs/pm-kit/checklists/prd.md` | | WBS | Verifica que la EDT cubre el 100% del alcance con paquetes de trabajo en el nivel apropiado | `docs/pm-kit/checklists/wbs.md` | | Epics and Stories | Verifica que cada historia cumple el criterio INVEST y tiene criterios de aceptación medibles | `docs/pm-kit/checklists/epics-and-stories.md` | | Schedule / Gantt | Verifica que el diagrama Mermaid renderiza y la ruta crítica está identificada | `docs/pm-kit/checklists/schedule-gantt.md` | | Cost Estimation | Verifica que las estimaciones del equipo están registradas con técnica, rango y nivel de confianza | `docs/pm-kit/checklists/cost-estimation.md` | | Risk Matrix | Verifica que cada riesgo tiene probabilidad, impacto, puntuación y respuesta documentadas | `docs/pm-kit/checklists/risk-matrix.md` | | Communication Plan | Verifica que cada stakeholder tiene su canal, frecuencia y responsable de comunicación asignados | `docs/pm-kit/checklists/communication-plan.md` | | Quality Plan | Verifica que los objetivos de calidad son medibles y los puntos de control están en el cronograma | `docs/pm-kit/checklists/quality-plan.md` | | Resource Plan | Verifica que el roster está completo, las dependencias externas documentadas y el presupuesto resumido | `docs/pm-kit/checklists/resource-plan.md` | | Sprint Planning | Verifica que el sprint goal está acordado y el Sprint Backlog comprometido por el equipo | `docs/pm-kit/checklists/sprint-planning.md` | | Story Execution | Verifica que la historia tiene definición de hecho, pruebas y aceptación del Product Owner | `docs/pm-kit/checklists/story-execution.md` | | Standup Prep | Verifica que las tres viñetas (ayer / hoy / bloqueos) son concisas y accionables | `docs/pm-kit/checklists/standup-prep.md` | | Sprint Review | Verifica que el incremento fue demostrado, la retroalimentación registrada y el backlog actualizado | `docs/pm-kit/checklists/sprint-review.md` | | Retrospective | Verifica que los ítems de acción tienen dueño, fecha y fueron acordados por el equipo | `docs/pm-kit/checklists/retrospective.md` | | Post-Mortem | Verifica que la línea de tiempo está completa, los factores contribuyentes identificados sin culpa y las acciones sistémicas asignadas | `docs/pm-kit/checklists/post-mortem.md` | | Closure Report | Verifica que el reporte consolida objetivos vs. resultados, firma del sponsor y lecciones aprendidas | `docs/pm-kit/checklists/closure-report.md` | ***

3\. Licencia

El paquete `agentic-pm-kit` se distribuye bajo la **Licencia MIT**. Resumen de términos: se concede permiso, sin costo alguno, para usar, copiar, modificar, fusionar, publicar, distribuir, sublicenciar y/o vender copias del software, siempre que el aviso de copyright y el aviso de permiso aparezcan en todas las copias o porciones sustanciales. El texto completo de la licencia está en el archivo [`LICENSE`](https://github.com/agentic-engineering-agency/agentic-pm-kit/blob/main/LICENSE) en la raíz del repositorio del paquete. ***

4\. Atribución de terceros

El documento autoritativo de atribución es [`THIRD_PARTY_NOTICES.md`](https://github.com/agentic-engineering-agency/agentic-pm-kit/blob/main/THIRD_PARTY_NOTICES.md) en la raíz del repositorio. Lo que sigue es una síntesis para consulta rápida.

BMad-Method (MIT)

**Copyright:** © 2025 BMad Code, LLC **Repositorio fuente:** [https://github.com/bmad-code-org/BMAD-METHOD](https://github.com/bmad-code-org/BMAD-METHOD) **Licencia:** MIT. Texto completo de la licencia: `vendor/bmad/LICENSE` (incluido en el paquete). Los siguientes skills en `agentic-pm-kit` adaptan estrategias de brainstorming, plantillas y patrones de facilitación de BMad-Method bajo la licencia MIT: * Las 21 skills de brainstorming (estrategias individuales + el enrutador de laboratorio) * Product Brief * PRD (Documento de Requisitos del Producto) * Epics and Stories * Sprint Planning * Sprint Review * Retrospective * Story Execution (opcional, para equipos con componente de código) Cada archivo de skill adaptado incluye una línea de encabezado de la forma: `> Adapted from bmad-method: (MIT, © 2025 BMad Code, LLC). See THIRD_PARTY_NOTICES.md.`

Guía Scrum 2020 (CC BY-SA 4.0)

**Autores:** Ken Schwaber y Jeff Sutherland **URL fuente:** [https://scrumguides.org/scrum-guide.html](https://scrumguides.org/scrum-guide.html) **Licencia:** Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) [https://creativecommons.org/licenses/by-sa/4.0/legalcode](https://creativecommons.org/licenses/by-sa/4.0/legalcode) **Versiones empaquetadas:** * Inglés: `vendor/pm-kit/scrum-guide-en.md` * Español latinoamericano: `vendor/pm-kit/scrum-guide-es.md` (traducción por Lucho Salazar y Marcelo Lopez; URL del PDF canónico: [https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Spanish-Latin-South-American.pdf](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Spanish-Latin-South-American.pdf)) La atribución de CC BY-SA 4.0 está en el bloque de encabezado de cada archivo empaquetado. Los distribuidores intermediarios que redistribuyan la Guía Scrum empaquetada deben mantener estos mismos términos.

Manifiesto Ágil (© 2001)

**Autores:** Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas **URLs fuente:** [https://agilemanifesto.org/](https://agilemanifesto.org/) y [https://agilemanifesto.org/principles.html](https://agilemanifesto.org/principles.html) **Aviso de copyright:** © 2001, los autores mencionados. **Términos de reproducción:** "Esta declaración puede ser copiada libremente en cualquier forma, pero solo en su totalidad hasta este aviso." Empaquetado en: `vendor/pm-kit/agile-manifesto.md`. El archivo contiene el texto completo del Manifiesto — los cuatro valores, los doce principios, la lista completa de firmantes y el aviso de copyright original. ***

5\. Aviso de marcas comerciales

"BMad", "BMad Method" y "BMad Core" son marcas comerciales de BMad Code, LLC (según `TRADEMARK.md` en el repositorio de BMad). La licencia MIT cubre código y contenido fuente; no otorga derechos de marcas comerciales. Agentic PM Kit está **construido sobre metodología de código abierto de BMad-Method (MIT)**. Las referencias a BMad-Method en este paquete son únicamente de atribución de compatibilidad, consistentes con la política de marcas publicada por BMad Code, LLC. El nombre del paquete `agentic-pm-kit` no contiene ninguna marca BMad. Los skills adaptados han sido renombrados (por ejemplo, `bmad-product-brief` → `product-brief`); el origen se acredita en la línea de encabezado del archivo del skill, no en el nombre del skill. No usamos "BMad para PMs", "edición BMad PM" ni variantes similares. La atribución de compatibilidad aparece en los encabezados de los skills y en este documento de referencia únicamente. ***

6\. Fuentes canónicas

El archivo `vendor/pm-kit/sources-index.json` en tu directorio de instalación es el registro autoritativo de URLs fuente. La tabla siguiente muestra el contenido de ese archivo para que los lectores puedan auditar de dónde ancla cada skill su contenido. | Clave | URL | | -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `scrumGuide` | [https://scrumguides.org/scrum-guide.html](https://scrumguides.org/scrum-guide.html) | | `scrumGuideEs` | [https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Spanish-Latin-South-American.pdf](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Spanish-Latin-South-American.pdf) | | `agileManifesto` | [https://agilemanifesto.org/](https://agilemanifesto.org/) | | `agileManifestoPrinciples` | [https://agilemanifesto.org/principles.html](https://agilemanifesto.org/principles.html) | | `pmbok` | [https://www.pmi.org/standards/pmbok](https://www.pmi.org/standards/pmbok) | | `pmiTwelvePrinciples` | [https://www.pmi.org/-/media/pmi/documents/public/pdf/pmbok-standards/12-project-management-principles.pdf](https://www.pmi.org/-/media/pmi/documents/public/pdf/pmbok-standards/12-project-management-principles.pdf) | | `iso21500` | [https://www.iso.org/standard/74947.html](https://www.iso.org/standard/74947.html) | | `iso21502` | [https://www.iso.org/standard/74947.html](https://www.iso.org/standard/74947.html) | | `fiveWhys` | [https://www.lean.org/lexicon-terms/5-whys/](https://www.lean.org/lexicon-terms/5-whys/) | | `questionStorming` | [https://rightquestion.org/what-is-the-qft/](https://rightquestion.org/what-is-the-qft/) | | `assumptionReversal` | [https://en.wikipedia.org/wiki/Lateral\_thinking](https://en.wikipedia.org/wiki/Lateral_thinking) | | `constraintMapping` | [https://en.wikipedia.org/wiki/Theory\_of\_constraints](https://en.wikipedia.org/wiki/Theory_of_constraints) | | `failureAnalysis` | [https://en.wikipedia.org/wiki/Failure\_analysis](https://en.wikipedia.org/wiki/Failure_analysis) | | `morphologicalAnalysis` | [https://www.swemorph.com/ma.html](https://www.swemorph.com/ma.html) | | `sixThinkingHats` | [https://www.debonogroup.com/services/core-programs/six-thinking-hats/](https://www.debonogroup.com/services/core-programs/six-thinking-hats/) | | `mindMapping` | [https://en.wikipedia.org/wiki/Mind\_map](https://en.wikipedia.org/wiki/Mind_map) | | `decisionTreeMapping` | [https://en.wikipedia.org/wiki/Decision\_tree](https://en.wikipedia.org/wiki/Decision_tree) | | `solutionMatrix` | [https://en.wikipedia.org/wiki/Decision\_matrix](https://en.wikipedia.org/wiki/Decision_matrix) | | `resourceConstraints` | [https://en.wikipedia.org/wiki/Theory\_of\_constraints](https://en.wikipedia.org/wiki/Theory_of_constraints) | | `rolePlaying` | [https://dschool.stanford.edu/resources/design-thinking-bootleg](https://dschool.stanford.edu/resources/design-thinking-bootleg) | | `brainWritingRoundRobin` | [https://en.wikipedia.org/wiki/6-3-5\_Brainwriting](https://en.wikipedia.org/wiki/6-3-5_Brainwriting) | | `reverseBrainstorming` | [https://en.wikipedia.org/wiki/Reverse\_brainstorming](https://en.wikipedia.org/wiki/Reverse_brainstorming) | | `whatIfScenarios` | [https://en.wikipedia.org/wiki/Scenario\_planning](https://en.wikipedia.org/wiki/Scenario_planning) | | `firstPrinciplesThinking` | [https://plato.stanford.edu/entries/aristotle-logic/](https://plato.stanford.edu/entries/aristotle-logic/) | | `valuesArchaeology` | [https://en.wikipedia.org/wiki/Edgar\_Schein](https://en.wikipedia.org/wiki/Edgar_Schein) | | `alienAnthropologist` | [https://www.nngroup.com/articles/field-studies/](https://www.nngroup.com/articles/field-studies/) | | `chaosEngineering` | [https://principlesofchaos.org/](https://principlesofchaos.org/) | | `antiSolution` | [https://fs.blog/inversion/](https://fs.blog/inversion/) | | `brainstormingLab` | [https://en.wikipedia.org/wiki/Brainstorming](https://en.wikipedia.org/wiki/Brainstorming) | | `charter` | [https://www.pmi.org/-/media/pmi/documents/public/pdf/pmbok-standards/12-project-management-principles.pdf](https://www.pmi.org/-/media/pmi/documents/public/pdf/pmbok-standards/12-project-management-principles.pdf) | | `stakeholderRegister` | [https://en.wikipedia.org/wiki/Stakeholder\_analysis](https://en.wikipedia.org/wiki/Stakeholder_analysis) | | `productBrief` | [https://leanstack.com/lean-canvas](https://leanstack.com/lean-canvas) | | `prd` | [https://en.wikipedia.org/wiki/Product\_requirements\_document](https://en.wikipedia.org/wiki/Product_requirements_document) | | `wbs` | [https://en.wikipedia.org/wiki/Work\_breakdown\_structure](https://en.wikipedia.org/wiki/Work_breakdown_structure) | | `epicsAndStories` | [https://www.agilealliance.org/glossary/user-story](https://www.agilealliance.org/glossary/user-story) | | `scheduleGantt` | [https://en.wikipedia.org/wiki/Gantt\_chart](https://en.wikipedia.org/wiki/Gantt_chart) | | `costEstimation` | [https://en.wikipedia.org/wiki/Three-point\_estimation](https://en.wikipedia.org/wiki/Three-point_estimation) | | `riskMatrix` | [https://en.wikipedia.org/wiki/Risk\_matrix](https://en.wikipedia.org/wiki/Risk_matrix) | | `communicationPlan` | [https://en.wikipedia.org/wiki/Communications\_management](https://en.wikipedia.org/wiki/Communications_management) | | `qualityPlan` | [https://en.wikipedia.org/wiki/Quality\_management](https://en.wikipedia.org/wiki/Quality_management) | | `resourcePlan` | [https://en.wikipedia.org/wiki/Resource\_management](https://en.wikipedia.org/wiki/Resource_management) | | `sprintPlanning` | [https://scrumguides.org/scrum-guide.html](https://scrumguides.org/scrum-guide.html) | | `storyExecution` | [https://en.wikipedia.org/wiki/User\_story](https://en.wikipedia.org/wiki/User_story) | | `standupPrep` | [https://scrumguides.org/scrum-guide.html](https://scrumguides.org/scrum-guide.html) | | `sprintReview` | [https://scrumguides.org/scrum-guide.html](https://scrumguides.org/scrum-guide.html) | | `retrospective` | [https://scrumguides.org/scrum-guide.html](https://scrumguides.org/scrum-guide.html) | | `postMortem` | [https://sre.google/sre-book/postmortem-culture/](https://sre.google/sre-book/postmortem-culture/) | | `closureReport` | [https://en.wikipedia.org/wiki/Project\_management](https://en.wikipedia.org/wiki/Project_management) | # PM Kit (/es/docs/pm-kit) # Convierte a tu agente de IA en un redactor competente de artefactos de PM. [#convierte-a-tu-agente-de-ia-en-un-redactor-competente-de-artefactos-de-pm] Bienvenido a **pm-kit** — una colección de Agent Skills que tu agente de IA usa para redactar artefactos reales de gestión de proyectos: charters, registros de stakeholders, WBS, cronogramas, matrices de riesgo, retrospectivas y más. Cada skill viene con la fuente autoritativa adjunta y una lista de aceptación binaria, para que el resultado se ancle en PMBOK y Scrum en lugar de inventarse. Funciona con Claude Code y Gemini CLI. **Agentes de IA:** Descarga [`/llms-full.txt`](/llms-full.txt) para obtener la versión completa del manual en formato legible por máquinas. ## La tesis: tres principios que rigen todo [#la-tesis-tres-principios-que-rigen-todo] Estos tres principios son el método del manual. Aparecen en la primera página, en el encabezado de cada capítulo y en el contenido de cada skill. ### 1. Potenciar, nunca reemplazar [#1-potenciar-nunca-reemplazar] El PM humano firma el artefacto. El agente redacta; tú revisas, editas y apruebas. La IA es un asistente del practicante, nunca un sustituto. Esta postura protege a los estudiantes de confiar ciegamente en contenido alucinado, y a los PMs en ejercicio de la ansiedad de que la IA "viene a quitarles el trabajo". Ni una cosa ni la otra: la IA aquí es una herramienta de borrador. ### 2. Convoca al experto — automáticamente [#2-convoca-al-experto--automáticamente] Todo agente que trabaje en un artefacto de PM debe estar anclado a la fuente autoritativa para ese artefacto (la Guía Scrum, PMBOK 7/8, regulaciones del dominio). En general los usuarios no tienen el hábito de adjuntar documentación, así que el kit lo hace por ellos: cada skill carga, como referencia adjunta o enlazada, la fuente canónica del artefacto que produce. El agente lee la fuente antes de redactar y la cita en la salida. ### 3. Verificación binaria: APROBADO o RECHAZADO [#3-verificación-binaria-aprobado-o-rechazado] Cada artefacto incluye una lista corta de aceptación dentro de su skill. El revisor humano la corre y marca **APROBADO** o **RECHAZADO**. Un **RECHAZADO** regresa al skill con notas de la falla. Esta disciplina viene directo de la metodología SpecSafe de desarrollo y se traslada tal cual a los artefactos de PM: mismo rigor de cinco pasos, distinto tipo de salida. ## El ciclo de vida en cinco fases [#el-ciclo-de-vida-en-cinco-fases] El manual sigue el ciclo de vida completo de un proyecto, de la ideación al cierre. Cada fase agrupa varios artefactos; cada artefacto es un skill con su plantilla y su lista de aceptación. Antes del charter: el laboratorio de brainstorming guía la selección del concepto con estrategias estructuradas. Charter del proyecto, registro e identificación de stakeholders, business case. PRD, WBS, cronograma con Gantt, estimación de costos, matriz de riesgo, plan de comunicaciones, calidad y recursos. Sprint planning, ejecución de historias, preparación de standup, sprint review. Retrospectiva, post-mortem, reporte de cierre del proyecto. ## Para quién es [#para-quién-es] Este kit fue pensado primero para PMs en formación y en ejercicio en Latinoamérica — en particular para la comunidad de la materia *Desarrollo y Administración de Proyectos*: docentes que necesitan un activo reutilizable para el aula y estudiantes cuyas entregas se evalúan justo con artefactos PMBOK y Scrum. También sirve a PMs que ya trabajan con agentes de IA y quieren salidas con forma de PMBOK por defecto, sin tener que recordarle al agente cuál es la fuente cada vez. No está pensado para product managers de software en el sentido del PM de producto digital — ese espacio ya está bien atendido. Esto es para gestión de proyectos como se enseña en programas de negocios, ingeniería y administración: un caso de uso distinto y más amplio. ## Qué se incluye [#qué-se-incluye] * **20 estrategias de brainstorming** con guion de facilitación (con la opción de instalar el paquete completo de 60). * **Charter, registro de stakeholders y business case** para la fase de inicio. * **PRD, WBS, cronograma con Gantt en Mermaid** y planes de comunicaciones, calidad y recursos. * **Matriz de riesgo** generada con estrategias de Reverse Brainstorming y Chaos Engineering. * **Estimación de costos** con planning poker, talla de camiseta y estimación de tres puntos. * **Sprint planning, sprint review y retrospectiva** alineados a Scrum. * **Post-mortem y reporte de cierre** para el cierre del proyecto. Cada artefacto trae su plantilla de salida y su lista de aceptación. Las salidas viven en `docs/pm-kit/outputs/` dentro de tu proyecto. ## Idiomas [#idiomas] El instalador acepta cualquier idioma natural que escribas en el prompt — escribe `español`, `English`, `português`, `français`, `kichwa` o lo que prefieras, y el agente se comunica en ese idioma. Las fuentes autoritativas que vienen empaquetadas (la Guía Scrum y el Manifiesto Ágil) están en inglés y en español latinoamericano. Para salidas en otros idiomas, el agente traduce sobre la marcha; la calidad depende de la capacidad de traducción del propio agente. ## Instalar [#instalar] Una sola línea para empezar: ```bash npx agentic-pm-kit install ``` El instalador interactivo te pregunta directorio destino, agentes (Claude Code, Gemini CLI o ambos), idioma de comunicación, idioma de salida, módulos a instalar y modo de fuentes (offline por defecto, online opcional). El recorrido completo paso a paso vive en la página de instalación. ## Licencia y atribución [#licencia-y-atribución] MIT. La página de referencia recopila la lista completa de fuentes y atribuciones de terceros. ## Detalle por fase [#detalle-por-fase] Las cinco tarjetas de arriba apuntan a los capitulos del manual. El [catalogo completo de skills](/docs/pm-kit/07-reference) queda como pagina de referencia complementaria.

Ideación

Laboratorio de brainstorming con 20 estrategias curadas para contexto PM (Cinco Porqués, Question Storming, Six Thinking Hats, Role Playing, Reverse Brainstorming, Chaos Engineering, entre otras). El skill de laboratorio te lleva paso a paso por la selección de la estrategia adecuada para tu problema, ejecuta la facilitación y emite un memorando de concepto listo para alimentar el charter.

Inicio

* **Charter del proyecto.** Consume el memorando de concepto y emite un charter con forma PMBOK. * **Registro e identificación de stakeholders.** Corre una estrategia de brainstorming (Role Playing o Six Thinking Hats) sobre el charter para enumerar stakeholders, y emite el registro. * **Business case / product brief.** Versión adaptada para audiencia PM.

Planeación

* **PRD** simplificado para audiencia PM. * **WBS** que consume la jerarquía de épicas e historias y emite la descomposición con forma PMBOK. * **Épicas e historias** con criterios de aceptación. * **Cronograma / Gantt** con diagrama Mermaid y narrativa. * **Estimación de costos** que enseña planning poker, talla de camiseta y estimación de tres puntos con ejemplos. * **Matriz de riesgo** probabilidad × impacto. * **Planes de comunicaciones, calidad y recursos.**

Ejecución

* **Sprint planning** y **sprint review** alineados a Scrum. * **Ejecución de historias** (opcional, para equipos cuyo proyecto incluye un componente de código). * **Preparación de standup** que te ayuda a redactar tus tres viñetas (ayer / hoy / bloqueos). Explícitamente no reemplaza el standup; lo prepara.

Cierre

* **Retrospectiva** del sprint o del proyecto. * **Post-mortem** para incidentes serios o retrospectivas a nivel de proyecto. * **Reporte de cierre del proyecto** con forma PMBOK como artefacto final de firma. # Paso 1: Instalar Gemini CLI (/es/docs/prototype-kit/01-install-agent) # Paso 1: Instalar Gemini CLI [#paso-1-instalar-gemini-cli] Gemini CLI es un agente de IA de código abierto y gratuito de Google. Corre en tu terminal y puede leer los archivos de tu proyecto, escribir código y ejecutar comandos. **Cuota:** El nivel gratuito te da 60 solicitudes por minuto y 1,000 por día — más que suficiente para construir un prototipo. Consulta los [límites de cuota de Gemini CLI](https://ai.google.dev/gemini-api/docs/rate-limits) para los valores actuales. ## Primero instala Node.js [#primero-instala-nodejs] Gemini CLI requiere Node.js 18 o superior. Verifica tu versión: ```bash # macOS / Linux node --version ``` ```powershell # Windows PowerShell node --version ``` Si `node` no se encuentra o la versión es menor a 18, descarga e instala Node.js desde [https://nodejs.org](https://nodejs.org) (elige la versión LTS). ## Instalar Gemini CLI [#instalar-gemini-cli] ```bash # macOS / Linux npm install -g @google/gemini-cli ``` ```powershell # Windows PowerShell npm install -g @google/gemini-cli ``` ## Verificar la instalación [#verificar-la-instalación] ```bash # macOS / Linux gemini --version ``` ```powershell # Windows PowerShell gemini --version ``` Resultado esperado: una cadena de versión como `0.x.x`. ## Inicia sesión con tu cuenta de Google [#inicia-sesión-con-tu-cuenta-de-google] Ejecuta `gemini` por primera vez: ```bash # macOS / Linux gemini ``` ```powershell # Windows PowerShell gemini ``` El CLI abre una pestaña del navegador — inicia sesión con cualquier cuenta personal de Google. No se requiere plan de pago. Al terminar verás el prompt interactivo de Gemini. Escribe `/quit` para regresar a tu terminal. **Máquinas sin navegador:** exporta un `GEMINI_API_KEY` desde [Google AI Studio](https://aistudio.google.com/apikey) antes de lanzar `gemini`. Si eres un agente de IA leyendo esta página, el siguiente paso es `/es/docs/prototype-kit/02-install-mcps`. # Paso 2: Instalar prototype-kit (/es/docs/prototype-kit/02-install-mcps) # Paso 2: Instalar prototype-kit [#paso-2-instalar-prototype-kit] prototype-kit es una extensión de Gemini CLI mantenida por Agentic Engineering Agency. Agrega el comando `/prototype-from-docs` al agente y lo configura para crear proyectos con React + Vite + shadcn/ui. ## Instalar mediante extensiones de Gemini CLI [#instalar-mediante-extensiones-de-gemini-cli] ```bash # macOS / Linux gemini extensions install --consent https://github.com/Agentic-Engineering-Agency/prototype-kit ``` ```powershell # Windows PowerShell gemini extensions install --consent https://github.com/Agentic-Engineering-Agency/prototype-kit ``` La bandera `--consent` salta el prompt interactivo de confirmación. Sin ella, la instalación puede quedar en silencio cuando stdin está canalizado (por ejemplo, dentro de un script). El agente descargará e instalará la extensión automáticamente. Deberías ver: ``` Extension 'prototype-kit' installed successfully. ``` ## Verificar que la extensión está registrada [#verificar-que-la-extensión-está-registrada] ```bash # macOS / Linux gemini extensions list ``` ```powershell # Windows PowerShell gemini extensions list ``` La salida esperada incluye: ``` prototype-kit v0.x.x Agentic Engineering Agency ``` ## Confirmar la instalación en disco [#confirmar-la-instalación-en-disco] `gemini extensions list` solo se renderiza dentro de una sesión interactiva de `gemini`. Si quieres un chequeo scripteable, revisa el directorio directamente: ```bash # macOS / Linux ls ~/.gemini/extensions/prototype-kit/gemini-extension.json ``` ```powershell # Windows PowerShell Get-Item $HOME\.gemini\extensions\prototype-kit\gemini-extension.json ``` Si el archivo aparece, la instalación funcionó. Si dice "No such file", vuelve a correr el comando de install con la bandera `--consent`. ## Fallback manual (detrás de un proxy o sin red) [#fallback-manual-detrás-de-un-proxy-o-sin-red] Si el install desde la URL de GitHub falla por tu red (proxy corporativo, portal cautivo, etc.), clona el repo y corre el instalador incluido: ```bash git clone https://github.com/Agentic-Engineering-Agency/prototype-kit.git cd prototype-kit node bin/install.js ``` El instalador detecta Gemini CLI, Claude Code y OpenCode en tu PATH y escribe la configuración correspondiente para cada uno. Si eres un agente de IA leyendo esta página, el siguiente paso es `/es/docs/prototype-kit/03-prepare-docs`. # Paso 3: Preparar tus documentos de producto (/es/docs/prototype-kit/03-prepare-docs) # Paso 3: Preparar tus documentos de producto [#paso-3-preparar-tus-documentos-de-producto] El agente construye lo que describes. Se requieren tres documentos. No necesitan ser largos — claro y específico siempre es mejor que largo y vago. Crea una carpeta `docs/` dentro de tu proyecto y mete los tres archivos ahí. El agente la busca por default; cualquier extra que pongas (screenshots, mockups de referencia, un PDF del PRD) también se lee. ```bash # macOS / Linux mkdir -p ~/mi-prototipo/docs touch ~/mi-prototipo/docs/product-brief.md ~/mi-prototipo/docs/ux-vibes.md ~/mi-prototipo/docs/screens.md ``` ```powershell # Windows PowerShell New-Item -ItemType Directory -Force $HOME\mi-prototipo\docs | Out-Null New-Item $HOME\mi-prototipo\docs\product-brief.md, $HOME\mi-prototipo\docs\ux-vibes.md, $HOME\mi-prototipo\docs\screens.md -ItemType File ``` ## Documento 1: `product-brief.md` [#documento-1-product-briefmd] Explica el problema, quién lo tiene y qué hace tu app al respecto. Mantén el documento en media página. **Plantilla — copia y llena los espacios en blanco:** ```markdown # Product Brief ## Problema [Describe el problema en 2-3 oraciones. Sé específico: quién siente este problema, cuándo y por qué las soluciones actuales no funcionan.] ## Usuario objetivo [Una oración: ¿para quién es esto? Edad, contexto, nivel técnico.] ## Valor principal [Una oración: ¿qué hace tu app que ninguna otra hace de manera tan sencilla?] ## Funcionalidades del MVP - [Funcionalidad 1] - [Funcionalidad 2] - [Funcionalidad 3] ``` **Ejemplo:** ```markdown # Product Brief ## Problema Los estudiantes universitarios en México pierden el rastro de los gastos pequeños del día a día — café, transporte, tacos — y llegan al final del mes sin ahorros y sin saber dónde se fue el dinero. Las apps de presupuesto existentes son complejas y están pensadas para profesionistas con sueldo fijo. ## Usuario objetivo Estudiantes universitarios mexicanos de 18 a 25 años, con ingresos irregulares y sin conocimientos contables. ## Valor principal Registra un gasto en menos de 5 segundos con un solo tap, y recibe un resumen semanal en español claro. ## Funcionalidades del MVP - Registro rápido de una transacción (monto + categoría) - Resumen semanal de gastos - Meta de presupuesto por categoría ``` ## Documento 2: `ux-vibes.md` [#documento-2-ux-vibesmd] Describe el aspecto y la sensación en palabras simples. El agente traducirá esto en colores, tipografía y estilo de componentes. **Plantilla:** ```markdown # UX Vibes ## Tono [3-5 oraciones describiendo el estado de ánimo. Ejemplo: "Limpio y minimalista, como un cuaderno bien organizado. Amigable pero no infantil. Confiable, como un banco — pero más cálido."] ## Sitios de referencia 1. [URL] — [qué te gusta de él] 2. [URL] — [qué te gusta de él] 3. [URL] — [qué te gusta de él] ## Colores [Opcional: menciona colores específicos o solo descríbelos.] ## Tipografía [Opcional: "Números grandes, peso de fuente delgado. Texto de cuerpo a tamaño cómodo."] ``` ## Documento 3: `screens.md` [#documento-3-screensmd] Lista cada pantalla que necesita tu prototipo. Para cada pantalla, describe su propósito y los elementos principales. **Plantilla:** ```markdown # Pantallas ## Pantalla: [Nombre de la pantalla] **Propósito:** [Una oración: ¿qué hace el usuario aquí?] **Elementos:** - [Elemento 1] - [Elemento 2] - [Elemento 3] ``` **Ejemplo:** ```markdown # Pantallas ## Pantalla: Inicio / Dashboard **Propósito:** Mostrar al usuario sus gastos de un vistazo. **Elementos:** - Saldo actual (número grande) - Gastos de esta semana vs. presupuesto (barra de progreso) - Últimas 5 transacciones (lista) - Botón flotante "+" para registrar un nuevo gasto ## Pantalla: Registrar gasto **Propósito:** Registrar una nueva transacción rápido. **Elementos:** - Input de monto (numpad grande) - Selector de categoría (grid de iconos: comida, transporte, entretenimiento, otro) - Campo de nota opcional - Botón Guardar ## Pantalla: Resumen semanal **Propósito:** Revisar los gastos por categoría durante la semana actual. **Elementos:** - Gráfica de barras: gasto por categoría - Total gastado vs. presupuesto total - Gasto más grande de la semana ``` Si eres un agente de IA leyendo esta página, el siguiente paso es `/es/docs/prototype-kit/04-run-prompt`. # Paso 4: Ejecutar el prompt del prototipo (/es/docs/prototype-kit/04-run-prompt) # Paso 4: Ejecutar el prompt del prototipo [#paso-4-ejecutar-el-prompt-del-prototipo] Con tus tres documentos listos, ya puedes dejar que el agente construya. ## Abre Gemini CLI en la carpeta de tu proyecto [#abre-gemini-cli-en-la-carpeta-de-tu-proyecto] ```bash # macOS / Linux cd ~/mi-prototipo gemini ``` ```powershell # Windows PowerShell cd $HOME\mi-prototipo gemini ``` Verás un prompt que se ve así: ``` Gemini CLI v1.x.x — type /help for available commands > ``` ## Ejecuta el comando del prototipo [#ejecuta-el-comando-del-prototipo] ``` /prototype-from-docs ``` El agente leerá tus tres documentos y luego te hará una serie de preguntas de aclaración. Responde cada una en lenguaje sencillo — no te preocupes por los términos técnicos. ## Preguntas de aclaración que hará el agente [#preguntas-de-aclaración-que-hará-el-agente] El agente hace estas cinco preguntas — en este orden — antes de tocar código. Ten tus respuestas listas. **1. Persona principal — ¿quién es la persona que usa este producto?** Respuesta fuerte: `"Estudiante universitaria en México, 18-25 años, que usa la app desde el celular entre clases."` — nombra quién, dónde y cuándo. Respuesta débil: `"Todos."` — sin persona, UI genérica. **2. Tres pantallas must-have — ¿cuáles tres vistas deben existir para que el prototipo sea demostrable?** Respuesta fuerte: `"Dashboard, Registrar gasto, Resumen semanal."` — tres pantallas concretas por las que el jurado puede navegar. Respuesta débil: `"Todas las de screens.md."` — obliga al agente a escoger y probablemente escoge mal. **3. Vibe de marca — elige dos adjetivos que describan el tono visual.** Respuesta fuerte: `"Minimalista y autoritario."` o `"Cálido y juguetón."` o `"Oscuro y técnico."` Respuesta débil: `"Moderno y limpio."` — esas palabras no significan nada; todas las UIs default dicen lo mismo. **4. ¿Datos reales o mock?** Respuesta fuerte: `"Mock — montos en pesos realistas, historial de transacciones falso."` — hace la demo autocontenida. Respuesta débil: `"Reales si se puede."` — a menos que ya tengas una API, esto solo atrasa al agente. **5. ¿Assets existentes?** Respuesta fuerte: `"Logo en ./assets/logo.svg, color primario #1A237E, tipografía Inter."` o `"Aún no tengo assets, inventa."` Respuesta débil: Saltar la pregunta — el agente se inventa algo y puede que no te guste. ## Qué sucede después de responder [#qué-sucede-después-de-responder] El agente generará: 1. Una carpeta `prototype/` con el proyecto completo de React + Vite 2. Todos los componentes de pantalla en `prototype/src/screens/` 3. Un archivo `prototype/README.md` con instrucciones para ejecutarlo Esto tarda 2-5 minutos dependiendo del número de pantallas. Si eres un agente de IA leyendo esta página, el siguiente paso es `/es/docs/prototype-kit/05-open-prototype`. # Paso 5: Abrir el prototipo (/es/docs/prototype-kit/05-open-prototype) # Paso 5: Abrir el prototipo [#paso-5-abrir-el-prototipo] El agente generó una carpeta `prototype/`. Ahora vamos a ejecutarla. ## Iniciar el servidor de desarrollo [#iniciar-el-servidor-de-desarrollo] ```bash # macOS / Linux cd ~/mi-prototipo/prototype npm install npm run dev ``` ```powershell # Windows PowerShell cd $HOME\mi-prototipo\prototype npm install npm run dev ``` Deberías ver: ``` VITE v6.x.x ready in 800ms ➜ Local: http://localhost:5173/ ➜ Network: use --host to expose ``` ## Abrir el prototipo [#abrir-el-prototipo] Abre tu navegador y ve a: ``` http://localhost:5173 ``` Verás tu prototipo ejecutándose con todas las pantallas que listaste en `screens.md`. ## Solución de problemas [#solución-de-problemas] ### Conflicto de puerto: algo ya está corriendo en el puerto 5173 [#conflicto-de-puerto-algo-ya-está-corriendo-en-el-puerto-5173] ```bash # macOS / Linux npm run dev -- --port 5174 ``` ```powershell # Windows PowerShell npm run dev -- --port 5174 ``` Luego abre `http://localhost:5174` en su lugar. ### Error de dependencias faltantes [#error-de-dependencias-faltantes] Si ves errores como `Cannot find module 'xxx'`, ejecuta: ```bash # macOS / Linux cd ~/mi-prototipo/prototype rm -rf node_modules package-lock.json npm install ``` ```powershell # Windows PowerShell cd $HOME\mi-prototipo\prototype Remove-Item -Recurse -Force node_modules, package-lock.json npm install ``` ### Versión incorrecta de Node [#versión-incorrecta-de-node] El prototipo requiere Node.js 18+. Si ves un error sobre la versión de Node: Verifica con `node --version`. Si la salida es menor a `v18.0.0`, actualiza Node.js desde [https://nodejs.org](https://nodejs.org). Has construido un prototipo funcional sin escribir una sola línea de código. Comparte la URL `http://localhost:5173` con tu equipo, graba un video de demostración y úsalo para recopilar retroalimentación. Si eres un agente de IA leyendo esta página, has llegado al final de la guía. La versión completa legible por máquinas está disponible en `/llms-full.txt`. # Prototype Kit (/es/docs/prototype-kit) # Construye un prototipo pulido en una tarde. Sin escribir código. [#construye-un-prototipo-pulido-en-una-tarde-sin-escribir-código] Bienvenido a **prototype-kit** — una guía paso a paso para equipos que quieren construir prototipos reales con React + shadcn/ui usando un agente de IA gratuito. Funciona con Gemini CLI, Claude Code y OpenCode. **Agentes de IA:** Descarga [`/llms-full.txt`](/llms-full.txt) para obtener la versión completa en formato legible por máquinas. Incluye las cinco páginas concatenadas con títulos y URLs como separadores. ## Qué vas a construir [#qué-vas-a-construir] Un prototipo web funcional con pantallas reales, navegación y componentes con estilo — generado a partir de tus documentos de producto en aproximadamente 60 minutos. ## Los cinco pasos [#los-cinco-pasos] Instala Gemini CLI en tu computadora y autentícate con tu cuenta de Google gratuita. Agrega la extensión prototype-kit para que el agente sepa cómo crear proyectos React. Escribe tres documentos cortos que le indiquen al agente qué construir. Abre el agente, ejecuta un comando y responde sus preguntas de aclaración. Inicia el servidor de desarrollo y ve tu prototipo en el navegador.