juno-code 1.0.45 → 1.0.46

package/dist/templates/services/claude.py

@@ -27,10 +27,11 @@ class ClaudeService:
         ":claude-haiku-4-5": "claude-haiku-4-5-20251001",
         ":claude-sonnet-4-5": "claude-sonnet-4-5-20250929",
         ":claude-opus-4-5": "claude-opus-4-5-20251101",
+        ":claude-opus-4-6": "claude-opus-4-6",
         ":claude-opus-4": "claude-opus-4-20250514",
         ":haiku": "claude-haiku-4-5-20251001",
         ":sonnet": "claude-sonnet-4-5-20250929",
-        ":opus": "claude-opus-4-5-20251101",
+        ":opus": "claude-opus-4-6",
     }
 
     # Default allowed tools (used with --append-allowed-tools)

package/dist/templates/services/codex.py

@@ -17,12 +17,13 @@ class CodexService:
     """Service wrapper for OpenAI Codex CLI"""
 
     # Default configuration
-    DEFAULT_MODEL = "codex-5.2-max"
+    DEFAULT_MODEL = "gpt-5.3-codex"
     DEFAULT_AUTO_INSTRUCTION = """You are an AI coding assistant. Follow the instructions provided and generate high-quality code."""
 
     # Model shorthand mappings (colon-prefixed names expand to full model IDs)
     MODEL_SHORTHANDS = {
-        ":codex": "codex-5.2-codex-max",
+        ":codex": "gpt-5.3-codex",
+        ":codex-mini": "gpt-5.1-codex-mini",
         ":gpt-5": "gpt-5",
         ":mini": "gpt-5-codex-mini",
     }
@@ -70,10 +71,10 @@ Examples:
   %(prog)s -p "Write a hello world function"
   %(prog)s -pp prompt.txt --cd /path/to/project
   %(prog)s -p "Add tests" -m gpt-4 -c custom_arg=value
-  %(prog)s -p "Optimize code" -m :codex  # uses codex-5.2-codex-max
+  %(prog)s -p "Optimize code" -m :codex  # uses gpt-5.3-codex
 
 Environment Variables:
-  CODEX_MODEL                Model name (supports shorthand, default: codex-5.2-max)
+  CODEX_MODEL                Model name (supports shorthand, default: gpt-5.3-codex)
   CODEX_HIDE_STREAM_TYPES    Comma-separated list of streaming msg types to hide
                              Default: turn_diff,token_count,exec_command_output_delta
   JUNO_CODE_HIDE_STREAM_TYPES Same as CODEX_HIDE_STREAM_TYPES (alias)

