Contract for RIPDPI VPN deployment tracked work (portfolio tasks, bugs, epics, OpenSpec-backed changes) covering file locations, taskctl-only lifecycle, stable IDs, and prohibitions. Use for triage, review, or closing work, or whenever the rules themselves matter; narrower skills own creating, starting, implementing, and archiving.
Installs into .claude/skills of the current project.
Sponsors
SSkills DirectorySkills Directory
Is that skill safe to install?
SSkills DirectorySkills Directory
Know which skills are safe — weekly.
Are you the author of Repo Task Board?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/po4yka-repo-task-board)
---
name: repo-task-board
description: Contract for RIPDPI VPN deployment tracked work (portfolio tasks, bugs, epics, OpenSpec-backed changes) covering file locations, taskctl-only lifecycle, stable IDs, and prohibitions. Use for triage, review, or closing work, or whenever the rules themselves matter; narrower skills own creating, starting, implementing, and archiving.
---
# Repository task board
`docs/tasks/issues/*.md` is the portfolio source of truth. `docs/tasks/board.md` is generated. Execution lives in exactly one of:
- simple work: `docs/tasks/work/<TASK-ID>.md`;
- specification-driven work: `openspec/changes/<change>/tasks.md`.
For a missing active task query, follow `docs/tasks/README.md` section
**Find active work or terminal history**. Discover exact-ID candidates only in
the pinned integrated history and archive revision, then validate the covered
terminal transition and purge in a clean detached checkout of that endpoint,
using its own pinned tools as documented.
A candidate is not accepted terminal evidence; failed or incomplete validation
leaves it unresolved. Resolve any linked successor through current `taskctl show`.
Narrower skills own the individual steps: `mdtask-create` (new work), `mdtask-next` (pick and start), `sdd` (whether OpenSpec is required), `openspec-propose` / `openspec-apply-change` (plan and implement a change), `openspec-archive-change` (finalize), `mdtask` (execution checkboxes).
Use only `./taskctl` for lifecycle operations:
- inspect: `list`, `show`, `ready`, `graph`;
- create/start/update: `new`, `start`, `transition`, `steps`;
- validate: `verify`, `validate`, `generate-board`;
- complete: commit the task, execution, verification, and regenerated board in `review`; then `verify <task-id> --archive-ready`, `openspec archive <change>`, `close prepare <task-id> --outcome done --evidence "<summary>"`, commit, and later `close purge` in a separate commit. `main` is rebase-merge only, so these commits may share one pull request as separate commits; never squash lifecycle commits together locally, because the purge audit validates each transition as its own first-parent commit;
- drop: `close prepare <task-id> --outcome dropped --evidence "<summary>" --reason "<why>"` and commit the dropped record and its receipts. A linked OpenSpec change must then go through `./taskctl openspec archive <change>`, which archives a dropped change with `--skip-specs` so its deltas never reach the main specs; commit that archive. Removing the change instead is not an option: `close purge` refuses an active or unarchived change. Run `close purge` last and commit the deletion separately.
Stable IDs are area-prefixed with globally unique 16-digit numeric suffixes. Worktrees share a locked allocator reservation through the Git common directory; committed validation catches cross-clone collisions. Local references use stable IDs; cross-repository references use qualified IDs such as `po4yka/RIPDPI#TRN-...`. `blocked_by` is canonical; reverse `blocks` is derived locally or through `./taskctl federation`. OpenSpec-mandatory categories are listed in the `sdd` skill; high-risk work can never waive it. Never hand-edit the generated board, use direct upstream archive, pass `--no-validate`, close work without evidence, or delete a record before its terminal-state commit exists.
Before parallel agents write, record owned paths and serialized shared-file lanes in the execution file's `## Ownership` section. Implementation work uses a dedicated worktree.