@hanzlaa/rcode 3.6.16 → 4.1.0

package/rihal/skills/actions/2-plan/rihal-validate-prd/workflow.md

@@ -1,62 +0,0 @@
----
-main_config: '{project-root}/.rihal/config.json'
-validateWorkflow: './steps-v/step-v-01-discovery.md'
----
-
-# PRD Validate Workflow
-
-**Goal:** Validate existing PRDs against Rihal standards through comprehensive review.
-
-**Your Role:** Validation Architect and Quality Assurance Specialist.
-
-You will continue to operate with your given name, identity, and communication_style, merged with the details of this role description.
-
-## 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
-
-## INITIALIZATION SEQUENCE
-
-### 1. Configuration Loading
-
-Load and read full config from {main_config} and resolve:
-
-- `project_name`, `output_folder`, `planning_artifacts`, `user_name`
-- `communication_language`, `document_output_language`, `user_skill_level`
-- `date` as system-generated current datetime
-
-✅ 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}`.
-
-### 2. Route to Validate Workflow
-
-"**Validate Mode: Validating an existing PRD against Rihal standards.**"
-
-Then read fully and follow: `{validateWorkflow}` (steps-v/step-v-01-discovery.md)

package/rihal/skills/actions/3-solutioning/rihal-check-implementation-readiness/SKILL.md

@@ -1,46 +0,0 @@
----
-name: rihal-check-implementation-readiness
-internal: true
-description: >
-  Verify that PRD, UX designs, architecture decisions, and epics/stories are
-  all aligned and ready for implementation. Activates when the user says
-  "check implementation readiness", "is this ready for dev", "verify
-  alignment", "readiness check", "IR check", or "can we start building". Do
-  NOT use during active implementation (use rihal-correct-course instead).
-triggers:
-  - "check implementation readiness"
-  - "is this ready for dev"
-  - "verify
-  alignment"
-  - "readiness check"
-  - "IR check"
-  - "can we start building"
-user-invocable: true
----
-@.rihal/references/karpathy-guidelines.md
-
-
-## Overview
-
-Verify that PRD, UX designs, architecture decisions, and epics/stories are all aligned and ready for implementation.
-
-## Workflow
-
-Follow the instructions in ./workflow.md.
-
-## Output Format
-
-- Produces an alignment report with checklist format
-- Each artifact checked: PRD exists? | UX exists? | ADR exists? | Stories exist? | Cross-references match?
-- Final verdict: READY / BLOCKED (with explicit blockers)
-- Do NOT declare ready if any artifact is missing or references are stale
-
-## Examples
-
-### Happy Path
-**Input:** "Check if phase-03 is ready for implementation"
-**Expected behavior:** Read all artifacts in .rihal/phases/phase-03/. Cross-check references. Produce table with READY/MISSING per artifact. Final verdict with any blockers.
-
-### Edge Case: Stale Cross-References
-**Input:** (PRD mentions a feature that has no corresponding story)
-**Expected behavior:** Report as BLOCKED: "PRD section 3.2 references 'admin panel' but no story exists. Either create the story or remove from PRD scope."

package/rihal/skills/actions/3-solutioning/rihal-check-implementation-readiness/steps/step-06-final-assessment.md

@@ -1,126 +0,0 @@
----
-outputFile: '{planning_artifacts}/implementation-readiness-report-{{date}}.md'
----
-
-# Step 6: Final Assessment
-
-## STEP GOAL:
-
-To provide a comprehensive summary of all findings and give the report a final polish, ensuring clear recommendations and overall readiness status.
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-### Universal Rules:
-
-- 🛑 NEVER generate content without user input
-- 📖 CRITICAL: Read the complete step file before taking any action
-- 📖 You are at the final step - complete the assessment
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-### Role Reinforcement:
-
-- ✅ You are delivering the FINAL ASSESSMENT
-- ✅ Your findings are objective and backed by evidence
-- ✅ Provide clear, actionable recommendations
-- ✅ Success is measured by value of findings
-
-### Step-Specific Rules:
-
-- 🎯 Compile and summarize all findings
-- 🚫 Don't soften the message - be direct
-- 💬 Provide specific examples for problems
-- 🚪 Add final section to the report
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Review all findings from previous steps
-- 💾 Add summary and recommendations
-- 📖 Determine overall readiness status
-- 🚫 Complete and present final report
-
-## FINAL ASSESSMENT PROCESS:
-
-### 1. Initialize Final Assessment
-
-"Completing **Final Assessment**.
-
-I will now:
-
-1. Review all findings from previous steps
-2. Provide a comprehensive summary
-3. Add specific recommendations
-4. Determine overall readiness status"
-
-### 2. Review Previous Findings
-
-Check the {outputFile} for sections added by previous steps:
-
-- File and FR Validation findings
-- UX Alignment issues
-- Epic Quality violations
-
-### 3. Add Final Assessment Section
-
-Append to {outputFile}:
-
-```markdown
-## Summary and Recommendations
-
-### Overall Readiness Status
-
-[READY/NEEDS WORK/NOT READY]
-
-### Critical Issues Requiring Immediate Action
-
-[List most critical issues that must be addressed]
-
-### Recommended Next Steps
-
-1. [Specific action item 1]
-2. [Specific action item 2]
-3. [Specific action item 3]
-
-### Final Note
-
-This assessment identified [X] issues across [Y] categories. Address the critical issues before proceeding to implementation. These findings can be used to improve the artifacts or you may choose to proceed as-is.
-```
-
-### 4. Complete the Report
-
-- Ensure all findings are clearly documented
-- Verify recommendations are actionable
-- Add date and assessor information
-- Save the final report
-
-### 5. Present Completion
-
-Display:
-"**Implementation Readiness Assessment Complete**
-
-Report generated: {outputFile}
-
-The assessment found [number] issues requiring attention. Review the detailed report for specific findings and recommendations."
-
-## WORKFLOW COMPLETE
-
-The implementation readiness workflow is now complete. The report contains all findings and recommendations for the user to consider.
-
-Implementation Readiness complete. Invoke the `rihal-help` skill.
-
----
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS:
-
-- All findings compiled and summarized
-- Clear recommendations provided
-- Readiness status determined
-- Final report saved
-
-### ❌ SYSTEM FAILURE:
-
-- Not reviewing previous findings
-- Incomplete summary
-- No clear recommendations

package/rihal/skills/actions/3-solutioning/rihal-check-implementation-readiness/workflow.md

@@ -1,49 +0,0 @@
-# Implementation Readiness
-
-**Goal:** Validate that PRD, Architecture, Epics and Stories are complete and aligned before Phase 4 implementation starts, with a focus on ensuring epics and stories are logical and have accounted for all requirements and planning.
-
-**Your Role:** You are an expert Product Manager and Scrum Master, renowned and respected in the field of requirements traceability and spotting gaps in planning. Your success is measured in spotting the failures others have made in planning or preparation of epics and stories to produce the users product vision.
-
-## WORKFLOW ARCHITECTURE
-
-### Core Principles
-
-- **Micro-file Design**: Each step of the overall goal is a self contained instruction file that you will adhere too 1 file as directed at a time
-- **Just-In-Time Loading**: Only 1 current step file will be loaded and followed to completion - 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
-
----
-
-## INITIALIZATION SEQUENCE
-
-### 1. Module Configuration Loading
-
-Load and read full config from {project-root}/.rihal/config.json and resolve:
-
-- `project_name`, `output_folder`, `planning_artifacts`, `user_name`, `communication_language`, `document_output_language`
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-### 2. First Step EXECUTION
-
-Read fully and follow: `./steps/step-01-document-discovery.md` to begin the workflow.

package/rihal/skills/actions/3-solutioning/rihal-create-architecture/SKILL.md

@@ -1,50 +0,0 @@
----
-name: rihal-create-architecture
-internal: true
-description: >
-  Write an Architecture Decision Record (ADR) to lock a significant
-  technical decision. Activates when the user says "write an ADR", "create
-  architecture decision", "document this architectural choice", "write an
-  architecture record", "lock this technical decision", or "record the
-  decision to use X". Do NOT use for implementation code (use
-  rihal-dev-story) or sprint planning (use rihal-sprint-planning).
-triggers:
-  - "write an ADR"
-  - "create
-  architecture decision"
-  - "document this architectural choice"
-  - "write an
-  architecture record"
-  - "lock this technical decision"
-  - "record the
-  decision to use X"
-user-invocable: true
----
-@.rihal/references/karpathy-guidelines.md
-
-
-## Overview
-
-Write an Architecture Decision Record (ADR) to lock a significant technical decision.
-
-## Workflow
-
-Follow the instructions in ./workflow.md.
-
-## Output Format
-
-- ADR file structure is fixed: Title | Status | Date | Decider | Context | Decision | Consequences | Alternatives Considered
-- Saved to .rihal/decisions/{NNN}-{slug}.md with sequential numbering
-- Status values: Proposed / Accepted / Deprecated / Superseded
-- At least 2 alternatives considered, each with explicit rejection reason
-- Do NOT skip the Alternatives section — it's the most important part
-
-## Examples
-
-### Happy Path
-**Input:** "Create an ADR for choosing Postgres over MongoDB"
-**Expected behavior:** Ask for context (what project, constraints). Produce ADR with Context, Decision (Postgres), Consequences (trade-offs both ways), Alternatives (MongoDB rejected because X, SQLite rejected because Y).
-
-### Edge Case: Insufficient Justification
-**Input:** "ADR: we're using React"
-**Expected behavior:** Refuse to write a one-liner ADR. Ask: "What did you reject (Vue, Svelte, Angular)? What trade-offs did you weigh? An ADR without alternatives is a note, not a decision record."

package/rihal/skills/actions/3-solutioning/rihal-create-architecture/steps/step-02-context.md

@@ -1,224 +0,0 @@
-# Step 2: Project Context Analysis
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- 🛑 NEVER generate content without user input
-
-- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
-- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
-- ✅ ALWAYS treat this as collaborative discovery between architectural peers
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- 💬 FOCUS on understanding project scope and requirements for architecture
-- 🎯 ANALYZE loaded documents, don't assume or generate requirements
-- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- ⚠️ Present A/P/C menu after generating project context analysis
-- 💾 ONLY save when user chooses C (Continue)
-- 📖 Update frontmatter `stepsCompleted: [1, 2]` before loading next step
-- 🚫 FORBIDDEN to load next step until C is selected
-
-## COLLABORATION MENUS (A/P/C):
-
-This step will generate content and present choices:
-
-- **A (Advanced Elicitation)**: Use discovery protocols to develop deeper insights about project context and architectural implications
-- **P (Party Mode)**: Bring multiple perspectives to analyze project requirements from different architectural angles
-- **C (Continue)**: Save the content to the document and proceed to next step
-
-## PROTOCOL INTEGRATION:
-
-- When 'A' selected: Invoke the `rihal-advanced-elicitation` skill
-- When 'P' selected: Invoke the `rihal-party-mode` skill
-- PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
-- User accepts/rejects protocol changes before proceeding
-
-## CONTEXT BOUNDARIES:
-
-- Current document and frontmatter from step 1 are available
-- Input documents already loaded are in memory (PRD, epics, UX spec, etc.)
-- Focus on architectural implications of requirements
-- No technology decisions yet - pure analysis phase
-
-## YOUR TASK:
-
-Fully read and Analyze the loaded project documents to understand architectural scope, requirements, and constraints before beginning decision making.
-
-## CONTEXT ANALYSIS SEQUENCE:
-
-### 1. Review Project Requirements
-
-**From PRD Analysis:**
-
-- Extract and analyze Functional Requirements (FRs)
-- Identify Non-Functional Requirements (NFRs) like performance, security, compliance
-- Note any technical constraints or dependencies mentioned
-- Count and categorize requirements to understand project scale
-
-**From Epics/Stories (if available):**
-
-- Map epic structure and user stories to architectural components
-- Extract acceptance criteria for technical implications
-- Identify cross-cutting concerns that span multiple epics
-- Estimate story complexity for architectural planning
-
-**From UX Design (if available):**
-
-- Extract architectural implications from UX requirements:
-  - Component complexity (simple forms vs rich interactions)
-  - Animation/transition requirements
-  - Real-time update needs (live data, collaborative features)
-  - Platform-specific UI requirements
-  - Accessibility standards (WCAG compliance level)
-  - Responsive design breakpoints
-  - Offline capability requirements
-  - Performance expectations (load times, interaction responsiveness)
-
-### 2. Project Scale Assessment
-
-Calculate and present project complexity:
-
-**Complexity Indicators:**
-
-- Real-time features requirements
-- Multi-tenancy needs
-- Regulatory compliance requirements
-- Integration complexity
-- User interaction complexity
-- Data complexity and volume
-
-### 3. Reflect Understanding
-
-Present your analysis back to user for validation:
-
-"I'm reviewing your project documentation for {{project_name}}.
-
-{if_epics_loaded}I see {{epic_count}} epics with {{story_count}} total stories.{/if_epics_loaded}
-{if_no_epics}I found {{fr_count}} functional requirements organized into {{fr_category_list}}.{/if_no_epics}
-{if_ux_loaded}I also found your UX specification which defines the user experience requirements.{/if_ux_loaded}
-
-**Key architectural aspects I notice:**
-
-- [Summarize core functionality from FRs]
-- [Note critical NFRs that will shape architecture]
-- {if_ux_loaded}[Note UX complexity and technical requirements]{/if_ux_loaded}
-- [Identify unique technical challenges or constraints]
-- [Highlight any regulatory or compliance requirements]
-
-**Scale indicators:**
-
-- Project complexity appears to be: [low/medium/high/enterprise]
-- Primary technical domain: [web/mobile/api/backend/full-stack/etc]
-- Cross-cutting concerns identified: [list major ones]
-
-This analysis will help me guide you through the architectural decisions needed to ensure AI agents implement this consistently.
-
-Does this match your understanding of the project scope and requirements?"
-
-### 4. Generate Project Context Content
-
-Prepare the content to append to the document:
-
-#### Content Structure:
-
-```markdown
-## Project Context Analysis
-
-### Requirements Overview
-
-**Functional Requirements:**
-{{analysis of FRs and what they mean architecturally}}
-
-**Non-Functional Requirements:**
-{{NFRs that will drive architectural decisions}}
-
-**Scale & Complexity:**
-{{project_scale_assessment}}
-
-- Primary domain: {{technical_domain}}
-- Complexity level: {{complexity_level}}
-- Estimated architectural components: {{component_count}}
-
-### Technical Constraints & Dependencies
-
-{{known_constraints_dependencies}}
-
-### Cross-Cutting Concerns Identified
-
-{{concerns_that_will_affect_multiple_components}}
-```
-
-### 5. Present Content and Menu
-
-Show the generated content and present choices:
-
-"I've drafted the Project Context Analysis based on your requirements. This sets the foundation for our architectural decisions.
-
-**Here's what I'll add to the document:**
-
-[Show the complete markdown content from step 4]
-
-**What would you like to do?**
-[A] Advanced Elicitation - Let's dive deeper into architectural implications
-[P] Party Mode - Bring different perspectives to analyze requirements
-[C] Continue - Save this analysis and begin architectural decisions"
-
-### 6. Handle Menu Selection
-
-#### If 'A' (Advanced Elicitation):
-
-- Invoke the `rihal-advanced-elicitation` skill with the current context analysis
-- Process the enhanced architectural insights that come back
-- Ask user: "Accept these enhancements to the project context analysis? (y/n)"
-- If yes: Update content with improvements, then return to A/P/C menu
-- If no: Keep original content, then return to A/P/C menu
-
-#### If 'P' (Party Mode):
-
-- Invoke the `rihal-party-mode` skill with the current project context
-- Process the collaborative improvements to architectural understanding
-- Ask user: "Accept these changes to the project context analysis? (y/n)"
-- If yes: Update content with improvements, then return to A/P/C menu
-- If no: Keep original content, then return to A/P/C menu
-
-#### If 'C' (Continue):
-
-- Append the final content to `{planning_artifacts}/architecture.md`
-- Update frontmatter: `stepsCompleted: [1, 2]`
-- Load `./step-03-starter.md`
-
-## APPEND TO DOCUMENT:
-
-When user selects 'C', append the content directly to the document using the structure from step 4.
-
-## SUCCESS METRICS:
-
-✅ All input documents thoroughly analyzed for architectural implications
-✅ Project scope and complexity clearly assessed and validated
-✅ Technical constraints and dependencies identified
-✅ Cross-cutting concerns mapped for architectural planning
-✅ User confirmation of project understanding
-✅ A/P/C menu presented and handled correctly
-✅ Content properly appended to document when C selected
-
-## FAILURE MODES:
-
-❌ Skimming documents without deep architectural analysis
-❌ Missing or misinterpreting critical NFRs
-❌ Not validating project understanding with user
-❌ Underestimating complexity indicators
-❌ Generating content without real analysis of loaded documents
-❌ Not presenting A/P/C menu after content generation
-
-❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
-❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
-❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
-
-## NEXT STEP:
-
-After user selects 'C' and content is saved to document, load `./step-03-starter.md` to evaluate starter template options.
-
-Remember: Do NOT proceed to step-03 until user explicitly selects 'C' from the A/P/C menu and content is saved!