corp-v1-channel-general-3darch/SKILL.md

---
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.2.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, Features, and Ideas must live in the project documentation repository, not only in Discord. Use the uppercase project code in stable identifiers:

```text
Epic:    <UPPERCASE_PROJECT_CODE>-EP-<NUMBER>
Feature: <UPPERCASE_PROJECT_CODE>-FT-<NUMBER>
```

For project code `xyz`, examples are `XYZ-EP-1`, `XYZ-EP-2`, `XYZ-FT-1`, and `XYZ-FT-2`. Allocate each type's next number monotonically. Never reuse an ID after rejection, deferral, deletion, or consolidation, and never renumber existing records merely to close a gap.

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 Roadmap, Epics, Features, Ideas, overall project status, issues, and durable general-channel decisions. Discord announces and discusses changes; it does not replace documentation.

### Mandatory Scope information architecture

Every project documentation site must expose **Scope** as a top-level navigation item immediately **before Architecture**. Scope must be a dedicated documentation area with its own sidebar—not a category inside another area's sidebar.

The Scope sidebar order and hierarchy are mandatory:

```text
Roadmap
Epics
  <CODE>-EP-1
    <CODE>-FT-1
    <CODE>-FT-2
  <CODE>-EP-2
    ...
Ideas
```

The pages and navigation must satisfy this contract:

1. **Roadmap** always reflects both the verified current situation and the predicted upcoming plan at Epic and Feature level. Distinguish actual/approved state from forecasts and proposals; include status, sequence or horizon, dependencies, material blockers, and last evidence/update date. Refresh it whenever an Epic or Feature changes materially.
2. **Epics** is the ordered registry and hierarchy for all Epic records. Each Epic has its own page titled with its stable `<CODE>-EP-N` ID and human-readable title.
3. Each **Epic page** contains at least the Epic title, description, and a Features section with a table linking every child Feature and showing its current status. The table must not contain unlinked or nonexistent Feature IDs.
4. Each **Feature** is nested under its parent Epic in the sidebar and has its own page titled with its stable `<CODE>-FT-N` ID and human-readable title.
5. Each **Feature page** contains at least the Feature title, description, and a Tasks section with a table linking every architecture-owned implementation task and showing its current status. Preserve the task identifiers established by the Architecture channel; do not create duplicate General-channel task records.
6. **Ideas** tracks early opportunities that are not yet accepted as Epics or Features. Each Idea records a stable local reference, title, description, evidence/source, owner when known, status, and any resulting Epic/Feature link. Promotion preserves provenance rather than deleting the Idea.

Minimum Epic Features table:

```markdown
| Feature | Title | Status |
|---|---|---|
| [XYZ-FT-1](./xyz-ft-1) | Example feature | Proposed |
```

Minimum Feature Tasks table:

```markdown
| Task | Title | Status |
|---|---|---|
| [authoritative task ID](task-record-link) | Example task | Planned |
```

Validate top-menu order, Scope's dedicated sidebar, hierarchy, unique IDs, parent-child relationships, and every Epic→Feature and Feature→Task link during documentation builds. Empty registries require useful empty-state pages; they do not justify omitting Scope, Roadmap, Epics, or Ideas.

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 Scope navigation, Roadmap, Epics, Features, Ideas, task links, and lifecycle status.
6. Reconcile the Roadmap whenever current or predicted Epic/Feature state changed.
7. Add or materially improve at least one useful evidence-based documentation artifact; never create filler solely to satisfy cadence.
8. Perform other safe, reversible coordination work when useful.
9. Validate Scope menu order, dedicated sidebar hierarchy, identifiers, relationships, links, and the documentation build; verify changes through remote readback.
10. 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.
8. Placing Scope after Architecture or embedding it in another area's sidebar.
9. Using generic `EPIC-0001`/`FEAT-0001` IDs instead of project-scoped `<CODE>-EP-N`/`<CODE>-FT-N` IDs.
10. Letting the Roadmap become a static wish list that does not distinguish current evidence from predicted plans.
11. Listing Features or Tasks without links, current statuses, or valid parent relationships.

## 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.
- [ ] Scope appears immediately before Architecture in the top menu and uses its own sidebar.
- [ ] Scope sidebar order is Roadmap, Epics with nested Features, then Ideas.
- [ ] Roadmap shows current evidence and predicted Epic/Feature plans distinctly and is current.
- [ ] Epics and Features use stable `<CODE>-EP-N` and `<CODE>-FT-N` IDs and lifecycle state.
- [ ] Every Epic links all child Features with statuses; every Feature links all authoritative tasks with statuses.
- [ ] Ideas and their promotion provenance are maintained.
- [ ] 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.