channel-delivery-skic/SKILL.md

name, description, version, author, license, metadata

name	description	version	author	license	metadata
channel-delivery-skic	Use when operating or synchronizing a Corp v1 project's delivery channel. Drives coding, unit testing, build and continuous-integration health, attempts safe evidence-based fixes, escalates requirement or architecture contradictions, and maintains Ways of Working and Engineering documentation.	1.18.0	Hermes Agent	MIT	hermes tags related_skills corp-v1 discord channel delivery coding testing ci channel-board-skic discord documentation-docusaurus-global glossary-skic development-durable-wave-execution development-gates development-integrity development-method-ttd development-branching-strategy development-monorepo-pnpm development-scripts development-gitops-argo-cd-home-gondor-v1 ci-runtime-skic delivery-docs status-reporting-skic development-security development-security-skic develop-monorepo-pnpm-app-skic develop-monorepo-pnpm-package-skic

SKIC Delivery Channel Reference

Hermes Kanban direct-link contract

Whenever a response mentions a Hermes Kanban board, initiative, card, or task, it must include a direct dashboard link in the form [descriptive board label](<dashboard-public-url>/kanban?board=<board-slug>). Resolve the dashboard public URL and exact board slug before reporting; never provide only a board name, slug, card count, “visible cards,” or “available in the dashboard.” If no task-specific deep link exists, link the board and include the exact task ID or title in the same statement. Project-adopted skills must replace this generic form with their verified project board URL.

Canonical Scope Status Vocabulary

Before reporting or changing lifecycle status, load status-and-reporting.md and read the project's current Ways of Working Scope page. That binding loads status-reporting-skic for canonical vocabulary and requested wave format; local Task gates retain gate codes, and development-integrity owns checkpoint claims. Delivery claims only an exact READY_FOR_DELIVERY Task into IN_PROGRESS, without a second Focus admission. BLOCKED remains a separate flag; merge/green CI is not DONE, and releasable application work normally ends Delivery at TO_BE_RELEASED.

This skill owns delivery health for a Corp v1 project. It monitors the project's general, scope, architecture, ui-ux, kanban, delivery, uat, and releases channels and implements only tasks whose parent Feature has explicit human Approved for Implementation evidence and whose exact Task status is READY_FOR_DELIVERY. That status is the Focus-admitted pickup handoff; no separate post-status admission gate exists.

Its scope includes coding, unit testing, builds, continuous integration, review readiness, delivery blockers, and maintenance of the project documentation's Ways of Working and Engineering areas.

Delivery owns application unit testing only plus static/build-time validation of the application artifacts it publishes: Dockerfiles, image/container contracts, publication records/workflows, and Helm chart linting/rendering/packaging. The project's standalone E2E repository under its UAT channel owns every functional non-unit suite and its fixtures, configuration, runner, and evidence: integration, browser, E2E, acceptance, security-boundary, performance, runtime-budget, smoke, regression, and deployed-environment testing. Delivery must not maintain or execute functional non-unit suites in the application repository. E2E must not install Helm or build/publish application images. It consumes UAT failures as defect evidence, fixes application code with unit-first TTD, and hands the corrected deployed tuple back to UAT.

Before login or credential-bearing operations, load development-security-skic and development-security; stop if the authoritative Board policy cannot load. These owners govern the non-secret operation binding and exposure preflight, not new access authority.

Before branch or script work, load the generic development-branching-strategy / development-scripts base alongside the named project overlay; inherit only non-conflicting mechanics.

Development Skill Routing

Before changing an application's configuration, startup/readiness/shutdown contract or integration boundaries, load develop-monorepo-pnpm-app-skic. Before changing a shared package's public API/exports, dependency boundary, version compatibility or published contents, load develop-monorepo-pnpm-package-skic. For a change crossing both boundaries, load both and identify producer/consumer responsibilities; do not infer impact solely from a directory name.

These are draft review aids, not approved standards. Contributor input and project adoption approval are separate from source publication or this routing. Use them to identify questions and evidence against the Task's already approved contract; do not enforce a proposed convention without the relevant human owner's approval. They complement development-monorepo-pnpm, which continues to own workspace/build/package-manager mechanics. Review, CI, one implementation worker per Task, deployment and test-ownership gates remain unchanged; loading a draft grants no execution authority. Authoritative drafts: https://gitea.lego-cloud.eu/skic-skills/develop-monorepo-pnpm-app-skic and https://gitea.lego-cloud.eu/skic-skills/develop-monorepo-pnpm-package-skic.

Before CI/runtime/repair work load ci-runtime-skic; before status/blocker reports load status-reporting-skic; before documentation load delivery-docs; before authenticated operations load development-security-skic and development-security. Supply the concrete bindings in the matching local reference. Authoritative helper repositories: https://gitea.lego-cloud.eu/skic-skills/ci-runtime-skic, https://gitea.lego-cloud.eu/global-skills/delivery-docs, https://gitea.lego-cloud.eu/skic-skills/status-reporting-skic, https://gitea.lego-cloud.eu/global-skills/development-security and https://gitea.lego-cloud.eu/skic-skills/development-security-skic.

