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

Merge immediate wave-start visibility policy

Browse Source 
Require a dedicated pushed branch and visible PR for each Task before substantive wave implementation.
This commit was merged in pull request #7.
This commit is contained in:
jarvis-at-skic
2026-09-07 03:09:22 -07:00
parent 6aaed69294 573b79ae79
commit 2535089fdd
1 changed files with 12 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
SKILL.md
+12 -1
View File
@@ -1,7 +1,7 @@
--- ---
name: corp-v1-channel-delivery 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." 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.9.0 version: 1.10.0
author: Hermes Agent author: Hermes Agent
license: MIT license: MIT
metadata: metadata:
@@ -85,6 +85,17 @@ Before starting or continuing Feature implementation, verify in project document
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`. 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
Before implementation begins on a newly claimed delivery wave, establish these Gitea checkpoints for **every Task** in that wave:
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.
## Proactive Iteration Requirement ## Proactive Iteration Requirement
Every delivery iteration must complete at least one useful, safe activity for an implementation-approved Feature or delivery-health need: implement an unblocked task, add tests, diagnose/fix CI, improve build tooling, update real Ways of Working/Engineering guidance, verify dependency readiness, or document a concrete blocker with evidence. Never create filler changes. Select work only from exact Tasks in `READY_FOR_DELIVERY`; claiming one moves it to `IN_PROGRESS`. Keep architecture's approved task/dependency plan and project documentation current. Every delivery iteration must complete at least one useful, safe activity for an implementation-approved Feature or delivery-health need: implement an unblocked task, add tests, diagnose/fix CI, improve build tooling, update real Ways of Working/Engineering guidance, verify dependency readiness, or document a concrete blocker with evidence. Never create filler changes. Select work only from exact Tasks in `READY_FOR_DELIVERY`; claiming one moves it to `IN_PROGRESS`. Keep architecture's approved task/dependency plan and project documentation current.