---
name: m0n0x41d/h-onboard
source: https://app.decimal.ai/s/m0n0x41d-h-onboard@3/SKILL.md
source_sha256: c8adc3846f7f
---

# h-onboard — Bootstrap through one readable setup contract

Use the native Pi `haft_onboard` tool rather than exposing low-level profile or
memory machinery.

Contract truth: project-profile onboarding and automatic project-memory setup are
**V9 CONTRACT** capabilities. Source, schema, skill, or local-test presence is
not installed-runtime proof and does not establish Pi host parity. A readiness
claim requires current **EXACT-CANDIDATE EVIDENCE** from P14 tied to one exact
candidate; RC or release status additionally requires release authority. Pi
support is experimental, and contract inclusion or evidence alone does not
establish **CURRENT PRODUCT** status.

Start with:

```json
{
  "action": "status"
}
```

Follow only its closed result kind:

- `needs_init` — run the explicitly requested `haft init`, reconnect when
  instructed, and repeat `status`;
- `needs_profile` — call `haft_onboard` with
  `{ "action": "profile_prepare" }`;
- `profile_review_ready` — present the readable review and its exact next act;
- `ready` — only the canonical profile and structured project memory are ready.
  This does not establish specification applicability, health, lifecycle, or
  release readiness; use `h-spec` separately for specification work.

`haft init` installs default project memory as part of initialization. Never
ask the operator to enable, defer, select, or understand a memory schema. A
legacy or partial installation reporting `needs_init` is repaired by rerunning
`haft init`, reconnecting, and repeating `status`.

If repository detection cannot establish the profile basis, call
`profile_prepare` again with the top-level readable `basis` and explicit
`scopes`. Each scope uses only `scope_id`, `label`, `realization_kind`, and
supporting `evidence_paths`. A prepared or reused review is non-binding and
does not change canonical profile state.

Detector proposals are read-only. Profile and spec gates remain human. A
readable scope_id is not a ScopeID or proof of canonical applicability.

Automatic `h-onboard` may inspect and prepare but must not apply. After the
readable review and engineering assessment, route only a direct, unambiguous
operator selection of that exact profile and scope to `haft onboard profile
apply`. Do not require a skill name or ask for a second confirmation. A bare
`yes` or `да` works only for one current unambiguous profile brief.
Successful application records `host_routed_operator_request` provenance;
automatic singleton bootstrap remains the separate `detector_default` path.

A missing `entity_reference` does not make `TargetSystemSpec` underdetermined
and is never a prerequisite for spec lifecycle. Use
`profile_change_prepare` only when the operator directly asks to add or replace
the relation itself, never to make a carrier applicable. The exact existing
`scope_id` and operator-selected `entity_ref` create or reuse only the
predecessor-pinned `.haft/profile-change-review.json`; they cannot change
another profile field. Do not infer the target from memory rank or repository
paths. After a direct selection, `haft onboard profile change apply` remains
CAS-pinned and changes profile identity metadata only; it does not advance a
SpecSection lifecycle.

Never expose or ask the operator to choose internal memory schemas, revision
heads, staging records, or implementation letters. Missing setup or known
absence does not authorize EntityOfConcern creation and does not block
unrelated already-authorized Work.

After exact project applicability is readable, inspect the spec lifecycle and
draft only applicable carriers. A non-software or unresolved scope must not
receive false SoftwareSystemSpec pressure. Keep every spec lifecycle gate
human.

Do not create a ProblemCard merely because onboarding is occurring and do not
infer a project sequence. Continuing lifecycle work belongs to `h-spec`.