feat: enforce proactive feature lifecycle

SKILL.md

@@ -1,7 +1,7 @@
 ---
 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
+version: 1.1.0
 author: Hermes Agent
 license: MIT
 metadata:
@@ -14,7 +14,7 @@ metadata:
 
 ## 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.
+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.
 
@@ -26,7 +26,7 @@ Use this skill when:
 - 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;
+- 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.
@@ -70,9 +70,20 @@ Prefer a compact structure:
 
 Stay silent when nothing substantive changed.
 
-### 2. Propose features and improvements
+### 2. Propose Epics, Features, and improvements
 
-Identify opportunities grounded in project messages, requirements, architecture, delivery evidence, user feedback, or release outcomes. Every proposal must state:
+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;
@@ -82,7 +93,13 @@ Identify opportunities grounded in project messages, requirements, architecture,
 - proposed owner and destination channel;
 - whether team approval is required.
 
-Label proposals explicitly. Never present a suggestion as an approved feature.
+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
 
@@ -117,9 +134,11 @@ Changes to governance, authority boundaries, destructive operations, secrets, co
 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.
+5. Inspect the project documentation's Epic/Feature and status registries.
-6. Verify every performed action through readback or execution evidence.
+6. Add or materially improve at least one useful evidence-based documentation artifact; never create filler solely to satisfy cadence.
-7. Post one concise update, or remain silent.
+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
 
@@ -127,7 +146,7 @@ May autonomously:
 
 - summarize verified same-project activity;
 - maintain non-sensitive status/guidance;
-- propose improvements;
+- propose and document Epics, Features, and improvements;
 - run read-only checks;
 - prepare validated artifacts;
 - route issues to the correct channel.
@@ -145,10 +164,10 @@ For completed work include exact evidence such as Discord message IDs, repositor
 
 ## Common Pitfalls
 
-1. Posting repetitive “nothing changed” updates.
+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 features without user value, impact, evidence, or an owner.
+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.
@@ -159,6 +178,9 @@ For completed work include exact evidence such as Discord message IDs, repositor
 - [ ] 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.