Delivery Skill Split — Review Draft
This is a review document only. aerosim_skills/ is untouched. Each section below is the full
draft text of one proposed skill, built from the current corp-v1-channel-delivery (SKILL.md +
its 7 references + test file) — not a summary of what would go there. Review here first; actual
file creation/edits happen only after you sign off on each skill's content.
Proposed skill and reference map
The skill view combines the seven-reference central draft below with mandatory preservation of all current AeroSim skill links. The reference-allocation view remains limited to the seven central source files; the two AeroSim-only references remain unchanged. Neither view implements or approves the split. Skill numbers match the summary table; placeholders remain explicitly marked.
Proposed skills and retained references
The layout follows the current reference map: retained central files on the left, the proposed AeroSim Delivery adoption in the centre, and all 27 proposed direct skill pointers on the right. Green label accents identify the 18 retained current links; blue label accents identify the nine additional central-draft pointers. This legend shows retention status, not body-versus-metadata usage. The disposition table specifies each current link's retained responsibility and the extracted skills' concrete load bindings.
Loading Proposed Delivery skills and retained references…
Browse source records, memberships, and relationships
Source groups
- References retained by skill 1 (ID:
refs) - Proposed AeroSim direct skill pointers (27) — 18 retained + 9 additions (ID:
skills)
| Skill | Meaning | Source membership |
|---|---|---|
task-delivery-gates.md (ID: ref-0) | Kept whole | Member of References retained by skill 1 (ID: refs) |
repository-entry-and-visibility.md (ID: ref-1) | Kept whole | Member of References retained by skill 1 (ID: refs) |
planning-artifact-reconciliation.md (ID: ref-2) | Kept whole | Member of References retained by skill 1 (ID: refs) |
common-pitfalls.md (ID: ref-3) | Trimmed: governance pitfalls | Member of References retained by skill 1 (ID: refs) |
1. corp-v1-channel-delivery-aerosim (ID: delivery) | Proposed adoption of thinned Delivery All current skill links retained | Source diagram root (ID: 1) |
corp-v1-main (ID: skill-0) | Retained current link — Delivery and security overlay | Member of Proposed AeroSim direct skill pointers (27) — 18 retained + 9 additions (ID: skills) |
corp-v1-channel-general-aerosim (ID: skill-1) | Retained current link — Delivery governance | Member of Proposed AeroSim direct skill pointers (27) — 18 retained + 9 additions (ID: skills) |
corp-v1-channel-releases-aerosim (ID: skill-2) | Retained current link — Delivery release handoff | Member of Proposed AeroSim direct skill pointers (27) — 18 retained + 9 additions (ID: skills) |
home-v1-discord (ID: skill-3) | Retained current link — Delivery channel operations | Member of Proposed AeroSim direct skill pointers (27) — 18 retained + 9 additions (ID: skills) |
documentation-docusaurus-aerosim (ID: skill-4) | Retained current link — delivery-docs → AeroSim documentation binding | Member of Proposed AeroSim direct skill pointers (27) — 18 retained + 9 additions (ID: skills) |
corp-v1-glossary (ID: skill-5) | Retained current link — delivery-docs → Corp v1 glossary binding | Member of Proposed AeroSim direct skill pointers (27) — 18 retained + 9 additions (ID: skills) |
self-hosted-service-account-recovery (ID: skill-6) | Retained current link — corp-v1-ci-runtime → recovery binding | Member of Proposed AeroSim direct skill pointers (27) — 18 retained + 9 additions (ID: skills) |
home-v1--truenas (ID: skill-7) | Retained current link — corp-v1-ci-runtime → platform-storage binding | Member of Proposed AeroSim direct skill pointers (27) — 18 retained + 9 additions (ID: skills) |
development-durable-wave-execution (ID: skill-8) | Retained current link — Delivery wave orchestration | Member of Proposed AeroSim direct skill pointers (27) — 18 retained + 9 additions (ID: skills) |
development-gates (ID: skill-9) | Retained current link — Delivery and corp-v1-ci-runtime | Member of Proposed AeroSim direct skill pointers (27) — 18 retained + 9 additions (ID: skills) |
development-integrity (ID: skill-10) | Retained current link — Delivery and corp-v1-status-reporting | Member of Proposed AeroSim direct skill pointers (27) — 18 retained + 9 additions (ID: skills) |
development-method-ttd (ID: skill-11) | Retained current link — Delivery coding and unit testing | Member of Proposed AeroSim direct skill pointers (27) — 18 retained + 9 additions (ID: skills) |
development-branching-strategy-aerosim (ID: skill-12) | Retained current link — Delivery → AeroSim branching overlay | Member of Proposed AeroSim direct skill pointers (27) — 18 retained + 9 additions (ID: skills) |
development-monorepo-pnpm (ID: skill-13) | 7. Unchanged external — retained current link | Member of Proposed AeroSim direct skill pointers (27) — 18 retained + 9 additions (ID: skills) |
development-scripts-aerosim (ID: skill-14) | Retained current link — Delivery → AeroSim script overlay | Member of Proposed AeroSim direct skill pointers (27) — 18 retained + 9 additions (ID: skills) |
devsecops-ci-cd-gitea (ID: skill-15) | Retained current link — corp-v1-ci-runtime → reusable pipeline mechanics | Member of Proposed AeroSim direct skill pointers (27) — 18 retained + 9 additions (ID: skills) |
devsecops-ci-cd-gitea-aerosim (ID: skill-16) | Retained current link — corp-v1-ci-runtime → AeroSim pipeline overlay | Member of Proposed AeroSim direct skill pointers (27) — 18 retained + 9 additions (ID: skills) |
development-gitops-argo-cd-gondor-v1 (ID: skill-17) | Retained current link — corp-v1-ci-runtime and Delivery GitOps work | Member of Proposed AeroSim direct skill pointers (27) — 18 retained + 9 additions (ID: skills) |
corp-v1-ci-runtime (ID: skill-18) | 2. New — extracted CI/runtime | Member of Proposed AeroSim direct skill pointers (27) — 18 retained + 9 additions (ID: skills) |
delivery-docs (ID: skill-19) | 3. New — global documentation | Member of Proposed AeroSim direct skill pointers (27) — 18 retained + 9 additions (ID: skills) |
corp-v1-status-reporting (ID: skill-20) | 4. New — extracted reporting | Member of Proposed AeroSim direct skill pointers (27) — 18 retained + 9 additions (ID: skills) |
development-security (ID: skill-21) | 5. New — global security | Member of Proposed AeroSim direct skill pointers (27) — 18 retained + 9 additions (ID: skills) |
corp-v1-development-security (ID: skill-22) | 6. New — Corp v1 overlay | Member of Proposed AeroSim direct skill pointers (27) — 18 retained + 9 additions (ID: skills) |
corp-v1-develop-monorepo-pnpm-app (ID: skill-23) | 8. Placeholder — not ready to publish | Member of Proposed AeroSim direct skill pointers (27) — 18 retained + 9 additions (ID: skills) |
corp-v1-develop-monorepo-pnpm-package (ID: skill-24) | 9. Placeholder — not ready to publish | Member of Proposed AeroSim direct skill pointers (27) — 18 retained + 9 additions (ID: skills) |
development-branching-strategy (ID: skill-25) | Additional generic base — AeroSim overlay retained | Member of Proposed AeroSim direct skill pointers (27) — 18 retained + 9 additions (ID: skills) |
development-scripts (ID: skill-26) | Additional generic base — AeroSim overlay retained | Member of Proposed AeroSim direct skill pointers (27) — 18 retained + 9 additions (ID: skills) |
- References retained by skill 1 (ID:
refs) → 1. corp-v1-channel-delivery-aerosim (ID:delivery) - 1. corp-v1-channel-delivery-aerosim (ID:
delivery) → Proposed AeroSim direct skill pointers (27) — 18 retained + 9 additions (ID:skills)
DRAFT ONLY — AeroSim Delivery dependency-preserving split
Left: four references retained in the central split draft; AeroSim-only references remain unchanged. Right: union of existing AeroSim dependencies and central proposal pointers. Generic bases supplement, never erase, project overlays. Full retained-link rationale and load bindings are in the page disposition table.
Reference content destinations
Arrows show where each original reference's content would belong. Repeated destination cards identify the same skill. Extracted content is not presented as a newly created reference file; the separately proposed final checklist is explicitly identified.
Loading Proposed Delivery reference content destinations…
Browse source records, memberships, and relationships
Source groups
- Proposed destinations (ID:
dest-0) - Proposed destinations (ID:
dest-1) - Proposed destination (ID:
dest-2) - Proposed destination (ID:
dest-3) - Proposed destination (ID:
dest-4) - Proposed destination (ID:
dest-5) - Proposed destination (ID:
dest-6) - Proposed destination (ID:
dest-7)
| Skill | Meaning | Source membership |
|---|---|---|
common-pitfalls.md (ID: source-0) | Source diagram root (ID: 1) | |
corp-v1-channel-delivery (ID: dest-0-0) | Gate / branch / PR pitfalls | Member of Proposed destinations (ID: dest-0) |
corp-v1-ci-runtime (ID: dest-0-1) | CI/runtime pitfalls | Member of Proposed destinations (ID: dest-0) |
delivery-docs (ID: dest-0-2) | Documentation pitfalls | Member of Proposed destinations (ID: dest-0) |
corp-v1-status-reporting (ID: dest-0-3) | Reporting pitfalls | Member of Proposed destinations (ID: dest-0) |
failure-and-documentation.md (ID: source-1) | Source diagram root (ID: 1) | |
corp-v1-ci-runtime (ID: dest-1-0) | Failure-repair mechanics | Member of Proposed destinations (ID: dest-1) |
delivery-docs (ID: dest-1-1) | Documentation ownership | Member of Proposed destinations (ID: dest-1) |
corp-v1-status-reporting (ID: dest-1-2) | Blocker routing | Member of Proposed destinations (ID: dest-1) |
runtime-and-ci.md (ID: source-2) | Source diagram root (ID: 1) | |
corp-v1-ci-runtime (ID: dest-2-0) | Build, CI, base images, resources, preflight, cache/uploads | Member of Proposed destination (ID: dest-2) |
status-and-reporting.md (ID: source-3) | Source diagram root (ID: 1) | |
corp-v1-status-reporting (ID: dest-3-0) | Vocabulary, reports and evidence | Member of Proposed destination (ID: dest-3) |
task-delivery-gates.md (ID: source-4) | Source diagram root (ID: 1) | |
corp-v1-channel-delivery (ID: dest-4-0) | Kept whole; cross-references skills 2 and 4 | Member of Proposed destination (ID: dest-4) |
repository-entry-and-visibility.md (ID: source-5) | Source diagram root (ID: 1) | |
corp-v1-channel-delivery (ID: dest-5-0) | Kept whole — workspace and entry gates | Member of Proposed destination (ID: dest-5) |
planning-artifact-reconciliation.md (ID: source-6) | Source diagram root (ID: 1) | |
corp-v1-channel-delivery (ID: dest-6-0) | Kept whole — planning reconciliation | Member of Proposed destination (ID: dest-6) |
Proposed new reference (ID: source-7) | Source diagram root (ID: 1) | |
corp-v1-status-reporting (ID: dest-7-0) | Owns references/final-delivery-checklist.md | Member of Proposed destination (ID: dest-7) |
- common-pitfalls.md (ID:
source-0) → Proposed destinations (ID:dest-0) - failure-and-documentation.md (ID:
source-1) → Proposed destinations (ID:dest-1) - runtime-and-ci.md (ID:
source-2) → Proposed destination (ID:dest-2) - status-and-reporting.md (ID:
source-3) → Proposed destination (ID:dest-3) - task-delivery-gates.md (ID:
source-4) → Proposed destination (ID:dest-4) - repository-entry-and-visibility.md (ID:
source-5) → Proposed destination (ID:dest-5) - planning-artifact-reconciliation.md (ID:
source-6) → Proposed destination (ID:dest-6) - Proposed new reference (ID:
source-7) → Proposed destination (ID:dest-7)
DRAFT ONLY — reference content destinations
Arrows show proposed content allocation, not runtime calls. Repeated cards identify the same skill; extracted content does not imply new filenames. No installed skill, runtime routing or approval status is changed.
Editable source: engineering/diagrams/delivery-skill-split-proposal.drawio.
Current-to-proposed skill link disposition
No current skill link is removed. The proposed AeroSim adoption keeps all 18 current links and adds the 9 distinct pointers from the central draft that are not already in that set: 27 direct pointers in total. Those additions comprise seven new or placeholder helper skills and two generic base skills. development-monorepo-pnpm is already present and is not counted again.
Baseline: the current Delivery reference map and AeroSim Delivery SKILL.md at 0c0e68bde318, repository version 1.24.0. Their 18-member skill sets agree. The existing map labels its earlier inventory as version 1.25.0; that label is not used as proof of the repository version. The central draft below remains reusable; the mandatory AeroSim adoption overlay after this table preserves the concrete project dependencies rather than silently rewriting them into generic names.
| Current skill | Disposition | Proposed load point / owner | Why the link is retained |
|---|---|---|---|
corp-v1-main | Retained | Delivery and security overlay | Retains shared Corp v1 policy; extracting login rules does not replace project governance. |
corp-v1-channel-general-aerosim | Retained | Delivery governance | Retains the authoritative project ownership and approval-routing record; the generic draft cannot replace it. |
corp-v1-channel-releases-aerosim | Retained | Delivery release handoff | Retains the release owner and completion/handoff contract; a reporting helper does not grant release authority. |
home-v1-discord | Retained | Delivery channel operations | Retains the existing Discord operations pointer; no evidence establishes that it is obsolete. |
documentation-docusaurus-aerosim | Retained | delivery-docs → AeroSim documentation binding | Retains the concrete documentation-platform skill required by the generic delivery-docs draft. |
corp-v1-glossary | Retained | delivery-docs → Corp v1 glossary binding | Retains canonical term ownership; generic documentation guidance is not a substitute for the glossary. |
self-hosted-service-account-recovery | Retained | corp-v1-ci-runtime → recovery binding | Retains the specialist recovery procedure pointer; invocation remains subject to the exact project authorization and preconditions, with no broadened authority. |
home-v1--truenas | Retained | corp-v1-ci-runtime → platform-storage binding | Retains the concrete TrueNAS procedure pointer required by the runtime/storage policy; it is not replaced by generic CI guidance. |
development-durable-wave-execution | Retained | Delivery wave orchestration | Retains reusable dependency-wave claim, continuation, recovery and closure mechanics. |
development-gates | Retained | Delivery and corp-v1-ci-runtime | Retains immutable review, exact-head CI and integration gates; CI extraction does not reimplement them. |
development-integrity | Retained | Delivery and corp-v1-status-reporting | Retains evidence and honest completion rules; reporting templates add an overlay rather than replacing integrity checks. |
development-method-ttd | Retained | Delivery coding and unit testing | Retains RED–GREEN–REFACTOR and unit-test discipline for behavior changes and fixes. |
development-branching-strategy-aerosim | Retained | Delivery → AeroSim branching overlay | Retains project-specific branching and PR rules alongside the generic base; similar names are not proof of equivalence. |
development-monorepo-pnpm | Retained | Delivery and proposed app/package helpers | Retains the existing global monorepo contract; proposed folder helpers are narrower and remain incomplete. |
development-scripts-aerosim | Retained | Delivery → AeroSim script overlay | Retains project-specific Taskfile and script conventions alongside the generic base, without flattening local rules. |
devsecops-ci-cd-gitea | Retained | corp-v1-ci-runtime → reusable pipeline mechanics | Retains Gitea/Harbor workflow mechanics; the new CI/runtime skill coordinates them instead of duplicating them. |
devsecops-ci-cd-gitea-aerosim | Retained | corp-v1-ci-runtime → AeroSim pipeline overlay | Retains the exact AeroSim CI/CD contract as well as the reusable Gitea skill; neither substitutes for the other. |
development-gitops-argo-cd-gondor-v1 | Retained | corp-v1-ci-runtime and Delivery GitOps work | Retains the current selected GitOps implementation skill; this proposal does not authorize switching to another variant. |
The proposed load points are additive routing obligations, not link removals. Delivery retains all 18 direct pointers in its adopted metadata. Extracted skills must load their listed concrete project bindings at the corresponding decision point; this avoids making a needed dependency discoverable only through an assumed transitive chain. A generic base skill does not replace its AeroSim overlay. Apply the existing project-authority precedence rule when both are loaded.
Mandatory AeroSim adoption overlay
This metadata is a proposed adoption contract, not an installed skill change. Merge the reusable draft's 16 pointers with the 18 current AeroSim pointers, deduplicate by exact name, and preserve all 27 entries below. The nine-section summary later on describes the split candidates, not the complete dependency inventory.
name: corp-v1-channel-delivery-aerosim
metadata:
hermes:
related_skills: [corp-v1-main, corp-v1-channel-general-aerosim, corp-v1-channel-releases-aerosim, home-v1-discord, documentation-docusaurus-aerosim, corp-v1-glossary, self-hosted-service-account-recovery, home-v1--truenas, development-durable-wave-execution, development-gates, development-integrity, development-method-ttd, development-branching-strategy-aerosim, development-monorepo-pnpm, development-scripts-aerosim, devsecops-ci-cd-gitea, devsecops-ci-cd-gitea-aerosim, development-gitops-argo-cd-gondor-v1, corp-v1-ci-runtime, delivery-docs, corp-v1-status-reporting, development-security, corp-v1-development-security, corp-v1-develop-monorepo-pnpm-app, corp-v1-develop-monorepo-pnpm-package, development-branching-strategy, development-scripts]
Concrete load bindings for the extracted skills when adopted in AeroSim:
delivery-docs: loaddocumentation-docusaurus-aerosimbefore documentation changes andcorp-v1-glossarybefore defining shared terms. Its generic wording must not erase these names from the project adoption.corp-v1-ci-runtime: loaddevsecops-ci-cd-giteaanddevsecops-ci-cd-gitea-aerosimfor Actions/publishing work,home-v1--truenasfor applicable storage operations, andself-hosted-service-account-recoveryonly for an explicitly authorized recovery procedure. Keep the existingdevelopment-gates,development-integrityanddevelopment-gitops-argo-cd-gondor-v1dependencies. No new account-recovery or platform authority is granted here.corp-v1-status-reporting: loaddevelopment-integrityfor evidence/completion wording and retain thecorp-v1-channel-releases-aerosimhandoff boundary; reporting does not own release approval or execution.- Delivery retains
corp-v1-channel-general-aerosim,corp-v1-mainandhome-v1-discordfor project governance and channel operations, plus both AeroSim branching/script overlays. The new app/package helpers do not replacedevelopment-monorepo-pnpm.
Removal or replacement gate
Any later proposed removal must identify the exact current skill, reason, replacement or evidence that it is no longer needed, affected responsibilities and call sites, and the owner decision required by existing governance. A move to an extracted skill must name and link the new owner and prove the dependency remains reachable and is loaded at the right decision point. It is not a deletion rationale by itself. Similar names, genericization, or absence from the central draft are not sufficient reasons. Until this evidence is reviewed, preserve the direct link and mark any questioned dependency retained pending review. This revision proposes zero removals.
The two AeroSim-only references absent from the seven-reference central source (gitea-actions-policy.md and single-subagent-task-delivery.md) also remain project-owned and unchanged; the reference-allocation view below does not silently delete or relocate them.
Reference file disposition
corp-v1-channel-delivery currently ships 7 reference files. All 7 were read and checked; 4 had
content pulled out into new skills, 3 stay fully owned by skill 1 unchanged (their content is
branch/PR/task-selection/orchestration — exactly what you said to keep in the main skill).
| Reference file | Disposition |
|---|---|
common-pitfalls.md | Split — distributed across skills 1, 2, 3, 4 by pitfall topic |
failure-and-documentation.md | Split — repair-loop mechanics → skill 2, blocker routing → skill 4, docs → skill 3 |
runtime-and-ci.md | Split — CI base images, runtime-resource placement, toolchain preflight, cache/uploads workspace → skill 2 |
status-and-reporting.md | Split — vocabulary, wave/human-facing report formats → skill 4 |
task-delivery-gates.md | Kept whole in skill 1 — pure branch/PR/coding/test/CI-gate procedure, already in scope; cross-references skills 2 and 4 instead of restating them |
repository-entry-and-visibility.md | Kept whole in skill 1 — workspace layout, Entry Gate, branch/PR naming; all in-scope |
planning-artifact-reconciliation.md | Kept whole in skill 1 — Scope/Architecture/Kanban reconciliation is orchestration, in-scope |
Summary table
| # | Skill | Global? | Status |
|---|---|---|---|
| 1 | corp-v1-channel-delivery | No | Thinned — keeps name |
| 2 | corp-v1-ci-runtime | No | New, extracted |
| 3 | delivery-docs | Yes | New, extracted + genericized |
| 4 | corp-v1-status-reporting | No | New, extracted |
| 5 | development-security | Yes | New, genericized |
| 6 | corp-v1-development-security | No | New — holds the non-global parts |
| 7 | development-monorepo-pnpm | Yes | Unchanged — already exists externally, just referenced |
| 8 | corp-v1-develop-monorepo-pnpm-app | No | New — placeholder, no prior source |
| 9 | corp-v1-develop-monorepo-pnpm-package | No | New — placeholder, no prior source |
1. corp-v1-channel-delivery (thinned)
---
name: corp-v1-channel-delivery
description: "Use when operating or synchronizing a Corp v1 project's delivery channel. Owns task eligibility, sequencing, branching/PR mechanics, coding, and unit testing; delegates CI/runtime, documentation, status/evidence reporting, and login/secrets to dedicated skills."
version: 2.0.0
author: Hermes Agent
license: MIT
metadata:
hermes:
tags: [corp-v1, discord, channel, delivery, coding, testing]
related_skills: [corp-v1-main, corp-v1-ci-runtime, delivery-docs, corp-v1-status-reporting, development-security, corp-v1-development-security, development-monorepo-pnpm, corp-v1-develop-monorepo-pnpm-app, corp-v1-develop-monorepo-pnpm-package, development-durable-wave-execution, development-gates, development-integrity, development-method-ttd, development-branching-strategy, development-scripts, development-gitops-argo-cd-gondor-v1]
---
# Corp v1 Delivery Channel
## 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.
## Scope
This skill owns delivery health for a Corp v1 project: task eligibility, sequencing, branching/PR mechanics, coding, and **unit testing only**. It monitors the project's `general`, `scope`, `architecture`, `ui-ux`, `kanban`, `delivery`, 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`.
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.
Load the matching dedicated skill at the decision point instead of restating its rules here:
- Before login: load `development-security` and `corp-v1-development-security`.
- Before build/CI/base-image/runtime work: load `corp-v1-ci-runtime`.
- Before status, wave, blocker, CI, or completion reporting: load `corp-v1-status-reporting`.
- Before changing Ways of Working or Engineering documentation: load `delivery-docs`.
- Before pnpm/TypeScript implementation: load `development-monorepo-pnpm`, plus `corp-v1-develop-monorepo-pnpm-app` (app folder structure) or `corp-v1-develop-monorepo-pnpm-package` (packages/ structure) as applicable.
## Development Skill Routing
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 source |
|---|---|---|
| dependency-wave claim, continuation, recovery, and closure | `development-durable-wave-execution` | https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-durable-wave-execution |
| immutable candidate review, exact-head CI, merge, and integration gates | `development-gates` | https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-gates |
| delivery, CI, blocker, and completion reporting | `development-integrity` | https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-integrity |
| behavior changes, defect fixes, and refactoring | `development-method-ttd` | https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-method-ttd |
| branch naming, worktrees, PR topology, and base synchronization | `development-branching-strategy` | https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-branching-strategy |
| pnpm/TypeScript monorepo implementation | `development-monorepo-pnpm` | https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-monorepo-pnpm |
| Taskfile, `.scripts/`, shell wrappers, environment validation, and Devbox | `development-scripts` | https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-scripts |
| Gondor Argo CD template, rendered desired state, and repository connection | `development-gitops-argo-cd-gondor-v1` | https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-gitops-argo-cd-gondor-v1 |
| build, CI, base images, runtime resources | `corp-v1-ci-runtime` | this project's skills (skill 2 of this proposal) |
| Ways of Working / Engineering documentation | `delivery-docs` | this project's skills (skill 3 of this proposal) |
| lifecycle status, blockers, evidence, final checklist | `corp-v1-status-reporting` | this project's skills (skill 4 of this proposal) |
| generic login/secrets handling rules | `development-security` | this project's skills (skill 5 of this proposal) |
| Corp v1's exact login secret names | `corp-v1-development-security` | this project's skills (skill 6 of this proposal) |
| app (front-end/back-end) folder structure | `corp-v1-develop-monorepo-pnpm-app` | this project's skills (skill 8 of this proposal) |
| packages/ structure and unit-test principles | `corp-v1-develop-monorepo-pnpm-package` | this project's skills (skill 9 of this proposal) |
The channel skill may narrow authority, lifecycle, workspace, visibility, handoff, and evidence requirements. When a project/channel overlay conflicts with a reusable skill on branch naming, human confirmation, worker count, review identity, merge authority, deployment authority, or release authority, the explicit project/channel overlay wins; inherit only the 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.
Full workspace layout, branch/PR naming contract, and readback mechanics: `references/repository-entry-and-visibility.md` (kept whole, see below).
## Approved Information Boundary
Inspect only the project's seven channels:
```text
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
```
Use enough delivery history to avoid duplicate work and only relevant new activity from the other channels. Never inspect another project.
> **Carried-forward note:** this list still excludes the UAT channel while the Scope section above says this skill "consumes UAT failures." That's the same contradiction flagged in `delivery-uat-overlap-report.md` finding #2 — this split does not resolve it, only relocates the text unchanged. Decide separately whether to fix it.
## 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.
## 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 `corp-v1-ci-runtime` and any other applicable project engineering skill.
5. Complete at least one useful, safe activity when an authorized path exists — implement an unblocked task, add unit tests, diagnose/fix CI, improve build tooling, update real Ways of Working/Engineering guidance, or verify dependency readiness; never create filler changes, and select work only from exact Tasks in `READY_FOR_DELIVERY`. Otherwise document and route the exact blocker with evidence.
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 (see `delivery-docs`) when durable practice changed.
9. Post a concise update with work completed, evidence, blockers, and required decisions (see `corp-v1-status-reporting` for the required formats).
## Authority and Escalation
May autonomously:
- run unit tests, Delivery artifact validations, and read-only checks; functional non-unit suites run through UAT;
- repair clear CI/build defects within authorized scope (mechanics: `corp-v1-ci-runtime`);
- add unit tests for an approved behavior and request non-unit coverage from UAT;
- prepare branches/commits/PRs where the project workflow authorizes it.
Requires approval before:
- changing requirements or architecture to make tests pass;
- silently choosing between contradictory requirements or architecture decisions instead of escalating;
- merging protected changes;
- deploying or releasing;
- changing secrets, permissions, costs, external services, or destructive resources;
- suppressing required quality/security gates.
## Mined Project-Adoption Improvements
### 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.
### Reference Routing
Task-file state, one-Task-at-a-time discipline, branch/PR/gate identity, and gate-failure repair are fully owned by `references/task-delivery-gates.md`, `references/repository-entry-and-visibility.md`, and `corp-v1-status-reporting` — do not restate them here.
Load the matching detailed reference at the decision point—not from memory:
- Task selection, execution, review, merge, and handoff: [references/task-delivery-gates.md](references/task-delivery-gates.md) (kept whole, cross-references `corp-v1-ci-runtime` and `corp-v1-status-reporting` instead of restating them)
- Workspace, branch, PR, and visibility entry: [references/repository-entry-and-visibility.md](references/repository-entry-and-visibility.md) (kept whole, unchanged)
- Planning-artifact reconciliation: [references/planning-artifact-reconciliation.md](references/planning-artifact-reconciliation.md) (kept whole, unchanged)
- Gate/branch/PR pitfalls: [references/common-pitfalls.md](references/common-pitfalls.md) (kept, trimmed to the items below)
- Build, CI, base-image, and runtime mechanics, plus the failure-repair loop: load `corp-v1-ci-runtime`
- Status, wave, blocker, CI, and completion wording: load `corp-v1-status-reporting`
- Ways of Working / Engineering documentation: load `delivery-docs`
- Login/secrets: load `development-security` and `corp-v1-development-security`
Project adoptions may narrow execution to a named main session or prohibit subagents/cron. Preserve that project-local authority overlay; the central reference does not grant account recovery, permission changes, merge, release, or deployment authority.
When selectable controls are needed, explain every complete option and its trade-offs in prose first, then use short `Option A`, `Option B`, and so on labels in the control. Put the recommended option first and keep button labels free of hidden consequences.
## Common Pitfalls
1. Patching symptoms before understanding root cause.
2. Changing requirements or architecture implicitly through code.
3. Editing without loading applicable project engineering skills.
4. Skipping tests for behavioral fixes.
5. Inspecting another project.
6. Starting implementation because requirements exist but human implementation approval is absent.
7. Ignoring architecture task dependencies, the Task's `READY_FOR_DELIVERY` handoff, or target-version allocation.
8. Treating a human-merged planning or Architecture documentation PR as implementation approval.
9. Treating an ideation-board entry, generated presentation, or broad approval as equivalent to an exact Task `READY_FOR_DELIVERY` transition—or requiring a second admission after that verified transition.
10. Editing in a local-only worktree or on a differently named local branch before the exact remote branch and PR head are visible and verified.
Dropped entirely from this skill (moved out, not duplicated): Canonical Scope Status Vocabulary, Shared Corp v1 System Login, Build/CI/base-images/Runtime-resource-placement, Failure-Repair Workflow, Documentation Ownership, Evidence Requirements, Verification Checklist, and 10 of the 20 common-pitfalls.md items (CI/reporting/docs-specific ones — see skills 2/3/4 below).
Also removed per the older trim list (new-skills-proposal.md's brainstorm, now applied): When to Use (redundant with the frontmatter description; its one substantive rule — don't silently resolve contradictory requirements/architecture — moved into Authority and Escalation's approval-required list); Proactive Iteration Requirement (merged into Synchronization Workflow step 5, since it only restated "do one useful thing per iteration"); and the first two paragraphs of Project-Adoption Delivery Lessons (renamed Reference Routing — those paragraphs restated Task-file/lifecycle and branch/PR/gate rules already owned by task-delivery-gates.md, repository-entry-and-visibility.md, and corp-v1-status-reporting).
2. corp-v1-ci-runtime
---
name: corp-v1-ci-runtime
description: "Use when building, running CI, publishing reusable CI base images, or provisioning runtime resources for a Corp v1 project's delivery pipeline."
version: 1.0.0
author: Hermes Agent
license: MIT
metadata:
hermes:
tags: [corp-v1, ci, build, runtime, base-images]
related_skills: [corp-v1-channel-delivery, corp-v1-status-reporting, development-gates, development-integrity, development-gitops-argo-cd-gondor-v1]
---
# Corp v1 CI & Runtime
## 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.
Monitor local builds and Gitea Actions for:
- compile/type failures;
- unit-test failures and UAT-reported non-unit failures;
- lint/format failures;
- dependency, packaging, container, or chart failures;
- workflow/configuration defects;
- missing or stale artifacts;
- branch/head-SHA mismatch.
Functional non-unit browser, integration, performance, security-boundary, and acceptance failures arrive as UAT evidence and are routed back to `corp-v1-channel-delivery` for application remediation. A green local build is never remote CI evidence — verify the actual remote branch and matching CI task/run.
## Execution-context toolchain preflight
Treat every foreground shell, detached worktree, background process, Hermes main-session review command, and CI job as a separate execution context. Before any repository command or operation runs in an execution context, complete the applicable preflight for that exact context. For a Node/pnpm repository—or any command that may invoke Node or pnpm—the following checks are mandatory:
1. resolve the repository-required Node and pnpm versions from its committed toolchain contract;
2. run `command -v node`, `node --version`, `command -v pnpm`, and `pnpm --version` inside the exact context, then compare the observed versions with the committed required versions;
3. verify required non-secret environment variable names are present, including disposable-test database markers when applicable, without reading or printing their values;
4. verify the actual working directory, linked branch/PR identity, and clean or intentionally staged repository state; and
5. start the repository command only after every applicable preflight check passes.
Never assume a background process inherits `PATH`, shell activation, Devbox state, Corepack activation, database variables, or other exports from a foreground terminal. A missing `pnpm` executable is always an execution-context/toolchain failure, never an application-code or test failure. Repair the exact context by providing the required toolchain path or activation, repeat the complete preflight there, and rerun the original command before making any claim about repository code.
## Per-project reusable CI base images
Each Corp v1 project should own `corp-v1-<code>/corp-v1-<code>-base-images` when stable runtimes or operating-system tools would otherwise be downloaded repeatedly in application CI.
- Keep one folder per image, with its Dockerfile, machine-readable version/platform metadata, usage documentation, build helper, and static publication contract. Runtime smoke belongs to UAT.
- Pin the upstream base by digest and assert exact runtime/tool versions, architecture, numeric non-root identity, writable workspace, CA trust, Git, shell, and other required tools.
- Build and perform static/unit validation without registry credentials on pull requests. Publish only from the trusted integration branch (`test`) using a narrowly scoped Harbor robot secret; UAT validates the published digest at runtime.
- Publish immutable full-source-SHA tags, read back the Harbor artifact digest, and consume the image from project workflows by digest—not `latest`, a mutable version tag, or an unverified local name.
- Extend fail-closed tests to reject broad publication triggers, mutable tags, secret access from candidate/PR paths, shell interpolation, wrong digests, and reintroduced runtime setup actions.
- Prefer the verified job image over repeated runtime or package-manager setup actions (e.g. `actions/setup-node`). Keep lockfile-frozen application dependency installation (`pnpm install --frozen-lockfile --ignore-scripts`) in the application repository; do not bake project dependencies into a generic base image.
- Treat the first real Gitea build, Harbor publication, digest readback, and consumer workflow at the exact candidate SHA as separate Delivery layers. Runtime smoke is a separate UAT layer.
- Repair image or publication failures forward only. Preserve the last known-good digest for consumers until the replacement image and consuming workflow pass exact-head CI.
## Runtime-resource placement
CI jobs and developer workstations must not provision databases, queues, object stores, caches, brokers, or other application runtime services. Load `development-gitops-argo-cd-gondor-v1` before defining or changing Gondor desired state. Render the committed project template separately into one repository per environment; this skill may update only the repository assigned to its non-production environment, while production remains outside this skill's authority unless an explicit project overlay says otherwise.
- Keep every non-production environment—including development, integration, test, staging, and preview—and all of its resources isolated from production and from other non-production environments. Destructive or concurrent validation requires a per-run database/schema/role or explicit serialization; it must not reset shared data.
- CI may orchestrate exact-head unit/build validation, but it must not start application runtime-resource service containers or receive application-resource credentials. Harmless process-local test doubles and build tools are not runtime resources. UAT owns resource-dependent tests and their restricted execution; this skill only provisions an approved development dependency and hands its exact identity to UAT. Do not expose an internal resource through Ingress, NodePort, LoadBalancer, or a runner-accessible public endpoint. Prefer a narrowly governed in-platform Job/Workflow trigger so a private resource does not need public or runner-network exposure.
- Persistent storage must follow the project's named platform-storage operations skill; load that skill before designing or mutating storage (for the Gondor/TrueNAS reference implementation: create a purpose-specific TrueNAS dataset and NFS share restricted to Gondor node networks, then bind a static PV/PVC with `persistentVolumeReclaimPolicy: Retain` and `storageClassName: ""`; do not use the default dynamic `truenas-csi` StorageClass for durable data because its `Delete` reclaim policy can remove the backing dataset with the PVC). If neither an approved skill nor an approved procedure is identified, stop and route the missing decision to Architecture/platform operations; do not infer a provider or provisioning method.
- Use only External Secrets backed by the existing Bitwarden `ClusterSecretStore`; never commit connection strings or credentials.
- Provision and verify required runtime resources before treating dependent application work as deployable. Resource-independent implementation may proceed, but deployment remains blocked until the dependency is healthy and consumed by the application.
## Channel-owned CI/runtime workspace
Resolve the channel root as `corp-v1-<code>-delivery/` under the active user's working root. This skill owns the channel-level `cache/` and `uploads/` folders inside it; the per-Task `workspace/<TASK_ID>/` tree (`application/`, `documentation/`, and optional `review/`/`cache/`/`tmp/`/`logs/`/`artifacts/`) is owned by `corp-v1-channel-delivery`.
- `cache/` contains reusable technical dependencies installed by Delivery, including pinned Node/pnpm toolchains, Nginx binaries, and package-manager download caches. Browser/Playwright dependencies for non-unit suites belong to the UAT workspace and E2E repository. Reuse verified entries across Tasks instead of reinstalling them. Version or digest cache paths when compatibility matters, verify the resolved executable and version in every execution context, and never store credentials, Task evidence, repository content, or mutable application state there.
- `uploads/` contains files supplied through this channel. It is not a repository checkout or build directory.
## Failure-repair loop (mechanics)
When a build or CI failure is observed:
1. verify repository, linked branch and PR, exact failed command/file/test/job, failure class, and exact logs;
2. reproduce locally when feasible;
3. determine root cause before editing;
4. compare the intended fix against approved FR/NFRs, ADRs, architecture documentation, and project conventions;
5. implement the smallest safe fix;
6. add/update tests where behavior changed;
7. run local validation;
8. commit and push through the approved branch workflow;
9. inspect CI for the exact new head SHA;
10. report evidence and remaining risk;
11. repeat diagnosis, repair, and affected validation until the active gate passes.
This skill must continue with a safe forward fix when the failure and expected behavior are clear. A repairable failure does not end the Task or authorize moving to another gate or Task. If evidence is insufficient, requirements/architecture conflict, an external dependency is unavailable, or the required action exceeds authority, keep the Task in the same gate, record the separate blocker with evidence and owner, and route it — see `corp-v1-status-reporting` for the blocker-escalation table. Never guess the team's intended direction, weaken a gate, or treat a blocker as a passed gate. Resume the same gate and continue the repair loop when the blocker is removed.
## CI/runtime pitfalls
1. Claiming CI success from a local build.
2. Validating a stale channel-reported SHA instead of freshly resolving and checking the current remote merge head.
3. Continuing to report or validate an open PR head after the PR merged during the run; re-resolve the merge/default-branch SHA and require local validation plus CI for that exact merge commit.
4. Starting `pnpm`, tests, or a background worker before checking the toolchain and required environment inside that exact execution context.
5. Stopping at a repairable gate failure, abandoning the active Task, or starting another Task instead of fixing forward and rerunning the gate until it passes.
3. delivery-docs (global)
---
name: delivery-docs
description: "Use when maintaining a project's Ways of Working and Engineering documentation areas — their required structure, and the rule that documentation reflects verified practice, not aspiration."
version: 1.0.0
author: Hermes Agent
license: MIT
metadata:
hermes:
tags: [documentation, ways-of-working, engineering]
---
# Delivery Documentation Structure
Maintain two documentation areas.
## Ways of Working — five sections
1. **Delivery workflow** — intake, prioritization, implementation states, and definition of done.
2. **Branching and reviews** — branch conventions, pull requests, approvals, and merge expectations.
3. **Planning and ownership** — backlog, sequencing, owners, dependencies, blockers, and escalation.
4. **Quality practices** — review standards, test strategy, defect handling, and evidence expectations.
5. **Collaboration and decisions** — channel routing, handoffs, decision references, and communication norms.
## Engineering — five sections
1. **Repository and workspace** — monorepo/application/package structure and local prerequisites.
2. **Development and unit testing** — commands, unit-test fixtures, debugging, artifact validation, and the handoff to whichever skill or team owns every functional non-unit suite.
3. **Build and continuous integration** — pipelines, checks, artifacts, runners, and failure diagnosis.
4. **Packaging and deployment preparation** — containers, Helm/GitOps interfaces, configuration, and release inputs.
5. **Operations and troubleshooting** — observability, known failure modes, recovery checks, and evidence collection.
## Rules
- Update these pages from verified project practice. Do not document a planned process as already operational.
- Before changing documentation structure, navigation, Markdown/MDX, or builds, load your project's shared documentation-platform skill if one exists.
- Before defining or explaining a reusable term, load your project's shared glossary skill if one exists; maintain one canonical definition and link to it rather than duplicating explanations across pages.
## Pitfalls
1. Updating documentation with aspirational rather than actual practice.
Genericized out: the literal names documentation-docusaurus and corp-v1-glossary and their Gitea URLs (https://gitea.lego-cloud.eu/home-v1-skills-code-agent/documentation-docusaurus and https://gitea.lego-cloud.eu/home-v1-skills-code-agent/corp-v1-glossary) — those are project-specific pointers and belong back in corp-v1-channel-delivery (or a small overlay) as: "This project's documentation-platform skill is documentation-docusaurus (<url>); its glossary skill is corp-v1-glossary (<url>)."
4. corp-v1-status-reporting
---
name: corp-v1-status-reporting
description: "Use when reading Task/Feature/Epic lifecycle status, reporting delivery/wave/CI/blocker status, or running the final delivery checklist for a Corp v1 project."
version: 1.0.0
author: Hermes Agent
license: MIT
metadata:
hermes:
tags: [corp-v1, status, reporting, evidence]
related_skills: [corp-v1-channel-delivery, corp-v1-ci-runtime]
---
# Corp v1 Status & Reporting
## Canonical Scope Status Vocabulary
Before reporting or changing any lifecycle status, read the project's current Ways of Working Scope page. Use only the canonical values defined there.
Ideas, Epics, and Features:
```text
IN_BACKLOG → IN_DESIGN → READY_FOR_DELIVERY → IN_DELIVERY → TO_BE_RELEASED → DONE
```
Tasks:
```text
IN_BACKLOG → READY_FOR_DELIVERY → IN_PROGRESS → TO_BE_RELEASED → DONE
```
`READY_FOR_DELIVERY` is the exact Task's Focus-admitted, pickup-ready state. It means Architecture, dependencies, implementation boundaries, verification steps, and Kanban selection are complete; implementation has not started. Delivery claims that Task by moving it directly to `IN_PROGRESS`. Never require or invent a second Focus-admission decision after `READY_FOR_DELIVERY`.
`CANCELLED` is an exceptional terminal status. `BLOCKED` is a separate flag with a reason and evidence; it never replaces the lifecycle status.
Never invent, abbreviate, or substitute lifecycle values such as `Ready`, `Active`, `Delivered`, `Complete`, `Awaiting CI`, or `Overrun`. Those phrases may describe activity only when clearly separated from the canonical status field. If the canonical status cannot be verified, report `status unverified` and inspect the source record rather than guessing.
A merge or successful CI does not automatically mean `DONE`. Releasable application Tasks normally move from `IN_PROGRESS` to `TO_BE_RELEASED`; `DONE` requires the applicable release or completion evidence. Status reports must show the exact canonical value even when a separate plain-language action is also included.
## Wave Status Report
When the active project authority explicitly asks for project, delivery, blocker, progress, or wave status, begin the status report with this exact first-line structure, with no text before it:
```text
wave-previous: <previous wave> | wave-current: <current wave> | wave-next: <next wave>
```
Each value must be an actual dependency-wave label calculated by the adopted project's Release Task Board, such as `Wave 11`, `Wave 12`, or `Wave 13`. Never substitute activities, work descriptions, statuses, invented phases, or ad hoc labels. Resolve the current wave and its adjacent existing waves from the Board selector and task assignments; do not infer them from conversation wording. Use `none` only when the Board has no previous or next wave.
Do not repeat the wave header or task chapter in ordinary acknowledgements, implementation narration, questions, or non-status replies. Use them only when the active project authority explicitly asks for status.
### Current-wave task chapter
Immediately after the header in a requested status report, include:
```text
## Wave XX (Current)
- TASK-XXXX — <status> — Responsible: <Hermes main session or concrete owning process>
```
Replace `XX` with the current Board wave number. List every Task assigned to that wave—never a sample or only changed Tasks—and use each Task's verified flow status. For responsibility, name Hermes main session when it actively owns the Task; otherwise name the concrete owning process, such as Delivery pickup, implementation/review, integration, or Release handoff. When no active executor or owning process exists, say `Unassigned`; never invent an agent, process, or ownership. Refresh the Board/task records and live process state before reporting when they may have changed.
## Human-facing delivery updates
In every implementation, review, CI, blocker, merge, handoff, or completion update, lead with the linked branch and pull request where the work is visible. The next line must identify the Task, exact Task status, active gate code, and gate title:
```text
<TASK_ID> | <TASK_STATUS> | <GATE_CODE> — <GATE_TITLE>
```
Example:
```text
TASK-0084 | IN_PROGRESS | GATE_003_TASK_IMPLEMENTATION — Implement and Review the Task
```
While work remains inside a gate, continue reporting that same code. When its exit gate passes, report the transition explicitly:
```text
GATE_003_TASK_IMPLEMENTATION passed → GATE_004_TASK_PR_CI
```
When blocked, name the gate where progress stopped:
```text
BLOCKED at GATE_004_TASK_PR_CI — Verify and Merge the Task PR
```
Do not invent a separate phase or shorthand. Do not lead with or routinely include commit SHAs, tree hashes, digests, internal worktree paths, or temporary review-commit identities; retain those for automated verification and provide them only when the active project authority asks for audit detail or when an identity mismatch itself is the blocker.
When anything fails, identify the exact failed command, file, test, or CI job. State its failure classification—application code, test assertion, workflow, infrastructure, credentials, or local execution environment—then provide the expected behavior and observed behavior, whether repository or remote state changed, and the concrete repair or owner. Never summarize a failure as only "validation failed", "review failed", or "CI failed".
## Blocker escalation routing
| Blocker type | Route to |
|---|---|
| requirement/product ambiguity | `general` and/or `architecture` |
| architecture contradiction | `architecture` |
| release policy/readiness ambiguity | `releases` |
| implementation-only blocker | `delivery` |
## 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.
## Verification Checklist
Moved to `references/final-delivery-checklist.md`, invoked explicitly at `GATE_005_TASK_POST_MERGE` / `GATE_006_NEXT_TASK` exit — not restated inline in the skill body, since most of the original 11 items just repeated exit criteria already defined in `task-delivery-gates.md` (approved-for-implementation evidence, dependencies, `READY_FOR_DELIVERY`, skills loaded, tests/builds run, branch/CI head verified, docs accuracy, evidence — all owned elsewhere). The reference keeps only the items that aren't already stated as a gate-exit condition anywhere else:
- [ ] Only same-project channels and repositories were used.
- [ ] Contradictions were escalated, not guessed through.
- [ ] Completed work includes exact evidence (see Evidence Requirements above).
## Status/reporting pitfalls
1. Repeatedly posting unchanged failure summaries.
2. Posting passive status when safe implementation, testing, diagnosis, or documentation work is available.
3. Reposting an unchanged gate summary when no new decision, head, CI result, failure, or durable artifact exists.
4. Reporting only "failed" or leading with hashes instead of the linked branch/PR and the exact failed command, file, test, or CI job.
5. development-security (global)
---
name: development-security
description: "Use before any login to a system under test or operation. Defines the generic rules for handling injected runtime secrets — this skill has no project-specific secret names."
version: 1.0.0
author: Hermes Agent
license: MIT
metadata:
hermes:
tags: [security, secrets, login]
---
# Development Security — Secrets & Login
- Secret availability is capability, not authorization. Verify the destination origin and task purpose before using an injected secret to log in.
- Never print, inspect, log, hash, serialize, paste, screenshot, or persist a secret value.
- Never place a secret value in a command line, URL, file, repository, prompt, chat message, browser console, test fixture, CI output, or generated artifact.
- Never ask a human to paste a secret value into chat.
- If a required secret is unavailable, report only its missing variable name and request injection through the project's secret manager — never invent, hardcode, or ask for a substitute value.
- Login does not authorize account recovery, MFA or credential changes, permission changes, billing, spending, destructive operations, or access outside the approved task.
- Consult your project's own overlay skill for the exact secret names and injection mechanism this rule set applies to.
6. corp-v1-development-security
---
name: corp-v1-development-security
description: "Project-specific login policy for Corp v1 systems — names the exact injected secrets. Always load development-security alongside this skill."
version: 1.0.0
author: Hermes Agent
license: MIT
metadata:
hermes:
tags: [corp-v1, security, secrets, login]
related_skills: [development-security, corp-v1-main, corp-v1-channel-delivery]
---
# Corp v1 Login
When an authorized task requires login to a Corp v1 system being built or operated, follow `corp-v1-main`'s shared policy and use only the Bitwarden-injected runtime secrets named:
```text
HL_V1_SSO_EMAIL
HL_V1_SSO_PASSWORD
```
All handling rules for these values are defined once in `development-security` — load it alongside this skill rather than restating its rules here.
Observation (not acted on here): corp-v1-channel-uat currently has no equivalent pointer and authenticates via an unnamed "runtime secrets" mechanism (journey-repository-contract.md: "Authentication is loaded from runtime secrets and never persisted in committed storage-state files" — no secret names, no reference to corp-v1-main or this convention at all). If UAT ever needs the same login, it could load this same skill instead of inventing its own convention — this would close overlap-report finding #6, but that's a change to the UAT skill, out of scope here.
7. development-monorepo-pnpm — no change
Already exists externally at https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-monorepo-pnpm and is already referenced in corp-v1-channel-delivery's routing table and related_skills. Nothing to draft — just keep the reference in skill 1's routing table pointed at it.
8. corp-v1-develop-monorepo-pnpm-app (placeholder — no prior source material)
---
name: corp-v1-develop-monorepo-pnpm-app
description: "Use when creating or reviewing the high-level folder structure of a Corp v1 front-end or back-end application inside the pnpm monorepo."
version: 0.1.0
author: Hermes Agent
license: MIT
metadata:
hermes:
tags: [corp-v1, monorepo, pnpm, structure]
related_skills: [development-monorepo-pnpm, corp-v1-channel-delivery]
---
# Corp v1 App Structure
> DRAFT — this content did not exist in the current delivery skill. Fill in with your project's actual conventions before publishing.
## Front-end app case
(TODO: describe required top-level folders — e.g. `src/`, `routes/`, `components/`, `assets/` — and the rule for where shared UI code lives vs. app-local code)
## Back-end app case
(TODO: describe required top-level folders — e.g. `src/`, `routes/` or `handlers/`, `services/`, `config/` — and the rule for where shared server code lives vs. app-local code)
9. corp-v1-develop-monorepo-pnpm-package (placeholder — no prior source material)
---
name: corp-v1-develop-monorepo-pnpm-package
description: "Use when creating or reviewing a shared library under packages/ in the Corp v1 pnpm monorepo, including its required unit-testing principles."
version: 0.1.0
author: Hermes Agent
license: MIT
metadata:
hermes:
tags: [corp-v1, monorepo, pnpm, packages, testing]
related_skills: [development-monorepo-pnpm, corp-v1-channel-delivery]
---
# Corp v1 Package Structure
> DRAFT — this content did not exist in the current delivery skill. Fill in with your project's actual conventions before publishing.
## Package folder structure
(TODO: describe required layout under `packages/<name>/` — e.g. `src/`, `dist/`, `package.json` exports, `tsconfig` references)
## Unit-testing principles for packages
(TODO: describe required coverage expectations, test file placement, and how a package's tests differ in scope from an app's unit tests)