This channel skill owns delivery governance and project-channel coordination. Reusable engineering procedures belong to the global development-* skills below; load the matching skill before the action and treat a project-adopted variant as the project-specific overlay when one exists.

Work	Required reusable skill	Authoritative Gitea source
dependency-wave claim, continuation, recovery, and closure	development-durable-wave-execution	https://gitea.lego-cloud.eu/global-skills/development-durable-wave-execution
immutable candidate review, exact-head CI, merge, and integration gates	development-gates	https://gitea.lego-cloud.eu/global-skills/development-gates
delivery, CI, blocker, and completion reporting	development-integrity	https://gitea.lego-cloud.eu/global-skills/development-integrity
behavior changes, defect fixes, and refactoring	development-method-ttd	https://gitea.lego-cloud.eu/global-skills/development-method-ttd
branch naming, worktrees, PR topology, and base synchronization	development-branching-strategy	https://gitea.lego-cloud.eu/global-skills/development-branching-strategy
pnpm/TypeScript monorepo implementation	development-monorepo-pnpm	https://gitea.lego-cloud.eu/global-skills/development-monorepo-pnpm
Taskfile, .scripts/, shell wrappers, environment validation, and Devbox	development-scripts	https://gitea.lego-cloud.eu/global-skills/development-scripts
Gondor Argo CD template, rendered desired state, and repository connection	development-gitops-argo-cd-home-gondor-v1	https://gitea.lego-cloud.eu/home-gondor-v1-skills/development-gitops-argo-cd-home-gondor-v1

The channel skill may narrow authority, lifecycle, workspace, visibility, handoff, and evidence requirements. Project bindings must not contradict global skills. The global development-gates contract governs independent review, review-before-push ordering, candidate/base identity and CI. Project overlays supply branch naming, human ownership, one implementation worker, visibility and existing merge/deployment/release authority without weakening these gates; inherit only non-conflicting mechanics. It must not restate generic RED–GREEN–REFACTOR mechanics, shell-module layouts, pnpm workspace conventions, ordinary Git branching mechanics, exact-head gate algorithms, or Argo CD authoring procedures. Improve those reusable skills at their linked sources and keep only the project/channel overlay here.

Implementation Entry Gate

Before starting or continuing Feature implementation, verify in project documentation:

• Feature ID and parent Epic;
• explicit human Approved for Implementation evidence;
• linked FRs/NFRs and accepted solution/ADR context;
• task breakdown and dependencies;
• target version and status;
• acceptance evidence expected from delivery.
• exact Task READY_FOR_DELIVERY evidence, which itself records human Kanban Focus admission.

Hermes cannot approve a Feature for implementation or move a Task to READY_FOR_DELIVERY. Once that exact state exists, Hermes must not require a second Focus-admission decision; Delivery claims the Task by moving it to IN_PROGRESS.

Immediate Wave-Start Visibility Gate

Load development-durable-wave-execution, development-branching-strategy, and development-gates before claiming or starting a wave. Those skills own durable whole-wave claims, branch/worktree mechanics, immutable candidate identity, and exact-head review/CI behavior.

The Corp v1 overlay is narrower: every Task requires a dedicated visible branch and PR before substantive coding, and that PR must carry the Task ID, wave, planned scope, current state, exact head, and governed test base. If Gitea requires a delta, use an empty kickoff commit rather than a filler file. Read the branch and PR back before editing. One Task maps to one branch and PR unless Architecture or the human owner explicitly approves another topology.

Approved Information Boundary

Inspect only the project's eight channels:

<code>-general
<code>-scope
<code>-architecture
<code>-ui-ux
<code>-kanban
<code>-delivery
<code>-uat
<code>-releases

Use enough delivery history to avoid duplicate work and only relevant new activity from the other channels. Never inspect another project.

Delivery Responsibilities

Coding

Load the project-adopted engineering skill for the repository stack before editing. development-monorepo-pnpm owns pnpm/TypeScript workspace implementation, while development-scripts owns Taskfile, .scripts/, shell-wrapper, environment-validation, and Devbox conventions. Delivery adds only the approved requirement/Task boundary, traceability, and prohibition on unrelated refactoring or fabricated evidence.

Unit testing

Load development-method-ttd for every behavior change, defect fix, or refactor. It owns RED–GREEN–REFACTOR mechanics, focused-test progression, and test-design anti-patterns. Delivery requires unit tests to map to approved acceptance evidence and retains their real commands/results. UAT owns every functional non-unit test required to prove that evidence outside the unit boundary; Delivery retains build-time image/container/Helm artifact validation.

Build and continuous integration

Load development-gates before candidate review, remote CI, merge, or integration validation, and load development-integrity before reporting their status. These skills own exact-head identity, attempt integrity, base-drift handling, candidate-versus-integration separation, and honest checkpoint wording.

Delivery still monitors repository-specific compile/type, unit-test, lint/format, dependency, packaging, workflow, image/container contract, Helm chart, and artifact-publication failures. Functional non-unit browser, integration, performance, security-boundary, and acceptance failures arrive as UAT evidence and are routed back for application remediation. A green local build is never remote CI evidence.

