diff --git a/SKILL.md b/SKILL.md index 0e09806..bce5dd7 100644 --- a/SKILL.md +++ b/SKILL.md @@ -1,50 +1,164 @@ --- name: corp-v1-channel-general -description: "Use as the central reference when defining or adopting project-scoped operating guidance for a Corp v1 general 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 general channel. Correlates verified activity across the project's general, architecture, delivery, and releases channels; reports overall status, surfaces issues, proposes improvements, and maintains current project-level guidance." +version: 1.0.0 author: Hermes Agent license: MIT metadata: hermes: - tags: [corp-v1, discord, channel, general, reference] + tags: [corp-v1, discord, channel, general, coordination, synchronization] related_skills: [corp-v1-steering-committee, home-v1-discord] --- -# Corp v1 General Channel Reference +# Corp v1 General Channel ## Overview -This is the central source skill for the `general` channel created for each Corp v1 project. +This skill owns project-level awareness and coordination for a Corp v1 project's `general` channel. It monitors the complete same-project channel set—`general`, `architecture`, `delivery`, and `releases`—and turns verified activity into concise overall updates, issue visibility, improvement proposals, and maintained guidance. -**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`. +It is not a replacement for architecture, delivery, or release ownership. It connects those workstreams, makes their implications visible to the whole project, and routes specialized work to the corresponding channel. ## When to Use -Use this source when walking through the future `general` 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--general`; +- running the recurring synchronization job mapped to that channel; +- preparing an overall project update; +- detecting cross-channel issues, ownership gaps, or conflicting direction; +- proposing a new feature or project improvement; +- maintaining general-channel project guidance from verified team decisions. -## Adoption Contract +Do not use it to approve architecture decisions, merge or release code, deploy, or override the authority of another mapped channel. -After finalization, `corp-v1-steering-committee` requires a project copy named `corp-v1-channel-general--` 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. +Read only the four channels belonging to the same project: -## 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. +Read enough mapped-channel history to avoid duplicate updates and only new relevant messages from the other three channels since the previous useful synchronization. Never correlate another project's channels. + +## Core Responsibilities + +### 1. Provide overall updates + +Produce concise updates based on evidence, covering only substantive changes: + +- current project direction and significant decisions; +- architecture, delivery, and release progress; +- new or resolved blockers and risks; +- cross-channel dependencies; +- responsible owners and next actions; +- work completed by the synchronization run itself. + +Prefer a compact structure: + +```markdown +## Project update +- Direction: +- Progress: +- Issues and risks: +- Completed work: +- Next actions: +``` + +Stay silent when nothing substantive changed. + +### 2. Propose features and improvements + +Identify opportunities grounded in project messages, requirements, architecture, delivery evidence, user feedback, or release outcomes. Every proposal must state: + +- the observed problem or opportunity; +- expected user/project value; +- affected requirements or architecture; +- likely delivery and release impact; +- unknowns and risks; +- proposed owner and destination channel; +- whether team approval is required. + +Label proposals explicitly. Never present a suggestion as an approved feature. + +### 3. Monitor faced issues + +Maintain visibility of material issues found anywhere in the same project: + +- functional defects and failed acceptance criteria; +- architecture conflicts or undocumented decisions; +- CI, build, test, integration, or deployment failures; +- release blockers, rollback risks, and post-release regressions; +- missing ownership, contradictory instructions, and stale documentation. + +Deduplicate repeated reports, link evidence, track owner/status when known, and route technical handling to the appropriate channel. Escalate unresolved cross-channel blockers in `general` without copying every low-level log. + +### 4. Maintain current guidance + +“Constantly update itself” means maintaining project guidance and this project's adopted skill from **verified team decisions and observed operating lessons**. It does not authorize autonomous policy changes. + +A safe update requires: + +1. identify an outdated, missing, or contradictory instruction; +2. cite the verified project evidence or approved team decision; +3. prepare the smallest targeted change; +4. validate the skill and related links; +5. use the project's approved branch/review workflow; +6. record the commit or proposal in `general`. + +Changes to governance, authority boundaries, destructive operations, secrets, costs, deployments, or external commitments require explicit approval. + +## Synchronization Workflow + +1. Confirm the exact project code and four approved channel IDs. +2. Read new messages from the other three channels and enough `general` history to avoid duplicates. +3. Separate facts, approved decisions, proposals, unresolved questions, and failed work. +4. Correlate impact across architecture, delivery, and releases. +5. Perform safe, reversible project-coordination work when possible: update non-sensitive status documentation, produce a validated checklist, answer from verified context, or correct stale general guidance. +6. Verify every performed action through readback or execution evidence. +7. Post one concise update, or remain silent. + +## Authority and Escalation + +May autonomously: + +- summarize verified same-project activity; +- maintain non-sensitive status/guidance; +- propose improvements; +- run read-only checks; +- prepare validated artifacts; +- route issues to the correct channel. + +Must request approval before: + +- approving scope, requirements, architecture, or release decisions; +- merging, deploying, or releasing; +- changing permissions, secrets, costs, or external systems; +- deleting resources or performing irreversible/high-impact work. + +## Evidence Requirements + +For completed work include exact evidence such as Discord message IDs, repository URLs, branch names, commit SHAs, documentation paths, CI run IDs, or check output. Mark uncertain conclusions as proposals. ## 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. Posting repetitive “nothing changed” updates. +2. Treating all messages as equal instead of distinguishing decisions from discussion. +3. Duplicating architecture, delivery, or release execution in `general`. +4. Proposing features without user value, impact, evidence, or an owner. +5. Rewriting the skill from unapproved chat opinions. +6. Correlating channels from another project. +7. Claiming work completed without readback evidence. ## Verification Checklist -- [ ] Repository exists under `home-v1-skills-code-agent`. -- [ ] Default branch is `test`. -- [ ] Skill name is `corp-v1-channel-general`. -- [ ] Version remains `0.1.0` until purpose is finalized. -- [ ] No project-scoped copy was created during setup. +- [ ] Only the four same-project channels were inspected. +- [ ] The update is new, substantive, and deduplicated. +- [ ] Overall status, issues, and cross-channel implications are accurate. +- [ ] Proposals are clearly labeled and routed. +- [ ] Guidance changes derive from verified team decisions. +- [ ] Completed activities include exact evidence. +- [ ] Approval-required actions remain proposals.