Compare commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
4d363b9c45 | ||
|
|
8a456cc5ce | ||
|
|
924ab161df | ||
|
|
d893597905 |
@@ -1,7 +1,7 @@
|
||||
---
|
||||
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.5.1
|
||||
description: "Use when operating or synchronizing a Corp v1 project's Scope channel. Owns Roadmap, Epics, Features, and Ideas; correlates all seven same-project channels; proactively improves evidence-based product scope; and records human approval before work enters Architecture solution design."
|
||||
version: 1.5.3
|
||||
author: Hermes Agent
|
||||
license: MIT
|
||||
metadata:
|
||||
@@ -14,7 +14,7 @@ metadata:
|
||||
|
||||
## 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.
|
||||
This skill owns product discovery and durable scope for a Corp v1 project's `scope` channel. It monitors the seven same-project channels—`general`, `scope`, `architecture`, `ui-ux`, `kanban`, `delivery`, and `releases`—and maintains the project documentation's top-level **Scope** area.
|
||||
|
||||
Scope owns Overview, Roadmap, Epics, Features, canonical Task records/reader pages, Ideas, and Questions. 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 and remains semantic owner of requirement/task derivation, dependencies, and readiness. Hermes participates proactively by proposing and refining useful scope, but never approves its own proposals.
|
||||
|
||||
@@ -44,12 +44,13 @@ Inspect only:
|
||||
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 Scope history to avoid duplicates and only relevant new activity from the other five channels. Never inspect or correlate another project's channels.
|
||||
Read enough Scope history to avoid duplicates and only relevant new activity from the other six channels. Never inspect or correlate another project's channels.
|
||||
|
||||
## Human Approval Gate
|
||||
|
||||
@@ -241,7 +242,7 @@ Acceptance requires canonical-YAML validation, graph/table parity where a semant
|
||||
|
||||
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.
|
||||
Use evidence from all seven 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
|
||||
|
||||
@@ -251,10 +252,14 @@ Use evidence from all six same-project channels. Delivery and release outcomes m
|
||||
- **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.
|
||||
|
||||
## UI/UX Coordination
|
||||
|
||||
Scope supplies UI/UX with stable Feature identity, user problems, value, acceptance outcomes, and approval evidence. UI/UX may explore proposals but only an approved design package may become implementation-readiness evidence; Scope remains authoritative for product outcome and disposition.
|
||||
|
||||
## 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.
|
||||
1. Confirm the exact project code and seven approved channel IDs.
|
||||
2. Read new activity from the other six channels and enough Scope history to avoid duplication.
|
||||
3. Separate verified facts, human decisions, proposals, forecasts, and unresolved questions.
|
||||
4. Inspect Overview, Roadmap, Ideas, Questions, the exact Epics → Epic → Features → Feature → Tasks hierarchy, every separate Task reader page, links, IDs, unified delivery statuses, required-child roll-ups, and approval evidence.
|
||||
5. Reconcile architecture feasibility, Kanban flow, delivery progress, and release outcomes against scope.
|
||||
@@ -262,7 +267,7 @@ Use evidence from all six same-project channels. Delivery and release outcomes m
|
||||
7. Load `documentation-docusaurus` and the project CI/CD skill. Run only fast, dependency-free local preflight checks such as schema/parity scripts, targeted tests already available, `git diff --check`, and secret scanning. Do not spend the working session installing dependencies or repeatedly running the full documentation build locally when PR-triggered Gitea Actions can provide the authoritative environment.
|
||||
8. Push the smallest coherent reviewable branch early and open or refresh its PR. The PR workflow must install dependencies and run the complete canonical-data validation, tests, typecheck, strict production build, and built-site assertions without publishing. Wait for the run attached to the exact pushed SHA; inspect failed job steps and logs, fix only evidenced defects, push, and repeat until that exact head is green.
|
||||
9. Review the exact CI-green head, merge through the repository workflow, then require default-head CI/publication success and deployed remote readback before reporting completion. Never treat a local build, a stale run, or CI for another SHA as acceptance evidence.
|
||||
10. Post a concise Scope update with changed artifacts, implications, human gate, exact PR/head/run evidence, and deployed readback. Stay silent when no substantive result exists.
|
||||
10. Post a concise Scope update with changed artifacts, implications, human gate, exact PR/head/run evidence, and deployed readback. Whenever the update reports the latest work through a merged documentation PR, include a reader-facing link to the relevant route in the deployed documentation portal; a PR, commit, or Actions URL is not a substitute for the documentation link. Prefer the most specific verified page, and include the portal landing page when several pages changed. If default-head publication or page-body verification is still pending, say so instead of presenting the route as published, then provide the documentation link in the completion follow-up after verification. Stay silent when no substantive result exists.
|
||||
|
||||
## Authority and Escalation
|
||||
|
||||
@@ -303,10 +308,11 @@ Requires human approval for:
|
||||
17. Moving a parent to `TO_BE_RELEASED` while any required child remains in backlog, design, active delivery, or progress.
|
||||
18. Flattening the reader hierarchy by placing Features directly under an Epic or Tasks outside their owning Feature's `Tasks` group.
|
||||
19. Rewriting historic canonical identities, evidence, or append-only hashes solely to adopt `<UPPERCASE_PROJECT_CODE>-TS-<NUMBER>` display IDs.
|
||||
20. Reporting a merged documentation PR as the latest work without giving the reader a direct link to the verified documentation portal page.
|
||||
|
||||
## Verification Checklist
|
||||
|
||||
- [ ] Only the six same-project channels were inspected.
|
||||
- [ ] Only the seven same-project channels were inspected.
|
||||
- [ ] Scope appears immediately before Architecture with its own sidebar.
|
||||
- [ ] Sidebar order is Overview, Roadmap, Ideas with child pages, Questions with child pages, then the exact Epics → Epic → Features → Feature → Tasks hierarchy.
|
||||
- [ ] Ways of Working starts with a separate Scope page explaining the ticket hierarchy and governed statuses.
|
||||
@@ -325,5 +331,6 @@ Requires human approval for:
|
||||
- [ ] 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.
|
||||
- [ ] Every latest-work update that reports a merged documentation PR includes the relevant verified documentation portal link.
|
||||
- [ ] When React Flow is used, its graph and semantic table share one canonical-YAML selector and pass accessibility, build, browser, and remote exact-head checks.
|
||||
- [ ] Completed work includes exact message, path, commit, URL, or run evidence.
|
||||
|
||||
Reference in New Issue
Block a user