Add Away

---
name: add-away
description: "[ADD v0.11.0] Declare absence — get autonomous work plan for the duration"
argument-hint: "[duration, e.g. '4 hours', '30 minutes', 'end of day']"
---

<!-- ADD AskUserQuestion shim (Codex) -->
<!-- Injected by scripts/compile.py when skill-policy.yaml marks a skill -->
<!-- with requires_askuser_shim: true. See AC-026/027/028 in -->
<!-- specs/codex-native-skills.md. -->

> **Codex interaction mode notice (ADD)**
>
> This skill depends on structured question/answer turns. Behavior depends on
> Codex's current mode:
>
> - **Plan mode:** call the `ask_user_question` tool for each prompt below.
>   One question per call. Wait for the user's answer before moving on.
> - **Default mode (no `ask_user_question` available):** emit the questions
>   inline as a numbered list, then **halt and wait** for the user's next
>   prompt. Do **not** improvise, infer, or fabricate answers — this skill
>   fails closed if required input is missing. Resume only after the user
>   replies.
>
> The skill body below defines what to ask; the shim only governs *how* to ask.

---

# ADD Away Command v0.11.0

The human is stepping away. Establish what work can proceed autonomously and what must wait.

## Phase 1: Understand the Absence

Parse the duration from $ARGUMENTS. If not provided, default to **2 hours**. Do not ask — just acknowledge the default:
"No duration specified — I'll plan for a 2-hour session. Say `/add-away 4 hours` next time to adjust."

## Phase 2: Assess Available Work

1. Read `.add/config.json` for autonomy level and environment tier
2. **Re-read `docs/prd.md`** to ground yourself in the project's objectives and scope — this keeps autonomous work aligned with the product vision
3. Scan `specs/` for specs with status "Approved" or "Implementing"
4. Scan `docs/plans/` for plans with status "Approved" or "In Progress"
5. Check current git status for in-progress work
6. Run TodoWrite to see current task list

### Categorize Work

**Autonomous (can do without human):**
- Tasks with clear specs and plans where requirements are unambiguous
- Writing tests for specced features (RED phase)
- Implementing against existing failing tests (GREEN phase)
- Refactoring with test coverage (REFACTOR phase)
- Running quality gates and fixing lint/type errors
- Writing documentation for completed features
- Code review of existing PRs

**Queued (needs human decision):**
- Any task where the spec is ambiguous or missing
- Architecture decisions with multiple valid approaches
- Deployment to staging or production
- New feature specs (need interview)
- Dependency upgrades with breaking changes
- Anything that would benefit from a Decision Point

## Phase 3: Present the Plan

```
Got it — you'll be away for approximately {DURATION}.

AUTONOMOUS WORK PLAN:
━━━━━━━━━━━━━━━━━━━
{numbered list of tasks, with spec references}

Estimated completion: {rough estimate}

QUEUED FOR YOUR RETURN:
━━━━━━━━━━━━━━━━━━━━━
{numbered list of decisions/tasks that need human input}

I'll maintain a work log and have a return briefing ready.
```

## Phase 4: Get Confirmation

Ask: "Does this plan look right? Anything you want me to prioritize or avoid while you're away?"

Wait for confirmation before starting autonomous work.

## Phase 5: Create Away Log

Write `.add/away-log.md` to track progress:

```markdown
# Away Mode Log

**Started:** {timestamp}
**Expected Return:** {timestamp}
**Duration:** {duration}

## Work Plan
{the agreed plan}

## Progress Log
| Time | Task | Status | Notes |
|------|------|--------|-------|
```

Update this log as work progresses.

## During Away Mode

Away mode grants **elevated autonomy**. The human is not available — do not wait for input on routine development tasks.

### Autonomous Operations (do NOT ask for permission)
- **Commit to feature branches** — follow conventional commit format, commit after each TDD phase
- **Push to feature branches** — push regularly so work is not lost
- **Create PRs** — open PRs when a feature branch is ready for review
- **Run and fix quality gates** — lint, types, formatting errors are fixed without asking
- **Read specs, plans, and PRD** — re-read `docs/prd.md` whenever you need to validate a decision against the product vision
- **Run tests** — execute test suites freely to verify your work
- **Install dev dependencies** — if tests or builds need a missing dev dependency, install it
- **Promote through environments** — follow the promotion ladder defined in the environment-awareness rule. If verification passes at one level and `autoPromote` is true for the next environment, deploy there and verify. Rollback automatically on failure (see environment-awareness rule for details).

### Boundaries (do NOT cross without human)
- Do NOT deploy to production or any environment where `autoPromote: false`
- Do NOT merge PRs to main/production branches
- Do NOT start new features that lack a spec — if you finish all planned work, write documentation, improve test coverage, or refactor within existing specs
- Do NOT make irreversible changes (drop tables, delete branches, force push)
- Do NOT make architecture decisions with multiple valid approaches — log the decision point and move on

### Staying Aligned
- Before starting each task, re-read the relevant spec and plan
- If a task feels ambiguous, check the PRD (`docs/prd.md`) for guidance
- If still ambiguous after reading the PRD, **log the question and skip to the next task** — do not guess on product direction

### Work Discipline
- ONLY work on tasks from the approved plan
- Log every completed task in `.add/away-log.md`
- If a blocker is hit, log it and move to the next task
- Send brief status pulses in the conversation at reasonable intervals