corp-v1-channel-kanban-3darch/SKILL.md

---
name: corp-v1-channel-kanban
description: "Use when operating or synchronizing a Corp v1 project's Kanban channel. Maintains the project Kanban Board and Focus views across Epic, Feature, and task state; correlates all five same-project channels; and records human approval before tasks enter Delivery's executable InBacklog queue."
version: 1.1.0
author: Hermes Agent
license: MIT
metadata:
  hermes:
    tags: [corp-v1, discord, channel, kanban, board, focus, synchronization]
    related_skills: [corp-v1-steering-committee, home-v1-discord, documentation-docusaurus]
---

# Corp v1 Kanban Channel

## Overview

This skill owns flow visibility and task-readiness coordination for a Corp v1 project's `kanban` channel. It monitors the five same-project channels—`general`, `architecture`, `kanban`, `delivery`, and `releases`—and maintains the project documentation's top-level **Kanban** area.

Kanban does not replace product scope, architecture, implementation, or release ownership. General owns Epics and Features; Architecture owns requirements, design, task decomposition, dependencies, implementation approval, and version allocation; Kanban exposes flow and obtains human approval for ready tasks to enter Focus `InBacklog`; Delivery executes those approved tasks; Releases owns release readiness and controlled release preparation.

Load the global `documentation-docusaurus` skill from `https://gitea.lego-cloud.eu/home-v1-skills-code-agent/documentation-docusaurus` before changing documentation structure, navigation, Markdown/MDX, Docusaurus configuration, or builds.

## When to Use

Use this skill when:

- operating in `corp-v1-<code>-kanban`;
- running the recurring synchronization job mapped to that channel;
- maintaining Board or Focus documentation;
- reconciling Epic, Feature, and task status across project channels;
- identifying work that is blocked, stale, ready for prioritization, in progress, or awaiting release;
- preparing a task-readiness proposal for a human team member;
- recording a human decision that moves a task into Focus `InBacklog`.

Do not use it to approve tasks autonomously, redesign architecture, implement code, merge, release, deploy, or alter another project's board.

## Approved Information Boundary

Inspect only:

```text
corp-v1-<code>-general
corp-v1-<code>-architecture
corp-v1-<code>-kanban
corp-v1-<code>-delivery
corp-v1-<code>-releases
```

Read enough mapped-channel history to avoid duplicates and only relevant new activity from the other four channels. Never inspect or correlate another project's channels.

## Human Approval Gate

A task may enter Focus `InBacklog` only after a human team member explicitly approves that exact task as ready for Focus. Hermes may assess readiness, identify dependencies, prepare a recommendation, and record the human decision; Hermes may not approve its own recommendation or infer approval from silence.

Before proposing a task for Focus `InBacklog`, verify:

- stable task ID and parent Feature/Epic;
- the Feature has explicit human `Approved for Implementation` evidence;
- linked FR/NFR, architecture, ADR, and acceptance evidence exist;
- task dependencies are complete or explicitly satisfied;
- owner or required delivery capability is known;
- target version and sequencing constraints are documented;
- no unresolved blocker makes the task non-executable.

Record approver identity, decision evidence, date, resulting status, and any conditions. Delivery may start implementation only when both the Feature implementation gate and task Focus `InBacklog` gate are satisfied.

## Kanban Documentation Contract

Every project documentation site must expose **Kanban** as a top-level navigation item immediately **after Architecture**. Kanban must be a dedicated documentation area with its own sidebar:

```text
Board
Focus
```

### Board

Board provides a visual board of all unfinished Epics and Features grouped into exactly these flow columns:

1. `InIdeation`
2. `InBacklog`
3. `InProgress`
4. `ToBeReleased`

Each card must link to its authoritative Scope record and show at least ID, title, type, status, owner when known, target version when known, and blocking dependency when material. Completed, Done, Released, Rejected, Cancelled, or otherwise terminal Epics and Features must not appear on Board. Preserve their history in authoritative registries; hiding terminal work from Board is not deletion.

Board statuses mean:

- `InIdeation` — proposed or being refined; not approved for executable backlog.
- `InBacklog` — approved and eligible for prioritized work, subject to lower-level gates and dependencies.
- `InProgress` — active solution or implementation work exists.
- `ToBeReleased` — implementation is complete enough for release readiness; release approval and execution remain separate.

If source lifecycle states are more detailed, maintain an explicit deterministic mapping to these four board states. Never change authoritative approval history merely to simplify Board display.

### Focus

Focus shows only current work at Epic, Feature, and task level whose flow state is:

- `InBacklog`
- `InProgress`
- `ToBeReleased`

Focus excludes `InIdeation` and all terminal work. Organize Focus by flow state and preserve hierarchy:

