omad-scope

name	omad-scope
description	Resolve OMAD project and feature artifact scope. Use before any /omad-* workflow that reads or writes durable project documentation.

OMAD Scope And Tracking

Use this skill before any OMAD lifecycle phase that reads or writes artifacts. The purpose is to keep work belonging to different projects and features separate, and to make progress auditable.

Project boundary

1. project_root is the active opencode project/worktree root, not the directory containing OMAD commands or skills.
2. Resolve every relative project path from project_root.
3. Never write a consuming project's artifacts into the OMAD configuration repository or skill directory.
4. Inspect AGENTS.md, project-context.md, and existing project conventions before selecting an output directory.

If the active project root is not the project the user means, stop and ask for the project path. Do not guess from the OMAD repository name.

Feature boundary

Use a feature scope for work that can advance or complete independently. The user should pass a stable slug, for example:

/omad-align feature=linkedin-promotion Define the article initiative

Resolve the feature root as:

feature_root = project_root/docs/features/<feature-slug>

If the project already has an established feature/work-item directory, preserve it and record the chosen path in the feature manifest. Do not move existing artifacts automatically.

When no feature is supplied, use project scope only for genuinely project-wide work. Do not silently put feature-specific material in shared docs/ files. For ambiguous requests, ask the user to select or name a feature.

Feature manifest

Create or update <feature_root>/feature.yaml before producing durable feature artifacts. Keep it small and machine-readable:

id: linkedin-promotion
name: LinkedIn promotion article
status: active
phase: discover
started: 2026-08-23
last_updated: 2026-08-23
artifacts_root: docs/features/linkedin-promotion
phases:
  align: complete
  discover: in-progress
  shape: not-started
  design: not-started
  decompose: not-started
  plan: not-started
  build: not-started
  verify: not-started
  learn: not-started
acceptance:
  total: 0
  done: 0
  blocking: 0
stories:
  total: 0
  done: 0

Allowed feature statuses are proposed, active, blocked, done, and archived. Allowed phase statuses are not-started, in-progress, complete, blocked, and skipped.

Completeness rules

Do not invent a percentage before acceptance criteria exist. Report progress as counts and phase state:

• Before decomposition: phase progress only; acceptance completeness is n/a.
• After decomposition: done / total stories and acceptance criteria.
• A feature is done only when all required acceptance criteria are done, all required stories are done, verification has no blocking findings, and the human checkpoint is approved.
• A blocked feature remains blocked even if its latest phase has artifacts.
• A skipped phase requires a documented rationale in the feature manifest or a decision artifact.

Update the manifest at every phase handoff. Keep evidence in the feature root; the manifest is the index, not a substitute for requirements, stories, or verification records.

Every lifecycle phase must end with a visible handoff containing:

Recommended next phase: <phase> (<command with the project/feature scope>)

If the current phase is blocked, recommend the phase that resolves the blocker. If the completion rules are satisfied, report Recommended next phase: None (feature complete) instead of inventing more work.

Feature artifact layout

docs/features/<feature-slug>/
├── feature.yaml
├── brief.md
├── research/<run-slug>/
├── prfaq.md
├── product-requirements.md
├── decisions/
├── ux/ux-spec.md
├── architecture.md
├── adr/
├── epics/
├── stories/
├── traceability.md
├── sprint-status.yaml
├── sprint-plan.md
├── dependencies.md
├── reviews/
├── verification/
└── retrospectives/

Source code and tests remain in the project root's normal locations. Link them from feature stories and verification artifacts rather than copying them into the documentation workspace.

Portfolio index

Maintain docs/features/index.md as a concise table of all non-archived features. Each row must link to its feature.yaml and show status, current phase, acceptance progress, story progress, and blocking count. Lifecycle workflows should keep this view synchronized with manifests and feature sprint files.