siesa-agents 2.1.78 → 2.1.80

package/claude/skills/bmad-edit-prd/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: bmad-edit-prd
+description: 'Edit an existing PRD. Use when the user says "edit this PRD".'
+---
+
+# PRD Edit Workflow
+
+**Goal:** Edit and improve existing PRDs through structured enhancement workflow.
+
+**Your Role:** PRD improvement specialist.
+
+You will continue to operate with your given name, identity, and communication_style, merged with the details of this role description.
+
+## Conventions
+
+- Bare paths (e.g. `steps-e/step-e-01-discovery.md`) resolve from the skill root.
+- `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
+- `{project-root}`-prefixed paths resolve from the project working directory.
+- `{skill-name}` resolves to the skill directory's basename.
+
+## WORKFLOW ARCHITECTURE
+
+This uses **step-file architecture** for disciplined execution:
+
+### Core Principles
+
+- **Micro-file Design**: Each step is a self-contained instruction file that is a part of an overall workflow that must be followed exactly
+- **Just-In-Time Loading**: Only the current step file is in memory - never load future step files until told to do so
+- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
+- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
+- **Append-Only Building**: Build documents by appending content as directed to the output file
+
+### Step Processing Rules
+
+1. **READ COMPLETELY**: Always read the entire step file before taking any action
+2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
+3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
+4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
+5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
+6. **LOAD NEXT**: When directed, read fully and follow the next step file
+
+### Critical Rules (NO EXCEPTIONS)
+
+- 🛑 **NEVER** load multiple step files simultaneously
+- 📖 **ALWAYS** read entire step file before execution
+- 🚫 **NEVER** skip steps or optimize the sequence
+- 💾 **ALWAYS** update frontmatter of output files when writing the final output for a specific step
+- 🎯 **ALWAYS** follow the exact instructions in the step file
+- ⏸️ **ALWAYS** halt at menus and wait for user input
+- 📋 **NEVER** create mental todo lists from future steps
+
+## On Activation
+
+### Step 1: Resolve the Workflow Block
+
+Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
+
+**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
+
+1. `{skill-root}/customize.toml` — defaults
+2. `{project-root}/_bmad/custom/{skill-name}.toml` — team overrides
+3. `{project-root}/_bmad/custom/{skill-name}.user.toml` — personal overrides
+
+Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
+
+### Step 2: Execute Prepend Steps
+
+Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
+
+### Step 3: Load Persistent Facts
+
+Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
+
+### Step 4: Load Config
+
+Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
+- Use `{user_name}` for greeting
+- Use `{communication_language}` for all communications
+- Use `{document_output_language}` for output documents
+- Use `{planning_artifacts}` for output location and artifact scanning
+- Use `{project_knowledge}` for additional context scanning
+
+### Step 5: Greet the User
+
+Greet `{user_name}`, speaking in `{communication_language}`.
+
+### Step 6: Execute Append Steps
+
+Execute each entry in `{workflow.activation_steps_append}` in order.
+
+Activation is complete. Begin the workflow below.
+
+## Execution
+
+✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the configured `{communication_language}`.
+✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`.
+
+**Edit Mode: Improving an existing PRD.**
+
+Prompt for PRD path: "Which PRD would you like to edit? Please provide the path to the PRD.md file."
+
+Then read fully and follow: `./steps-e/step-e-01-discovery.md`

package/claude/skills/bmad-edit-prd/customize.toml

