---
name: bring-on-your-first-teammate
description: >-
  Prepare populated editable onboarding drafts for a small U.S. company's
  first employee, contractor, or working cofounder using canonical forms.
  Use when a founder needs another pair of hands and wants applicable
  employment and IP documents prepared for review without
  making final legal, tax, payroll, or worker-classification decisions.
license: Apache-2.0
compatibility: Requires an agent that can read Markdown files; web access is needed to verify current law and retrieve linked documents.
metadata:
  author: usejunior
  version: "0.2.1"
  source_repository: UseJunior/legal-explainer
catalog_group: Editing And Client Workflows
catalog_order: 45
---

# Bring on your first teammate

Help a small company move from “we need another pair of hands” to
populated editable documents that its decision-maker can review, accompanied
by a short list of unresolved decisions and relevant sources.

This workflow helps the company prepare its process; it does not create an
attorney-client relationship. Before asking the proposed teammate for sensitive
personal information, explain that you are helping the company and are
not acting as the teammate's lawyer. Avoid collecting personal identifiers
or completed government forms in chat.

## Boundaries

- Identify facts that affect the relationship; do not make a final employee,
  contractor, tax, benefits, or payroll classification.
- Do not assume a cofounder is already an employee merely because they work for
  the company or own stock.
- Do not send an offer, sign or file a document, start payroll, grant or issue
  equity, or invite anyone to a company system without explicit authorization.
- Keep company records wherever the user chooses. Do not require a hosted
  account or copy private matter state into the skill.
- Distinguish sourced facts, user statements, open questions, and your own
  inferences in every review package.

## Workflow

1. Establish the operational need, intended work, expected start date, work
   location, manager, and who can approve the engagement.
2. Establish each capacity separately. Ask whether the person is already a
   founder, director, officer, stockholder, optionholder, contractor, or service
   provider; then ask what new relationship the company proposes.
3. If the relationship is uncertain, collect the facts needed for counsel or a
   qualified payroll/tax adviser. Label the result “classification review
   required”; do not choose the more convenient form.
4. Identify the governing jurisdiction before recommending state-sensitive
   wage, invention-assignment, or restrictive-covenant material.
5. Inventory existing documents and approvals. Do not replace an existing
   founder stock, IP, board, contractor, or employment instrument without first
   identifying it.
6. Read the bundled Legal Explainer content listed in
   [references/resources.md](references/resources.md). These are source-linked
   exports, not a complete onboarding manual. Verify current law and applicable
   state guidance before using them for a recommendation. Select only the
   resources that fit the known facts; the same index links to canonical pages
   and downstream documents.
7. Prepare the selected canonical forms using their current declared fields
   and the facts already supplied. Ask one compact batch of material questions
   that remain unanswered; do not ask the user to repeat facts in their records.
   Separate missing facts that prevent selecting a form (such as work state)
   from unanswered fields that can remain visibly open (such as reporting
   manager). Continue with supported drafts while identifying blocked documents.
8. Return the editable drafts and short handoff described in
   [references/review-package.md](references/review-package.md).
9. Stop for approval before any external action.

## Drafting from canonical forms

Retrieve and read the actual form, including its fields, defaults, conditional
provisions and drafting notes. A catalog listing or link alone is not the form.
Read the canonical template page for its version, attribution and license,
and `https://openagreements.org/templates/<slug>/template.json` for current field
metadata; the annotated Markdown alone may not contain either. If a signal is
unavailable, state that rather than inventing it.
Use the current schema rather than inventing field names. Populate consistent
party names, compensation, dates and work location across the documents.
Preserve applicable notices and supply attribution/license information with the
delivered drafts, not only in retrieval logs. Remove fill instructions and
optional-module annotation banners from the populated document. Fill business
terms with the terms themselves; put drafting comments, approval limits and
decisions in the handoff, outside operative text.

### Conditional provisions

Read each form's annotated Markdown at
`https://openagreements.org/templates/<slug>/template-annotated.md` and its current
schema. The annotated form lists conditional sections and their triggers. Make
each applicable choice explicit; do not rely on a declared default or assume
an unset trigger omits a section. Check the tool's behavior against the source.

