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

feat: gate delivery through Kanban Focus

Browse Source
This commit is contained in:
jarvis-at-skic
2026-08-13 16:50:52 +00:00
parent 84f2e5cde8
commit 91ea1744a9
1 changed files with 10 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files
SKILL.md
+10 -8
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.1.0 version: 1.2.0
author: Hermes Agent author: Hermes Agent
license: MIT license: MIT
metadata: metadata:
@@ -14,7 +14,7 @@ metadata:
## Overview ## Overview
This skill owns delivery health for a Corp v1 project. It monitors the project's `general`, `architecture`, `delivery`, and `releases` channels and implements only Features that architecture documentation marks `Approved for Implementation` through an explicit human team-member decision. This skill owns delivery health for a Corp v1 project. It monitors the project's `general`, `architecture`, `kanban`, `delivery`, and `releases` channels and implements only tasks whose parent Feature has explicit human `Approved for Implementation` evidence and which a human team member separately admitted to Kanban Focus `InBacklog`.
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. 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.
@@ -42,20 +42,22 @@ Before starting or continuing Feature implementation, verify in project document
- task breakdown and dependencies; - task breakdown and dependencies;
- target version and status; - target version and status;
- acceptance evidence expected from delivery. - acceptance evidence expected from delivery.
- explicit human Kanban approval admitting the exact task to Focus `InBacklog`.
Hermes cannot approve a Feature for implementation. If the gate is incomplete, improve safe delivery-readiness documentation or raise the exact missing decision in `architecture`; do not start code. Hermes cannot approve a Feature for implementation or admit a task to Focus `InBacklog`. If the gate is incomplete, improve safe delivery-readiness documentation or raise the exact missing decision in `architecture`; do not start code.
## 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 from architecture's approved task/dependency plan and update progress in project documentation. 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 Kanban Focus `InBacklog`, backed by architecture's approved task/dependency plan, and update progress in project documentation.
## Approved Information Boundary ## Approved Information Boundary
Inspect only the project's four channels: Inspect only the project's five channels:
```text ```text
corp-v1-<code>-general corp-v1-<code>-general
corp-v1-<code>-architecture corp-v1-<code>-architecture
corp-v1-<code>-kanban
corp-v1-<code>-delivery corp-v1-<code>-delivery
corp-v1-<code>-releases corp-v1-<code>-releases
``` ```
@@ -144,7 +146,7 @@ Update these pages from verified project practice. Do not document a planned pro
## Synchronization Workflow ## Synchronization Workflow
1. Read new same-project activity and enough delivery history to avoid duplicates. 1. Read new same-project activity and enough delivery history to avoid duplicates.
2. Verify human `Approved for Implementation` evidence, task dependencies, and target version before Feature work. 2. Verify human `Approved for Implementation` evidence, explicit human Kanban Focus `InBacklog` admission, task dependencies, and target version before task work.
3. Identify executable tasks, CI failures, blockers, requirements/ADR implications, and documentation drift. 3. Identify executable tasks, CI failures, blockers, requirements/ADR implications, and documentation drift.
4. Load all applicable project engineering skills. 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. 5. Complete at least one useful safe activity when an authorized path exists; otherwise document and route the exact blocker.
@@ -186,7 +188,7 @@ Include repository, branch, commit SHA, changed paths, commands, local results,
7. Repeatedly posting unchanged failure summaries. 7. Repeatedly posting unchanged failure summaries.
8. Inspecting another project. 8. Inspecting another project.
9. Starting implementation because requirements exist but human implementation approval is absent. 9. Starting implementation because requirements exist but human implementation approval is absent.
10. Ignoring architecture task dependencies or target-version allocation. 10. Ignoring architecture task dependencies, Kanban Focus admission, or target-version allocation.
11. Posting passive status when safe implementation, testing, diagnosis, or documentation work is available. 11. Posting passive status when safe implementation, testing, diagnosis, or documentation work is available.
## Verification Checklist ## Verification Checklist
@@ -194,7 +196,7 @@ Include repository, branch, commit SHA, changed paths, commands, local results,
- [ ] Only same-project channels and repositories were used. - [ ] Only same-project channels and repositories were used.
- [ ] Work maps to approved requirements/architecture. - [ ] Work maps to approved requirements/architecture.
- [ ] Feature has explicit human `Approved for Implementation` evidence and a documented target version. - [ ] Feature has explicit human `Approved for Implementation` evidence and a documented target version.
- [ ] Selected tasks respect documented dependencies. - [ ] Selected tasks respect documented dependencies and have explicit human Focus `InBacklog` admission.
- [ ] At least one useful delivery activity was completed, or a concrete blocker was documented and routed. - [ ] At least one useful delivery activity was completed, or a concrete blocker was documented and routed.
- [ ] Applicable project skills were loaded. - [ ] Applicable project skills were loaded.
- [ ] Tests and builds were actually run. - [ ] Tests and builds were actually run.