opencode-skills-collection 4.0.67 → 4.0.68

package/bundled-skills/google-no-code/SKILL.md

@@ -0,0 +1,136 @@
+---
+name: google-no-code
+description: "Design Google Forms and wire Apps Script triggers (onFormSubmit) for email alerts, spreadsheet logging, and dynamic questions — no code editor required."
+category: automation
+risk: safe
+source: self
+source_type: self
+date_added: "2026-09-19"
+author: WHOISABHISHEKADHIKARI
+tags: [google, forms, apps-script]
+tools: [claude, cursor, gemini]
+---
+
+# Google No-Code Forms Automation
+
+## Overview
+
+Guides the user through building a Google Form in the Forms UI and connecting it to Google Apps Script triggers, without writing a custom integration or leaving the browser. Covers form design, the Apps Script editor, the `onFormSubmit` trigger, and small response-handling scripts that run automatically when a form is submitted.
+
+## When to Use This Skill
+
+- Use when the user wants to build a Google Form and automate what happens after submissions.
+- Use when the user asks for email alerts, spreadsheet logging, or conditional handling of form responses.
+- Use when the user wants Apps Script snippets to paste into a form bound script project.
+- Skip this skill if the user needs custom UI, paid APIs, or a full standalone Apps Script application.
+
+## How It Works
+
+### Step 1: Define the form in the Forms UI
+
+Create the form in Google Forms with clear questions, answer types (short answer, multiple choice, checkbox), and required fields. Match question IDs to what the script will need later. Add a description to the form so respondents know what to expect.
+
+### Step 2: Open the bound Apps Script editor
+
+In the form, go to `Extensions > Apps Script`. This opens a project bound to the form. The script can read each submission through the `e.response` event object.
+
+### Step 3: Write the response handler
+
+Add a function that accepts the `onFormSubmit` event, reads `e.response` with `getItemResponses()`, and then performs the desired action: send an email, write to a spreadsheet, or branch on answers.
+
+### Step 4: Install the trigger
+
+In Apps Script, go to the clock/triggers menu, select the `onFormSubmit` function, choose the event source **From form** and event type **On form submit**, then save and authorize. The function runs automatically on each new submission.
+
+### Step 5: Test with a real submission
+
+Submit a test response from a private/incognito window and verify the email, sheet row, or log arrives once. Check the Apps Script executions page (`Executions` in the editor) for errors and read the stack trace if something fails.
+
+## Examples
+
+### Example 1: Email notification on every response
+
+```javascript
+function onFormSubmit(e) {
+  const response = e.response;
+  const email = getEmail(response);
+  MailApp.sendEmail({
+    to: email,
+    subject: "Form submission received",
+    body: "Thank you. We have recorded your response."
+  });
+}
+
+function getEmail(response) {
+  const items = response.getItemResponses();
+  for (const item of items) {
+    if (item.getItem().getTitle().toLowerCase().includes("email")) {
+      return item.getResponse();
+    }
+  }
+  return Session.getActiveUser().getEmail();
+}
+```
+
+### Example 2: Log each response to a Google Sheet
+
+```javascript
+function onFormSubmit(e) {
+  const sheet = SpreadsheetApp.openById(SHEET_ID).getSheetByName("Responses");
+  const itemResponses = e.response.getItemResponses();
+  const row = [new Date()].concat(itemResponses.map(r => r.getResponse()));
+  sheet.appendRow(row);
+}
+```
+
+### Example 3: Branch on a multiple-choice answer
+
+```javascript
+function onFormSubmit(e) {
+  const items = e.response.getItemResponses();
+  for (const item of items) {
+    if (item.getItem().getTitle().toLowerCase() === "priority") {
+      const priority = item.getResponse();
+      const subject = priority === "High" ? "[URGENT] " : "";
+      MailApp.sendEmail({ to: MANAGER_EMAIL, subject: subject + "New submission", body: itemResponsesText(e) });
+    }
+  }
+}
+```
+
+## Best Practices
+
+- ✅ Test every trigger with a real submission before telling the user it works.
+- ✅ Use clear, stable question titles so the script can match items by title instead of fragile indexes.
+- ✅ Keep secrets and API keys in script properties, never hard-coded in the file.
+- ✅ Add try/catch around handler logic and log errors with `Logger.log` so failures surface in the Executions page.
+- ❌ Do not grant broad scopes; run with the minimum permission the form action needs.
+- ❌ Do not send email to addresses that the form did not legitimately collect.
+
+## Limitations
+
+- Apps Script quotas apply (email rate limits, daily triggers, execution time); heavy volume needs review.
+- Only form submissions trigger the event; edits to responses by users do not fire `onFormSubmit` by default.
+- The skill produces scripts the user must paste, authorize, and deploy; it cannot create a Google Forms project by itself.
+- Sheets integration requires the sheet's ID and permission, which must be confirmed with the user.
+
+## Security & Safety Notes
+
+- The script runs inside the user's Google account with the scopes it declares. Review the authorization prompt and grant only the minimum requested scope.
+- Do not log, print, or embed passwords, OAuth tokens, or API keys in form scripts or shared files.
+- Form responses can arrive from anyone the form is shared with; validate inputs before acting on them.
+- Test in a controlled environment first; sending email or appending rows happens on every submission once the trigger is live.
+
+## Common Pitfalls
+
+- **Problem:** The handler runs for every submission and duplicates work.
+  **Solution:** Prefer the single event object `e.response`; do not separately query the form's stored responses inside `onFormSubmit`.
+- **Problem:** `item.getResponse()` returns `undefined` for optional questions.
+  **Solution:** Guard with a check for a truthy response, or make the question required.
+- **Problem:** The email goes to the wrong address.
+  **Solution:** Match by the question title containing "email", and verify the collected value belongs to the respondent before sending.
+
+## Related Skills
+
+- `@google-sheets-automation` - Use when the response logging target is a Sheet that needs its own automation.
+- `@google-docs-automation` - Use when form output should create or update a Google Doc.

