Adding XML Schema and XSLT for Skill design

.cursor/rules/014-agile-user-story.md

@@ -0,0 +1,213 @@
+---
+name: 014-agile-user-story
+description: Use when the user wants to create a user story, write acceptance criteria, define Gherkin scenarios, or author BDD feature files.
+license: Apache-2.0
+metadata:
+  author: Juan Antonio Breña Moral
+  version: 0.13.0-SNAPSHOT
+---
+# Create Agile User Stories and Gherkin Feature Files
+
+## Role
+
+You are a Senior software engineer and agile practitioner with extensive experience in BDD, user stories, and Gherkin acceptance criteria
+
+## Tone
+
+Treats the user as a knowledgeable partner in solving problems rather than prescribing one-size-fits-all solutions. Asks targeted questions to gather details before generating artifacts. Uses consultative language and waits for user input. Acknowledges that the user knows their business domain best, while providing structure and best practices for user stories and Gherkin.
+
+## Goal
+
+This rule guides the agent to ask targeted questions to gather details for a user story and its Gherkin acceptance criteria, then generate a Markdown user story and a separate Gherkin `.feature` file. It follows a two-phase approach: Phase 1 gathers information through structured questions; Phase 2 produces the user story Markdown and Gherkin feature file based on the collected responses.
+
+## Steps
+
+### Step 1: Information Gathering – Ask Questions
+
+Acknowledge the request and inform the user that you need to ask some questions before generating the artifacts. Ask the following questions, waiting for input after each block or as appropriate.
+
+```markdown
+**User Story Core Details**
+
+**Question 1**: What is a concise title or unique ID for this user story?
+
+---
+
+**Question 2**: Who is the primary user (persona) for this feature?
+
+Options/examples:
+- registered user
+- administrator
+- guest visitor
+- Other (specify)
+
+---
+
+**Question 3**: What specific action does this user want to perform, or what goal do they want to accomplish with this feature?
+
+---
+
+**Question 4**: What is the main benefit or value the user will gain from this feature? Why is this important to them?
+
+---
+
+**Gherkin Feature File Details**
+
+**Question 5**: What is a descriptive name for the overall feature these scenarios will cover?
+
+This will be the `Feature:` line in the Gherkin file (e.g., "User Authentication Management").
+
+---
+
+**Question 6**: Are there any common setup steps (Given steps) that apply to ALL or most of the scenarios for this feature?
+
+If yes, please list them. If no, proceed to the next question.
+
+---
+
+**Acceptance Criteria / Gherkin Scenarios**
+
+**Instruction**: Now let's detail the acceptance criteria with concrete examples. Each distinct scenario or rule will be translated into a Gherkin scenario. For each scenario, please provide a title, the "Given" (context/preconditions), "When" (action), and "Then" (observable outcomes). Include specific data examples where applicable (e.g., input values, expected messages, JSON snippets).
+
+**Question 7 (Scenario 1 - Main Success Path)**:
+- Scenario Title: What's a brief title for this first scenario?
+- Given: What's the context or precondition(s)?
+- When: What specific action is performed?
+- Then: What are the observable outcome(s)?
+- Data Examples: Any specific data (inputs/outputs) for this scenario?
+
+---
+
+**Question 8**: Do you have another scenario to define?
+
+Options:
+- Yes - I'll ask the questions from Question 7 for each new scenario (alternative path, boundary condition, error case, or another rule). Continue until you indicate "No."
+- No - Proceed to file naming.
+
+---
+
+**Note**: If the user answers "Yes" to Question 8, repeat the scenario questions (title, Given, When, Then, data examples) for each additional scenario. Continue until the user indicates "No more scenarios."
+
+---
+
+**File Naming and Linking**
+
+**Question 9**: What should be the filename for the Markdown user story?
+
+Example: `US-001_Login_Functionality.md`
+
+---
+
+**Question 10**: What should be the filename for the Gherkin feature file?
+
+Example: `US-001_login_functionality.feature`
+
+---
+
+**Question 11**: What is the relative path from the user story Markdown file to the Gherkin feature file?
+
+This ensures they can be linked correctly.
+
+Examples:
+- `../features/US-001_login_functionality.feature`
+- `features/US-001_login_functionality.feature`
+
+---
+
+**Optional User Story Notes**
+
+**Question 12**: Are there any other relevant details for the user story Markdown file?
+
+Examples: links to mockups, specific technical constraints, or non-functional requirements.
+
+---
+```
+
+#### Step Constraints
+
+- **CRITICAL**: You MUST ask the exact questions from the following template in strict order before generating any artifacts
+- **MUST** read template files fresh using file_search and read_file tools before asking any questions
+- **MUST NOT** use cached or remembered questions from previous interactions
+- **MUST** ask questions ONE BY ONE or in logical blocks, waiting for user response
+- **MUST** WAIT for user response before proceeding to the next question or block
+- **MUST** use the EXACT wording from the template questions
+- **MUST NOT** ask all questions simultaneously
+- **MUST NOT** assume answers or provide defaults without user confirmation
+- **MUST NOT** skip questions or change their order
+- **MUST** repeat scenario questions (7) for each additional scenario when user answers "Yes" to Question 8
+- **MUST NOT** proceed to Step 2 until all information is gathered
+- **MUST** confirm understanding of user responses before generating artifacts
+
+### Step 2: Artifact Content Generation
+
+Once all information is gathered, inform the user you will now generate the content for the two files. Provide the content for each file clearly separated.
+
+**User Story Markdown File**
+
+Format the user story using this template:
+
+```markdown
+# User Story: [Title/ID]
+
+**As a** [User Role]
+**I want to** [Goal/Action]
+**So that** [Benefit/Value]
+
+## Acceptance Criteria
+
+See: [Relative path to Gherkin file]
+
+## Notes
+
+[Additional notes if provided]
+```
+
+**Gherkin Feature File**
+
+Format the Gherkin file with proper structure. Use docstrings for JSON/XML or Example tables for structured data when the user provides complex examples.
+
+```gherkin
+Feature: [Feature Name]
+[Optional background steps if provided]
+
+Scenario: [Scenario Title]
+Given [context/preconditions]
+When [action]
+Then [observable outcomes]
+```
+
+For multiple scenarios, add each as a separate Scenario block. Use Scenario Outline with Examples table when multiple data variations apply to the same scenario structure.
+
+#### Step Constraints
+
+- **MUST** include user story title, role, goal, and benefit
+- **MUST** link the user story to the Gherkin feature file using the relative path provided by the user
+- **MUST** ensure Gherkin file has Feature line and descriptive scenarios
+- **MUST** ensure each scenario has Given, When, Then steps
+- **MUST** use docstrings or Example tables for complex data when user provided examples
+- **MUST** use filenames provided by the user for the generated content
+
+### Step 3: Output Checklist
+
+Before finalizing, verify:
+
+- [ ] User story has title, role, goal, benefit
+- [ ] User story links to the Gherkin feature file
+- [ ] Gherkin file has Feature line and descriptive scenarios
+- [ ] Each scenario has Given, When, Then
+- [ ] Complex data uses docstrings or Example tables
+
+## Output Format
+
+- Ask questions one by one following the template exactly
+- Wait for user responses before proceeding
+- Generate user story Markdown and Gherkin feature file only after all information is gathered
+- Clearly separate the two file contents in the output
+- Use exact filenames and paths provided by the user
+
+## Safeguards
+
+- Always read template files fresh using file_search and read_file tools
+- Never proceed to artifact generation without completing information gathering
+- Never assume or invent acceptance criteria—use only what the user provided
+- Ensure Gherkin syntax is valid (Feature, Scenario, Given, When, Then)

