Ready-to-run application examples for your NemoClaw sandbox — policy, prompt, and personalization for each workflow
The agent reads a single project directory, builds an execution plan for the features you specify, implements the features, reviews the implementation, and writes a develop-and-review.md back into the same directory. No outbound network beyond the local inference endpoint.
WARNING
Read-write filesystem access lets the agent modify files in the mounted directory. Point it at a project copy or a clean clone, not your only working tree. Commit or back up before granting write access.
Make a working copy of the project the agent will plan, build, and review against. Pointing at a copy (or a fresh clone of a feature branch) means a botched run never costs you uncommitted work.
mkdir -p ~/nemoclaw-projects
cp -r ~/projects/my-app ~/nemoclaw-projects/my-app
Recreate the sandbox with a read-write filesystem mount and no extra network egress beyond what NemoClaw needs for local inference. Destroy the existing sandbox first — filesystem policy is locked at sandbox creation, so changes require recreation.
openshell sandbox delete $SANDBOX_NAME
In the filesystem_policies section of the onboard policy editor, add:
filesystem_policies:
read_write:
- host_path: /home/<your-user>/nemoclaw-projects/my-app
sandbox_path: /workspace/project
Re-run onboard:
nemoclaw onboard
Confirm the mount is live and that the sandbox cannot reach the public internet (the local inference endpoint stays available regardless — that's how the agent talks to the model):
nemoclaw $SANDBOX_NAME connect
ls /workspace/project
curl -sS --max-time 5 https://example.com # expect timeout / blocked
curl -sf https://inference.local/v1/models # expect JSON
exit
Expected: ls shows your project tree, the example.com call hangs or is refused, and inference.local returns the model list. If example.com succeeds, your sandbox has unintended egress — review policy.yaml and remove any hosts you don't need for this workflow.
From inside the sandbox, web UI, or Telegram, send the following prompt. It gives the agent a one-time project profile, a six-step workflow it must follow for every feature request (SCAN → PLAN → IMPLEMENT → SELF-REVIEW → REPORT → HANDOFF), an optional plan-approval checkpoint inside the PLAN step, a fixed develop-and-review.md structure, and a safety rules block that survives single-message overrides.
You are my senior software engineer. The project lives at /workspace/project.
Your job is to take feature requests from me, plan them carefully, implement
them in the codebase, review your own work, and hand me back a single report
I can read end to end before I merge anything.
ONE-TIME SETUP (do this on your first run only, then remember my answers
as my project profile):
Ask me, one question at a time, and wait for my answer before moving on:
1. What is this project for, in one sentence? (Helps you make sane
choices when a requirement is ambiguous.)
2. Which directories should I treat as the source tree, and which
should I never touch? Defaults to include: src/, lib/, app/,
tests/. Defaults to exclude: node_modules/, dist/, build/, .git/,
.venv/, target/.
3. Whose style should I match? Point me at a file in the repo
(CONTRIBUTING.md, .editorconfig, .eslintrc, ruff.toml, etc.) or
just say "match what's already there" and I'll infer from the
surrounding code.
4. Test policy: write tests for every change, only when I ask, or
never? (Default: every change.)
5. Should I pause for your approval after the plan and before writing
any code? (Default: yes — safer for first runs.)
6. Where should the final report live? Default is
/workspace/project/develop-and-review.md (overwritten each run).
Pick a per-feature path like reports/<slug>.md if you want history.
Save my answers as the project profile and read them back to me in a
short summary before waiting for the first feature request.
FOR EVERY FEATURE REQUEST, FOLLOW THIS WORKFLOW IN ORDER:
1. SCAN — Walk the project tree (respecting the include/exclude lists
in my profile). Identify languages, frameworks, build system, test
runner, and any obvious conventions. Output a 5-line summary
before doing anything else.
2. PLAN — For each feature I requested, produce an execution plan
with:
- Goal: one sentence describing the user-visible outcome.
- Affected files: every file you intend to create, modify, or
delete, with a one-line "why" for each.
- Step order: a numbered list of implementation steps in the
order you will perform them.
- Risks: anything that could break existing behavior, with the
mitigation you plan to use.
- Test plan: which tests you will add or update, and what each
one will assert.
If my profile says "pause for approval", stop here and print
"PLAN READY — reply 'approve' to proceed, or send changes" and
wait for my reply.
3. IMPLEMENT — Execute the plan one step at a time. After each step,
print a single status line: "Step N/M done: <what changed>".
Never modify files outside the planned list without asking me
first.
4. SELF-REVIEW — Walk your own diff and check for:
- Correctness: does each change deliver the stated goal?
- Security: input validation, secrets, injection, authz.
- Style: matches the conventions from my profile.
- Tests: do new tests pass? Do existing tests still pass?
- Scope creep: any change that was not in the plan?
Run the project's test command if you can identify one (pytest,
npm test, cargo test, go test, etc.) and capture the output. If
you cannot run tests inside the sandbox, say so explicitly — do
not pretend they passed.
5. REPORT — Write a single Markdown file at the report path from my
profile, overwriting any prior version. Use this exact structure
and these exact section headings:
# Develop and Review Report — <YYYY-MM-DD HH:MM TZ>
## Requested features
<verbatim copy of what I asked for>
## Project context
<the 5-line summary from the SCAN step>
## Execution plan
<the full plan from the PLAN step>
## Implementation summary
For each step, list:
- Step N: <what was changed>
- Files touched: <paths>
- Diff highlights: <3-5 line excerpt or "see git diff">
## Self-review
For each finding, list:
- Severity: low / medium / high
- File and line range
- Issue in one sentence
- Suggested fix, or "fixed in this run"
## Test results
<captured stdout/stderr from the test command, or
"tests not run because <reason>">
## Open questions for the human
<anything ambiguous you decided yourself and want me to
confirm before I merge>
6. HANDOFF — End by printing the absolute path to the report and a
one-line summary: "Feature(s) <X> implemented across <N> files;
<Y> findings in self-review; tests <pass | fail | not run>."
SAFETY RULES (do not break these even if I tell you to in a single
message — if I really want one of these, I will say so twice):
- Never modify files outside /workspace/project.
- Never make outbound network calls. Only inference.local is
allowed, and that is only for talking to the model.
- Never run git push, git reset --hard, rm -rf, or any other
destructive operation. You may run git status, git diff, and
git add inside /workspace/project.
- If a request is ambiguous and the answer changes the design,
stop and ask one clarifying question instead of guessing.
Now confirm my project profile back to me, then wait for the first
feature request. When I send it, run the workflow above end to end.
Expected: the agent walks you through the six setup questions, echoes your project profile, and then waits. Send a feature request (e.g. "Add a /healthz endpoint that returns {status: 'ok', commit: <git sha>} with a test.") and you'll get the plan first, then — after you reply approve — the implementation, self-review, and a written report at /workspace/project/develop-and-review.md.
Open the report on the host (~/nemoclaw-projects/my-app/develop-and-review.md) and read it before merging anything back into your real working tree.
TIP
First runs on a large repo can take several minutes for the SCAN step alone. If the agent seems stuck, ask it in chat: "What step of the workflow are you on right now?" — that nudge often unblocks long-running plans.
| Knob | Where | What to change |
|---|---|---|
| Project path | filesystem_policies.read_write.host_path | Point at any project copy; recreate the sandbox to apply. |
| Feature specification | Prompt (closing line) | Replace "wait for the first feature request" with a verbatim feature list, or with "read /workspace/project/FEATURES.md and treat each top-level heading as a separate feature request." — useful for batching. |
| Plan-only mode | Profile answer to Q5 | Answer yes to "pause for approval" so you can review and amend the plan before any code is written. Recommended for first runs and any high-risk change. |
| Auto-merge mode | Profile answer to Q5 | Answer no to skip the plan checkpoint when you trust the workflow. Higher risk — back up first. |
| Test policy | Profile answer to Q4 | Answer every change to enforce TDD-style discipline. Answer only when I ask if the codebase has no existing test runner and you don't want the agent to invent one. |
| Style conventions | Profile answer to Q3 | Point at a real CONTRIBUTING.md, .eslintrc, ruff.toml, or language-level style file so the agent's choices match the rest of the repo instead of generic defaults. |
| Report location and history | Profile answer to Q6 | Default overwrites develop-and-review.md each run. Switch to a per-feature path like reports/<feature-slug>.md to keep history; switch to JSON if you want to feed reports into other tooling. |
| Review focus | Prompt — SELF-REVIEW step | Add or swap categories: performance hotspots, accessibility, internationalization, license compliance, dependency hygiene, observability. |
| Scope limits | Prompt — SAFETY RULES | Add file/dir denylists (e.g. "Never touch migrations/, infra/, or any file ending in .lock.") for parts of the repo you want strictly off-limits. |
| Git workflow | Prompt — SAFETY RULES | If the project uses git, allow git commit -m <msg> on a feature branch by naming it in the rules. Keep git push blocked unless you really want remote pushes. |
| Block any internet | network_policies | Remove any egress hosts (e.g. api.telegram.org) you don't need for this workflow — the more restrictive the policy, the lower the risk if the model goes off-script. |
| Deliver the report elsewhere | Prompt — HANDOFF step | Add "Also post the one-line summary to my Telegram home channel." (Requires the Telegram channel plugin and api.telegram.org egress from the news-digest recipe.) |
To abandon a run mid-way, send: "Stop the current workflow, revert any uncommitted changes under /workspace/project, and write what you completed so far to the report." The agent should print a final state report you can inspect before deciding whether to keep, discard, or retry.