1. On platforms with native plan mode (e.g., Claude Code's

   EnterPlanMode

   , Gemini CLI's planning mode): invoke the native plan mode mechanism immediately.
2. On platforms without native plan mode: simulate plan mode by completing all planning phases (INTAKE through PLAN) in full before making any code changes. Present the complete plan to the user for explicit approval before proceeding to EXECUTE.

.absolute-human/board.md

1. Detect: Read the existing board and determine its status (

   in-progress

   ,

   blocked

   ,

   completed

   )
2. Display: Print a compact status summary showing completed/in-progress/blocked/remaining tasks
3. Resume: Pick up from the last incomplete wave - do NOT restart from INTAKE
4. Reconcile: If the codebase has changed since the last session (e.g., manual edits, other commits), run a quick diff check against the board's expected state and flag any conflicts before resuming

completed

.absolute-human/archive/

• Multi-step feature development touching 3+ files or components
• User says "build this end-to-end" or "plan and execute this"
• User says "break this into tasks" or "sprint plan this"
• Any task requiring planning + implementation + verification
• Greenfield projects, major refactors, or migrations
• Complex bug fixes that span multiple systems

• Single-file bug fixes or typo corrections
• Quick questions or code explanations
• Tasks the user wants to do manually with your guidance
• Pure research or exploration tasks

• Simple (single component, clear scope): 3 questions
• Medium (multi-component, some ambiguity): 5 questions
• Complex (cross-cutting, greenfield, migration): 8-10 questions

1. Problem Statement: What exactly needs to be built or changed? What triggered this work?
2. Success Criteria: How will we know this is done? What does "working" look like?
3. Constraints: Are there existing patterns, libraries, or conventions we must follow?

1. Existing Code: Is there related code already in the repo? Should we extend it or build fresh?
2. Dependencies: Does this depend on external APIs, services, or other in-progress work?

1. Edge Cases: What are the known edge cases or failure modes?
2. Testing Strategy: Are there existing test patterns? Integration vs unit preference?
3. Rollout: Any migration steps, feature flags, or backwards compatibility needs?
4. Documentation: What docs need updating? API docs, README, architecture docs?
5. Priority: Which parts are most critical? What can be deferred if needed?

• ID: Sequential identifier (e.g.,

  SH-001

  )
• Title: Clear, action-oriented (e.g., "Create user authentication middleware")
• Description: 2-3 sentences on what this task does
• Type:

  code

  |

  test

  |

  docs

  |

  infra

  |

  config

• Complexity:

  S

  (< 50 lines) |

  M

  (50-200 lines) |

  L

  (200+ lines - consider splitting)
• Dependencies: List of task IDs this depends on (e.g.,

  [SH-001, SH-003]

  )

1. Every task should be S or M complexity. If L, decompose further
2. Test tasks are separate from implementation tasks
3. Infrastructure/config tasks come before code that depends on them
4. Documentation tasks depend on the code they document
5. Aim for 5-15 sub-tasks. Fewer means under-decomposed; more means over-engineered
6. Every task graph MUST end with three mandatory tail tasks (see below)
7. Apply the complexity budget (see below)

• Count the total number of tasks by complexity: S (small), M (medium), L (large)
• If any L tasks remain, decompose them further - L tasks are not allowed
• If total estimated scope exceeds 15 M-equivalent tasks (where 1 L = 3 M, 1 S = 0.5 M), flag to the user that scope may be too large for a single Absolute Human session
• Suggest splitting into multiple Absolute Human sessions with clear boundaries (e.g., "Session 1: backend API, Session 2: frontend integration")
• The user can override and proceed, but they must explicitly acknowledge the scope

1. List all sub-tasks
2. For each task, identify which other tasks must complete first
3. Draw edges from dependencies to dependents
4. Verify no cycles exist (it's a DAG, not a general graph)

• Wave 1: Tasks with zero dependencies (roots of the DAG)
• Wave 2: Tasks whose dependencies are all in Wave 1
• Wave N: Tasks whose dependencies are all in Waves 1 through N-1

1. Codedocs Lookup (if

   codedocs_available: true

   on the board)
   • Check

     docs/INDEX.md

     to find which module doc covers the files relevant to this task
   • Read the relevant

     docs/modules/<module>.md

     for public API, internal structure, dependencies, and implementation notes
   • Check

     docs/patterns/

     for any cross-cutting pattern docs (error handling, testing strategy, logging) that apply to this task
   • Use

     docs/OVERVIEW.md

     for architecture context and to understand how this task's module fits into the system
   • Only proceed to Codebase Exploration below if the docs don't contain enough detail - flag any gaps in the docs as a staleness note on the board
   • Record which doc files were used in the task's research notes on the board
2. Codebase Exploration (always run; use to fill gaps left by docs or when codedocs is not available)
   • Find existing patterns, utilities, and conventions relevant to this task
   • Identify files that will be created or modified
   • Check for reusable functions, types, or components
   • Understand the testing patterns used in the project
3. Web Research (when codebase context is insufficient)
   • Official documentation for libraries and APIs involved
   • Best practices and common patterns
   • Known gotchas or breaking changes
4. Risk Assessment
   • Flag unknowns or ambiguities
   • Identify potential conflicts with other sub-tasks
   • Note any assumptions that need validation

• Launch parallel Explore agents for all tasks in Wave 1 simultaneously
• Once Wave 1 research completes, launch Wave 2 research, and so on
• Each agent writes its findings to the board under the respective task

• Key files identified
• Reusable code/patterns found
• Risks and unknowns flagged
• External docs referenced

1. Files to Create/Modify: Exact file paths
2. Test Files: Test file paths (TDD - these are written first)
3. Implementation Approach: Brief description of the approach
4. Acceptance Criteria: Specific, verifiable conditions for "done"
5. Test Cases: List of test cases to write
   • Happy path tests
   • Edge case tests
   • Error handling tests

1. Tests are always planned before implementation
2. Each plan must reference specific reusable code found in DISCOVER
3. Plans must respect the project's existing conventions (naming, structure, patterns)
4. If a plan reveals a missing dependency, update the task graph (re-approve with user)

1. Ensure all current changes are committed or stashed
2. Record the current commit hash on the board under

   ## Rollback Point

3. If execution goes catastrophically wrong (build broken after max retries, critical files corrupted), the user can

   git reset --hard

   to this commit
4. Remind the user of the rollback point hash when flagging unrecoverable failures

1. Tests: Run the task's test suite - all tests must pass
2. Lint: Run the project's linter on modified files
3. Type Check: Run type checker if applicable (TypeScript, mypy, etc.)
4. Build: Verify the project still builds

1. Run tests for tasks that depend on this wave's output
2. Check for conflicts between parallel tasks (file conflicts, API mismatches)
3. Run the full test suite if available

• Tests: pass/fail (with details on failures)
• Lint: clean/issues
• Type check: pass/fail
• Build: pass/fail

references/verification-framework.md

1. Merge: If using worktrees or branches, merge all work into the target branch
2. Full Test Suite: Run the complete project test suite
3. Documentation: Update any docs that were part of the task scope
4. Summary: Generate a change summary with:
   • Files created/modified (with line counts)
   • Tests added (with coverage if available)
   • Key decisions made during execution
   • Any deferred work or follow-ups
5. Close Board: Mark the board as

   completed

   with a timestamp
6. Suggest Commit: Propose a commit message summarizing the work

• Full history of all 7 phases
• Every sub-task with its research, plan, and verification
• Timeline of execution
• Any issues encountered and how they were resolved

1. Parallel agents modifying shared files without a lock strategy - Two agents in the same wave that both edit the same utility file or test fixture will produce a merge conflict at the wave boundary. During DECOMPOSE, identify shared files and assign ownership to one task; other tasks must treat those files as read-only until the owning task completes.
2. Board marked

   completed

   but tests were never run - The mandatory tail task "Run full project verification suite" is frequently skipped when agents declare done based on subjective confidence. Never mark the board

   completed

   until the actual test/lint/build commands have been run and their output recorded on the board.
3. DISCOVER phase skipped for "obvious" tasks - Agents assume they know the codebase well enough to skip research. Then they write code that duplicates existing utilities, uses the wrong import paths, or misses a convention that would have been visible in a 2-minute code scan. Always run DISCOVER, even for small tasks.
4. Rollback point recorded after Wave 1 has already started - Recording the git commit hash mid-wave means the rollback point already includes partial changes. The pre-execution snapshot must be taken before any file is touched - before Wave 1 begins, not during it.
5. Scope creep absorbed silently expands the DAG without user visibility - Agents frequently discover adjacent improvements during EXECUTE and absorb them into the current task without flagging them. This makes the wave take longer than planned, obscures what changed, and violates the scope agreement from INTAKE. Everything outside the original scope goes to the Deferred Work section.

• references/intake-playbook.md

  - Full question bank organized by task type (feature, bug, refactor, greenfield, migration), with scaling rules and example sessions

• references/dependency-graph-patterns.md

  - Common DAG patterns, ASCII rendering format, wave assignment algorithm, and example graphs

• references/wave-execution.md

  - Parallel agent orchestration, agent prompt templates, blocked task handling, error recovery

• references/verification-framework.md

  - TDD workflow per sub-task, verification signals, integration testing, failure handling

• references/board-format.md

  - Full

  .absolute-human/board.md

  specification with format, status transitions, and example board

On first activation of this skill in a conversation: check which companion skills are installed by running

ls ~/.claude/skills/ ~/.agent/skills/ ~/.agents/skills/ .claude/skills/ .agent/skills/ .agents/skills/ 2>/dev/null

. Compare the results against the

recommended_skills

field in this file's frontmatter. For any that are missing, mention them once and offer to install:

npx skills add AbsolutelySkilled/AbsolutelySkilled --skill <name>

Skip entirely if

recommended_skills

is empty or all companions are already installed.