@@ -0,0 +1,42 @@
+# DO NOT EDIT -- overwritten on every update.
+#
+# Workflow customization surface for bmad-edit-prd. Mirrors the
+# agent customization shape under the [workflow] namespace.
+
+[workflow]
+
+# --- Configurable below. Overrides merge per BMad structural rules: ---
+#   scalars: override wins • arrays (persistent_facts, activation_steps_*): append
+#   arrays-of-tables with `code`/`id`: replace matching items, append new ones.
+
+# Steps to run before the standard activation (config load, greet).
+# Overrides append. Use for pre-flight loads, compliance checks, etc.
+
+activation_steps_prepend = []
+
+# Steps to run after greet but before the workflow begins.
+# Overrides append. Use for context-heavy setup that should happen
+# once the user has been acknowledged.
+
+activation_steps_append = []
+
+# Persistent facts the workflow keeps in mind for the whole run
+# (standards, compliance constraints, stylistic guardrails).
+# Distinct from the runtime memory sidecar — these are static context
+# loaded on activation. Overrides append.
+#
+# Each entry is either:
+#   - a literal sentence, e.g. "All PRDs must include a regulatory-risk section."
+#   - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
+#     (glob patterns are supported; the file's contents are loaded and treated as facts).
+
+persistent_facts = [
+  "file:{project-root}/**/project-context.md",
+]
+
+# Scalar: executed when the workflow reaches Step E-4 (Complete & Validate) and the
+# user exits via [S] Summary or [X] Exit — not on [V] Validate (which chains to
+# bmad-validate-prd) or [E] Edit More (which loops back). Override wins.
+# Leave empty for no custom post-completion behavior.
+
+on_complete = ""

package/claude/skills/bmad-edit-prd/data/prd-purpose.md

