187 lines
9.0 KiB
Markdown
187 lines
9.0 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.1.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, maintained guidance, and a durable project-documentation backlog of proposed Epics and Features.
|
|
|
|
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, refining, or documenting Epics, Features, and project improvements;
|
|
- 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 Epics, Features, and improvements
|
|
|
|
Identify opportunities grounded in project messages, requirements, architecture, delivery evidence, user feedback, or release outcomes. Hermes is an active participant in discovery: on every synchronization iteration, add or materially improve at least one useful project artifact when safe and evidence permits. Prefer refining an existing item over creating noise or duplicates.
|
|
|
|
All Epics and Features must live in the project documentation repository, not only in Discord. Maintain a durable product registry with stable IDs such as `EPIC-0001` and `FEAT-0001`, links between Features and parent Epics, and preserved status history.
|
|
|
|
Minimum fields:
|
|
|
|
```text
|
|
Epic: ID | title | problem/opportunity | intended outcome | value | status | owner | feature links | evidence
|
|
Feature: ID | epic | user/problem statement | expected value | scope | acceptance outcomes | status | owner | dependencies | evidence
|
|
```
|
|
|
|
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.
|
|
|
|
Use lifecycle states `Proposed`, `Approved for Solution`, `Rejected`, or `Deferred`. Only a human team member may move an Epic or Feature to `Approved for Solution`. Hermes may propose and refine items, but must never approve its own proposal or imply approval from silence.
|
|
|
|
## Project Documentation Ownership
|
|
|
|
The project documentation repository is authoritative for Epics, Features, overall project status, issues, and durable general-channel decisions. Discord announces and discusses changes; it does not replace documentation.
|
|
|
|
Each useful iteration must add or materially improve at least one evidence-based artifact—for example a grounded proposal, better value/scope/acceptance outcomes, deduplication, status from an explicit human decision, cross-links, or a concrete unanswered product question. Never create filler merely to satisfy cadence. If evidence is insufficient, document and raise the specific blocker/question.
|
|
|
|
### 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. Inspect the project documentation's Epic/Feature and status registries.
|
|
6. Add or materially improve at least one useful evidence-based documentation artifact; never create filler solely to satisfy cadence.
|
|
7. Perform other safe, reversible coordination work when useful.
|
|
8. Verify every performed action through checks and remote readback.
|
|
9. Post one concise update with documentation path and commit evidence, or state the concrete blocker that prevented a useful change.
|
|
|
|
## Authority and Escalation
|
|
|
|
May autonomously:
|
|
|
|
- summarize verified same-project activity;
|
|
- maintain non-sensitive status/guidance;
|
|
- propose and document Epics, Features, and 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 instead of contributing useful documentation.
|
|
2. Treating all messages as equal instead of distinguishing decisions from discussion.
|
|
3. Duplicating architecture, delivery, or release execution in `general`.
|
|
4. Proposing Epics or Features without user value, acceptance outcomes, 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.
|
|
- [ ] Epics and Features are persisted in project documentation with stable IDs and lifecycle state.
|
|
- [ ] At least one useful artifact was added or materially improved, or a concrete evidence blocker was raised.
|
|
- [ ] No Epic or Feature was marked `Approved for Solution` without an explicit human team-member decision.
|
|
- [ ] Guidance changes derive from verified team decisions.
|
|
- [ ] Completed activities include exact evidence.
|
|
- [ ] Approval-required actions remain proposals.
|