feat: define Scope channel operations

2026-08-13 19:33:31 +00:00
commit 4faf71358f
1 changed files with 177 additions and 0 deletions
@@ -0,0 +1,177 @@
 ---
 name: corp-v1-channel-scope
 description: "Use when operating or synchronizing a Corp v1 project's Scope channel. Owns Roadmap, Epics, Features, and Ideas; correlates all six same-project channels; proactively improves evidence-based product scope; and records human approval before work enters Architecture solution design."
 version: 1.0.0
 author: Hermes Agent
 license: MIT
 metadata:
  hermes:
    tags: [corp-v1, discord, channel, scope, roadmap, epics, features, discovery]
    related_skills: [corp-v1-steering-committee, home-v1-discord, documentation-docusaurus]
 ---
 # Corp v1 Scope Channel
 ## Overview
 This skill owns product discovery and durable scope for a Corp v1 project's `scope` channel. It monitors the six same-project channels—`general`, `scope`, `architecture`, `kanban`, `delivery`, and `releases`—and maintains the project documentation's top-level **Scope** area.
 Scope owns Roadmap, Epics, Features, and Ideas. General coordinates overall project awareness but does not duplicate Scope records. Architecture performs solution work only for Features explicitly approved for solution by a human team member. Hermes participates proactively by proposing and refining useful scope, but never approves its own proposals.
 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.
 ## When to Use
 Use this skill when:
 - operating in `corp-v1-<code>-scope`;
 - running its recurring synchronization job;
 - maintaining Roadmap, Epics, Features, or Ideas;
 - discovering user/project problems and opportunities;
 - refining value, scope, acceptance outcomes, dependencies, or risks;
 - preparing an Epic or Feature for human `Approved for Solution` review;
 - reconciling scope against architecture, Kanban, delivery, or release evidence.
 Do not use it to design architecture, approve solution entry, approve implementation, admit tasks to Kanban Focus, implement code, or authorize releases.
 ## Approved Information Boundary
 Inspect only:
 ```text
 corp-v1-<code>-general
 corp-v1-<code>-scope
 corp-v1-<code>-architecture
 corp-v1-<code>-kanban
 corp-v1-<code>-delivery
 corp-v1-<code>-releases
 ```
 Read enough Scope history to avoid duplicates and only relevant new activity from the other five channels. Never inspect or correlate another project's channels.
 ## Human Approval Gate
 Only a human team member may move an Epic or Feature to `Approved for Solution`. Hermes may propose, investigate, refine, deduplicate, identify dependencies, prepare acceptance outcomes, and recommend approval. Silence, an agent statement, CI success, delivery activity, or a forecast is not approval.
 Record approver identity, decision evidence, date, resulting status, and conditions. Architecture may begin solution work only after this evidence exists.
 ## Documentation Contract
 `Scope` is a top-level menu item immediately before `Architecture`, with its own dedicated sidebar:
 ```text
 Roadmap
 Epics
  <CODE>-EP-1
    <CODE>-FT-1
    <CODE>-FT-2
  <CODE>-EP-2
    ...
 Ideas
 ```
 ### Roadmap
 Show verified current state and predicted plans at Epic and Feature level. Distinguish approved/current facts from forecasts and proposals. Include sequence or horizon, status, dependencies, material blockers, owner, and last evidence/update date.
 ### Epics and Features
 Use stable project-scoped IDs:
 ```text
 Epic:    <UPPERCASE_PROJECT_CODE>-EP-<NUMBER>
 Feature: <UPPERCASE_PROJECT_CODE>-FT-<NUMBER>
 ```
 Allocate numbers monotonically. Never reuse or renumber an ID after rejection, deferral, deletion, or consolidation.
 Minimum Epic fields:
 ```text
 ID | title | problem/opportunity | intended outcome | value | status | owner | Feature links | evidence
 ```
 Minimum Feature fields:
 ```text
 ID | Epic | user/problem statement | expected value | scope | acceptance outcomes | status | owner | dependencies | risks | evidence
 ```
 Each Epic page contains a linked Features table with current statuses. Each Feature page contains title, description, value, scope, acceptance outcomes, dependencies, risks, human approval evidence, and a linked table of authoritative Architecture tasks when they exist. Scope never creates duplicate task identities.
 Lifecycle states are `Proposed`, `Approved for Solution`, `Rejected`, or `Deferred`.
 ### Ideas
 Ideas are early opportunities not yet accepted as Epics or Features. Record stable local reference, title, description, evidence/source, owner when known, status, and resulting Epic/Feature links. Preserve provenance after promotion.
 ## Proactive Iteration Requirement
 Every Scope iteration must add or materially improve at least one evidence-based scope artifact when a safe path exists: a grounded Idea, Epic, or Feature; clearer value or acceptance outcomes; dependency/risk evidence; deduplication; Roadmap reconciliation; cross-links; or a concrete unanswered product question. Never create filler to satisfy cadence.
 Use evidence from all six same-project channels. Delivery and release outcomes may expose new Ideas or required scope corrections; Architecture may expose infeasible assumptions; Kanban may expose flow or dependency problems. Preserve authority boundaries while incorporating that evidence.
 ## Handoffs
 - **Scope → Architecture:** only human-approved Features with stable ID, parent Epic, value, scope, acceptance outcomes, dependencies, risks, and approval evidence.
 - **Architecture → Scope:** feasibility constraints, requirement implications, dependencies, and proposed scope clarifications; Architecture does not silently rewrite product scope.
 - **Scope → Kanban:** stable Epic/Feature identities and lifecycle state for Board/Focus reconciliation.
 - **Delivery/Releases → Scope:** verified outcomes, regressions, user feedback, and follow-up opportunities that may alter the Roadmap or create Ideas.
 - **Scope → General:** concise overall implications, decisions requiring visibility, owners, and cross-channel blockers.
 ## Synchronization Workflow
 1. Confirm the exact project code and six approved channel IDs.
 2. Read new activity from the other five channels and enough Scope history to avoid duplication.
 3. Separate verified facts, human decisions, proposals, forecasts, and unresolved questions.
 4. Inspect Roadmap, Epics, Features, Ideas, links, IDs, lifecycle states, and approval evidence.
 5. Reconcile architecture feasibility, Kanban flow, delivery progress, and release outcomes against scope.
 6. Add or materially improve at least one useful evidence-based artifact, or document the exact evidence/approval blocker.
 7. Load `documentation-docusaurus`, validate menu order, dedicated sidebar, hierarchy, links, and documentation build, then verify remote state.
 8. Post a concise Scope update with changed artifacts, implications, human gate, and exact evidence. Stay silent when no substantive result exists.
 ## Authority and Escalation
 May autonomously:
 - summarize verified same-project scope implications;
 - propose and refine Ideas, Epics, and Features;
 - maintain Roadmap mechanics, links, IDs, and evidence;
 - record explicit human decisions;
 - run read-only checks and documentation validation;
 - repair clear non-semantic documentation defects.
 Requires human approval for:
 - moving an Epic or Feature to `Approved for Solution`;
 - materially accepting/rejecting product scope;
 - changing governance, architecture, implementation, version, or release decisions;
 - permissions, credentials, spending, external contact, or irreversible/high-impact work.
 ## Common Pitfalls
 1. Treating General as the authoritative owner of Scope records.
 2. Approving a proposal because nobody objected.
 3. Creating Epics or Features without evidence, value, acceptance outcomes, owner, or dependencies.
 4. Using generic IDs instead of project-scoped stable IDs.
 5. Duplicating Architecture task records in Scope.
 6. Mixing approved/current state with predictions in the Roadmap.
 7. Ignoring Architecture, Kanban, Delivery, or Releases evidence.
 8. Inspecting another project's channels.
 9. Posting repetitive status instead of improving durable documentation.
 10. Claiming completion without build and remote readback evidence.
 ## Verification Checklist
 - [ ] Only the six same-project channels were inspected.
 - [ ] Scope appears immediately before Architecture with its own sidebar.
 - [ ] Sidebar order is Roadmap, Epics with nested Features, then Ideas.
 - [ ] Roadmap distinguishes verified current state from predicted plans.
 - [ ] Epics and Features use stable project-scoped IDs and valid parent-child links.
 - [ ] Every Epic links child Features; every Feature links authoritative tasks when present.
 - [ ] Ideas preserve provenance when promoted.
 - [ ] At least one useful artifact was improved, or an exact evidence/approval blocker was recorded.
 - [ ] No Epic or Feature entered `Approved for Solution` without explicit human evidence.
 - [ ] Architecture handoff contains value, scope, acceptance outcomes, dependencies, risks, and approval evidence.
 - [ ] Documentation build, links, and remote readback passed.
 - [ ] Completed work includes exact message, path, commit, URL, or run evidence.