package/dist/templates/skills/claude/plan-kanban-tasks/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: plan-kanban-tasks
+description: Generate Product Development Requirments(PDR) and create task on kanban. Use when user explictly ask for, or ask for creating a task, planing a feature, register a task on kaban.
+argument-hint: [Required Features] [Constraints] [Specification] [Test Criteria]
+---
+
+First task is to study @.juno_task/plan.md  (it may be incorrect) 
+and study what is needed to achieve the main task.
+
+
+Second Task is to understand the task, create a spec for process to follow, plan to execute, scripts to create, virtual enviroment that we need, things that we need to be aware of, how to test the scripts and follow progress.
+Think hard and plan/create spec for every step of this task
+and for each part create a seperate .md file under @.juno_task/specs/*
+
+## Task 2
+Update @.juno_task/plan.md with the new specs and Requirments.
+
+## Part 3 
+
+Create PDR on kanban, kanban is available in @.juno_task/scripts/kanban.sh 
+In the task body, include requirments, success criteria, test scenarios and jobs to be done. 
+For each chunk of the required feature create a seperate task, we want tasks, small enough to be done in one iteration, without compacting context window.
+
+
+

package/dist/templates/skills/claude/ralph-loop/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: ralph-loop
+description: should only get executed with explicit user request.
+---
+0a. study [references/implement.md](references/implement.md).
+
+0b.  When you discover a syntax, logic, UI, User Flow Error or bug. Immediately update  tasks.md with your findings using a  subagent. When the issue is resolved, update tasks.md and remove the item using a  subagent.
+
+
+999. Important: When authoring documentation capture the why tests and the backing implementation is important.
+
+9999. Important: We want single sources of truth, no migrations/adapters. If tests unrelated to your work fail then it's your job to resolve these tests as part of the increment of change.
+
+999999. As soon as there are no build or test errors create a git tag. If there are no git tags start at 0.0.0 and increment patch by 1 for example 0.0.1 if 0.0.0 does not exist.
+
+999999999. You may add extra logging if required to be able to debug the issues.
+
+9999999999. ALWAYS KEEP Tasks up to date with your learnings using a  subagent. Especially after wrapping up/finishing your turn.
+
+
+
+99999999999. When you learn something new about how to run the app or examples make sure you update @Claude.md using a  subagent but keep it brief. For example if you run commands multiple times before learning the correct command then that file should be updated.
+
+999999999999. IMPORTANT when you discover a bug resolve it using  subagents even if it is unrelated to the current piece of work after documenting it in Tasks
+
+9999999999999999999. Keep @Claude.md up to date with information on how to build the app and your learnings to optimize the build/test loop using a  subagent.
+
+999999999999999999999. For any bugs you notice, it's important to resolve them or document them in Tasks to be resolved using a  subagent.
+
+99999999999999999999999. When authoring the missing features you may author multiple standard libraries at once using up to 1000 parallel subagents
+
+99999999999999999999999999. When Tasks, Claude.md becomes large periodically clean out the items that are completed from the file using a  subagent.
+Large Claude.md reduce the performance.
+
+
+
+9999999999999999999999999999. DO NOT IMPLEMENT PLACEHOLDER OR SIMPLE IMPLEMENTATIONS. WE WANT FULL IMPLEMENTATIONS. DO IT OR I WILL YELL AT YOU
+
+9999999999999999999999999999999. SUPER IMPORTANT DO NOT IGNORE. DO NOT PLACE STATUS REPORT UPDATES INTO @Claude.md
+
+99999999999999999999999999999999. After reveiwing Feedback, if you find an open issue, you need to update previously handled issues status as well. If user reporting a bug, that earlier on reported on the Tasks or @Claude.md as resolved. You should update it to reflect that the issue is not resolved.
+it would be ok to include past reasoning and root causing to the open issue, You should mention. <PREVIOUS_AGENT_ATTEMP> Tag and describe the approach already taken, so the agent knows 1.the issue is still open,2. past approaches to resolve it, what it was, and know that it has failed.
+Tasks , USER_FEEDBACK and @Claude.md should repesent truth. User Open Issue is a high level of truth. so you need to reflect it on the files.

package/dist/templates/skills/claude/ralph-loop/references/first_check.md

@@ -0,0 +1,20 @@
+### Check once
+
+Perform these check once, to make sure about the git logic. There is no need to keep running this on every execution.
+
+**Detection & Creation Logic**:
+   - Check if the following command succeeds to determine if the repository is a git repo (create/verify .gitignore if so):
+
+     ```sh
+     git rev-parse --git-dir 2>/dev/null
+     ```
+   - Check if Dockerfile* exists or Docker in plan.md → create/verify .dockerignore
+   - Check if .eslintrc* or eslint.config.* exists → create/verify .eslintignore
+   - Check if .prettierrc* exists → create/verify .prettierignore
+   - Check if .npmrc or package.json exists → create/verify .npmignore (if publishing)
+   - Check if terraform files (*.tf) exist → create/verify .terraformignore
+   - Check if .helmignore needed (helm charts present) → create/verify .helmignore
+   
+   **If ignore file already exists**: Verify it contains essential patterns, append missing critical patterns only
+   **If ignore file missing**: Create with full pattern set for detected technology
+   

package/dist/templates/skills/claude/ralph-loop/references/implement.md

@@ -0,0 +1,99 @@
+---
+description: Study kanban.sh and Execute the implementation plan by processing and executing all tasks defined in  ./juno_task/tasks.md, update ./juno_task/tasks.md with the tasks on kanban
+---
+
+## User Input
+```text
+A.
+**ALWAYS check remaing tasks and user feedbacks. Integrate it into the plan,
+this is the primary mechanism for user input and for you to track your progress.
+`./juno_task/scripts/kanban.sh list --limit 5`
+return the most recent 5 Tasks and their status and potential agent response to them.
+
+**Important** ./juno_task/scripts/kanban.sh has already installed in your enviroment and you can execute it in your bash.
+
+A-1.
+read @.juno_task/USER_FEEDBACK.md user feedback on your current execution will be writeen here. And will guide you. If user wants to talk to you while you are working , he will write into this file. first think you do is to read it file.
+
+B.
+Based on Items in **./juno_task/scripts/kanban.sh** reflect on @.juno_task/plan.md and keep it up-to-date.
+0g. Entities and their status in **./juno_task/scripts/kanban.sh** has higher priority and level of truth than other parts of the app.
+If you see user report a bug that you earlier marked as resolved, you need to investigate the issue again.
+./juno_task/scripts/kanban.sh items has the higher level of truth. Always
+
+0e. Status in ./juno_task/scripts/kanban.sh could be backlog, todo, in_progress, done.
+in_progress, todo, backlog. That is the priority of tasks in general sense, unless you find something with 10X magnitute of importance, or if you do it first it make other tasks easier or unnecessary.
+
+
+0f. After reviwing Feedback, if you find an open issue, you need to update previously handled issues status as well. If user reporting a bug, that earlier on reported on the feedback/plan or Claude.md as resolved. You should update it to reflect that the issue is not resolved.
+`./juno_task/scripts/kanban.sh mark todo --ID {Task_ID}`
+
+it would be ok to include past reasoning and root causing to the open issue, You should mention. <PREVIOUS_AGENT_ATTEMP> Tag and describe the approach already taken, so the agent knows
+   1.the issue is still open,
+   2. past approaches to resolve it, what it was, and know that it has failed.
+`./juno_task/scripts/kanban.sh mark todo --ID {Task_ID} --response "<PREVIOUS_AGENT_ATTEMP>{what happend before ...}<PREVIOUS_AGENT_ATTEMP>" `
+
+   **Note** updating response will REPLACE response. So you need to include everything important from the past as well you can check the content of a task with
+   `./juno_task/scripts/kanban.sh get {TASK_ID}`
+
+
+
+C. Using parallel subagents. You may use up to 500 parallel subagents for all operations but only 1 subagent for build/tests.
+
+D. Choose the most important 1 things, ( Based on Open Issue  and Also Tasks ), Think hard about what is the most important Task. 
+
+E. update status of most important task on ./juno_task/scripts/kanban.sh.
+(if the task is not on ./juno_task/scripts/kanban.sh, create it ! Kanban is our source of truth)
+`./juno_task/scripts/kanban.sh mark in_progress --ID {Task_ID}`
+
+
+F. Implement the most important 1 thing following the outline. 
+
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## Outline
+  
+. Execute implementation following the task plan:
+   - **Phase-by-phase execution**: Complete each phase before moving to the next
+   - **Respect dependencies**: Run sequential tasks in order, parallel tasks [P] can run together  
+   - **Follow TDD approach**: Execute test tasks before their corresponding implementation tasks
+   - **File-based coordination**: Tasks affecting the same files must run sequentially
+   - **Validation checkpoints**: Verify each phase completion before proceeding
+
+7. Implementation execution rules:
+   - **Setup first**: Initialize project structure, dependencies, configuration
+   - **Tests before code**: If you need to write tests for contracts, entities, and integration scenarios
+   - **Core development**: Implement models, services, CLI commands, endpoints
+   - **Integration work**: Database connections, middleware, logging, external services
+   - **Polish and validation**: Unit tests, performance optimization, documentation
+
+8. Progress tracking and error handling:
+   - Report progress after each completed task
+   - Halt execution if any non-parallel task fails
+   - For parallel tasks [P], continue with successful tasks, report failed ones
+   - Provide clear error messages with context for debugging
+   - Suggest next steps if implementation cannot proceed
+   - **IMPORTANT** For completed tasks, make sure to mark the task off as [X] in the tasks file.
+   - **IMPORTANT** Keep ./juno_task/scripts/kanban.sh up-to-date
+   When the issue is resolved always update ./juno_task/scripts/kanban.sh
+   `./juno_task/scripts/kanban.sh --status {status} --ID {task_id} --response "{key actions you take, and how you did test it}"`
+
+9. Completion validation:
+   - Verify all required tasks are completed
+   - Check that implemented features match the original specification
+   - Validate that tests pass and coverage meets requirements
+   - Confirm the implementation follows the technical plan
+   - Report final status with summary of completed work
+   - When the issue is resolved always update ./juno_task/scripts/kanban.sh
+   `./juno_task/scripts/kanban.sh --mark done --ID {task_id} --response "{key actions you take, and how you did test it}"`
+
+10. Git
+
+   When the tests pass update ./juno_task/scripts/kanban.sh, then add changed code with "git add -A" via bash then do a "git commit" with a message that describes the changes you made to the code. After the commit do a "git push" to push the changes to the remote repository.
+   Use commit message as a backlog of what has achieved. So later on we would know exactly what we achieved in each commit.
+   Update the task in ./juno_task/scripts/kanban.sh with the commit hash so later on we could map each task to a specific git commit
+   `./juno_task/scripts/kanban.sh update {task_id} --commit {commit_hash}`
+
+

package/dist/templates/skills/claude/ralph-loop/scripts/kanban.sh

@@ -0,0 +1,293 @@
+#!/usr/bin/env bash
+
+# kanban.sh
+#
+# Purpose: Kanban wrapper with Python environment setup
+#
+# This script ensures juno-kanban always executes from the project root directory
+# with the proper Python virtual environment activated.
+#
+# Usage: ./.juno_task/scripts/kanban.sh [juno-kanban arguments]
+# Example: ./.juno_task/scripts/kanban.sh list --limit 5
+# Example: ./.juno_task/scripts/kanban.sh list -f json --raw  # (flag order normalized)
+# Example: ./.juno_task/scripts/kanban.sh -f json --raw list  # (also works)
+#
+# Note: Global flags (-f/--format, -p/--pretty, --raw, -v/--verbose, -c/--config)
+#       can be placed anywhere in the command line. This wrapper normalizes them
+#       to appear before the command for juno-kanban compatibility.
+#
+# Environment Variables:
+#   JUNO_DEBUG=true    - Show [DEBUG] diagnostic messages
+#   JUNO_VERBOSE=true  - Show [KANBAN] informational messages
+#   (Both default to false for silent operation)
+#
+# Created by: juno-code init command
+# Date: Auto-generated during project initialization
+
+set -euo pipefail  # Exit on error, undefined variable, or pipe failure
+
+# DEBUG OUTPUT: Show that kanban.sh is being executed (only if JUNO_DEBUG=true)
+# Note: JUNO_DEBUG is separate from JUNO_VERBOSE for fine-grained control
+if [ "${JUNO_DEBUG:-false}" = "true" ]; then
+    echo "[DEBUG] kanban.sh is being executed from: $(pwd)" >&2
+fi
+
+# Color output for better readability
+RED='\033[0;31m'
+GREEN='\033[0;32m'
+YELLOW='\033[1;33m'
+BLUE='\033[0;34m'
+NC='\033[0m' # No Color
+
+# Configuration
+VENV_DIR=".venv_juno"
+SCRIPTS_DIR=".juno_task/scripts"
+INSTALL_SCRIPT="${SCRIPTS_DIR}/install_requirements.sh"
+
+# Logging functions
+log_info() {
+    # Only print if JUNO_VERBOSE is set to true
+    if [ "${JUNO_VERBOSE:-false}" = "true" ]; then
+        echo -e "${BLUE}[KANBAN]${NC} $1"
+    fi
+}
+
+log_success() {
+    # Only print if JUNO_VERBOSE is set to true
+    if [ "${JUNO_VERBOSE:-false}" = "true" ]; then
+        echo -e "${GREEN}[KANBAN]${NC} $1"
+    fi
+}
+
+log_warning() {
+    # Only print if JUNO_VERBOSE is set to true
+    if [ "${JUNO_VERBOSE:-false}" = "true" ]; then
+        echo -e "${YELLOW}[KANBAN]${NC} $1"
+    fi
+}
+
+log_error() {
+    # Always print errors regardless of JUNO_VERBOSE
+    echo -e "${RED}[KANBAN]${NC} $1"
+}
+
+# Function to check if we're inside .venv_juno specifically
+# CRITICAL: Don't just check for ANY venv - check if we're in .venv_juno
+is_in_venv_juno() {
+    # Check if VIRTUAL_ENV is set and points to .venv_juno
+    if [ -n "${VIRTUAL_ENV:-}" ]; then
+        # Check if VIRTUAL_ENV path contains .venv_juno
+        if [[ "${VIRTUAL_ENV:-}" == *"/.venv_juno" ]] || [[ "${VIRTUAL_ENV:-}" == *".venv_juno"* ]]; then
+            return 0  # Inside .venv_juno
+        fi
+
+        # Check if the basename is .venv_juno
+        if [ "$(basename "${VIRTUAL_ENV:-}")" = ".venv_juno" ]; then
+            return 0  # Inside .venv_juno
+        fi
+    fi
+
+    return 1  # Not inside .venv_juno (or not in any venv)
+}
+
+# Function to activate virtual environment
+activate_venv() {
+    local venv_path="$1"
+
+    if [ ! -d "$venv_path" ]; then
+        log_error "Virtual environment not found: $venv_path"
+        return 1
+    fi
+
+    # Activate the venv
+    # shellcheck disable=SC1091
+    if [ -f "$venv_path/bin/activate" ]; then
+        source "$venv_path/bin/activate"
+        log_success "Activated virtual environment: $venv_path"
+        return 0
+    else
+        log_error "Activation script not found: $venv_path/bin/activate"
+        return 1
+    fi
+}
+
+# Function to ensure Python environment is ready
+ensure_python_environment() {
+    log_info "Checking Python environment..."
+
+    # Step 1: Check if we're already in .venv_juno specifically
+    if is_in_venv_juno; then
+        log_success "Already inside .venv_juno virtual environment"
+        return 0
+    fi
+
+    # Step 2: Not in .venv_juno - check if .venv_juno exists in project root
+    if [ -d "$VENV_DIR" ]; then
+        log_info "Found existing virtual environment: $VENV_DIR"
+
+        # Activate the venv
+        if activate_venv "$VENV_DIR"; then
+            return 0
+        else
+            log_error "Failed to activate virtual environment"
+            return 1
+        fi
+    fi
+
+    # Step 3: .venv_juno doesn't exist - need to create it
+    log_warning "Virtual environment not found: $VENV_DIR"
+    log_info "Running install_requirements.sh to create virtual environment..."
+
+    # Check if install_requirements.sh exists
+    if [ ! -f "$INSTALL_SCRIPT" ]; then
+        log_error "Install script not found: $INSTALL_SCRIPT"
+        log_error "Please run 'juno-code init' to initialize the project"
+        return 1
+    fi
+
+    # Make sure the script is executable
+    chmod +x "$INSTALL_SCRIPT"
+
+    # Run the install script
+    if bash "$INSTALL_SCRIPT"; then
+        log_success "Python environment setup completed successfully"
+
+        # After install, activate the venv if it was created
+        if [ -d "$VENV_DIR" ]; then
+            if activate_venv "$VENV_DIR"; then
+                return 0
+            fi
+        fi
+
+        return 0
+    else
+        log_error "Failed to run install_requirements.sh"
+        log_error "Please check the error messages above"
+        return 1
+    fi
+}
+
+# Get the directory where this script is located
+SCRIPT_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
+
+# Navigate to project root (parent of scripts directory)
+PROJECT_ROOT="$( cd "$SCRIPT_DIR/../../../.." && pwd )"
+
+# Change to project root
+cd "$PROJECT_ROOT"
+
+# Arrays to store normalized arguments (declared at script level for proper handling)
+declare -a NORMALIZED_GLOBAL_FLAGS=()
+declare -a NORMALIZED_COMMAND_ARGS=()
+
+# Normalize argument order for juno-kanban
+# juno-kanban requires global flags BEFORE the command, but users often
+# write them after (e.g., "list -f json --raw" instead of "-f json --raw list")
+# This function reorders arguments so global flags come first.
+# Results are stored in NORMALIZED_GLOBAL_FLAGS and NORMALIZED_COMMAND_ARGS arrays.
+normalize_arguments() {
+    # Reset arrays
+    NORMALIZED_GLOBAL_FLAGS=()
+    NORMALIZED_COMMAND_ARGS=()
+    local found_command=false
+
+    # Known subcommands
+    local commands="create search get show update archive mark list merge"
+
+    while [[ $# -gt 0 ]]; do
+        case $1 in
+            # Global flags that take a value
+            -f|--format|-c|--config)
+                if [[ -n "${2:-}" ]]; then
+                    NORMALIZED_GLOBAL_FLAGS+=("$1" "$2")
+                    shift 2
+                else
+                    NORMALIZED_GLOBAL_FLAGS+=("$1")
+                    shift
+                fi
+                ;;
+            # Global flags that don't take a value
+            -p|--pretty|--raw|-v|--verbose|-h|--help|--version)
+                NORMALIZED_GLOBAL_FLAGS+=("$1")
+                shift
+                ;;
+            # Check if this is a known command
+            *)
+                # Check if this argument is a known command
+                local is_command=false
+                for cmd in $commands; do
+                    if [[ "$1" == "$cmd" ]]; then
+                        is_command=true
+                        found_command=true
+                        break
+                    fi
+                done
+
+                # If we found a command, everything from here goes to command_args
+                if $is_command || $found_command; then
+                    NORMALIZED_COMMAND_ARGS+=("$1")
+                    found_command=true
+                else
+                    # Before finding a command, treat as command arg
+                    NORMALIZED_COMMAND_ARGS+=("$1")
+                fi
+                shift
+                ;;
+        esac
+    done
+}
+
+# Main kanban logic
+main() {
+    log_info "=== juno-kanban Wrapper ==="
+
+    # Ensure Python environment is ready
+    if ! ensure_python_environment; then
+        log_error "Failed to setup Python environment"
+        exit 1
+    fi
+
+    log_success "Python environment ready!"
+
+    # Normalize argument order (global flags before command)
+    # This allows users to write "list -f json --raw" which gets reordered to "-f json --raw list"
+    normalize_arguments "$@"
+
+    if [ "${JUNO_DEBUG:-false}" = "true" ]; then
+        echo "[DEBUG] Original args: $*" >&2
+        echo "[DEBUG] Normalized global flags: ${NORMALIZED_GLOBAL_FLAGS[*]:-<none>}" >&2
+        echo "[DEBUG] Normalized command args: ${NORMALIZED_COMMAND_ARGS[*]:-<none>}" >&2
+    fi
+
+    # Execute juno-kanban with normalized arguments from project root
+    # Build the command properly preserving argument quoting
+    log_info "Executing juno-kanban with normalized arguments"
+
+    # Execute with proper array expansion to preserve quoting
+    # Use ${arr[@]+"${arr[@]}"} pattern to handle empty arrays with set -u
+    #
+    # Stdin handling:
+    # Detect the type of stdin to determine whether to pass it through or redirect from /dev/null:
+    # - 'p' (pipe): Pass through - user is piping data (e.g., echo "..." | kanban.sh create)
+    # - '-' (regular file): Pass through - user is using heredoc (kanban.sh create << 'EOF')
+    # - 'c' (character device) or other: Redirect from /dev/null to prevent hanging
+    #   when called from tools that don't provide stdin (Issue #42, #60)
+    #
+    # The first character of `ls -la /dev/fd/0` indicates the file type:
+    # p = pipe, - = regular file, c = character device, l = symlink, etc.
+    local stdin_type
+    stdin_type=$(ls -la /dev/fd/0 2>/dev/null | cut -c1)
+
+    if [[ "$stdin_type" == "p" || "$stdin_type" == "-" ]]; then
+        # stdin is a pipe or regular file (heredoc) - pass it through
+        juno-kanban ${NORMALIZED_GLOBAL_FLAGS[@]+"${NORMALIZED_GLOBAL_FLAGS[@]}"} \
+                    ${NORMALIZED_COMMAND_ARGS[@]+"${NORMALIZED_COMMAND_ARGS[@]}"}
+    else
+        # stdin is a character device or unknown - redirect from /dev/null to prevent hanging
+        juno-kanban ${NORMALIZED_GLOBAL_FLAGS[@]+"${NORMALIZED_GLOBAL_FLAGS[@]}"} \
+                    ${NORMALIZED_COMMAND_ARGS[@]+"${NORMALIZED_COMMAND_ARGS[@]}"} < /dev/null
+    fi
+}
+
+# Run main function with all arguments
+main "$@"

package/dist/templates/skills/claude/understand-project/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: understand-project
+description: Understand current project and create/update specs under @.juno_task/specs/* , it allows you understand dependencies. and prepare for implementation. Use when user explicitly ask you, or when asking for understand the project, first see how it works and then do [main task] with respect to [constraints] 
+argument-hint: [Main Task] [Constraints] [Ultimate Goal]
+---
+
+
+
+## Main Task
+$0
+
+### Task 1
+First task is to study @.juno_task/plan.md  (it may be incorrect) and is to use up to 500 subagents to study existing project
+and study what is needed to achieve the main task.
+From that create/update a @.juno_task/plan.md  which is a bullet point list sorted in priority of the items which have yet to be implemeneted. Think extra hard.
+Study @.juno_task/plan.md to determine starting point for research and keep it up to date with items considered complete/incomplete using subagents.
+
+### Task 2
+Second Task is to understand the task, create a spec for process to follow, plan to execute, scripts to create, virtual enviroment that we need, things that we need to be aware of, how to test the scripts and follow progress.
+Think hard and plan/create spec for every step of this task
+and for each part create a seperate .md file under @.juno_task/specs/*
+
+## ULTIMATE Goal
+We want to achieve the main Task with respect to the Constraints section
+Consider missing steps and plan. If the step is missing then author the specification at @.juno_task/specs/FILENAME.md (do NOT assume that it does not exist, search before creating). The naming of the module should be GenZ named and not conflict with another module name. If you create a new step then document the plan to implement in @.juno_task/plan.md
+
+### @.juno_task/specs/ file format.
+- github flavored markdown
+- GenZ module names and without conflict to another module name.
+- Start with Priority in Codebase, Example: P0-core-module.md 
+- the goal is when we run `ls` command in the specs folder we could understand what are the cornerstone of the project with one glance.
+
+### Constraints
+
+$1
+
+---
+
+$ARGUMENTS

package/dist/templates/skills/codex/ralph-loop/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: ralph-loop
+description: should only get executed with explicit user request.
+---
+0a. study [references/implement.md](references/implement.md).
+
+0b.  When you discover a syntax, logic, UI, User Flow Error or bug. Immediately update  tasks.md with your findings using a  subagent. When the issue is resolved, update tasks.md and remove the item using a  subagent.
+
+
+999. Important: When authoring documentation capture the why tests and the backing implementation is important.
+
+9999. Important: We want single sources of truth, no migrations/adapters. If tests unrelated to your work fail then it's your job to resolve these tests as part of the increment of change.
+
+999999. As soon as there are no build or test errors create a git tag. If there are no git tags start at 0.0.0 and increment patch by 1 for example 0.0.1 if 0.0.0 does not exist.
+
+999999999. You may add extra logging if required to be able to debug the issues.
+
+9999999999. ALWAYS KEEP Tasks up to date with your learnings using a  subagent. Especially after wrapping up/finishing your turn.
+
+
+
+99999999999. When you learn something new about how to run the app or examples make sure you update @AGENTS.md using a  subagent but keep it brief. For example if you run commands multiple times before learning the correct command then that file should be updated.
+
+999999999999. IMPORTANT when you discover a bug resolve it using  subagents even if it is unrelated to the current piece of work after documenting it in Tasks
+
+9999999999999999999. Keep @AGENTS.md up to date with information on how to build the app and your learnings to optimize the build/test loop using a  subagent.
+
+999999999999999999999. For any bugs you notice, it's important to resolve them or document them in Tasks to be resolved using a  subagent.
+
+99999999999999999999999. When authoring the missing features you may author multiple standard libraries at once using up to 1000 parallel subagents
+
+99999999999999999999999999. When Tasks, AGENTS.md becomes large periodically clean out the items that are completed from the file using a  subagent.
+Large AGENTS.md reduce the performance.
+
+
+
+9999999999999999999999999999. DO NOT IMPLEMENT PLACEHOLDER OR SIMPLE IMPLEMENTATIONS. WE WANT FULL IMPLEMENTATIONS. DO IT OR I WILL YELL AT YOU
+
+9999999999999999999999999999999. SUPER IMPORTANT DO NOT IGNORE. DO NOT PLACE STATUS REPORT UPDATES INTO @AGENTS.md
+
+99999999999999999999999999999999. After reveiwing Feedback, if you find an open issue, you need to update previously handled issues status as well. If user reporting a bug, that earlier on reported on the Tasks or @AGENTS.md as resolved. You should update it to reflect that the issue is not resolved.
+it would be ok to include past reasoning and root causing to the open issue, You should mention. <PREVIOUS_AGENT_ATTEMP> Tag and describe the approach already taken, so the agent knows 1.the issue is still open,2. past approaches to resolve it, what it was, and know that it has failed.
+Tasks , USER_FEEDBACK and @AGENTS.md should repesent truth. User Open Issue is a high level of truth. so you need to reflect it on the files.

package/dist/templates/skills/codex/ralph-loop/references/first_check.md

@@ -0,0 +1,20 @@
+### Check once
+
+Perform these check once, to make sure about the git logic. There is no need to keep running this on every execution.
+
+**Detection & Creation Logic**:
+   - Check if the following command succeeds to determine if the repository is a git repo (create/verify .gitignore if so):
+
+     ```sh
+     git rev-parse --git-dir 2>/dev/null
+     ```
+   - Check if Dockerfile* exists or Docker in plan.md → create/verify .dockerignore
+   - Check if .eslintrc* or eslint.config.* exists → create/verify .eslintignore
+   - Check if .prettierrc* exists → create/verify .prettierignore
+   - Check if .npmrc or package.json exists → create/verify .npmignore (if publishing)
+   - Check if terraform files (*.tf) exist → create/verify .terraformignore
+   - Check if .helmignore needed (helm charts present) → create/verify .helmignore
+   
+   **If ignore file already exists**: Verify it contains essential patterns, append missing critical patterns only
+   **If ignore file missing**: Create with full pattern set for detected technology
+