Home/stef-openclaw-skills
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Clarify approval-safe property assessor flow

Browse Source
This commit is contained in:
Stefano Fiorini
2026-03-27 23:47:24 -05:00
parent 1f23eac52c
commit 7570f748f0
2 changed files with 19 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
docs/property-assessor.md
View File

@@ -220,11 +220,21 @@ Good:
- `node har-photos.js "<url>"`
- `scripts/property-assessor locate-public-records --address "..."`
- `scripts/property-assessor render-report --input ... --output ...`
- `web_fetch` to read an official CAD / assessor page when the TypeScript helper needs a plain page fetch
Avoid when possible:
- `node -e "..."`
- `node --input-type=module -e "..."`
- `python3 - <<'PY' ... PY`
- `python -c "..."`
- raw `bash -lc '...'` or `zsh -lc '...'` probes for CAD / public-record lookup
Reason:
- OpenClaw exec approvals are path-based, and inline shell / interpreter forms are treated conservatively in allowlist mode.
- For `property-assessor`, CAD and public-record lookup should stay on the skill’s file-based TypeScript helper path or use `web_fetch`.
- If the workflow drifts into an ad hoc shell snippet, that is not the approved skill path and can still trigger Control UI approval prompts.
## PDF report template

9
skills/property-assessor/SKILL.md
View File

@@ -46,6 +46,8 @@ Rules:
- Avoid fragile interactive gallery flows if they are likely to require approval or bounce the user into Control UI.
- If a richer photo pass would require approval, do not silently force that path first. Continue with the best approval-free workflow available and clearly lower confidence if needed.
- Only escalate to approval-heavy browser interaction when there is no reasonable alternative and the extra fidelity materially changes the assessment.
- Do **not** use ad hoc shell snippets, heredocs, or inline interpreter eval for public-record or CAD lookup from chat. Avoid forms like `python3 - <<'PY'`, `python -c`, `node -e`, `node --input-type=module -e`, or raw `bash -lc '...'` probes.
- For public-record enrichment, use `scripts/property-assessor locate-public-records`, `scripts/property-assessor assess`, or `web_fetch`. If a one-off fetch helper is truly needed, add a file-based helper under the skill tree first and run that file-based entrypoint instead of inline code.
## Source order
@@ -106,6 +108,12 @@ Default approach:
4. use the official public-record site as a primary-source check against listing data
5. link the official jurisdiction page and any direct property page used in the final result
Approval-safe rule:
- do not perform CAD/public-record discovery with inline shell or interpreter snippets
- use the built-in TypeScript helper path first
- if the official site needs a plain page fetch, prefer `web_fetch`
- if rendered interaction is unavoidable, use a file-based `web-automation` helper rather than ad hoc shell text
Use the helper CLI first:
```bash
@@ -141,6 +149,7 @@ Important rules:
- parcel/APN/account identifiers from Zillow/HAR/Redfin are much stronger keys than listing geo IDs
- if a direct public-record property page is available, use its data in the assessment and link it explicitly
- if the jurisdiction can be identified but the property detail page is not directly retrievable, still link the official jurisdiction page and say what could not be confirmed
- a host approval prompt triggered by an ad hoc shell snippet is workflow drift; return to `locate-public-records`, `assess`, `web_fetch`, or a file-based helper instead of approving the inline probe by default
### Texas rule