# Act Meditation Continuity

> Consolidates substantive Scout work into a concise, approval-first repository handoff and evidence-based reusable-capability candidates without automatic writes.

- Skill: `fabioc-aloha/act-meditation-continuity` (Agent Skill)
- Install (CLI): `npx skillmds@latest add fabioc-aloha/act-meditation-continuity`
- Raw SKILL.md: https://api.skillmd.com/api/skills/fabioc-aloha/act-meditation-continuity/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: fabioc-aloha (https://skillmd.com/u/fabioc-aloha)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/fabioc-aloha/act-meditation-continuity

---


# Meditation Continuity

Use this Scout-native continuity practice only at the end of substantive work,
before a handoff, or after a real reusable insight or failure. Do not use it for
routine execution: a handoff or candidate without new signal creates noise.

## Review the Current State

1. Identify the current target repository or workspace. Inspect the actual Git
   branch, latest commit, working-tree status, current work, recorded decisions,
   failures, any repo-root `HANDOFF.md`, and relevant local skills, instructions,
   prompts, scripts, and automation patterns.
2. Separate **verified facts** (directly observed), **assumptions** (reasonable
   but unconfirmed), and **unverified history** (reported or inferred without
   current evidence). Do not present assumptions or history as facts.
3. Never include credentials, private Microsoft 365 content, personal data, or
   opaque application state in a handoff, candidate, or postmortem. Do not make
   persistent-memory claims, create source scripts or host-specific folders, or
   treat session context as a durable record.

## Preserve Continuity Deliberately

1. Prepare a concise proposed update for repo-root `HANDOFF.md` containing the
   objective and project state; verified completed work; decisions and approval
   boundaries; observed Git branch, latest commit, and working-tree state;
   unresolved risks or blocks; and the next safe action.
2. If `HANDOFF.md` already exists, preserve its valid content and merge or update
   only relevant sections. Never blindly overwrite it.
3. Preview the exact proposed content and obtain explicit approval before
   creating or modifying `HANDOFF.md`. Approval to assess continuity is not
   approval to write a project file.

## Extract Only Demonstrated Reuse

1. Retain an automation candidate only when recurrence is demonstrated by at
   least two occurrences, or by a concrete repeated failure. Reject one-off,
   aspirational, duplicate, or unverified candidates.
2. Before proposing an artifact, scan existing project-local skills, guidance,
   prompts, scripts, and automation. Prefer reuse or extension over duplication.
3. For each retained candidate, describe its trigger, inputs, outputs, failure
   modes, placement, validation, owner, and rollback. State the recurrence
   evidence and why existing local patterns are insufficient.
4. Route an approved project-local artifact to
   `act-project-capability-authoring`. Route a cross-machine reusable candidate
   first to `act-constellation-curation`; package, release, or publication work
   needs a separate explicit approval and workflow.
5. Do not automatically create a local skill or script, change project files,
   write memory, publish a package, change OneDrive, or share across machines.

## Learn from Failures

For a real failure, propose a concise postmortem that records the actual root
cause, the generalizable pattern, and prevention. Do not assign blame or claim a
root cause without evidence. Keep it proposed unless its destination and write
are separately approved.

## Report

Report the current state; the handoff candidate and required action; retained
and rejected candidates with evidence; any postmortem candidate; and the next
safe action. If no durable signal exists, say so and leave no artifact behind.