Grayscale/nanobot
1
0
Fork 0
Code Issues Pull Requests Actions 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
Download Patch File Download Diff File Expand all files Collapse all files
nanobot/skills/README.md
+1 -1
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 |
nanobot/skills/long-goal/SKILL.md
+17 -1
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.