---
title: "Skills & Hobbies (Camp Counselor)"
slug: skills-hobbies-camp-counselor
section: Applicant Journey
status: stable
description: "The authoritative skill taxonomy collected at the Camp Counselor “Skills & Hobbies” intake step — length categories, skills."
last-updated: 2026-10-07
---

# Skills & Hobbies (Camp Counselor)

The authoritative skill taxonomy collected at the Camp Counselor “Skills & Hobbies” intake step — length categories, skills.

> **Camp Counselor Program Only**
>
> This taxonomy applies to the Camp Counselor program only. It does not apply to SWT (Summer Work & Travel), Teach USA, Intern/Trainee, or any other program. Other programs use their own skill and experience capture, defined on their own intake workflows.

## Overview

During Phase 1 intake, every Camp Counselor applicant completes a Skills & Hobbies step (see Applicant Lifecycle → Portal Phase Mapping ). This page is the source of truth for the catalog presented at that step: the full Skills & Hobbies V4.0 list of length categories and skills, transcribed exactly as authored.

Skills selected here feed the Matching Engine , which weights the Skills dimension most heavily for Camp Counselor placements. This page documents the taxonomy only — it does not define the matching weights, the selection UI, or any validation logic.

## Selection Requirements

At the Skills & Hobbies step, the applicant must make the following selections:

3–5

Skills required

Minimum 3, maximum 5 skills selected from the categories below.

2–6

Hobbies required

Minimum 2, maximum 6 hobbies. Both the V4 and V5 step variants show the “Select 2–6 hobbies” instruction and block a seventh selection.

> **Selection Rule**
>
> 3–5 skills required, 2–6 hobbies required.

### Free-Text Word Minimum

Every free-text answer that is filled in must contain at least **20 words**: each selected skill's Experience Description, the Hobbies Reflection, and (V4 only) My Experience with Children. Individual hobbies are a plain multi-select with no per-entry narrative, so they carry no word minimum. The same bound is enforced on the portal step-submit route and on staff step completion (the rule lives in the shared Skills & Hobbies schema), and the live word counters in the step read the same served minimums.

Enforcement differs by route, because the Applicant Portal saves this step incrementally (on every added or edited entry):

- **Portal submit (`POST /api/portal/steps/:stepKey/submit`)** enforces only the 20-word minimum, and only on free-text boxes that are filled in. Empty boxes and incomplete selections are accepted. A short answer returns 422 with per-field errors naming the minimum (for example “Please write at least 20 words describing your experience with Cooking (currently 3).”).
- **Staff step completion** enforces the full completion rules: 3–5 skills with proficiency levels, certification documents for Certified skills, the hobby count, and the required reflection and (V4) children-experience boxes, together with the word minimums.

**Grandfathering of `children_experience`.** The required My Experience with Children box and its 20-word minimum are completion-time rules, and they are not applied retroactively. On both the portal submit route and the staff completion path, a step that was already complete before the write is exempt from the `children_experience` rule when its prior persisted snapshot carried fewer than 20 words in that field (absent, or a short pre-rule answer). A prior answer that already met the minimum is not grandfathered, so the new submission must still meet it. A step that was never completed is not grandfathered, and neither is a regression on a step whose prior snapshot already carried a qualifying answer. Only `children_experience` is exempted; every other rule still applies in full. On the portal route the prior-snapshot lookup is best-effort: if it fails, that request falls back to the stricter behaviour.

## Children Experience Field (V4)

Skills & Hobbies V4 adds a **Children Experience** textarea to the Skills & Hobbies step in the back-office (Shipped Aug 11 2026). The field is **required for Camp Counselor applicants**, and its value feeds directly into the Category 2 (Cat 2) eligibility derivation.

The field's contents populate the `children_experience` data used to derive the Camp Counselor SEVIS eligibility path: an applicant with direct childcare experience captured here derives Category 2, which the CAMP-002 add-on rule ("Youth worker evidence verified") checks. For the full eligibility-path priority order (Cat 1 > Cat 2 > Cat 3), staff override, and the CAMP-001 / CAMP-002 / CAMP-003 gate, see the SEVIS Readiness page.

## Staff Review & Save Behaviour

In the back-office applicant profile, staff review of the Skills & Hobbies step is gated on the applicant having submitted it:

- **Item review waits for submission.** Item-level review and whole-step approval are available only once the applicant has submitted the step (the step is completed) or a whole-step review already exists. Until then the review panel is replaced by an “Awaiting applicant submission” notice.
- **Staff “Save & Continue” completes an incomplete step.** When staff enter or edit the answers for a step that is not yet complete, “Save & Continue” saves the edits and then completes the step through the server completion gate (so invalid answers, such as a reflection under 20 words, are rejected and nothing is written). On an already-completed step the button reads “Save” and is a plain edit-save.
- **Both data shapes are written.** A staff save writes the canonical nested `skills_hobbies_data` value and the same values flattened at the top level, matching what the Applicant Portal persists, because the completion gate's required-field check reads the top-level keys.

## Field-Level Sponsor Review

*Status: item-level review (changes_requested / applicant_resubmitted items) and the portal `reviewFeedback` block are implemented; the scope decisions below record the design.*

Sponsors reviewing the Skills & Hobbies step can approve or request changes on individual skills (and the hobbies reflection) rather than only accepting or rejecting the whole step. Staff compose targeted per-skill comments as a private draft, then publish them by returning the step to the applicant ("Return for changes") or approving it. The applicant sees an amber "Program team feedback" panel under each affected skill — visually distinct from the optional AI writing suggestions — and the feedback persists through edits and resubmission until staff resolves each item.

Binding scope decisions of record:

- **No new step status.** The tracked step status remains `rejected` — all reopen machinery (reject-clearable lock release, rejection-message staleness gate, portal needs-action) keys on that literal value. "Changes requested" is decision/item vocabulary only; the UI relabels the actions to "Return for changes" and "Approve step".
- **No submission-attempt entity.** Review-item resolution keys on the resubmission event and timestamps.
- **Stable `itemId` lands first.** Each selected skill and hobby entry in the composite contract gains a permanent UUID so feedback can target an entry across renames and reorders. This is a cross-repo frozen-schema change (the canonical schema is deep-frozen and drift-locked, shared with the Applicant Portal form-engine bundle); legacy rows without IDs resolve by name-match fallback.
- **Server-side approve gate.** The step cannot be approved while any published review item remains in a changes-requested state.
- **Curated reason code stays mandatory** on the overall return; per-item comments are supplemental free text.
- **Items carry their own lifecycle.** Published items persist through resubmission until staff resolves them — deliberately not gated on live step status, unlike whole-step rejection messages.
- **Portal delivery reuses existing read surfaces.** Feedback ships as a `reviewFeedback` block on the step-access payload with audience filtering (internal-only staff notes never leave Globus); no parallel channel.

The review framework is generic (review sessions + review items) so future composite steps — work experience, education, references — inherit the capability without rework.

**Persistence.** Whole-step review decisions are stored in `step_review_decisions`: one row per application and step key (unique on that pair) with `decision`, `review_notes`, the reviewer id and name, and the curated reason code id and label plus the applicant message as snapshots. Field-level review uses `step_review_sessions` (per application and step: `decision` of `draft`, `approved` or `changes_requested`, `overall_comment`, the reason code fields, `published_at` null while private and stamped on publish, and `supersedes_review_session_id` linking a correction to the published session it replaces; at most one open draft per application and step) and `step_review_items` (per session: `target_type`, today `skill`, `hobby` or `hobbies_reflection`; `target_item_id`, `target_label`, `field_path`; `status` of `not_reviewed`, `approved`, `changes_requested`, `resolved` or `applicant_resubmitted`; `comment`; `visibility` of `internal` or `applicant`; `resolved_at` and `resolved_by`).

Delivery is sequenced across four tickets: the `itemId` contract change (P1.2 Form Control), the review sessions/items framework with staff UI and approve gate (P11.1 Step Locking), the portal read path (P11.1 Step Locking), and the Applicant Portal rendering (PPPToo Greenfield Rebuild).

## Skills & Hobbies V4.0 Taxonomy

The per-category skill lists are not reproduced on this page; the served V4.0 catalogue is `SKILLS_HOBBIES_V4_SKILL_CATEGORIES` in `shared/skillsHobbiesSchema.ts`.

The V4.0 catalogue has ten categories, in this canonical order: Arts & Crafts, Performing Arts, Adventure Sports, Land Sports, STEM, Water Sports, Outdoor Adventure, Nature, Child Care, and Other Cool Stuff. Other Cool Stuff is always listed last.