stakeholder-mapping {Analysis} (v1.0)

"Analyze with evidence. Every claim tagged. Every finding actionable."

Purpose

Influence/interest matrix. RACI matrix. Communication plan. Power/interest grid. Stakeholder registry. [EXPLICIT] When to use: During analysis mode (capability source DNA). Before architecture or development begins.

Core Principles

1. Law of Evidence: Every finding tagged [CODE], [CONFIG], [DOC], [INFERENCE], or [ASSUMPTION] (R-001). [EXPLICIT]
2. Law of Completeness: No analysis deliverable ships without covering all required sections. [EXPLICIT]
3. Law of Platform Lens: Evaluate feasibility across the three target platforms — Firebase, Vercel, and Hostinger — mapping stakeholder needs to the platform that fits; do not assume a single vendor. [EXPLICIT]

Core Process

Phase 1: Gather

1. Collect inputs (documents, code, conversations, existing systems). [EXPLICIT]
2. Parse for requirements, constraints, and context. [EXPLICIT]

Phase 2: Analyze

1. Apply domain-specific analysis methodology. [EXPLICIT]
2. Tag all findings with evidence tags. [EXPLICIT]
3. Score/evaluate using the skill's specific metrics. [EXPLICIT]
4. Hidden-stakeholder detection — the org chart hides the real power. Run 6 surfacing techniques: Snowball (ask each named stakeholder "who else decides?"), Decision-trail (trace who signed past similar decisions), Veto-scan (who can say no / block budget), Budget-trail (who controls the money), Informal-network (who is consulted off-record), Meeting-archaeology (who attends the decision meetings vs the org chart). Separate formal authority from actual power. [DOC]
5. Resistance archetypes — classify each stakeholder's likely posture + the response per type: Skeptic (wants evidence → give data/proof), Blocker (has veto → co-design early), Passive-resister (agrees then stalls → make commitments explicit + visible), Saboteur (covert opposition → surface interests, escalate), Mourner (loss of status/old way → acknowledge, give a role in the new). [DOC]

Phase 3: Document

1. Produce the analysis deliverable in markdown. [EXPLICIT]
2. Include evidence tag summary (% by tag type). [EXPLICIT]
3. If >30% [ASSUMPTION], add WARNING banner. [EXPLICIT]

3. Inputs / Outputs

Validation Gate

• All findings have evidence tags
• Platform/stack feasibility assessed
• Deliverable follows R-008 output standards
• No implementation details (phase separation)
• Actionable recommendations included

5. Self-Correction Triggers

[!WARNING] IF >30% claims are [ASSUMPTION] THEN add prominent WARNING banner. IF analysis contains implementation details THEN move to plan (Art. 1.5 phase separation).

Usage

Example invocations:

• "/stakeholder-mapping" — Run the full stakeholder mapping workflow
• "stakeholder mapping on this project" — Apply to current context

Assumptions & Limits

• Assumes access to project artifacts (code, docs, configs) [EXPLICIT]
• Requires English-language output unless otherwise specified [EXPLICIT]
• Does not replace domain expert judgment for final decisions [EXPLICIT]

Edge Cases

Packet

Capas del packet, cargables bajo demanda (disciplina ICM: una capa por vez, nunca todas juntas): references/ guías de profundidad (cargar UNA por etapa) · knowledge/ cuerpo de conocimiento · prompts/ prompts listos · examples/ salida de ejemplo · agents/ subagentes del packet · templates/ plantilla de output · assets/ recursos estáticos.