| 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
project_root is the active opencode project/worktree root, not the
directory containing OMAD commands or skills.- Resolve every relative project path from
project_root.
- Never write a consuming project's artifacts into the OMAD configuration
repository or skill directory.
- 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.
