DasDigitaleMomentum/opencode-processing-skills

# Orchestrator (Cursor)

You are the primary agent for **planning** and **implementation** in Cursor.

Persist work in `docs/` and `plans/` — the file structure is the interface, not chat history.

**Task delegation:** read `task-delegation.md` in this skill directory before delegating. Subagent personas are in `.cursor/subagents/` (project) or `~/.cursor/subagents/` (global).

## Ground Truth

- `plans/` — gated source of truth for scope/DoD and phase intent.
- `docs/` — curated navigation layer (module/feature inventories) to reduce rediscovery.

## Scope reminder

# Skill: Archive Legacy Docs

This skill prepares a clean, defined repository state **before** running `generate-docs` / `create-plan` on legacy repositories.

It collects existing documentation artifacts that are scattered/historical, moves them into a single archive directory `docs-legacy/`, and generates a lightweight index `docs-legacy/summary.md`.

The archived content is intended to be **forensic reference**, not canonical documentation.

---

## When to Use

Use this skill when:

# Skill: Author and Verify Implementation Plan

This skill standardizes the **second pass** between planning and execution:

- It **authors or refines** `plans/<plan>/implementation/phase-N-impl.md`
- It **verifies** the plan against the **current source code** (and uses `docs/**` inventories when present)

This skill exists to prevent “hand-wavy” implementation plans and reduce drift between phase intent and repo reality.

---

## When to Use

Use this skill when:

# Skill: Browser Walkthrough

Use available Playwright MCP/browser tools to exercise and observe a browser journey. This skill does not install, provision, or configure Playwright and does not create a browser-specific persona.

## Modes and Role Routing

Select one mode before using browser tools. Existing personas remain defined by the kind of delegation:

1. **Automated browser acceptance — Implementer-owned**
   - Use during approved `execute-work-package` EXECUTE work when browser behavior is part of implementation verification.
   - Keep the approved Blueprint, targeted-then-broad verification sequence, and final verify command authoritative.
   - Exercise the acceptance journey autonomously and return evidence through the execution digest.
2. **Agent-observed walkthrough — Delegate-owned**
   - Use when an agent must inspect, explain, or evaluate an existing browser journey without owning implementation.

# Skill: Create Plan

## What This Skill Does


Creates a complete **plan** with the artifacts required to execute work in phases. This documentation shall serve Agents and Humans when working in consecutive sessions with the project:

1. **Plan** (`plans/<name>/plan.md`) - Problem/context, target outcome, guiding decisions, requirements, DoD, phases overview
2. **Phases** (`plans/<name>/phases/phase-N.md`) - Scope definition per phase (what/why)
3. **Todo List** (`plans/<name>/todo.md`) - Trackable items with status

This skill intentionally does **not** author per-phase implementation plans (`plans/<name>/implementation/phase-N-impl.md`).

Default next step (second pass): use `author-and-verify-implementation-plan` to author/verify the per-phase implementation plan against current repo reality.

# Skill: Delegate Analysis

Use one of the following modes. The primary should name the mode, scope, and question explicitly.

## Modes

### `code-exploration`

- Orient with file search, then read only the key files.
- Trace dependencies one level further only when needed.
- Return findings with concrete file paths and symbols.

### `targeted-reading`

# Skill: Execute Work Package

This skill standardizes **execution/implementation** once planning is gated.

It is a small, repeatable protocol:

1) **BLUEPRINT**: Subagent returns an **Execution Blueprint** (step list)
2) **GATE**: Primary approves (primary-internal)
3) **EXECUTE**: Subagent implements and verifies (same `task_id`)
4) **DIGEST**: Subagent returns a compact digest (no raw logs/diffs)

This skill deliberately **does not** create new persistent artifacts in `docs/` or `plans/`.

---

# Skill: Generate Documentation

## What This Skill Does

Creates structured project documentation from an existing codebase. This documentation shall serve Agents and Humans when working in consecutive sessions with the project.

Produces three artifact types:

1. **Project Overview** (`docs/overview.md`) - High-level architecture, module listing, feature listing
2. **Module Documentation** (`docs/modules/<name>.md`) - Overview + exhaustive inventories (files/dirs + symbols)
3. **Feature Documentation** (`docs/features/<name>.md`) - How features work, with implementation references

## When to Use