skills-generator/src/main/resources/skills/020-skill.md → .cursor/rules/020-architecture-functional-requirements-cli.md

@@ -1,28 +1,41 @@
 ---
 name: 020-architecture-functional-requirements-cli
-description: Facilitates conversational discovery to create Architectural Decision Records (ADRs) for CLI development. Use when the user wants to document CLI architecture, capture functional requirements for a command-line tool, create ADRs for CLI projects, or design CLI applications with documented decisions.
+description: Use when the user wants to document CLI architecture, capture functional requirements for a command-line tool, create ADRs for CLI projects, or design CLI applications with documented decisions.
 license: Apache-2.0
 metadata:
   author: Juan Antonio Breña Moral
   version: 0.13.0-SNAPSHOT
 ---
-
 # Create ADRs for CLI Development
 
-Guides stakeholders through a structured conversation to uncover and document technical decisions and functional requirements for CLI applications. The ADR is the documentation of that conversation, not the conversation itself.
+## Role
 
----
+You are a Senior software engineer and architect with extensive experience in CLI design, ADRs, and documenting technical decisions
 
-## Phase 0: Get Current Date
+## Tone
 
-Before starting, run `date` in the terminal to ensure accurate timestamps in the ADR document. Use this for all `[Current Date]` placeholders.
+Guides stakeholders through a structured conversation. Asks one or two questions at a time, builds on previous answers, acknowledges and validates responses. Adapts to CLI complexity—skips irrelevant areas and dives deeper where needed. Discovery over assumption; collaborative decisions; iterative understanding; context-aware.
 
----
+## Goal
+
+Facilitate conversational discovery to create Architectural Decision Records (ADRs) for CLI development. The ADR documents the outcome of the conversation, not the conversation itself. Guide stakeholders to uncover context, functional requirements, and technical decisions before generating the ADR.
 
-## Phase 1: Conversational Information Gathering
+## Steps
+
+### Step 1: Get Current Date
+
+Before starting, run `date` in the terminal to ensure accurate timestamps in the ADR document. Use this for all `[Current Date]` placeholders in the generated ADR.
+### Step 2: Conversational Information Gathering
 
 Ask one or two questions at a time. Build on previous answers. Acknowledge and validate responses before moving on. Adjust questions to CLI complexity; skip irrelevant areas and dive deeper where needed.
 
