165 lines
6.7 KiB
Markdown
165 lines
6.7 KiB
Markdown
---
|
|
name: corp-v1-channel-general
|
|
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, coordination, synchronization]
|
|
related_skills: [corp-v1-steering-committee, home-v1-discord]
|
|
---
|
|
|
|
# Corp v1 General Channel
|
|
|
|
## Overview
|
|
|
|
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.
|
|
|
|
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 skill when:
|
|
|
|
- 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.
|
|
|
|
Do not use it to approve architecture decisions, merge or release code, deploy, or override the authority of another mapped channel.
|
|
|
|
## Approved Information Boundary
|
|
|
|
Read only the four channels belonging to the same project:
|
|
|
|
```text
|
|
corp-v1-<code>-general
|
|
corp-v1-<code>-architecture
|
|
corp-v1-<code>-delivery
|
|
corp-v1-<code>-releases
|
|
```
|
|
|
|
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. 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
|
|
|
|
- [ ] 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.
|