commit 4faf71358f8adcc05357e09a8ec7490ed17fa768 Author: Jarvis Jr Hermes Date: Thu Aug 13 19:33:31 2026 +0000 feat: define Scope channel operations diff --git a/SKILL.md b/SKILL.md new file mode 100644 index 0000000..c6c7328 --- /dev/null +++ b/SKILL.md @@ -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--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--general +corp-v1--scope +corp-v1--architecture +corp-v1--kanban +corp-v1--delivery +corp-v1--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 + -EP-1 + -FT-1 + -FT-2 + -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: -EP- +Feature: -FT- +``` + +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.