@@ -0,0 +1,197 @@
+# BMAD PRD Purpose
+
+**The PRD is the top of the required funnel that feeds all subsequent product development work in rhw BMad Method.**
+
+---
+
+## What is a BMAD PRD?
+
+A dual-audience document serving:
+1. **Human Product Managers and builders** - Vision, strategy, stakeholder communication
+2. **LLM Downstream Consumption** - UX Design → Architecture → Epics → Development AI Agents
+
+Each successive document becomes more AI-tailored and granular.
+
+---
+
+## Core Philosophy: Information Density
+
+**High Signal-to-Noise Ratio**
+
+Every sentence must carry information weight. LLMs consume precise, dense content efficiently.
+
+**Anti-Patterns (Eliminate These):**
+- ❌ "The system will allow users to..." → ✅ "Users can..."
+- ❌ "It is important to note that..." → ✅ State the fact directly
+- ❌ "In order to..." → ✅ "To..."
+- ❌ Conversational filler and padding → ✅ Direct, concise statements
+
+**Goal:** Maximum information per word. Zero fluff.
+
+---
+
+## The Traceability Chain
+
+**PRD starts the chain:**
+```
+Vision → Success Criteria → User Journeys → Functional Requirements → (future: User Stories)
+```
+
+**In the PRD, establish:**
+- Vision → Success Criteria alignment
+- Success Criteria → User Journey coverage
+- User Journey → Functional Requirement mapping
+- All requirements traceable to user needs
+
+**Why:** Each downstream artifact (UX, Architecture, Epics, Stories) must trace back to documented user needs and business objectives. This chain ensures we build the right thing.
+
+---
+
+## What Makes Great Functional Requirements?
+
+### FRs are Capabilities, Not Implementation
+
+**Good FR:** "Users can reset their password via email link"
+**Bad FR:** "System sends JWT via email and validates with database" (implementation leakage)
+
+**Good FR:** "Dashboard loads in under 2 seconds for 95th percentile"
+**Bad FR:** "Fast loading time" (subjective, unmeasurable)
+
+### SMART Quality Criteria
+
+**Specific:** Clear, precisely defined capability
+**Measurable:** Quantifiable with test criteria
+**Attainable:** Realistic within constraints
+**Relevant:** Aligns with business objectives
+**Traceable:** Links to source (executive summary or user journey)
+
+### FR Anti-Patterns
+
+**Subjective Adjectives:**
+- ❌ "easy to use", "intuitive", "user-friendly", "fast", "responsive"
+- ✅ Use metrics: "completes task in under 3 clicks", "loads in under 2 seconds"
+
+**Implementation Leakage:**
+- ❌ Technology names, specific libraries, implementation details
+- ✅ Focus on capability and measurable outcomes
+
+**Vague Quantifiers:**
+- ❌ "multiple users", "several options", "various formats"
+- ✅ "up to 100 concurrent users", "3-5 options", "PDF, DOCX, TXT formats"
+
+**Missing Test Criteria:**
+- ❌ "The system shall provide notifications"
+- ✅ "The system shall send email notifications within 30 seconds of trigger event"
+
+---
+
+## What Makes Great Non-Functional Requirements?
+
+### NFRs Must Be Measurable
+
+**Template:**
+```
+"The system shall [metric] [condition] [measurement method]"
+```
+
+**Examples:**
+- ✅ "The system shall respond to API requests in under 200ms for 95th percentile as measured by APM monitoring"
+- ✅ "The system shall maintain 99.9% uptime during business hours as measured by cloud provider SLA"
+- ✅ "The system shall support 10,000 concurrent users as measured by load testing"
+
+### NFR Anti-Patterns
+
+**Unmeasurable Claims:**
+- ❌ "The system shall be scalable" → ✅ "The system shall handle 10x load growth through horizontal scaling"
+- ❌ "High availability required" → ✅ "99.9% uptime as measured by cloud provider SLA"
+
+**Missing Context:**
+- ❌ "Response time under 1 second" → ✅ "API response time under 1 second for 95th percentile under normal load"
+
+---
+
+## Domain-Specific Requirements
+
+**Auto-Detect and Enforce Based on Project Context**
+
+Certain industries have mandatory requirements that must be present:
+
+- **Healthcare:** HIPAA Privacy & Security Rules, PHI encryption, audit logging, MFA
+- **Fintech:** PCI-DSS Level 1, AML/KYC compliance, SOX controls, financial audit trails
+- **GovTech:** NIST framework, Section 508 accessibility (WCAG 2.1 AA), FedRAMP, data residency
+- **E-Commerce:** PCI-DSS for payments, inventory accuracy, tax calculation by jurisdiction
+
+**Why:** Missing these requirements in the PRD means they'll be missed in architecture and implementation, creating expensive rework. During PRD creation there is a step to cover this - during validation we want to make sure it was covered. For this purpose steps will utilize a domain-complexity.csv and project-types.csv.
+
+---
+
+## Document Structure (Markdown, Human-Readable)
+
+### Required Sections
+1. **Executive Summary** - Vision, differentiator, target users
+2. **Success Criteria** - Measurable outcomes (SMART)
+3. **Product Scope** - MVP, Growth, Vision phases
+4. **User Journeys** - Comprehensive coverage
+5. **Domain Requirements** - Industry-specific compliance (if applicable)
+6. **Innovation Analysis** - Competitive differentiation (if applicable)
+7. **Project-Type Requirements** - Platform-specific needs
+8. **Functional Requirements** - Capability contract (FRs)
+9. **Non-Functional Requirements** - Quality attributes (NFRs)
+
+### Formatting for Dual Consumption
+
+**For Humans:**
+- Clear, professional language
+- Logical flow from vision to requirements
+- Easy for stakeholders to review and approve
+
+**For LLMs:**
+- ## Level 2 headers for all main sections (enables extraction)
+- Consistent structure and patterns
+- Precise, testable language
+- High information density
+
+---
+
+## Downstream Impact
+
+**How the PRD Feeds Next Artifacts:**
+
+**UX Design:**
+- User journeys → interaction flows
+- FRs → design requirements
+- Success criteria → UX metrics
+
+**Architecture:**
+- FRs → system capabilities
+- NFRs → architecture decisions
+- Domain requirements → compliance architecture
+- Project-type requirements → platform choices
+
+**Epics & Stories (created after architecture):**
+- FRs → user stories (1 FR could map to 1-3 stories potentially)
+- Acceptance criteria → story acceptance tests
+- Priority → sprint sequencing
+- Traceability → stories map back to vision
+
+**Development AI Agents:**
+- Precise requirements → implementation clarity
+- Test criteria → automated test generation
+- Domain requirements → compliance enforcement
+- Measurable NFRs → performance targets
+
+---
+
+## Summary: What Makes a Great BMAD PRD?
+
+✅ **High Information Density** - Every sentence carries weight, zero fluff
+✅ **Measurable Requirements** - All FRs and NFRs are testable with specific criteria
+✅ **Clear Traceability** - Each requirement links to user need and business objective
+✅ **Domain Awareness** - Industry-specific requirements auto-detected and included
+✅ **Zero Anti-Patterns** - No subjective adjectives, implementation leakage, or vague quantifiers
+✅ **Dual Audience Optimized** - Human-readable AND LLM-consumable
+✅ **Markdown Format** - Professional, clean, accessible to all stakeholders
+
+---
+
+**Remember:** The PRD is the foundation. Quality here ripples through every subsequent phase. A dense, precise, well-traced PRD makes UX design, architecture, epic breakdown, and AI development dramatically more effective.

