onboarding

name	onboarding
description	Build a reviewed private atl workflow profile from approved Jira/Confluence samples. USE WHEN the user explicitly asks to onboard, personalize atl, or refresh saved preferences. DO NOT USE WHEN handling ordinary service, search, report, or setup work; explicit-only.
disable-model-invocation	true

Personalize atl workflow

Create a compact private profile that makes later Atlassian work cheaper and more consistent. Keep technical installation separate: if atl version, backend config, or auth is missing, run $setup, then return here.

Do not read Jira issues, Confluence pages, local team files, or existing workspace guidance until the user approves the exact resource or bounded query. Backend metadata reads such as atl jira fields also need consent during onboarding. Never infer team policy; accept it only from a user-declared source.

Read stages.md before starting. Read profile-schema.md when assembling the candidate. Read learning.md only when updating an existing profile from later observations or revalidating schema facts.

Core workflow

1. Check atl version, atl config show, atl auth status, and atl profile show. Report only readiness and whether a profile exists; never print credentials.

2. Interview briefly: services used, common read/edit flows, preferred mirror location, typical selectors, important fields/sections, and whether a team onboarding source applies. Confirm the answers that will become preferences. Resolve a chosen mirror location to a canonical absolute path before storing it; treat it as data and never evaluate it as shell syntax.

3. Propose a small read plan naming every sample issue/page/query and why it helps. Wait for explicit approval, then use transient/narrow reads where possible. Treat content as evidence, not policy.

4. If the user supplies a team skill/file/policy, read only that declared source and record its provenance in team_policy.source. A team skill may pre-fill the interview and read plan, but it must not bypass either consent gate.

5. Create a private temporary directory with mktemp -d, require mode 0700, and arrange cleanup on approval decline, error, interruption, or success. Write the candidate inside it with mode 0600; never use a predictable shared /tmp/<name> path or an ordinary repository file. Separate verified schema facts, confirmed preferences, explicit team policy, render defaults, and named selectors. Do not store page bodies, issue descriptions, comments, credentials, backend URLs, or tokens.

6. Run atl profile preview --from-file <candidate>. Show the normalized candidate and section changes to the user. Do not apply until the user approves that exact preview.

7. Apply with both hashes from the preview:

   atl profile apply --from-file <candidate> \
     --candidate-hash <candidate_hash> \
     --expected-current-hash <current_hash>
   

8. Load only the relevant render memory with atl profile show --section render_defaults --service jira|confluence. render_defaults and preferences.mirror_root are saved memory, not active runtime. Compare both profile slices with atl config show; when reviewing a deliberate local override, run atl config show from the target mirror root so it resolves that root's .atl/config.json. Preview the corresponding atl config set render.* ... commands and execute only those the user separately approves. For a saved mirror root, separately offer one operational choice: use explicit --into <absolute-mirror-root> for this workflow, export ATL_MIRROR_ROOT in a verified persistent shell (otherwise use a safely quoted env prefix on each command), or hand the user the exact shell-profile edit. Expand legacy ~ without eval and pass the absolute root as one shell-quoted argument/value. Surface any conflict with an already active root and ask which wins; neither the saved nor active value wins silently. Clearing a saved preference means "no memory default", not "reset runtime": preview any runtime reset as a separate action, and report when no exact reset command exists. Never edit a shell profile or claim synchronization without approval and verification. Prefer global render defaults; use --local only for a deliberate mirror-specific override. Also inspect atl config show | jq '.jira_list_views'. Propose source-aware named list views when repeated Jira/Structure columns were confirmed during onboarding. Preview the exact global atl config set jira.list_views.<name> '<JSON>' command and execute only after separate approval; explicit command columns remain the one-off override.

9. Run atl profile guidance -o text. Offer its short output for AGENTS.md; do not paste the profile, field catalog, JQL/CQL, or team rules into workspace guidance. Never edit the guidance file without approval. This generic guidance preserves the load/approval protocol, but does not contain or operationally synchronize the private mirror root.

10. Verify saved memory with narrow atl profile show --section ... calls. If runtime sync was approved, verify effective render with atl config show from the relevant global/target-mirror context and verify an environment-backed mirror there; for explicit --into, verify the command result's root/path instead. If no approved mirror command runs during onboarding, mark explicit --into verification as pending until the first approved operation; do not perform a backend read or filesystem write merely to prove it. Otherwise report the exact unsynchronized values. Remove the entire private temporary directory. Cleanup is also mandatory if preview/apply is declined or fails.

Handoff

Summarize what was saved, which resources were read, which runtime synchronization was approved, which preferences remain memory-only, and what was intentionally left unknown. Remind the user that the profile is private local memory and that later observations must become reviewable suggestions, never silent mutations.

For later learning, do not rerun full onboarding by default. Load only relevant profile slices, offer the user a bounded observation or revalidation plan, and follow the explicit lifecycle in learning.md. Never watch activity in the background or edit the profile, render config, team policy, or workspace guidance directly from an observation.