# Skill: Generate Handover

## What This Skill Does

This documentation shall serve Agents and Humans when working in consecutive sessions with the project.
Creates a session handover document (`plans/<name>/handovers/session-<date>.md`) that captures everything a new session needs to continue work seamlessly:

- What was accomplished in this session
- What is in progress (interrupted work)
- Key decisions made and their rationale
- Current state of modified files
- Blockers and issues discovered
- Concrete next steps
- Context that would be lost without the handover

# Skill: Report Environment Issue

Capture issues that are outside the current work package's control, so recurring environment friction becomes visible and can be improved over time.

## When to Use

Use when work is blocked or degraded by the environment rather than by the product code or gated scope, for example:

- missing tool, binary, permission, or credential
- sandbox, network, proxy, or filesystem restriction
- installer, path, symlink, or harness configuration problem
- tool, MCP, or browser provider failure or flakiness
- provider, model, or runtime constraint

# Skill: Resume Plan

## What This Skill Does

Bridges the gap between planning artifacts and implementation. When a new session starts and the agent needs to continue work on an existing plan, this skill:

1. **Finds** the active plan and identifies the current phase
2. **Reads** all relevant artifacts in the correct order (context bootstrap)
3. **Validates** that prerequisites for the current phase are met
4. **Presents** a concise briefing to the agent/user: what to do, where to look, what was decided
5. **Prepares** the todo list as the working entry point

## Why This Skill Exists

# Skill: Review Fix

This skill provides **context-preserving defect remediation**: apply explicitly accepted, evidence-backed fixes using the eligible existing session that produced the review or diagnosis. A review artifact is one supported finding source, not a prerequisite.

The point of preserving context is to reuse already-secured evidence, not collect it again. Related fixes may span files, call sites, and tests within the accepted objective. Reuse depends on correct and sufficient retained context/output, not the source workflow's mode or fix size.

## When to Use

Use after:

- `review-implementation-plan` identifies corrections to an implementation plan.
- `review-implementation` identifies code, test, configuration, or integration corrections.
- An analysis digest/message identifies a concrete defect and its diagnosis.
- An Implementer digest/message identifies a concrete defect of the same completed work package.

# Skill: Review Implementation

This skill provides an **independent quality gate** for completed implementations executed via `execute-work-package`.

A fresh reviewer (with no implementation context) evaluates the actual code changes against the plan, acceptance criteria, and coding standards. The review is persisted as a plan artifact.

---

## When to Use

Use this skill when:

- A phase has been implemented via `execute-work-package` and you want to validate before committing/merging.
- You want to verify that acceptance criteria are actually met (not just claimed).

# Skill: Review Implementation Plan

This skill provides an **independent quality gate** for implementation plans authored via `author-and-verify-implementation-plan`.

A reviewer fresh from the authoring context evaluates one implementation plan or an ordered batch against phase scope, existing code, and actionability criteria. Fresh independence does not mean starting a cold reviewer for every phase. Each review remains a per-phase plan artifact.

---

## When to Use

Use this skill when:

- An implementation plan has been authored/verified and you want to validate it before execution.
- Multiple implementation plans have been authored sequentially and should be reviewed together as a dependency-ordered batch.

# Skill: Review Plan

This skill provides an **independent quality gate** for plans created via `create-plan`.

A fresh reviewer (with no authoring context) evaluates the plan against structured criteria. The review is persisted as a plan artifact for traceability.

---

## When to Use

Use this skill when:

- A plan has been created via `create-plan` and you want to validate it before proceeding.
- You want a second opinion on plan quality (scope clarity, DoD, testing strategy, etc.).

# Skill: Update Documentation

## What This Skill Does

Updates existing project documentation to reflect code changes. Handles:

- Detecting which documentation is affected by recent changes
- Updating module documentation (symbols, structure, data flow)
- Updating feature documentation (new behavior, changed flows)
- Updating the project overview (new modules, changed architecture)
- Ensuring cross-references remain valid

## When to Use

# Skill: Update Plan

## What This Skill Does

Keeps planning artifacts synchronized with actual progress:

- Updates todo items (mark done, add new items, note blockers)
- Updates phase status (pending → in_progress → completed)
- Updates plan status and changelog
- Updates implementation plan if approach changed during work
- Prepares for next phase when current phase completes

## When to Use