```text
Epic
  Feature
    Task
```

Every item links to its authoritative record and shows ID, title, owner, dependency/blocker, target version, current evidence date, and status. A Feature or Epic may appear because descendant work is focused even when its own aggregate state is derived; label derived states clearly.

Tasks appear in Focus `InBacklog` only with explicit human approval evidence from the Kanban channel or authoritative documentation. A task moves to `InProgress` from verified Delivery evidence and to `ToBeReleased` only when implementation evidence and release handoff criteria are satisfied. Kanban reflects evidence; it does not fabricate progress.

## State Reconciliation

Use authoritative ownership:

- Epic/Feature identity and product status → Scope maintained by General;
- requirements, architecture, task definitions/dependencies, implementation approval, version allocation → Architecture;
- Focus admission decision → Kanban human decision;
- task execution progress and completion evidence → Delivery;
- release readiness, released state, and post-release outcome → Releases.

When sources conflict, do not choose silently. Mark the card as blocked or inconsistent, link both sources, and route the contradiction to the owning channel.

## Proactive Iteration Requirement

Every iteration must materially improve one useful, evidence-based Kanban artifact when possible: reconcile state, remove terminal cards from Board, repair links, expose a blocker, update hierarchy, prepare a task-readiness package, record a human Focus decision, or improve stale ownership/dependency/version evidence. Never create filler or autonomously advance approval-gated state.

If no task is ready, document the exact dependency or approval gate preventing Focus admission. Stay silent only when there is no substantive change and no useful maintenance action.

## Synchronization Workflow

1. Confirm the exact project code and five approved channel IDs.
2. Read new messages from the other four channels and enough Kanban history to avoid duplicates.
3. Fetch authoritative Scope, Architecture, Delivery, and Releases records.
4. Separate verified facts, human decisions, proposals, derived state, blockers, and contradictions.
5. Reconcile Board and Focus while preserving ownership and links.
6. Remove terminal Epic/Feature cards from Board and terminal items from Focus without deleting history.
7. Prepare task-readiness proposals; move a task to Focus `InBacklog` only from explicit human approval evidence.
8. Validate menu order, dedicated sidebar, allowed states, exclusion rules, hierarchy, links, and documentation build.
9. Push through the approved workflow and verify remote artifact and exact-SHA CI when configured.
10. Post one concise update with changed artifacts, task-admission decisions or gates, and exact evidence.

## Authority and Escalation

May autonomously:

- read and correlate the five same-project channels;
- maintain Board and Focus from verified authoritative state;
- calculate derived aggregate states when labeled;
- remove terminal work from active views while preserving history;
- prepare task-readiness recommendations;
- record explicit human decisions;
- run read-only and documentation-validation checks.

Requires human approval for:

- moving any task into Focus `InBacklog`;
- changing Epic/Feature approval or scope;
- approving implementation or final version allocation;
- overriding dependencies or blockers;
- merging, releasing, deploying, or changing architecture;
- secrets, permissions, costs, destructive, irreversible, or external actions.

## Evidence Requirements

Include exact project documentation paths, item IDs, source links, human decision message IDs or records, commits, remote readback, CI task/run IDs when configured, and any unresolved contradiction. Clearly label derived board state and proposals.

## Common Pitfalls

1. Treating Kanban as a second source of truth for Scope or Architecture.
2. Moving tasks to `InBacklog` without explicit human approval.
3. Showing completed or released Epics/Features on Board.
4. Showing `InIdeation` or terminal work in Focus.
5. Flattening Focus so task ancestry and dependencies are lost.
6. Treating `ToBeReleased` as release authorization.
7. Starting Delivery from Feature approval alone without task Focus admission.
8. Hiding contradictions instead of routing them to the owning channel.
9. Inspecting another project's channels.
10. Posting passive status when safe Board/Focus maintenance is possible.

## Verification Checklist

- [ ] Only the five same-project channels were inspected.
- [ ] Kanban appears immediately after Architecture and has its own Board/Focus sidebar.
- [ ] Board uses only `InIdeation`, `InBacklog`, `InProgress`, and `ToBeReleased`.
- [ ] Board contains only unfinished Epics and Features.
- [ ] Focus contains only `InBacklog`, `InProgress`, and `ToBeReleased` Epic/Feature/task hierarchy.
- [ ] Every card/item links to an authoritative record and displays current status.
- [ ] Every Focus `InBacklog` task has explicit human approval evidence.
- [ ] Feature implementation approval, task dependencies, and version constraints were verified.
- [ ] Derived states are labeled and contradictions are escalated.
- [ ] Documentation/navigation/link/build and remote readback checks passed.
- [ ] Completed work includes exact evidence.