@kolisachint/hoocode-agent 0.5.29 → 0.5.31

package/templates/prompts/grill-plan.md

@@ -0,0 +1,9 @@
+You are attacking the plan below, not executing it.
+
+Review it as a skeptical reviewer would:
+- Which steps rest on assumptions you have not verified in the codebase? Read the relevant files and verify them now.
+- Where could this fail silently — wrong-but-plausible behaviour rather than a loud error?
+- What does the goal require that the plan does not cover? What does the plan cover that the goal does not need?
+- Does the verification section prove the goal is met, or only that the code runs?
+
+Report what you find. Where a weakness is real, revise the plan file and state what changed. Where the plan holds up, say so plainly rather than inventing criticism. Do not implement anything.

package/templates/prompts/task-background-agents.md

@@ -0,0 +1,2 @@
+- Background agents run non-blocking (or force per call with `background: true`): you get a short "explore#1 finished" notification and pull the full result with `TaskOutput` (e.g. `TaskOutput("explore#1")`); `TaskOutput(list: true)` shows what's running.
+- After dispatching, don't idle — keep doing independent work (read/edit unrelated files, draft, dispatch more); barrier with `TaskOutput(wait: true)` (a named task, or all outstanding when no id) only when you genuinely can't proceed.

package/templates/prompts/task-background-none.md

@@ -0,0 +1 @@
+- You can force any task to run in the background with `background: true` (non-blocking): keep working, then pull its result with `TaskOutput` (e.g. `TaskOutput("explore#1")`) or block on it with `TaskOutput(wait: true)`.

package/templates/prompts/task-main.md

@@ -0,0 +1,19 @@
+You have access to the **Task** tool. Use it to delegate self-contained tasks to specialized subagents that run in their own isolated context and return only their final answer. Pick an agent by name from the <available_agents> list in this prompt and pass it as `subagent_type`.
+
+When to delegate:
+1. The work is self-contained and you only need the final result, not intermediate steps.
+2. You want to investigate or edit something in parallel without losing your current context or reasoning chain.
+3. The task is a discrete unit (explore one module, run one test file, review one PR, fix one isolated bug).
+4. You need to run a long command or test suite and wait for its output without blocking your own reasoning.
+
+Model tier (optional `complexity`): set `fast` for quick reads/lookups, `standard` for multi-file edits, `capable` for deep architecture work. It maps to a model from `settings.modelCategories`. Omit it to use the agent's default; an agent that pins its own model ignores `complexity`.
+
+Guidelines:
+- Choose the agent whose description best matches the task.
+- Make every task specific and self-contained. The subagent cannot see this conversation; pass all necessary context (files, constraints, prior findings) in `prompt`.
+- Do NOT delegate tasks that require tight back-and-forth with your current reasoning, or edits to files you are actively reasoning about.
+- The subagent returns ONLY its final answer. Its intermediate reasoning, tool calls, and output are hidden from you.
+- Delegate proactively when work is self-contained or parallelizable: multi-step investigation, read-only exploration (use `explore`), research before changes (use `plan`), drafting a standalone file/section, or running a long command/test suite. Dispatch independent subtasks in the same turn. Handle only trivial single-step edits or tightly interactive back-and-forth inline.
+{{BACKGROUND_GUIDANCE}}
+- When working through a TodoWrite plan, mark the plan item in_progress BEFORE dispatching subagents for it: each dispatch is attributed to the current in_progress item in the user's task panel, so dispatching first (or with several items in_progress) leaves the run unattributed.
+- To continue a previous subagent (for example one that returned partial results), call Task again with `resume_task_id` set to its task_id; it resumes with its full prior transcript and `prompt` is your follow-up.

package/templates/skills/plugin-authoring/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: plugin-authoring
+description: How to author a portable, reusable hoocode plugin — when a capability is worth extracting, how to name and describe it so it triggers again, and what makes content portable across repos and machines. Use before calling ProposePlugin or UpdatePlugin, or when deciding whether a recipe you just completed is worth keeping.
+allowed-tools: read, write, edit, grep, find, ls
+---
+
+# Authoring a plugin
+
+This is the craft half of the plugin tools. `ProposePlugin` and `UpdatePlugin`
+know how to *write* a plugin; this describes how to write a *good* one. Read it
+before authoring, not after.
+
+## When a capability is worth extracting
+
+Extract when both are true:
+
+- You completed a multi-step recipe you would plausibly repeat — or you repeated
+  the same pattern twice in one session.
+- `SearchPlugins` found nothing that already covers it.
+
+Do not extract a one-off. A job that came up twice may just be a job that came up
+twice; the test is whether the *shape* recurs, not whether the task did.
+
+## Name and describe by the capability, not the occasion
+
+The description is the only thing loaded on every turn, and it is the entire
+basis on which the plugin is chosen later. Write it for the next situation, not
+for the one that prompted it.
+
+- Bad: `fix-flaky-auth-test` — names the incident. It will never trigger again.
+- Good: `flaky-test-triage` — names the capability, with a description saying
+  when to reach for it.
+
+Say *when to use it* in the description, in the words someone would use when
+they need it. A description that only says what the plugin is will not trigger.
+
+## Portability
+
+The plugin has to work in a repo you have never seen, on a machine you do not
+control:
+
+- No absolute paths, no machine-specific paths. Prefer relative paths and
+  runtime discovery.
+- No embedded secrets, tokens, or environment-specific values.
+- No assumptions about the current repo unless that *is* the capability's point.
+- State prerequisites in the body rather than assuming them.
+
+The layout is the session's target platform. You never choose it.
+
+## Shape
+
+Put the whole plugin in one call — skills plus a hook go together, not in two
+passes. The risk gate is computed from the content, so do not pre-classify:
+read-only subagents, skills and commands go straight through; hooks, MCP
+servers, or a subagent needing bash/write/edit/MCP or `tools: *` pause for human
+confirmation.
+
+Passive content activates immediately and is reversible with `UninstallPlugin`.
+Announce what you created and why.
+
+## Growing one you already authored
+
+`UpdatePlugin` is additive: supply only the delta, and existing capabilities are
+preserved (a matching name replaces just that one). It cannot remove anything —
+that is `RemovePluginCapability`.
+
+Hooks are the exception to "additive is safe". They have no name, so supplying a
+changed command **adds a second hook alongside the old one** and both fire. To
+change a hook, remove the old one first, then add the new one.
+
+Adding a passive skill to an already-executable plugin does not re-prompt; only
+executable *additions* trigger confirmation.
+
+## Two things that are never yours to do
+
+- Never grant a subagent a plugin-system tool (`InstallPlugin`, `ProposePlugin`,
+  …). It is rejected, and the reason is that an agent that can install plugins
+  for other agents is a self-propagation primitive.
+- Never publish to a marketplace autonomously. Packaging is yours; publishing is
+  a human action, because pushing executable code into a marketplace other
+  agents install from unattended is a supply-chain compromise.