Before base-image work, load ci-runtime-skic and the project image binding.

Failure-Repair Workflow

Load failure-and-documentation.md when a build or CI failure is observed. It binds ci-runtime-skic for safe repair and status-reporting-skic for blocker routing, with existing gate owners for exact-head verification. Keep repairable failures in the same Task/gate; pause only for the documented external, authority, decision or safety blocker. Never guess requirements or Architecture, weaken a gate or treat a blocker as passing.

Before changing Ways of Working or Engineering, load delivery-docs and the concrete documentation bindings.

UI/UX Coordination

For frontend-affecting work, Delivery requires the approved UI/UX design package, exact Penpot links, responsive/state behavior, accessibility criteria, and mapped tasks. Delivery reports implementation deviations to UI/UX with concrete evidence rather than silently changing the approved experience.

Synchronization Workflow

1. Read new same-project activity and enough delivery history to avoid duplicates.
2. Verify human Approved for Implementation evidence, exact Task READY_FOR_DELIVERY state, task dependencies, and target version before task work.
3. Identify executable tasks, CI failures, blockers, requirements/ADR implications, and documentation drift.
4. Load all applicable project engineering skills.
5. Complete at least one useful safe activity when an authorized path exists; otherwise document and route the exact blocker.
6. Escalate uncertainty or contradiction rather than selecting direction.
7. Verify local and remote results and update task/Feature progress in project documentation.
8. Maintain Ways of Working and Engineering pages when durable practice changed.
9. Post a concise update with work completed, evidence, blockers, and required decisions.

Do not silently choose between contradictory requirements or Architecture decisions, approve releases, or bypass review/branch protections.

Authority and Escalation

May autonomously:

• run unit tests, builds, Delivery artifact validations, and read-only checks; functional non-unit suites run through UAT;
• repair clear CI/build defects within authorized scope;
• add unit tests for an approved behavior and request non-unit coverage from UAT;
• maintain accurate delivery documentation;
• prepare branches/commits/PRs where the project workflow authorizes it.

Requires approval before:

• changing requirements or architecture to make tests pass;
• merging protected changes;
• deploying or releasing;
• changing secrets, permissions, costs, external services, or destructive resources;
• suppressing required quality/security gates.

Evidence Requirements

Include repository, branch, commit SHA, changed paths, commands, local results, CI run/task IDs and status, and relevant requirement/ADR references. Report blockers honestly.

Mined Project-Adoption Improvements

Review provenance and exclusions: AeroSim lessons review.

Dedicated Project Channel Workspace

Every project adoption must bind this channel to a dedicated local workspace under the active working root. Keep clones, worktrees, plans, reports, screenshots, generated artifacts, retained logs, and channel inputs inside that channel root. Use run-unique or task-specific children under workspace/; keep durable project truth in approved repositories. A local folder boundary organizes execution only—it neither broadens authority nor replaces remote evidence. Delivery adoptions should additionally use a channel-level cache/ for reusable pinned toolchains and dependencies, while keeping Task evidence isolated by Task.

Decision-point references

Before selecting/continuing/reviewing/merging/handoff load Task gates; before branch/PR work load repository entry. Before commands, CI, images or resource work load runtime bindings; before failure repair/docs load failure/docs bindings. Before planning changes load planning reconciliation; on failed/resumed gates load exception checks.

Project adoptions may narrow implementation execution to a main session or prohibit implementation subagents/cron. Preserve that overlay without prohibiting independent read-only review; this reference grants no account recovery, permission, merge, release or deployment authority. Keep exactly one Task active unless explicit project authority defines another safe model. Freeze Task/branch/PR identity and retain exact-head review under the ordered gates.

When selectable controls are needed, provide complete options and their trade-offs, recommended first; follow the active interface's option-rendering contract without hiding consequences.

Before final Delivery handoff, load final verification and check the retained evidence against the ordered Task gates; do not repeat the checklist here.

Canonical naming and compatibility

• Canonical installed and repository name: channel-delivery-skic.
• Source: https://gitea.lego-cloud.eu/home-v1-skills-code-agent/channel-delivery-skic.
• Previous name: corp-v1-channel-delivery; retained locally only as a compatibility alias. New guidance and presentations use the canonical name.
• Naming-only migration authorized by RootAtSkic in presentation message 1562523679223578705. Repository ID, history, support files, project authority and organization ownership are preserved.
• This is a reusable central reference, not a new shared Discord channel. Project adoptions use channel-delivery-skic-<code> and remain separately owned.
• Current project channel: <code>-delivery inside skic-<code>.

Channel workspace standard

Load channel-workspace-organization for channel setup, file placement, and authorized workspace migration. Canonical standard: https://gitea.lego-cloud.eu/global-skills/channel-workspace-organization . Follow that shared policy rather than duplicating it here. Existing workspace bindings below remain current until an authorized migration is completed and verified; this reference alone does not relocate files or change bindings.