mirror/nanobot
1
0
Fork 0
mirror of https://github.com/HKUDS/nanobot.git synced 2026-05-19 16:12:30 +00:00
Code Issues Packages Projects Releases Wiki Activity

refactor(long_task): streamline goal instructions and enhance documentation

Browse Source
This commit is contained in:
Xubin Ren 2026-05-16 04:25:09 +00:00
parent 897eedaaa7
commit 2e31002e6e
3 changed files with 25 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
nanobot/agent/tools/long_task.py
View File

@ -84,12 +84,8 @@ class _GoalToolsMixin(ContextAware):
tool_parameters_schema(
goal=StringSchema(
"Full objective text for sustained execution on this chat thread. "
"Required: read the entire **long-goal** skill before composing this argument "
"(locate **long-goal** in the skills listing and open its file path, e.g. read_file)—do **not** "
"call `long_task` until you have read it. "
"Apply that skill literally: desired outcomes and acceptance criteria; "
"idempotent, self-contained wording (safe across compaction and resume; "
"no duplicate destructive steps); explicit deliverables, scope boundaries, and verification.",
"Required: open the **long-goal** skill from the skills listing (e.g. read_file its path)—do **not** "
"call `long_task` until you have read it. Compose `goal` exactly per that file.",
max_length=12_000,
),
ui_summary=StringSchema(
@ -123,16 +119,11 @@ class LongTaskTool(Tool, _GoalToolsMixin):
@property
def description(self) -> str:
return (
"Declare a sustained objective for this conversation. "
"Before calling: read the **long-goal** skill from its path in the skills listing—goals must be "
"idempotent and self-contained (clear end state, scope, verification), "
"not brittle step lists that break on retry or compaction. "
"Execution stays on the main agent across turns (use normal tools). "
"The active objective is mirrored each turn under Runtime Context as "
"\"Goal (active):\" plus the stored text. "
"When—and only when—the objective is fully satisfied, call complete_goal. "
"Do not call complete_goal for partial progress or because you are tired. "
"If an objective is already active, finish or complete_goal before starting another."
"Register one sustained objective for this thread. "
"Read the **long-goal** skill file (path in skills listing) before the first call—rules and phrasing live there. "
"The active goal is mirrored in Runtime Context each turn; use normal tools until done, then call "
"complete_goal only when the objective is fully satisfied (not for partial progress). "
"If a goal is already active, finish it or call complete_goal before registering another."
)
async def execute(self, goal: str, ui_summary: str | None = None, **kwargs: Any) -> str:

2
nanobot/skills/README.md
View File

@ -29,4 +29,4 @@ The skill format and metadata structure follow OpenClaw's conventions to maintai
| `tmux` | Remote-control tmux sessions |
| `clawhub` | Search and install skills from ClawHub registry |
| `skill-creator` | Create new skills |
| `long-goal` | Sustained objectives: `long_task`, `complete_goal`, idempotent goal wording |
| `long-goal` | Sustained objectives: `long_task`, `complete_goal`, idempotent goals, modular project work, early research |

18
nanobot/skills/long-goal/SKILL.md
View File

@ -1,6 +1,6 @@
---
name: long-goal
description: Sustained objectives via long_task / complete_goal, Runtime Context goal lines, and idempotent goal wording.
description: Sustained objectives via long_task / complete_goal — idempotent goal wording, project-style modular work, early web/doc research, Runtime Context metadata.
---
# Long-running objectives (`long_task` / `complete_goal`)
@ -40,3 +40,19 @@ Write goals so they are:
6. **`ui_summary`** — Short label for sidebars/logs; keep **non-load-bearing** (no secret requirements only in the summary).
If you discover the objective was underspecified, you may ask the user—or **`complete_goal`** with recap and register a **narrower** replacement goal rather than overloading one ambiguous string.
## Project-shaped work (avoid the “mega file” trap)
Use this when the goal is to **build or reshape a codebase** (app, service, tooling, sizeable feature):
1. **Modular layout** — Split into **meaningful modules** (directories + files with clear responsibilities: entrypoints, domain logic, config, infra, CLI/UI routes, etc.). **Do not** default to dumping an entire project into one giant source file unless the user explicitly wants a minimal single-file artifact.
2. **Conventional structure** — Follow normal practice for that stack (separation of concerns, sensible naming, config vs code, reusable helpers). Aim for reviewable increments, not unreadable blobs.
3. **Verify as you go** — Run/format/lint/tests the project affords after meaningful chunks so the tree stays truthful; bake **checks or manual steps into the goal** when they matter.
## Look things up instead of guessing
Facts (API specifics, tooling flags, deprecations, best practices newer than cutoff) fail silently in sustained work unless you anchor them early:
1. **Use discovery tools when appropriate** — If the ecosystem is unfamiliar or brittle, **`web_search`**, doc/web fetch (or MCP) **early**—before committing to architecture or rewriting large areas. Narrow queries tied to decisions you must make next.
2. **Turn findings into scoped action** — Summarize conclusions into repo artifacts only when helpful (comments, README, small design note); keep **compact**—not a substitute for executing the objective.
3. **Re-consult when stuck** — If errors contradict assumptions or loops repeat, pause and refresh context with targeted search/fetch rather than hammering blindly.