For the current offer and CIIAA forms, non-empty text or `true` keeps the
corresponding section; an empty string or `false` omits it. Set each offer
`bonus_terms` or `equity_terms` to an empty string unless that award is proposed;
record its absence in the handoff, not as “No bonus proposed” in a trigger field.
Set CIIAA `personnel_nonsolicit_included` and `future_employer_notice_included`
false when no optional post-employment restraints are requested. If the choice
is unresolved, prepare a provisional draft omitting them and identify the choice
for review. Preserve confidentiality, IP and statutory protections independently.
For the generic offer, set `california_specific_terms` explicitly according to
the confirmed work state; do not include California terms for a non-California
employee merely because the trigger was left unset.

Inspect every selected section in the output. Unknown trigger warnings or a
section retained against the stated choice make that output unusable regardless
of the tool's exit code. If the filler cannot honor the choice, return populated
editable Markdown from the canonical annotated form, removing the omitted
section and its related cover terms, and state that Word output was unavailable.
If the source or condition cannot be resolved, identify that document as blocked.

Use explicit placeholders for unanswered material terms. An invention disclosure
of “None” is an affirmative answer, not a substitute for an absent disclosure.
Distinguish an intended effective date from an executed agreement and a proposed
equity term from an approved grant. Verify current jurisdiction-specific rules
when making legal recommendations; filling user-supplied terms does not establish
their compliance.

Return editable Word files when available through the user's tools. Editable
Markdown containing the actual populated document is also useful; state when
Word rendering is unavailable. Fill-data files may accompany drafts but do not
replace them. If a canonical form cannot be retrieved, identify the unavailable
document and produce the other supported drafts. Do not recreate its substance
from memory or substitute another jurisdiction without explanation.
Inspect the returned documents: accepting fill values does not prove a tool
replaced visible field tokens or omitted the selected conditional provisions.
Unresolved placeholders should correspond only to facts still unanswered.

## Relationship routes

- **First employee:** ordinarily evaluate an offer letter, confidentiality and
  invention assignment, wage-and-hour rules, required notices, payroll setup,
  and any proposed restrictive covenant.
- **Working cofounder:** first inventory the person's existing founder,
  governance, equity, and IP documents. Treat employment, compensation, and
  payroll as additional questions, not consequences of founder status.
- **Contractor:** fact-spot classification risk and use contractor documents
  only after the proposed relationship remains supportable. Do not disguise an
  employee relationship with a contractor agreement.
- **Transition to payroll:** inventory prior services, compensation, IP,
  equity, and approvals; identify what changes prospectively and what historical
  questions require professional review.
- **Uncertain relationship:** produce a short fact matrix and escalation list
  rather than a document recommendation.

## Completion

For a worked intake with deliberately missing facts, see
[examples/first-employee.md](examples/first-employee.md).
For a specified synthetic NY hire and expected populated terms, see
[examples/new-york-employee.md](examples/new-york-employee.md). For a founder
transition, see [examples/founder-transition.md](examples/founder-transition.md).

For a drafting request, completion means returning the actual editable drafts
supported by the facts, with a short handoff naming unresolved terms, substantive
review points, unavailable documents and required decisions. A proposed-document
list or compliance checklist alone does not complete a sufficiently specified
drafting request. For incomplete intake, return supported work and focused
questions without describing the engagement as ready to implement.

## Policies, when requested

Use the company's actual current policies and identify their titles and company
revisions. Preparing a new policy is a separate drafting task. If supplied or
released, use canonical `openagreements-information-security-policy` and its
maintained security-policy skill; read the actual form and current schema rather
than assuming its ID means it is publicly available. Do not duplicate its
substance here. An unreleased draft retains its source-verification and
substantive-review gates; it is not an adopted company policy. A policy draft
remains Draft / Pending approval absent adoption evidence. Company policy
revision and template version are different identifiers.

A separate acknowledgment draft can list the identified policy versions. Do not
invent delivery dates, signatures, adoption or training completion. Acknowledgment,
training, employment acceptance and evidence that controls operate are distinct.
Keep records in the customer's chosen tools; no workforce database is required.