corp-v1-channel-general/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, scope, architecture, kanban, delivery, and releases channels; reports overall status, surfaces issues, and maintains project-level guidance."
version: 1.7.1
author: Hermes Agent
license: MIT
metadata:
  hermes:
    tags: [corp-v1, discord, channel, general, coordination, synchronization]
    related_skills: [corp-v1-main, home-v1-discord, documentation-docusaurus, corp-v1-glossary]
---

# 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`, `scope`, `architecture`, `ui-ux`, `kanban`, `delivery`, and `releases`—and turns verified activity into concise overall updates, issue visibility, and maintained guidance. Scope owns the authoritative Roadmap, Ideas, Epics, and Features; General may propose improvements and routes them to Scope instead of duplicating records.

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.

Load the global `documentation-docusaurus` skill from `https://gitea.lego-cloud.eu/home-v1-skills-code-agent/documentation-docusaurus` before changing documentation structure, navigation, Markdown/MDX, Docusaurus configuration, or builds.

Load the global `corp-v1-glossary` skill from `https://gitea.lego-cloud.eu/home-v1-skills-code-agent/corp-v1-glossary` whenever project documentation needs to define or explain a reusable term. Maintain one canonical definition in the project's final top-level **Glossary** area and link to it from the owning domain page; do not duplicate glossary-style explanations across channel documentation.

## Shared Corp v1 System Login

When an authorized task requires login to a Corp v1 system being built or operated, follow the shared policy in `corp-v1-main` and use only the Bitwarden-injected runtime secrets named:

```text
HL_V1_SSO_EMAIL
HL_V1_SSO_PASSWORD
```

Secret availability is capability, not authorization. Verify the destination origin and task purpose before login. Never print, inspect, log, hash, serialize, paste, screenshot, or persist either value; never place a value in a command line, URL, file, repository, prompt, Discord message, browser console, test fixture, CI output, or generated artifact. Never ask a human to paste a value into chat. If a variable is unavailable, report only its missing name and request Bitwarden/gateway injection. Login does not authorize account recovery, MFA or credential changes, permission changes, billing, spending, destructive operations, or access outside the approved project task.

## When to Use

Use this skill when:

- operating in `corp-v1-<code>-general`;
- running an explicitly Board-approved recurring bootstrap 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 unless a preserved project-local authorization override explicitly delegates those exact actions during a bounded bootstrap phase.

## Governed bootstrap autonomy

The Corp v1 default is no project scheduler. One 30-minute General-channel bootstrap job is permitted only when the project's approved kickoff decision and adopted General skill contain the same preserved project-local authorization override.

The override must identify the Board evidence, project, delegator, delegate, exact seven channels, autonomous actions, safety exclusions, and a **first-human-message stop condition**. Before every mutation, the job must scan all seven project channels after its frozen high-watermarks and distinguish human authors from bots, webhooks, and Hermes. If any human-authored project-channel message exists after bootstrap began, the job must make no further autonomous mutation, cite the message and channel, post one stop report in General, and pause or remove itself.

During an active approved bootstrap phase, the job may load the mapped project channel and engineering skills and advance approved MVP artifacts across Scope, Architecture, UI/UX, Kanban, Delivery, and Releases. It must preserve canonical ownership, exact-head validation, remote readback, and review evidence. It may not expose or change secret values, spend money, purchase goods, enable production payments, alter vendor accounts, make legal/commercial commitments, perform unrelated infrastructure work, or execute destructive/irreversible actions.

## Approved Information Boundary

Read only the seven channels belonging to the same project:

```text
corp-v1-<code>-general
corp-v1-<code>-scope
corp-v1-<code>-architecture
corp-v1-<code>-ui-ux
corp-v1-<code>-kanban
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 six 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.

## Kanban Handoff

General preserves authoritative Epic/Feature identity and Scope lifecycle evidence. Kanban consumes these records for active Board and Focus views but must not redefine them. Every status change must retain stable Scope links and approval evidence so Kanban can reconcile flow without inventing state.

## UI/UX Coordination

UI/UX owns frontend experience and interface-design work. General routes user-facing design needs and cross-channel design risks to `corp-v1-<code>-ui-ux`; it does not duplicate Penpot artifacts or design-package approval records.

## Synchronization Workflow

1. Confirm the exact project code and seven approved channel IDs.
2. Read new messages from the other six channels and enough `general` history to avoid duplicates.
3. Separate facts, approved decisions, proposals, unresolved questions, and failed work.
4. Correlate impact across architecture, Kanban, 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.

An exact project-local bootstrap override may delegate specified approval items above until its stop condition. Generic autonomy never does. The override cannot waive credential safety, spending, legal/commercial, destructive-operation, production-payment, or external-account gates.

## 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 seven 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.
- [ ] When a bootstrap job is active, its override, seven-channel boundary, frozen high-watermarks, human-message check, General delivery target, and scheduler state are verified.