juno-code 1.0.47 → 1.0.49

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

@@ -1,25 +1,32 @@
 ---
 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.
+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. "Generate PDR"
 argument-hint: [Required Features] [Constraints] [Specification] [Test Criteria]
+enable-shell-directives: true
 ---
 
-First task is to study @.juno_task/plan.md  (it may be incorrect) 
+Ultrathink for this task
+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/*
+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 
+## 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. 
+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.
 
+### Specs
+
+Current state of specs under @.juno_task/specs/
 
+!`ls -lrt .juno_task/specs/`
 
+$ARGUMENTS

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

@@ -2,42 +2,38 @@
 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.
+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.
-
+1000. 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.
 
+1001. 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.
 
-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.
+1002. You may add extra logging if required to be able to debug the issues.
 
-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
+1003. ALWAYS KEEP Tasks up to date with your learnings using a subagent. Especially after wrapping up/finishing your turn.
 
-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.
+1004. 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.
 
-999999999999999999999. For any bugs you notice, it's important to resolve them or document them in Tasks to be resolved using a  subagent.
+1005. 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
 
-99999999999999999999999. When authoring the missing features you may author multiple standard libraries at once using up to 1000 parallel subagents
+1006. 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.
 
-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.
+1007. For any bugs you notice, it's important to resolve them or document them in Tasks to be resolved using a subagent.
 
+1008. When authoring the missing features you may author multiple standard libraries at once using up to 1000 parallel subagents
 
+1009. 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
+1010. 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
+1011. 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.
+1012. 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

@@ -3,18 +3,19 @@
 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
-   
+- 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

@@ -3,6 +3,7 @@ description: Study kanban.sh and Execute the implementation plan by processing a
 ---
 
 ## User Input
+
 ```text
 A.
 **ALWAYS check remaing tasks and user feedbacks. Integrate it into the plan,
@@ -40,27 +41,28 @@ it would be ok to include past reasoning and root causing to the open issue, You
 
 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. 
+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. 
+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
+
+- **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
@@ -77,8 +79,8 @@ You **MUST** consider the user input before proceeding (if not empty).
    - 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}"`
+     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
@@ -87,13 +89,11 @@ You **MUST** consider the user input before proceeding (if not empty).
    - 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}"`
+     `./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}`
-
-
+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

@@ -170,8 +170,22 @@ ensure_python_environment() {
 # 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 )"
+# Auto-discover project root by walking up the directory tree looking for .juno_task/
+# This makes kanban.sh work from any installation depth (e.g. .juno_task/scripts/,
+# .claude/skills/ralph-loop/scripts/, etc.) without a hardcoded relative path.
+PROJECT_ROOT=""
+_dir="$SCRIPT_DIR"
+while [[ "$_dir" != "/" ]]; do
+    if [[ -d "$_dir/.juno_task" ]]; then
+        PROJECT_ROOT="$_dir"
+        break
+    fi
+    _dir="$( cd "$_dir/.." && pwd )"
+done
+if [[ -z "$PROJECT_ROOT" ]]; then
+    echo "ERROR: Could not find project root (no .juno_task/ directory found above $SCRIPT_DIR)" >&2
+    exit 1
+fi
 
 # Change to project root
 cd "$PROJECT_ROOT"
@@ -192,7 +206,7 @@ normalize_arguments() {
     local found_command=false
 
     # Known subcommands
-    local commands="create search get show update archive mark list merge"
+    local commands="create search get show update archive mark list merge ready deps order"
 
     while [[ $# -gt 0 ]]; do
         case $1 in
@@ -207,7 +221,7 @@ normalize_arguments() {
                 fi
                 ;;
             # Global flags that don't take a value
-            -p|--pretty|--raw|-v|--verbose|-h|--help|--version)
+            -p|--pretty|--raw|-v|--verbose|--version)
                 NORMALIZED_GLOBAL_FLAGS+=("$1")
                 shift
                 ;;

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

@@ -1,33 +1,40 @@
 ---
 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] 
+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]
+enable-shell-directives: true
 ---
 
+## Main Task
 
+!`jq -r '.mainTask' ./.juno_task/config.json`
 
-## Main Task
-$0
+$1
 
 ### 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
+
+Ultrathink !
+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.
+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/*
+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 
+- 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

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

@@ -2,42 +2,38 @@
 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.
+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.
-
+1000. 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.
 
+1001. 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.
 
-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.
+1002. You may add extra logging if required to be able to debug the issues.
 
-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
+1003. ALWAYS KEEP Tasks up to date with your learnings using a subagent. Especially after wrapping up/finishing your turn.
 
-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.
+1004. 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.
 
-999999999999999999999. For any bugs you notice, it's important to resolve them or document them in Tasks to be resolved using a  subagent.
+1005. 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
 
-99999999999999999999999. When authoring the missing features you may author multiple standard libraries at once using up to 1000 parallel subagents
+1006. 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.
 
-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.
+1007. For any bugs you notice, it's important to resolve them or document them in Tasks to be resolved using a subagent.
 
+1008. When authoring the missing features you may author multiple standard libraries at once using up to 1000 parallel subagents
 
+1009. 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
+1010. 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
+1011. 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.
+1012. 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

@@ -3,18 +3,19 @@
 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
-   
+- 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/codex/ralph-loop/references/implement.md

@@ -3,6 +3,7 @@ description: Study kanban.sh and Execute the implementation plan by processing a
 ---
 
 ## User Input
+
 ```text
 A.
 **ALWAYS check remaing tasks and user feedbacks. Integrate it into the plan,
@@ -40,27 +41,28 @@ it would be ok to include past reasoning and root causing to the open issue, You
 
 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. 
+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. 
+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
+
+- **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
@@ -77,8 +79,8 @@ You **MUST** consider the user input before proceeding (if not empty).
    - 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}"`
+     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
@@ -87,13 +89,11 @@ You **MUST** consider the user input before proceeding (if not empty).
    - 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}"`
+     `./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}`
-
-
+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/codex/ralph-loop/scripts/kanban.sh

@@ -170,8 +170,22 @@ ensure_python_environment() {
 # 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 )"
+# Auto-discover project root by walking up the directory tree looking for .juno_task/
+# This makes kanban.sh work from any installation depth (e.g. .juno_task/scripts/,
+# .claude/skills/ralph-loop/scripts/, etc.) without a hardcoded relative path.
+PROJECT_ROOT=""
+_dir="$SCRIPT_DIR"
+while [[ "$_dir" != "/" ]]; do
+    if [[ -d "$_dir/.juno_task" ]]; then
+        PROJECT_ROOT="$_dir"
+        break
+    fi
+    _dir="$( cd "$_dir/.." && pwd )"
+done
+if [[ -z "$PROJECT_ROOT" ]]; then
+    echo "ERROR: Could not find project root (no .juno_task/ directory found above $SCRIPT_DIR)" >&2
+    exit 1
+fi
 
 # Change to project root
 cd "$PROJECT_ROOT"
@@ -192,7 +206,7 @@ normalize_arguments() {
     local found_command=false
 
     # Known subcommands
-    local commands="create search get show update archive mark list merge"
+    local commands="create search get show update archive mark list merge ready deps order"
 
     while [[ $# -gt 0 ]]; do
         case $1 in
@@ -207,7 +221,7 @@ normalize_arguments() {
                 fi
                 ;;
             # Global flags that don't take a value
-            -p|--pretty|--raw|-v|--verbose|-h|--help|--version)
+            -p|--pretty|--raw|-v|--verbose|--version)
                 NORMALIZED_GLOBAL_FLAGS+=("$1")
                 shift
                 ;;

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

@@ -0,0 +1,32 @@
+---
+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. "Generate PDR"
+argument-hint: [Required Features] [Constraints] [Specification] [Test Criteria]
+enable-shell-directives: true
+---
+
+Ultrathink for this task
+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.
+
+### Specs
+
+Current state of specs under @.juno_task/specs/
+
+!`ls -lrt .juno_task/specs/`
+
+$ARGUMENTS

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

@@ -0,0 +1,39 @@
+---
+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.
+
+1000. 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.
+
+1001. 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.
+
+1002. You may add extra logging if required to be able to debug the issues.
+
+1003. ALWAYS KEEP Tasks up to date with your learnings using a subagent. Especially after wrapping up/finishing your turn.
+
+1004. 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.
+
+1005. 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
+
+1006. 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.
+
+1007. For any bugs you notice, it's important to resolve them or document them in Tasks to be resolved using a subagent.
+
+1008. When authoring the missing features you may author multiple standard libraries at once using up to 1000 parallel subagents
+
+1009. 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.
+
+1010. DO NOT IMPLEMENT PLACEHOLDER OR SIMPLE IMPLEMENTATIONS. WE WANT FULL IMPLEMENTATIONS. DO IT OR I WILL YELL AT YOU
+
+1011. SUPER IMPORTANT DO NOT IGNORE. DO NOT PLACE STATUS REPORT UPDATES INTO @AGENTS.md
+
+1012. 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.