Compare commits

...
Author SHA1 Message Date
jarvis-at-skic 4d363b9c45 docs: link merged work to documentation portal 2026-08-26 19:45:03 +00:00
jarvis-at-skic 8a456cc5ce Merge pull request 'feat: include UI/UX in Corp v1 channel coordination' (#13) from feat/ui-ux-channel-sync into test 2026-08-25 01:18:35 -07:00
jarvis-at-skic 924ab161df feat: include UI UX in channel coordination 2026-08-25 08:18:07 +00:00
jarvis-at-skic d893597905 Docs: prefer PR CI for heavy validation (#12)
Authorized by Board member RootAtSkic in Discord message 1541394858005110784. Skill repositories have no configured Actions workflows; exact-head diff/preflight checks passed.
2026-08-24 03:37:01 -07:00
+16 -9
View File
@@ -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.