From 63b883f03f78ea36fbbe9b977b4865136d949382 Mon Sep 17 00:00:00 2001 From: Jarvis Jr Hermes Date: Thu, 13 Aug 2026 16:50:51 +0000 Subject: [PATCH] feat: add Kanban task handoff --- SKILL.md | 21 ++++++++++++++------- 1 file changed, 14 insertions(+), 7 deletions(-) diff --git a/SKILL.md b/SKILL.md index 28c53ff..4b660f3 100644 --- a/SKILL.md +++ b/SKILL.md @@ -1,7 +1,7 @@ --- name: corp-v1-channel-architecture -description: "Use when operating or synchronizing a Corp v1 project's architecture channel. Maintains C4-based architecture documentation, Draw.io diagrams, architecture decisions, and functional/non-functional requirement registries while correlating verified activity across the project's four channels." -version: 1.1.0 +description: "Use when operating or synchronizing a Corp v1 project's architecture channel. Maintains C4-based architecture documentation, Draw.io diagrams, architecture decisions, and functional/non-functional requirement registries while correlating verified activity across the project's five channels." +version: 1.2.0 author: Hermes Agent license: MIT metadata: @@ -14,7 +14,7 @@ metadata: ## Overview -This skill owns the solution phase and architecture coherence for a Corp v1 project. It monitors the project's `general`, `architecture`, `delivery`, and `releases` channels, transforms human-approved Features into requirements and solution artifacts, breaks them into dependency-aware implementation tasks, assigns approved Features to versions, and maintains the Architecture section of the project documentation. +This skill owns the solution phase and architecture coherence for a Corp v1 project. It monitors the project's `general`, `architecture`, `kanban`, `delivery`, and `releases` channels, transforms human-approved Features into requirements and solution artifacts, breaks them into dependency-aware implementation tasks, assigns approved Features to versions, and maintains the Architecture section of the project documentation. The default architecture model is C4. Architecture diagrams must be authored and validated using the global `drawio-main` skill from: @@ -55,11 +55,12 @@ Inspect only: ```text corp-v1--general corp-v1--architecture +corp-v1--kanban corp-v1--delivery corp-v1--releases ``` -Use mapped-channel history to avoid duplicate work and new relevant activity from the other three channels. Never inspect another project's channels. +Use mapped-channel history to avoid duplicate work and new relevant activity from the other four channels. Never inspect another project's channels. ## Architecture Documentation Contract @@ -84,7 +85,8 @@ For each human-approved Feature from the General documentation registry: 5. break the Feature into implementation tasks with dependencies and acceptance evidence; 6. assess sequencing, risks, cross-feature dependencies, and release constraints; 7. propose and document the target version; -8. prepare a review package for the human implementation-approval decision. +8. prepare task-readiness evidence for Kanban Focus admission; +9. prepare a review package for the human implementation-approval decision. Do not perform solution work for merely `Proposed`, `Deferred`, or `Rejected` Features. @@ -153,12 +155,16 @@ Maintain a task registry in project documentation: ID | feature | outcome | scope | dependencies | owner | status | acceptance evidence | affected repository/component ``` -Use stable IDs such as `TASK-0001`. Model Feature→Task and Task→Task dependencies explicitly, identify critical sequencing and blocked work, and keep tasks small enough to implement and verify. Tasks may be drafted proactively, but only tasks belonging to a human-approved `Approved for Implementation` Feature may enter delivery execution. +Use stable IDs such as `TASK-0001`. Model Feature→Task and Task→Task dependencies explicitly, identify critical sequencing and blocked work, and keep tasks small enough to implement and verify. Tasks may be drafted proactively, but only tasks belonging to a human-approved `Approved for Implementation` Feature may be proposed to Kanban. A human team member must separately approve each ready task into Focus `InBacklog` before Delivery execution. ## Version Allocation Maintain a version allocation registry linking Features to intended versions. Record target version, rationale, dependencies, readiness constraints, status, and human decision evidence. Hermes may analyze and propose allocation; the team decides which Feature goes into which version. Do not invent version assignments or treat a proposal as final. +## Kanban Handoff + +After human Feature implementation approval, Architecture sends dependency-ready task records to Kanban. Architecture does not place tasks into Focus `InBacklog`; Kanban records the separate human task-admission decision. Keep task dependencies and readiness evidence current when Kanban or Delivery reports drift. + ## Proactive Iteration Requirement Every architecture iteration must add or materially improve a useful project-documentation artifact for an eligible human-approved Feature: FR/NFR traceability, C4/ADR content, task decomposition, dependency mapping, risk analysis, version proposal, or review package. Prefer improving existing artifacts over creating duplicates. If no Feature is approved for solution, document the exact waiting gate or actionable clarification instead of advancing unapproved work. @@ -211,7 +217,7 @@ Requires team approval for: ## Verification Checklist -- [ ] Only the four same-project channels were inspected. +- [ ] Only the five same-project channels were inspected. - [ ] Architecture documentation reflects verified status. - [ ] C4 scope and level are appropriate. - [ ] `drawio-main` governed every diagram change. @@ -219,6 +225,7 @@ Requires team approval for: - [ ] Every solution Feature has explicit human `Approved for Solution` evidence. - [ ] Eligible Features have dependency-aware task breakdowns and version proposals. - [ ] Only a human team member moved a Feature to `Approved for Implementation` or finalized its version. +- [ ] Tasks were proposed to Kanban with readiness/dependency evidence; Architecture did not self-admit them to Focus `InBacklog`. - [ ] At least one useful solution artifact was improved, or the exact human approval/clarification gate was documented. - [ ] Proposed items remain visibly proposed. - [ ] Documentation and diagram checks passed.