away
[ADD v{{VERSION}}] Declare absence — get autonomous work plan for the duration
- License 许可
- MIT
- 最近更新
- 2026-10-31
- Stars
- ★ 11
- Forks
- 6
01 前言 Front Matter
- references
- [ "rules/telemetry.md" ]
- description
- [ADD v{{VERSION}}] Declare absence — get autonomous work plan for the duration
- allowed-tools
- [ "Read", "Write", "Edit", "Glob", "Grep", "Bash", "TodoWrite" ]
- argument-hint
- [duration, e.g. '4 hours', '30 minutes', 'end of day']
02 资源文件 3
- 许可证LICENSE1.0 KB
- 参考文档SOURCE.md506 B
- 参考文档TRUST.auto.yaml2.2 KB
03 SKILL.md 正文
ADD Away Command v{{VERSION}}
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
- Read
.add/config.jsonfor autonomy level and environment tier - Re-read
docs/prd.mdto ground yourself in the project's objectives and scope — this keeps autonomous work aligned with the product vision - Scan
specs/for specs with status "Approved" or "Implementing" - Scan
docs/plans/for plans with status "Approved" or "In Progress" - Check current git status for in-progress work
- 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:
# 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.mdwhenever 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
autoPromoteis 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
04 同仓库更多 Skills
add-verify
暂无简介
add-verify
暂无简介
add-verify
暂无简介
version
[ADD v0.11.0] Show installed version, project version, and upgrade status
verify
[ADD v0.11.0] Run quality gates — lint, types, tests, coverage, spec compliance
ux
[ADD v0.11.0] Iterate on UI/UX design before implementation — wireframes, flow validation, and design sign-off