package/claude/skills/bmad-edit-prd/steps-e/step-e-01-discovery.md

@@ -0,0 +1,242 @@
+---
+# File references (ONLY variables used in this step)
+prdPurpose: '../data/prd-purpose.md'
+---
+
+# Step E-1: Discovery & Understanding
+
+## STEP GOAL:
+
+Understand what the user wants to edit in the PRD, detect PRD format/type, check for validation report guidance, and route appropriately.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
+
+### Role Reinforcement:
+
+- ✅ You are a Validation Architect and PRD Improvement Specialist
+- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring analytical expertise and improvement guidance
+- ✅ User brings domain knowledge and edit requirements
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on discovering user intent and PRD format
+- 🚫 FORBIDDEN to make any edits yet
+- 💬 Approach: Inquisitive and analytical, understanding before acting
+- 🚪 This is a branch step - may route to legacy conversion
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Discover user's edit requirements
+- 🎯 Auto-detect validation reports in PRD folder (use as guide)
+- 🎯 Load validation report if provided (use as guide)
+- 🎯 Detect PRD format (BMAD/legacy)
+- 🎯 Route appropriately based on format
+- 💾 Document discoveries for next step
+- 🚫 FORBIDDEN to proceed without understanding requirements
+
+## CONTEXT BOUNDARIES:
+
+- Available context: PRD file to edit, optional validation report, auto-detected validation reports
+- Focus: User intent discovery and format detection only
+- Limits: Don't edit yet, don't validate yet
+- Dependencies: None - this is first edit step
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
+
+### 1. Load PRD Purpose Standards
+
+Load and read the complete file at:
+`{prdPurpose}` (data/prd-purpose.md)
+
+This file defines what makes a great BMAD PRD. Internalize this understanding - it will guide improvement recommendations.
+
+### 2. Discover PRD to Edit
+
+"**PRD Edit Workflow**
+
+Which PRD would you like to edit?
+
+Please provide the path to the PRD file you want to edit."
+
+**Wait for user to provide PRD path.**
+
+### 3. Validate PRD Exists and Load
+
+Once PRD path is provided:
+- Check if PRD file exists at specified path
+- If not found: "I cannot find a PRD at that path. Please check the path and try again."
+- If found: Load the complete PRD file including frontmatter
+
+### 4. Check for Existing Validation Report
+
+**Check if validation report exists in the PRD folder:**
+
+```bash
+# Look for most recent validation report in the PRD folder
+ls -t {prd_folder_path}/validation-report-*.md 2>/dev/null | head -1
+```
+
+**If validation report found:**
+
+Display:
+"**📋 Found Validation Report**
+
+I found a validation report from {validation_date} in the PRD folder.
+
+This report contains findings from previous validation checks and can help guide our edits to fix known issues.
+
+**Would you like to:**
+- **[U] Use validation report** - Load it to guide and prioritize edits
+- **[S] Skip** - Proceed with manual edit discovery"
+
+**Wait for user input.**
+
+**IF U (Use validation report):**
+- Load the validation report file
+- Extract findings, issues, and improvement suggestions
+- Note: "Validation report loaded - will use it to guide prioritized improvements"
+- Continue to step 5
+
+**IF S (Skip) or no validation report found:**
+- Note: "Proceeding with manual edit discovery"
+- Continue to step 5
+
+**If no validation report found:**
+- Note: "No validation report found in PRD folder"
+- Continue to step 5 without asking user
+
+### 5. Ask About Validation Report
+
+"**Do you have a validation report to guide edits?**
+
+If you've run the validation workflow on this PRD, I can use that report to guide improvements and prioritize changes.
+
+Validation report path (or type 'none'):"
+
+**Wait for user input.**
+
+**If validation report path provided:**
+- Load the validation report
+- Extract findings, severity, improvement suggestions
+- Note: "Validation report loaded - will use it to guide prioritized improvements"
+
+**If no validation report:**
+- Note: "Proceeding with manual edit discovery"
+- Continue to step 6
+
+### 6. Discover Edit Requirements
+
+"**What would you like to edit in this PRD?**
+
+Please describe the changes you want to make. For example:
+- Fix specific issues (information density, implementation leakage, etc.)
+- Add missing sections or content
+- Improve structure and flow
+- Convert to BMAD format (if legacy PRD)
+- General improvements
+- Other changes
+
+**Describe your edit goals:**"
+
+**Wait for user to describe their requirements.**
+
+### 7. Detect PRD Format
+
+Analyze the loaded PRD:
+
+**Extract all ## Level 2 headers** from PRD
+
+**Check for BMAD PRD core sections:**
+1. Executive Summary
+2. Success Criteria
+3. Product Scope
+4. User Journeys
+5. Functional Requirements
+6. Non-Functional Requirements
+
+**Classify format:**
+- **BMAD Standard:** 5-6 core sections present
+- **BMAD Variant:** 3-4 core sections present, generally follows BMAD patterns
+- **Legacy (Non-Standard):** Fewer than 3 core sections, does not follow BMAD structure
+
+### 8. Route Based on Format and Context
+
+**IF validation report provided OR PRD is BMAD Standard/Variant:**
+
+Display: "**Edit Requirements Understood**
+
+**PRD Format:** {classification}
+{If validation report: "**Validation Guide:** Yes - will use validation report findings"}
+**Edit Goals:** {summary of user's requirements}
+
+**Proceeding to deep review and analysis...**"
+
+Read fully and follow: `./step-e-02-review.md`
+
+**IF PRD is Legacy (Non-Standard) AND no validation report:**
+
+Display: "**Format Detected:** Legacy PRD
+
+This PRD does not follow BMAD standard structure (only {count}/6 core sections present).
+
+**Your edit goals:** {user's requirements}
+
+**How would you like to proceed?**"
+
+Present MENU OPTIONS below for user selection
+
+### 9. Present MENU OPTIONS (Legacy PRDs Only)
+
+**[C] Convert to BMAD Format** - Convert PRD to BMAD standard structure, then apply your edits
+**[E] Edit As-Is** - Apply your edits without converting the format
+**[X] Exit** - Exit and review conversion options
+
+#### EXECUTION RULES:
+
+- ALWAYS halt and wait for user input
+- Only proceed based on user selection
+
+#### Menu Handling Logic:
+
+- IF C (Convert): Read fully and follow: `./step-e-01b-legacy-conversion.md`
+- IF E (Edit As-Is): Display "Proceeding with edits..." then load next step
+- IF X (Exit): Display summary and exit
+- IF Any other: help user, then redisplay menu
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- User's edit requirements clearly understood
+- Auto-detected validation reports loaded and analyzed (when found)
+- Manual validation report loaded and analyzed (if provided)
+- PRD format detected correctly
+- BMAD PRDs proceed directly to review step
+- Legacy PRDs pause and present conversion options
+- User can choose conversion path or edit as-is
+
+### ❌ SYSTEM FAILURE:
+
+- Not discovering user's edit requirements
+- Not auto-detecting validation reports in PRD folder
+- Not loading validation report when provided (auto or manual)
+- Missing format detection
+- Not pausing for legacy PRDs without guidance
+- Auto-proceeding without understanding intent
+
+**Master Rule:** Understand before editing. Detect format early so we can guide users appropriately. Auto-detect and use validation reports for prioritized improvements.