feat: define general channel operations
This commit is contained in:
@@ -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."
|
||||
version: 0.1.0
|
||||
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, 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.
|
||||
2. Creating project copies before the requested migration.
|
||||
3. Defining behavior indirectly instead of completing the walkthrough.
|
||||
4. Losing source history or attribution during adoption.
|
||||
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
|
||||
|
||||
- [ ] Repository exists under `home-v1-skills-code-agent`.
|
||||
- [ ] Default branch is `test`.
|
||||
- [ ] Skill name is `corp-v1-channel-general`.
|
||||
- [ ] Version remains `0.1.0` until purpose is finalized.
|
||||
- [ ] No project-scoped copy was created during setup.
|
||||
- [ ] 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.
|
||||
|
||||
Reference in New Issue
Block a user