corp-v1-channel-kanban/SKILL.md

name, description, version, author, license, metadata

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

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 seven same-project channels—general, scope, architecture, ui-ux, 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. Scope owns Roadmap, Ideas, 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.

Load the global corp-v1--glossary skill from https://gitea.lego-cloud.eu/home-v1-skills-code-agent/corp-v1--glossary whenever project documentation needs to define or explain a reusable term. Maintain one canonical definition in the project's final top-level Glossary area and link to it from the owning domain page; do not duplicate glossary-style explanations across channel documentation.

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:

corp-v1-<code>-general
corp-v1-<code>-scope
corp-v1-<code>-architecture
corp-v1-<code>-ui-ux
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 six 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:

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:

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.

React Flow visualization contract

When Kanban documentation contains relationship-dense execution data, deliberately consider a read-only @xyflow/react view after loading documentation-docusaurus and its React Flow guidance. React Flow may supplement—but never replace—the governed Board columns, Focus hierarchy, and semantic tables. Appropriate Kanban views include:

• Epic-to-Feature-to-task Focus hierarchy;
• task dependencies and blocking relationships;
• cross-item critical path only when it is explicitly derivable from approved canonical dependencies and sequencing evidence;
• governed flow-state transitions and bottlenecks;
• execution-to-governance contradictions, with links to both authoritative sources;
• version and release dependency views supported by canonical allocation and release evidence.

The four-column Board remains the primary governed representation and normally stays semantic HTML. A small, empty, or simple Focus dataset should remain a table or hierarchy. Render a graph only when validated canonical YAML contains the required identities, relationships, states, and evidence and the visualization materially improves comprehension. Do not infer approval, Focus admission, hierarchy, dependencies, sequencing, progress, version allocation, release readiness, or critical path.

Use one typed, deterministic adapter and the same selector to produce stable nodes, edges, legends, validation warnings, and an adjacent semantic table fallback. Generated graph data, coordinates, viewport state, and client state are derived presentation data, never a second source of truth. Preserve authority and relationship semantics: Scope identities, Architecture dependencies and implementation gates, Kanban Focus decisions, Delivery execution, and Releases evidence must remain distinguishable.

Use Dagre for ordinary directed graphs and ELK only for complex or grouped graphs. Use Docusaurus BrowserOnly where client-only rendering is required, while keeping the semantic fallback server-renderable, searchable, linkable, and usable if JavaScript or hydration fails.

Documentation canvases are read-only. Disable mutation affordances, including nodesDraggable={false}, nodesConnectable={false}, connection creation, deletion, and accidental persistence. Preserve keyboard navigation, meaningful accessible labels and authoritative-record links, visible focus, non-color-only meaning, reduced-motion behavior, responsive controls, and sharp styling with border-radius: 0.

Acceptance requires canonical-YAML validation, graph/table parity from the same selector, stable deterministic output, missing-reference failure or explicit warning behavior, empty/loading/error states, keyboard and screen-reader checks, no-JavaScript fallback, production build, browser console/network health, and remote exact-head verification.

State Reconciliation

Use authoritative ownership:

• Epic/Feature identity and product status → Scope;
• 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.

UI/UX Coordination

For frontend-affecting tasks, Kanban includes the approved UI/UX design-package link and unresolved design dependencies in readiness evidence. UI/UX does not self-admit tasks to Focus; Kanban retains task-admission and flow ownership.

Synchronization Workflow

1. Confirm the exact project code and seven approved channel IDs.
2. Read new messages from the other six 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 seven 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 seven 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.
• When React Flow is used, its graph and semantic table share one canonical-YAML selector and pass accessibility, build, browser, and remote exact-head checks.
• Completed work includes exact evidence.