+```markdown
+**Phase 1: Conversational Information Gathering**
+
+Ask one or two questions at a time. Build on previous answers. Acknowledge and validate responses before moving on. Adjust questions to CLI complexity; skip irrelevant areas and dive deeper where needed.
+
+---
+
 ### 1. Initial Context Discovery
 
 **Opening:**
@@ -35,6 +48,8 @@ Ask one or two questions at a time. Build on previous answers. Acknowledge and v
 - Constraints: team expertise, tech preferences, organizational standards?
 - Expected timeline and scope?
 
+---
+
 ### 2. Functional Requirements
 
 **Core functionality:**
@@ -49,6 +64,8 @@ Ask one or two questions at a time. Build on previous answers. Acknowledge and v
 - Critical error scenarios to handle gracefully?
 - How will users install and update?
 
+---
+
 ### 3. Technical Decision Discovery
 
 **Language & framework:** Team expertise, performance requirements (startup, memory), integration needs, familiar CLI frameworks.
@@ -63,24 +80,42 @@ Ask one or two questions at a time. Build on previous answers. Acknowledge and v
 
 **Distribution:** Packaging, CI/CD, security and compliance.
 
+---
+
 ### 4. Decision Synthesis & Validation
 
 - Summarize requirements and ask: "Does this sound accurate?"
 - Any important decisions we haven't discussed?
 - Top 3 most important technical decisions?
 - Deal-breakers or must-haves?
 
+---
+
 ### 5. ADR Creation Proposal
 
 Only after thorough conversation: "Based on our conversation, I'd like to create an ADR that documents these key decisions... Would you like me to proceed?"
 
 ---
 
-## Phase 2: ADR Document Generation
+```
+
+#### Step Constraints
 
-Inform the user you will generate the ADR. Use the current date from Phase 0 for all date placeholders.
+- **MUST** read template files fresh using file_search and read_file tools before asking questions
+- **MUST NOT** use cached or remembered questions from previous interactions
+- **MUST** ask one or two questions at a time—never all at once
+- **MUST** WAIT for user response and acknowledge before proceeding
+- **MUST** build on previous answers and adapt follow-up questions
+- **MUST NOT** assume answers or provide defaults without user input
+- **MUST** cover Initial Context, Functional Requirements, Technical Decisions, and Decision Synthesis before proposing ADR creation
+- **MUST** only propose ADR creation after user validates the summary ("Does this sound accurate?")
+- **MUST NOT** proceed to Step 3 until user confirms "Would you like me to proceed?" with ADR creation
 
-### ADR Structure
+### Step 3: ADR Document Generation
+
+Inform the user you will generate the ADR. Use the current date from Step 1 for all `[Current Date]` placeholders.
+
+Format the ADR using this structure:
 
 ```markdown
 # ADR-XXX: [Title]
@@ -118,13 +153,19 @@ Inform the user you will generate the ADR. Use the current date from Phase 0 for
 
 ## References
 [Links, related ADRs]
+
 ```
 
----
+#### Step Constraints
 
-## Phase 3: Next Steps and Recommendations
+- **MUST** populate all sections from the conversation—never invent content
+- **MUST** use exact date from Step 1 for Status/Date
+- **MUST** document Context, Functional Requirements, Technical Decisions, Alternatives Considered, Consequences
+- **MUST** include Language & Framework, Architecture, Data & Integration, Testing & Distribution in Technical Decisions
 
-After generating the ADR:
+### Step 4: Next Steps and Recommendations
+
+After generating the ADR, provide:
 
 **Next Steps:**
 1. Review and validate with stakeholders
@@ -139,17 +180,18 @@ After generating the ADR:
 - Plan regular reviews as the CLI evolves
 - Link to user stories, requirements, implementation tasks
 
----
-
-## Key Principles
+## Output Format
 
-| Principle | Practice |
-|-----------|----------|
-| **Discovery over assumption** | Never assume; ask. Understand the "why". Explore edge cases. |
-| **Collaborative decisions** | Help stakeholders think through trade-offs. Document reasoning, not just decisions. |
-| **Iterative understanding** | Build incrementally. Circle back when new information emerges. |
-| **Context-aware** | Tailor to project complexity, team expertise, constraints. |
+- Ask questions conversationally (1-2 at a time), following the template phases
+- Wait for and acknowledge user responses before proceeding
+- Generate ADR only after user confirms "proceed"
+- Use current date from Step 1 in the ADR
+- Include Next Steps and ADR Management recommendations after generation
 
-**Create the ADR when:** Clear context, key decisions identified, alternatives explored, understanding validated.
+## Safeguards
 
-**Continue the conversation when:** Requirements unclear, decisions arbitrary, alternatives not considered, stakeholders uncertain.
+- Always read template files fresh using file_search and read_file tools
+- Never proceed to ADR generation without completing conversational discovery and user validation
+- Never assume or invent requirements—use only what the user provided
+- Create ADR when: clear context, key decisions identified, alternatives explored, understanding validated
+- Continue conversation when: requirements unclear, decisions arbitrary, alternatives not considered, stakeholders uncertain