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

Require property assessor follow-through after preliminary helper

Browse Source
This commit is contained in:
Stefano Fiorini
2026-03-28 00:44:28 -05:00
parent be4f829704
commit 33466079a3
2 changed files with 25 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
docs/property-assessor.md
View File

@@ -60,6 +60,12 @@ Default operating sequence:
7. Underwrite carry costs and risk factors.
8. Render the final report as a fixed-template PDF.
Operational rule:
- The helper returning a preliminary payload is not the end of the job.
- For a user request that clearly asks for a full assessment or PDF delivery, the agent is expected to continue the missing analysis after the helper returns.
- Preliminary helper output should be treated as structured scaffolding for the remaining work, not as a reason to stop and wait for another user nudge.
### `assess`
```bash
@@ -82,6 +88,12 @@ Current behavior:
- does not render/send the PDF from a preliminary helper payload with `decision: pending`
- only renders the fixed-template PDF after a decision-grade verdict and fair-value range are actually present
Expected agent behavior:
- if the user asked for the full assessment, continue beyond the preliminary helper output
- fill the remaining gaps with listing facts, comp work, condition interpretation, and valuation logic
- only stop early when there is a real blocker, not merely because the helper stopped at a checkpoint
Important limitation:
- this implementation now wires the address-first intake, purpose-aware framing, public-record lookup, listing discovery, and photo-source extraction

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

@@ -34,6 +34,13 @@ Do not drop the unit when discovering listing sources. Unit-qualified condo/town
7. Flag risk drivers before giving a verdict.
8. End with a specific recommendation: `buy`, `pass`, or `only below X`.
Completion rule:
- A preliminary helper payload is not completion.
- If `assess` returns a preliminary payload, continue the remaining analysis yourself in the same run.
- Use the preliminary payload as scaffolding for the missing work: listing facts, comp analysis, valuation range, condition interpretation from photos, and final verdict.
- Do not stop and ask the user whether to continue just because the helper stopped at a preliminary checkpoint.
- Only interrupt the user when there is a genuine blocker: missing assessment purpose, missing recipient email at final render/send time, unavailable listing/public-record sources with no reasonable fallback, or missing facts that cannot be recovered.
## Approval-averse / chat-safe behavior
When operating from chat surfaces such as WhatsApp, Telegram, Signal, or other messaging channels, prefer workflows that do **not** trigger host exec approval prompts.
@@ -103,6 +110,12 @@ scripts/property-assessor render-report --input "<report-payload-json>" --output
- do **not** render or send a PDF from the helper's preliminary payload while verdict is still `pending` or fair value is not established
- if comps, valuation, or decision-grade condition interpretation are still incomplete, return the preliminary payload and say that the PDF/send step must wait
Agent follow-through rule:
- When the user asked for a full property assessment or asked for the PDF/email result, do not stop at the helper output.
- After `assess` returns a preliminary payload, continue with the remaining manual/model-driven steps needed to reach a decision-grade report.
- Only after the verdict and fair-value range are established should you render/send the PDF.
- If the analysis still cannot be completed, explain the first real blocker, not just that the helper was preliminary.
## Public-record enrichment
Public-record / assessor data should be used when available and linked in the final result.