home-v1-skills-code-agent/corp-v1-channel-delivery
6
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: route Delivery through development skills

Browse Source
This commit is contained in:
jarvis-at-skic
2026-09-23 19:38:14 +00:00
parent 52bee5e227
commit 6190262538
3 changed files with 59 additions and 31 deletions
Download Patch File Download Diff File Expand all files Collapse all files
SKILL.md
+25 -30
View File
@@ -1,13 +1,13 @@
---
name: corp-v1-channel-delivery
description: "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."
version: 1.11.0
version: 1.11.1
author: Hermes Agent
license: MIT
metadata:
hermes:
tags: [corp-v1, discord, channel, delivery, coding, testing, ci]
related_skills: [corp-v1-main, home-v1-discord, documentation-docusaurus, corp-v1-glossary]
related_skills: [corp-v1-main, home-v1-discord, documentation-docusaurus, corp-v1-glossary, development-durable-wave-execution, development-gates, development-integrity, development-method-ttd, development-branching-strategy, development-monorepo-pnpm, development-scripts, development-gitops-argo-cd-gondor-v1]
---
# Corp v1 Delivery Channel
@@ -75,6 +75,23 @@ Use this skill when:
Do not use it to silently choose between contradictory requirements or architecture decisions, approve releases, or bypass review and branch protections.
## 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 Gitea 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 |
The channel skill may narrow authority, lifecycle, workspace, visibility, handoff, and evidence requirements. 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:
@@ -91,14 +108,9 @@ Hermes cannot approve a Feature for implementation or move a Task to `READY_FOR_
## Immediate Wave-Start Visibility Gate
Before implementation begins on a newly claimed delivery wave, establish these Gitea checkpoints for **every Task** in that wave:
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.
1. Create a dedicated branch whose name includes the exact Task ID and concise purpose, and push it immediately.
2. Open a pull request from that branch to the governed integration branch immediately after the branch exists. Do not wait for implementation, tests, review, or a finished diff.
3. Put the Task ID, wave, planned scope, and current delivery state in the PR so the human owner and team can monitor progress from the beginning.
4. Read back and record the branch ref, PR URL/number, exact head SHA, and base branch before substantive coding starts. Keep the same PR updated as commits are pushed.
One Task requires one dedicated branch and one visible PR unless Architecture or the human owner explicitly approves a different grouping. Do not hide several independently deliverable Tasks behind a shared wave branch. If Gitea refuses a no-diff PR, create and push an empty kickoff commit—never a filler file change—then open the PR. A locally created worktree or unpushed branch does not satisfy this gate.
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.
## Proactive Iteration Requirement
@@ -124,34 +136,17 @@ Use enough delivery history to avoid duplicate work and only relevant new activi
### Coding
- implement only human-approved Features and their authorized tasks;
- load applicable project engineering skills before changing code;
- preserve project structure, conventions, and environment namespace;
- keep changes small, reviewable, and traceable to requirements/issues;
- avoid unrelated refactors during failure repair;
- never fabricate command, test, CI, or deployment results.
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
- add or update tests with behavioral changes;
- reproduce defects before fixing when practical;
- cover normal, edge, and failure cases proportional to risk;
- run the narrowest relevant tests first, then required broader validation;
- record exact commands and real results.
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 only requires that the resulting tests map to approved acceptance evidence and that real commands/results are retained.
### Build and continuous integration
Monitor local builds and Gitea Actions for:
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.
- compile/type failures;
- unit/integration test failures;
- lint/format failures;
- dependency, packaging, container, or chart failures;
- workflow/configuration defects;
- missing or stale artifacts;
- branch/head-SHA mismatch.
A green local build is not proof that CI or delivery succeeded. Verify the actual remote branch and matching CI task/run.
Delivery still monitors repository-specific compile/type, unit/integration, lint/format, dependency, packaging, container, chart, workflow, and artifact failures. A green local build is never remote CI evidence.
### Per-project reusable CI base images