feat: define general channel operations

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."
+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: 0.1.0
+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-<code>-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--<code>` under `corp-v1-<code>-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-<code>-general
+corp-v1-<code>-architecture
+corp-v1-<code>-delivery
+corp-v1-<code>-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.
+1. Posting repetitive “nothing changed” updates.
-2. Creating project copies before the requested migration.
+2. Treating all messages as equal instead of distinguishing decisions from discussion.
-3. Defining behavior indirectly instead of completing the walkthrough.
+3. Duplicating architecture, delivery, or release execution in `general`.
-4. Losing source history or attribution during adoption.
+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`.
+- [ ] Only the four same-project channels were inspected.
-- [ ] Default branch is `test`.
+- [ ] The update is new, substantive, and deduplicated.
-- [ ] Skill name is `corp-v1-channel-general`.
+- [ ] Overall status, issues, and cross-channel implications are accurate.
-- [ ] Version remains `0.1.0` until purpose is finalized.
+- [ ] Proposals are clearly labeled and routed.
-- [ ] No project-scoped copy was created during setup.
+- [ ] Guidance changes derive from verified team decisions.
+- [ ] Completed activities include exact evidence.
+- [ ] Approval-required actions remain proposals.