---
name: hitl-setup
description: Prepare a human-in-the-loop workflow with hitl.ph for an Australian or New Zealand business, using its existing task tools. Create a workflow brief and rehearse with sample data; use when setting up or assessing a possible hitl.ph connection.
---

# Prepare a human handoff with hitl.ph

This kit prepares a working arrangement. It does not connect an account, submit work to hitl.ph, book staff, or install a live API. No public hitl.ph task endpoint or credential-issuing service is available through this kit. Earlier website API and CLI examples are not a supported integration contract.

hitl.ph is exploring partnerships with Australian and New Zealand SMEs: employed people in the Philippines supporting automated processes, working to the client's instructions and decision limits. Agree the actual staffing and connection with the team before live work.

## Start with the client's existing process

Use the information already supplied. Ask only for missing details that affect the workflow: the business process, the tool that holds the work, the exception that needs a person, approximate volume, working hours, and who has authority to decide.

Prefer the client's existing Asana, Notion, Monday, Slack or other workspace. These are possible destinations, not bundled or guaranteed integrations. Distinguish the system that holds the task and final decision from channels that merely notify people. An ordinary message or emoji is not an approval unless an authorised, attributable approval mechanism has been explicitly designed and tested.

Read `workflow-brief.md` and produce a completed brief in the user's working folder. Label assumptions and unresolved decisions. Include:

- Trigger, context, named responsible role and source task reference.
- Checking instructions, allowed outcomes, decision limits and escalation owner.
- Where the final decision is recorded and how automation finds it.
- What happens on missing information, no response, duplicate events and a failed return delivery.
- Account permissions and access still needed; never ask for secrets in the brief.

## Rehearse locally

Inspect `rehearse.mjs`, then run `node rehearse.mjs` if a Node.js runtime is available. It uses fictional invoice records and writes a JSON report to stdout. It performs no network requests and writes no files. If Node is unavailable, walk through the same cases in text and say the script was not executed.

Use the report to discuss approve-within-limits, missing information, escalation and duplicate handling. Every decision in it is simulated. A passing rehearsal is not an integration test, a human review, or proof that a client's automation can resume reliably. Preserve that distinction in any demonstration or generated code.

Do not connect accounts or send sample records to external tools merely to demonstrate the kit. If the user separately authorises a real integration, inspect the available connector and its current official documentation, confirm the destination and permitted actions, and implement only that agreed scope. Use synthetic data for the first external test. Do not invent API endpoints, credentials, working integrations, response times or staffing availability.

## Deliver a useful next step

Return the workflow brief, rehearsal outcome, and the specific connection and operating decisions still outstanding. Offer the brief as material for a conversation with hitl.ph at ai@yoonet.io; do not send it without authorisation.

Live work needs an agreed process, staff and cover, authorised accounts, tested return delivery, and an accountable client decision-maker. Report readiness as either **planning**, **local rehearsal**, **external test**, or **live by agreement**, supported by what actually happened.