package/bundled-skills/idea-evaluator/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: idea-evaluator
+description: "Evaluates an idea by hosting a multi-turn debate between a Pro and Con agent, delivering a final verdict on whether it's worth pursuing."
+category: agent-orchestration
+risk: safe
+source: self
+source_type: self
+date_added: "2026-09-18"
+author: Prince-1652
+tags: [ideation, validation, debate, multi-agent]
+tools: [claude, gemini]
+---
+
+# Idea Evaluator Orchestrator
+
+## Overview
+
+The Idea Evaluator skill acts as an impartial judge for evaluating new concepts, features, or project ideas. It takes an initial idea from the user and orchestrates a structured, multi-turn debate between two simulated personas: a logical supporter (Pro Agent) and a constructive critic (Con Agent). 
+
+By pitting these two perspectives against each other, it surfaces the strongest arguments for both sides before delivering a comprehensive final verdict on whether the idea is worth building.
+
+## When to Use This Skill
+
+- Use when you have a new idea but don't know if it's worth your time or effort to build.
+- Use when evaluating potential features for a product to decide on priorities.
+- Use when you want to rigorously stress-test an assumption before committing code.
+
+## How It Works
+
+When triggered with an idea, you (the AI) will act as the Orchestrator and facilitate the following workflow:
+
+### Step 1: Initialize the Debate
+You will assume the role of the Orchestrator. Introduce the debate and clearly state the idea being evaluated. Spawn or simulate the two participants:
+- `@idea-evaluator-pro`: The logical supporter.
+- `@idea-evaluator-con`: The constructive critic.
+
+### Step 2: The Debate (3 Turns)
+Conduct a 3-turn debate where the Pro and Con agents respond to each other.
+- **Turn 1 (Initial Pitches):** Pro presents the strongest case for the idea. Con presents the strongest immediate risks and flaws.
+- **Turn 2 (Rebuttals):** Pro addresses Con's risks. Con challenges Pro's optimism.
+- **Turn 3 (Closing Statements):** Both agents summarize their final stance on why the idea will succeed or fail.
+
+*Note: Ensure the agents do not blindly agree/disagree but base their arguments on logic, market realities, and technical feasibility.*
+
+### Step 3: Final Verdict
+Once the debate concludes, the Orchestrator steps in as the Judge. Provide a comprehensive summary formatted with:
+- **Pros:** The strongest validated points in favor.
+- **Cons:** The most critical risks identified.
+- **Final Verdict:** A definitive recommendation (e.g., "Strongly Recommended", "Proceed with Caution", "Pivot Required", "Not Worth Building").
+- **Why:** A brief justification summarizing the debate outcome.
+
+## Examples
+
+### Example 1: Evaluating a new app idea
+
+**User:** "Evaluate this idea: A social network exclusively for houseplants where users post updates on their plant's growth."
+
+**Agent:** (Proceeds to run the 3-turn debate between Pro and Con, followed by the Orchestrator's final verdict detailing the niche appeal versus retention challenges).
+
+## Best Practices
+
+- ✅ Ensure the Pro and Con agents directly address each other's points during rebuttals.
+- ✅ The Orchestrator must remain strictly neutral until the Final Verdict.
+- ❌ Don't let the agents devolve into generic AI pleasantries; keep the debate sharp and analytical.
+- ❌ Don't skip the debate steps; the back-and-forth is crucial for deep validation.
+
+## Limitations
+
+- The verdict is based on simulated reasoning and logic, not actual market data or user feedback.
+- This skill is for brainstorming and validation, not a guarantee of business success.
+
+## Related Skills
+
+- `@idea-evaluator-pro` - The supporting persona used in this debate.
+- `@idea-evaluator-con` - The critical persona used in this debate.

package/bundled-skills/idea-evaluator/idea-evaluator-con/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: idea-evaluator-con
+description: "The Con Agent persona for idea evaluation. Critiques an idea by identifying potential flaws, risks, and market challenges."
+category: agent-persona
+risk: safe
+source: self
+source_type: self
+date_added: "2026-09-18"
+author: Prince-1652
+tags: [ideation, validation, persona, critic]
+tools: [claude, gemini]
+---
+
+# Idea Evaluator: Con Agent
+
+## Overview
+
+The Con Agent is a critical persona designed to rigorously challenge a new idea. It is summoned by the `@idea-evaluator` orchestrator during an idea validation debate.
+
+The Con Agent's job is not to be mean, but to act as a "red team." It actively looks for reasons why the idea will fail, waste time, or hit insurmountable technical/market hurdles. It helps prevent builders from falling in love with a bad idea.
+
+## When to Use This Skill
+
+- Use as a sub-agent or persona when running the `@idea-evaluator` skill.
+- Use when you need a reality check on a feature or product you are overly excited about.
+
+## How It Works
+
+When acting as the Con Agent in a debate:
+
+### Core Directives
+1. **Find the Flaws**: Identify the most significant risks: technical debt, lack of market demand, high acquisition costs, or strong existing competition.
+2. **Be Pragmatic**: Base your criticisms on reality. If an idea is technically possible but would take 5 years to build, point out the resource drain.
+3. **Counter-Punch**: When rebutting the Pro Agent, dismantle their optimism. If Pro says a workaround exists, point out why that workaround introduces new, worse problems.
+
+### Debate Behavior
+- **Turn 1 (Initial Critique):** Attack the core premise. Why is this a solution looking for a problem? What is the biggest immediate barrier to entry?
+- **Turn 2 (Rebuttal):** Directly challenge the Pro Agent's Turn 1 points. Expose any overly optimistic assumptions about user behavior or technical ease.
+- **Turn 3 (Closing):** Provide a succinct, hard-hitting summary of why pursuing this idea is a mistake or requires a massive pivot.
+
+## Examples
+
+### Example 1: Critiquing a weird idea
+
+**Idea:** A subscription box for slightly misshapen, un-sellable vegetables.
+
+**Con Agent Response (Turn 1):** "The logistics will kill this business. While the produce is cheap, shipping heavy, perishable boxes of vegetables direct-to-consumer destroys any margin advantage. Furthermore, the 'ugly produce' novelty wears off quickly for consumers when they realize they still have to prep and cook it. You are competing with the convenience of local grocery stores, not other subscription boxes."
+
+## Best Practices
+
+- ✅ Be specific with your critiques. Say "The database scaling costs will be too high because of X" rather than "It's too expensive."
+- ✅ Play the devil's advocate effectively by anticipating user apathy.
+- ❌ Don't be needlessly aggressive or insulting; be a cold, calculating realist.
+- ❌ Don't ignore the Pro Agent's points; actively dismantle them.
+
+## Limitations
+
+- Critiques are simulated red-team reasoning, not substitute for user research, legal review, or technical spikes.
+- Intended only as one side of the `@idea-evaluator` debate, not standalone rejection authority.
+
+## Related Skills
+
+- `@idea-evaluator` - The orchestrator that manages this persona.
+- `@idea-evaluator-pro` - The opposing persona.

package/bundled-skills/idea-evaluator/idea-evaluator-pro/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: idea-evaluator-pro
+description: "The Pro Agent persona for idea evaluation. Logically supports an idea, arguing for its market fit, feasibility, and potential."
+category: agent-persona
+risk: safe
+source: self
+source_type: self
+date_added: "2026-09-18"
+author: Prince-1652
+tags: [ideation, validation, persona, supporter]
+tools: [claude, gemini]
+---
+
+# Idea Evaluator: Pro Agent
+
+## Overview
+
+The Pro Agent is a supporting persona designed to logically advocate for a new idea. It is summoned by the `@idea-evaluator` orchestrator during an idea validation debate.
+
+Unlike a "yes-man," the Pro Agent doesn't blindly agree. Instead, it looks for the absolute strongest case for why an idea *could* work, focusing on market needs, technical feasibility, unique value propositions, and potential monetization.
+
+## When to Use This Skill
+
+- Use as a sub-agent or persona when running the `@idea-evaluator` skill.
+- Use when you need someone to help you find the hidden value in a seemingly crazy idea.
+
+## How It Works
+
+When acting as the Pro Agent in a debate:
+
+### Core Directives
+1. **Find the "Why"**: Always articulate why users would love this idea and what core problem it solves.
+2. **Be Logical**: Base your optimism on logical deductions, market trends, and technical possibilities, not just enthusiasm.
+3. **Counter-Punch**: When rebutting the Con Agent, directly address their concerns with potential mitigations or workarounds. For example, if Con says "It's too expensive," Pro should say "We can reduce costs by doing X."
+
+### Debate Behavior
+- **Turn 1 (Initial Pitch):** Highlight the core value proposition, the target audience, and the best-case scenario. Make the idea sound inevitable and brilliant.
+- **Turn 2 (Rebuttal):** Take the Con Agent's strongest attacks and dismantle them or reframe them as opportunities.
+- **Turn 3 (Closing):** Provide a succinct, powerful summary of why the idea is a winner.
+
+## Examples
+
+### Example 1: Defending a weird idea
+
+**Idea:** A subscription box for slightly misshapen, un-sellable vegetables.
+
+**Pro Agent Response (Turn 1):** "This is a brilliant arbitrage opportunity. It tackles food waste (a massive consumer trend) while offering organic produce at a steep discount. The 'ugly produce' angle is highly marketable on social media, leaning into authenticity and sustainability. The supply is nearly free, making the margins incredibly attractive once logistics are solved."
+
+## Best Practices
+
+- ✅ Ground your optimism in specific examples (e.g., "Similar to how X solved Y...").
+- ✅ Acknowledge risks but offer immediate, practical solutions to them.
+- ❌ Don't ignore the Con Agent's points; address them head-on.
+- ❌ Avoid generic praise like "This is a great idea!" Get specific about *why* it's great.
+
+## Limitations
+
+- Arguments are simulated advocacy, not verified market research or financial projections.
+- Intended only as one side of the `@idea-evaluator` debate, not standalone go/no-go authority.
+
+## Related Skills
+
+- `@idea-evaluator` - The orchestrator that manages this persona.
+- `@idea-evaluator-con` - The opposing persona.

package/bundled-skills/ledger-tasks-yylo/SKILL.md

@@ -0,0 +1,219 @@
+---
+name: ledger-tasks-yylo
+description: 'Use YYLO Ledger task management: create, list, search, get, mark, update,
+  archive, deps, ready, order and merge with dependencies.'
+category: project-management
+risk: safe
+source: https://github.com/yylo-dev/yylo-skills
+source_repo: yylo-dev/yylo-skills
+source_type: community
+date_added: '2026-09-19'
+license: MIT
+license_source: https://github.com/yylo-dev/yylo-skills/blob/main/LICENSE
+compatibility: Requires the `yy` CLI (YYLO Ledger 0.3.x+) installed and a routed Ledger
+  controller; git and bash for worktree tasks. Command help (`yy ledger --help`) is
+  authoritative for the installed runtime.
+argument-hint: '[command or workflow question]'
+enable-shell-directives: true
+---
+
+## YYLO Ledger CLI Reference
+
+Use `yy ledger` for all commands. Ledger 0.3.x exposes both the compatible flat task commands and the native ID-first `record|task|wiki|workflow|artifact` groups. `yy kanban` is a labelled compatibility alias for the same controller-routed task runtime.
+
+### Supported task contract
+
+- Preflight installed `yy ledger --version` and `yy ledger --help`; command help is authoritative for the selected runtime.
+- Use the flat task surface for lifecycle task management. Use the dedicated native skills for wiki, workflow, and artifact Records rather than guessing their arguments.
+- New operational PDRs, contracts, plans, reports, receipts, and evidence belong in typed Artifact Records, not product documentation, task bodies/responses, or new `.juno_task/specs` files.
+- If a required native group is absent, fail closed and request a Ledger upgrade. Never invoke mutable source directly or write Ledger store files by hand.
+- Read current task state before mutation, preserve mutation receipts where offered, and never bypass controller routing or lifecycle state with direct file edits.
+- Normal discovery is hot-only unless an explicit cold-archive command is used.
+
+### Opt-in cross-project routing
+
+Cross-project access is disabled by default. The source `.juno_task/config.json` must set `kanbanRegistry.enabled: true` and explicitly list `allowedProjects`; environment overrides are `YYLO_LEDGER_REGISTRY_ENABLED` and `YYLO_LEDGER_REGISTRY_ALLOWED_PROJECTS`. Register with `yy ledger project add ALIAS --path /absolute/project`, then route any command with `--project ALIAS`. The destination wrapper/runtime remains authoritative, and routing failures never fall back to the source board.
+
+### Legacy Task compatibility commands
+
+**CREATE** — Add a new task
+```bash
+yy ledger 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
+yy ledger list --limit 5 --sort asc
+yy ledger list --status todo --sort asc
+yy ledger list --status todo,in_progress --limit 10
+```
+
+**SEARCH** — Find tasks by criteria
+```bash
+yy ledger search --status todo --tag backend --limit 10
+yy ledger search --body "OAuth" --open
+yy ledger 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
+yy ledger get TASK_ID
+```
+
+**MARK** — Update status with required response message
+```bash
+yy ledger mark in_progress --id TASK_ID --response "Starting work on this"
+yy ledger mark done --id TASK_ID --response "Completed: implemented X, tested Y" --commit abc123def
+yy ledger mark todo --id TASK_ID --response "Reopening: found regression"
+```
+Required: `--id` and `--response`. Optional: `--commit` (recommended for done).
+
+**UPDATE** — Modify task fields
+```bash
+yy ledger update TASK_ID --status todo --tags backend,urgent
+yy ledger update TASK_ID --commit abc123def
+yy ledger update TASK_ID --response "Additional context"
+```
+
+**ARCHIVE** — Soft delete (preserves data, sets status to archive)
+```bash
+yy ledger archive TASK_ID
+```
+
+### Immutable cold archive packs
+
+Normal `list`, `search`, `ready`, and `order` are deliberately hot-only. Exact `get TASK_ID` transparently resolves a hot task or a read-only archived task; use `history TASK_ID` explicitly for its ledger. Discover cold tasks only with bounded, projected `archive-search` output:
+
+```bash
+yy ledger archive-search --tag backend --before 2026-01-01 --limit 20 --projection metadata
+```
+
+Before archive maintenance, preflight the installed version/help and obtain explicit owner authorization. The repository and index must be clean, and reports must be durable new paths outside the repository:
+
+```bash
+yy ledger --version
+yy ledger archive-pack plan --status done,archive --older-than 90d --max-tasks 1000 --target-bytes 26214400 --hard-max-bytes 47185920 --report /external/receipts/archive-plan.json
+# Independently inspect selected IDs, revisions, source HEAD, policy, and plan hash.
+yy ledger archive-pack create --plan /external/receipts/archive-plan.json --report /external/receipts/archive-create.json
+yy ledger archive-pack doctor
+yy ledger doctor
+```
+
+A stale plan or selected-task/worktree conflict must fail closed: discard the plan, resolve the conflict, and plan again. Never automate archival, edit/append packs or manifests, restore/reopen an archived ID, use force/lossy controls, or enumerate archive files directly. Create follow-up work as a new hot task related to the archived ID. Production archival, push/deploy, and post-deploy E2E each require separate authorization; agents must not infer it from implementation approval.
+
+### Dependency Management
+
+**DEPS** — View, add, or remove task dependencies
+```bash
+# View dependency info (blockers, dependents, priority score)
+yy ledger deps TASK_ID
+
+# Add blockers (TASK_ID cannot start until BLOCKER1 and BLOCKER2 are done)
+yy ledger deps add --id TASK_ID --blocked-by BLOCKER1 BLOCKER2
+
+# Remove a blocker
+yy ledger 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
+yy ledger ready
+yy ledger 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
+yy ledger order
+yy ledger 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
+# First produce and review a deterministic plan
+yy ledger merge ./sub1/.juno_task ./sub2/.juno_task --into ./.juno_task \
+  --dry-run --plan-file /external/ledger-merge-plan.json
+
+# Apply only that reviewed plan and retain its receipt
+yy ledger merge ./sub1/.juno_task ./sub2/.juno_task --into ./.juno_task \
+  --apply-plan /external/ledger-merge-plan.json \
+  --receipt-file /external/ledger-merge-receipt.json
+```
+
+### 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. **Concurrent features are supported** — start each selected task with `yy task start TASK_ID`; each gets a dedicated product worktree, while `yy merge` serializes only target updates
+
+### Canonical Controller Routing
+
+YYLO Ledger mutation resolves the controller in this order: explicit `JUNO_TASK_ROOT`, repository-local registration, then the current project root. Diagnose before orchestration with `.juno_task/scripts/controller_resolver.py --cwd "$PWD" --operation kanban`. The resolver may bootstrap or idempotently confirm a registration, but changing an existing controller requires `yy migrate registration plan` followed by a separately authorized apply. Explicit/registered path or branch errors fail closed—YYLO Ledger never switches Git branches or falls back silently.
+
+Run YYLO Ledger and workflows from the controller. A task checkout may implement/test but routes task/session writes to that controller. An integration-owner checkout stays clean and refuses Kanban/orchestration/session writes in strict mode; launch from the controller and pass the product checkout separately as `TASK_ROOT`.
+
+### Environment Variables
+
+- `JUNO_TASK_ROOT` — Explicit canonical controller/task-storage root (not the product `TASK_ROOT`)
+- `JUNO_CONTROLLER_BRANCH` — Expected controller branch for environment-based routing
+- `JUNO_WORKSPACE_ROLE` — `controller`, `task`, or `integration-owner`
+- `JUNO_WORKSPACE_ENFORCEMENT` — `off`, `warn`, or `strict`
+- `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
+
+## When to Use
+
+- You need to interact with the YYLO Ledger task board (create, list, search, get, mark, update, archive, deps, ready, order, merge).
+- You need dependency-aware scheduling (`deps`, `ready`, `order`) or multi-directory consolidation (`merge`).
+- Use the dedicated `wiki-yylo`, `workflow-yylo` and `artifact-yylo` skills for native wiki/workflow/artifact Records instead of guessing their arguments.
+
+## Limitations
+
+- Requires YYLO Ledger 0.3.x+ with the needed command groups; if a group is absent, fail closed and request a Ledger upgrade - never edit store files by hand.
+- Discovery (`list`, `search`, `ready`, `order`) is hot-only; cold tasks need explicit `archive-search`.
+- `archive-pack` and `merge` need explicit owner authorization, a clean tree, and external plan/receipt paths; never automate archival or force past conflicts.
+- Does not grant push, deploy, release, or production-mutation authority.
+
+### Example
+
+```bash
+yy ledger --version && yy ledger --help
+yy ledger ready --limit 5
+yy ledger get TASK_ID
+```
+
+> Adapted from [yylo-dev/yylo-skills](https://github.com/yylo-dev/yylo-skills) (MIT) - v2.0.1; frontmatter, When to Use/Limitations, and safety boundaries added for upstream compliance.

package/bundled-skills/loki-mode/examples/todo-app-generated/backend/package-lock.json

@@ -11,7 +11,7 @@
         "better-sqlite3": "^12.11.1",
         "cors": "^2.8.6",
         "express": "^4.18.2",
-        "express-rate-limit": "^8.6.2"
+        "express-rate-limit": "^8.7.0"
       },
       "devDependencies": {
         "@types/better-sqlite3": "^7.6.13",
@@ -691,9 +691,9 @@
       }
     },
     "node_modules/express-rate-limit": {
-      "version": "8.6.2",
-      "resolved": "https://registry.npmjs.org/express-rate-limit/-/express-rate-limit-8.6.2.tgz",
-      "integrity": "sha512-YH4ru+eOJxQABscKFfRCy9R7x9QFGdezclVMwwgFFndzS2Xnm0uo6B0ABZsLhcpeptGv2qvuJVWlQr9gQZoC3A==",
+      "version": "8.7.0",
+      "resolved": "https://registry.npmjs.org/express-rate-limit/-/express-rate-limit-8.7.0.tgz",
+      "integrity": "sha512-hOwV7WOxXfjRpAM1DSJWZDXx3GhplwD8IfwuwvogD8i1Qnkgosw/H45s4ZnFAUHDAhPjlY9hLBvJhKmGMyY26g==",
       "license": "MIT",
       "dependencies": {
         "debug": "^4.4.3",

package/bundled-skills/loki-mode/examples/todo-app-generated/backend/package.json

@@ -12,7 +12,7 @@
     "better-sqlite3": "^12.11.1",
     "cors": "^2.8.6",
     "express": "^4.18.2",
-    "express-rate-limit": "^8.6.2"
+    "express-rate-limit": "^8.7.0"
   },
   "devDependencies": {
     "@types/better-sqlite3": "^7.6.13",

package/bundled-skills/plan-ledger-tasks-yylo/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: plan-ledger-tasks-yylo
+description: Create a concise Product Development Requirement and one or more implementation-sized
+  YYLO Ledger tasks when the user explicitly asks to plan or register work.
+category: project-management
+risk: safe
+source: https://github.com/yylo-dev/yylo-skills
+source_repo: yylo-dev/yylo-skills
+source_type: community
+date_added: '2026-09-19'
+license: MIT
+license_source: https://github.com/yylo-dev/yylo-skills/blob/main/LICENSE
+compatibility: Requires the `yy` CLI with the `ledger` and `artifact` groups installed.
+  Planning only - implementation, worktrees, push, deploy and production mutation
+  need a separate explicit request.
+argument-hint: '[Required Features] [Constraints] [Acceptance Criteria]'
+enable-shell-directives: true
+---
+
+# Plan Kanban work
+
+1. Read the project instructions and relevant product code from the integration or feature worktree. Read existing task/spec metadata through the canonical controller; do not assume `.juno_task/plan.md` exists.
+2. Produce one concise PDR covering the goal, current behavior, scope, exclusions, risks, dependencies, acceptance criteria, and focused tests. Draft it in a fresh external file; do not place it in the product tree or a task body.
+3. Preflight `yy ledger --help` and `yy ledger artifact --help`. Capture the PDR as a local immutable `report` Artifact Record with task/request provenance, then verify its ID, digest, size, retention, retrieval, and history. If the artifact API is unavailable, stop with the external draft intact and request an upgrade; never fall back to product `docs/`, task bodies/responses, new `.juno_task/specs`, or direct store edits.
+4. Split only when pieces can be implemented and validated independently. Concurrent tasks must have explicit path ownership and dependencies.
+5. Create tasks through routed `yy ledger` commands. Put concise durable requirements and acceptance criteria in each task body, record the PDR artifact ID in supported task fields/provenance, and relate follow-ups instead of reopening archived IDs.
+6. Product documentation is only documentation shipped with the product. Never create controller-private tasks, ledger, state, artifacts, objects, specs, or receipts inside a product or feature worktree.
+7. Do not start implementation, create worktrees, push, deploy, or mutate production unless the user separately asks.
+
+Use `--id`, not legacy `--ID`, for Kanban mutations. Return the task IDs and a short dependency/order summary.
+
+$ARGUMENTS
+
+## When to Use
+
+- The user explicitly asks to plan or register work in the YYLO Ledger.
+- You need a concise Product Development Requirement (PDR) plus implementation-sized Ledger tasks with dependencies.
+
+## Limitations
+
+- Planning only: never start implementation, create worktrees, push, deploy, or mutate production from this skill.
+- Requires the installed `yy ledger artifact` API; if unavailable, stop with the external PDR draft intact - never fall back to product `docs/`, task bodies, or direct store edits.
+- Concurrent tasks need explicit path ownership and dependencies; relate follow-ups instead of reopening archived IDs.
+
+### Example
+
+```bash
+yy ledger --help
+yy ledger artifact --help
+```
+
+> Adapted from [yylo-dev/yylo-skills](https://github.com/yylo-dev/yylo-skills) (MIT) - v2.0.1; frontmatter, When to Use/Limitations, and safety boundaries added for upstream compliance.