juno-code 1.0.47 → 1.0.50

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,12 +170,30 @@ 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"
 
+# Export JUNO_TASK_ROOT so juno-kanban resolves .juno_task paths from project root,
+# not from wherever the calling agent happens to be. Respects existing override.
+export JUNO_TASK_ROOT="${JUNO_TASK_ROOT:-$PROJECT_ROOT}"
+
 # Arrays to store normalized arguments (declared at script level for proper handling)
 declare -a NORMALIZED_GLOBAL_FLAGS=()
 declare -a NORMALIZED_COMMAND_ARGS=()
@@ -192,7 +210,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 +225,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/codex/understand-project/SKILL.md

@@ -0,0 +1,46 @@
+---
+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]"
+enable-shell-directives: true
+---
+
+## Main Task
+
+!`jq -r '.mainTask' ./.juno_task/config.json`
+
+$1
+
+### Task 1
+
+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.
+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/pi/kanban-workflow/SKILL.md

@@ -0,0 +1,139 @@
+---
+name: kanban-workflow
+description: Comprehensive guide for using juno-kanban task management. Covers all commands (create, list, search, get, mark, update, archive, deps, ready, order, merge), dependency management, best practices, and workflow patterns. Use when you need to interact with the kanban board.
+argument-hint: "[command or workflow question]"
+enable-shell-directives: true
+---
+
+## Kanban CLI Reference
+
+All commands use `./.juno_task/scripts/kanban.sh` (wrapper around juno-kanban Python CLI).
+
+### Core Commands
+
+**CREATE** — Add a new task
+```bash
+./.juno_task/scripts/kanban.sh create "Task description here" --status backlog --tags feature,backend
+```
+Options: `--status` (backlog|todo|in_progress|done), `--tags` (comma/space-separated), `--blocked-by` (task IDs), `--related-tasks` (task IDs)
+
+**LIST** — Browse tasks with summary stats
+```bash
+./.juno_task/scripts/kanban.sh list --limit 5 --sort asc
+./.juno_task/scripts/kanban.sh list --status todo --sort asc
+./.juno_task/scripts/kanban.sh list --status todo,in_progress --limit 10
+```
+
+**SEARCH** — Find tasks by criteria
+```bash
+./.juno_task/scripts/kanban.sh search --status todo --tag backend --limit 10
+./.juno_task/scripts/kanban.sh search --body "OAuth" --open
+./.juno_task/scripts/kanban.sh search --commit abc123
+```
+Filters: `--status`, `--tag`, `--body`, `--response`, `--commit`, `--open` (no agent_response), `--recent`, `--exclude` (exclude tags)
+
+**GET** — Full task details (including dependency info and related task details)
+```bash
+./.juno_task/scripts/kanban.sh get TASK_ID
+```
+
+**MARK** — Update status with required response message
+```bash
+./.juno_task/scripts/kanban.sh mark in_progress --id TASK_ID --response "Starting work on this"
+./.juno_task/scripts/kanban.sh mark done --id TASK_ID --response "Completed: implemented X, tested Y" --commit abc123def
+./.juno_task/scripts/kanban.sh mark todo --id TASK_ID --response "Reopening: found regression"
+```
+Required: `--id` and `--response`. Optional: `--commit` (recommended for done).
+
+**UPDATE** — Modify task fields
+```bash
+./.juno_task/scripts/kanban.sh update TASK_ID --status todo --tags backend,urgent
+./.juno_task/scripts/kanban.sh update TASK_ID --commit abc123def
+./.juno_task/scripts/kanban.sh update TASK_ID --response "Additional context"
+```
+
+**ARCHIVE** — Soft delete (preserves data, sets status to archive)
+```bash
+./.juno_task/scripts/kanban.sh archive TASK_ID
+```
+
+### Dependency Management
+
+**DEPS** — View, add, or remove task dependencies
+```bash
+# View dependency info (blockers, dependents, priority score)
+./.juno_task/scripts/kanban.sh deps TASK_ID
+
+# Add blockers (TASK_ID cannot start until BLOCKER1 and BLOCKER2 are done)
+./.juno_task/scripts/kanban.sh deps add --id TASK_ID --blocked-by BLOCKER1 BLOCKER2
+
+# Remove a blocker
+./.juno_task/scripts/kanban.sh deps remove --id TASK_ID --blocked-by BLOCKER1
+```
+Cycle detection prevents circular dependencies automatically.
+
+**READY** — Tasks with all blockers satisfied (safe to work on)
+```bash
+./.juno_task/scripts/kanban.sh ready
+./.juno_task/scripts/kanban.sh ready --tag backend --limit 5
+```
+Returns tasks where status is backlog/todo/in_progress AND all `blocked_by` tasks are done/archive.
+
+**ORDER** — Topological sort of open tasks respecting dependencies
+```bash
+./.juno_task/scripts/kanban.sh order
+./.juno_task/scripts/kanban.sh order --scores
+```
+Use for determining safe parallel execution order.
+
+### Body Markup for Inline Dependencies
+
+Declare dependencies and relations directly in task body text:
+
+```
+[blocked_by]TASK_ID[/blocked_by]          — This task is blocked by TASK_ID
+[blocked_by]ID1, ID2[/blocked_by]         — Blocked by multiple tasks
+[task_id]RELATED_ID[/task_id]             — Reference a related task
+[task_id]ID1 ID2[/task_id]                — Multiple related tasks
+```
+
+These are parsed automatically when the task is created/updated.
+
+### Merge (Multi-Directory Consolidation)
+
+When tasks get scattered across subdirectories:
+```bash
+# Auto-discover and merge all .juno_task dirs
+./.juno_task/scripts/kanban.sh merge --find-all --into ./.juno_task --dry-run
+
+# Merge specific sources
+./.juno_task/scripts/kanban.sh merge ./sub1/.juno_task ./sub2/.juno_task --into ./.juno_task
+```
+Strategy: `--strategy keep-newer` (default) or `--strategy keep-both`.
+
+### Output Formats
+
+All commands support: `-f json`, `-f ndjson` (default), `-f xml`, `-f table`
+Add `--raw` for compact output. Add `-p` for pretty print.
+
+### Best Practices
+
+1. **Task sizing**: Create tasks small enough to complete in one iteration without filling the context window
+2. **Status flow**: backlog → todo → in_progress → done (or archive for abandoned tasks)
+3. **Always include `--response`** when using `mark` — document what you did and how you tested it
+4. **Attach commits**: Use `--commit HASH` when marking done, then `update TASK_ID --commit HASH` to link the git history
+5. **Use `ready`** before starting work to find unblocked tasks
+6. **Use `order --scores`** to plan parallel execution pipelines
+7. **Use `[blocked_by]` markup** in task body when creating tasks that depend on others
+8. **Use `[task_id]` markup** in task body to cross-reference related tasks
+9. **Use `get TASK_ID`** to see full task details including resolved dependency and related task info
+10. **One task in_progress at a time** — finish or re-queue before starting the next
+
+### Environment Variables
+
+- `JUNO_TASK_ROOT` — Pin kanban operations to a specific project root directory
+- `JUNO_DEBUG=true` — Show diagnostic messages
+- `JUNO_VERBOSE=true` — Show informational messages
+- `JUNO_KANBAN_LIST_BODY_TRUNCATE_CHARS=N` — Override list body truncation (default: 1200)
+
+$ARGUMENTS

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,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.
+
+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.
+
+<SPECIFIC_INSTRUCTION>
+$ARGUMENTS
+</SPECIFIC_INSTRUCTION>

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

@@ -0,0 +1,21 @@
+### 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/pi/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 AGENTS.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}`