diff --git a/SKILL.md b/SKILL.md index bd8dd89..6e366d1 100644 --- a/SKILL.md +++ b/SKILL.md @@ -1,50 +1,180 @@ --- name: corp-v1-channel-delivery -description: "Use as the central reference when defining or adopting project-scoped operating guidance for a Corp v1 delivery channel. This repository is initial setup only; detailed purpose and procedures remain pending steering walkthrough." -version: 0.1.0 +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.0.0 author: Hermes Agent license: MIT metadata: hermes: - tags: [corp-v1, discord, channel, delivery, reference] + tags: [corp-v1, discord, channel, delivery, coding, testing, ci] related_skills: [corp-v1-steering-committee, home-v1-discord] --- -# Corp v1 Delivery Channel Reference +# Corp v1 Delivery Channel ## Overview -This is the central source skill for the `delivery` channel created for each Corp v1 project. +This skill owns delivery health for a Corp v1 project. It monitors the project's `general`, `architecture`, `delivery`, and `releases` channels and turns approved requirements and architecture into implemented, tested, integrated, documented work. -**Current status: setup only.** Its detailed purpose, responsibilities, procedures, artifacts, authority boundaries, and verification rules are intentionally not defined yet. They will be agreed in a separate walkthrough before promotion beyond version `0.1.0`. +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. ## When to Use -Use this source when walking through the future `delivery` channel skill, creating a reviewed project copy after finalization, or comparing an adopted copy with its source. +Use this skill when: -Do not use this version as complete operating guidance for a live project channel. +- operating in `corp-v1--delivery`; +- running its recurring synchronization job; +- implementing or reviewing project code; +- adding or repairing unit tests; +- diagnosing build or CI failures; +- checking implementation against requirements and ADRs; +- maintaining delivery-oriented documentation. -## Adoption Contract +Do not use it to silently choose between contradictory requirements or architecture decisions, approve releases, or bypass review and branch protections. -After finalization, `corp-v1-steering-committee` requires a project copy named `corp-v1-channel-delivery--` under `corp-v1--skills-code-agent`. Adoption preserves source history and attribution, applies project context, validates the result, and records the source branch and commit. +## Approved Information Boundary -Creating existing-project copies is explicitly deferred until separately requested. +Inspect only the project's four channels: -## Purpose Definition Pending +```text +corp-v1--general +corp-v1--architecture +corp-v1--delivery +corp-v1--releases +``` -The walkthrough must define channel outcomes, responsibilities, activities, artifacts, cross-channel relationships, applicable engineering skills, synchronization behavior, approval boundaries, and verification criteria. +Use enough delivery history to avoid duplicate work and only relevant new activity from the other channels. Never inspect another project. + +## Delivery Responsibilities + +### Coding + +- implement only approved/authorized scope; +- 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. + +### 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. + +### Build and continuous integration + +Monitor local builds and Gitea Actions for: + +- 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. + +## Failure-Repair Workflow + +When a build or CI failure is observed: + +1. verify repository, branch, head SHA, failed job, 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. + +The skill may attempt a safe fix when the failure and expected behavior are clear. If evidence is insufficient or requirements/architecture conflict, stop and raise the issue in the relevant channel: + +- requirement/product ambiguity → `general` and/or `architecture` as appropriate; +- architecture contradiction → `architecture`; +- release policy/readiness ambiguity → `releases`; +- implementation-only blocker → `delivery`. + +Never guess the team's intended direction. + +## Documentation Ownership + +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 testing** — commands, unit/integration testing, fixtures, and debugging. +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. + +Update these pages from verified project practice. Do not document a planned process as already operational. + +## Synchronization Workflow + +1. Read new same-project activity and enough delivery history to avoid duplicates. +2. Identify executable work, CI failures, blockers, requirements/ADR implications, and documentation drift. +3. Load all applicable project engineering skills. +4. Perform safe authorized work when scope and expected outcome are clear. +5. Escalate uncertainty or contradiction rather than selecting direction. +6. Verify local and remote results. +7. Maintain Ways of Working and Engineering pages when durable practice changed. +8. Post a concise update with work completed, evidence, blockers, and required decisions; otherwise stay silent. + +## Authority and Escalation + +May autonomously: + +- run tests/builds/read-only checks; +- repair clear CI/build defects within authorized scope; +- add tests for an approved behavior; +- maintain accurate delivery documentation; +- prepare branches/commits/PRs where the project workflow authorizes it. + +Requires approval before: + +- changing requirements or architecture to make tests pass; +- merging protected changes; +- deploying or releasing; +- changing secrets, permissions, costs, external services, or destructive resources; +- suppressing required quality/security gates. + +## 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. ## Common Pitfalls -1. Treating this setup scaffold as finalized policy. -2. Creating project copies before the requested migration. -3. Defining behavior indirectly instead of completing the walkthrough. -4. Losing source history or attribution during adoption. +1. Patching symptoms before understanding root cause. +2. Changing requirements or architecture implicitly through code. +3. Claiming CI success from a local build. +4. Editing without loading applicable project engineering skills. +5. Skipping tests for behavioral fixes. +6. Updating documentation with aspirational rather than actual practice. +7. Repeatedly posting unchanged failure summaries. +8. Inspecting another project. ## Verification Checklist -- [ ] Repository exists under `home-v1-skills-code-agent`. -- [ ] Default branch is `test`. -- [ ] Skill name is `corp-v1-channel-delivery`. -- [ ] Version remains `0.1.0` until purpose is finalized. -- [ ] No project-scoped copy was created during setup. +- [ ] Only same-project channels and repositories were used. +- [ ] Work maps to approved requirements/architecture. +- [ ] Applicable project skills were loaded. +- [ ] Tests and builds were actually run. +- [ ] Remote branch and matching CI head SHA were verified. +- [ ] Contradictions were escalated, not guessed through. +- [ ] Ways of Working and Engineering documentation remains accurate. +- [ ] Completed work includes exact evidence.