Menu
Issue-board (Issue Pivot) generation domain. Use when reasoning about `cn issues map`'s fetch, taxonomy-parse, effort-computation, and render pipeline, or about the board's JSON/HTML output contract.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | issues/map |
| description | Issue-board (Issue Pivot) generation domain. Use when reasoning about `cn issues map`'s fetch, taxonomy-parse, effort-computation, and render pipeline, or about the board's JSON/HTML output contract. |
| artifact_class | skill |
| kata_surface | none |
| governing_question | How does an open-issue set become a taxonomy-aware, effort-weighted board record set and a self-contained interactive board output? |
| visibility | public |
| triggers | ["issues map","issue board","issue pivot","board-data.json"] |
| scope | task-local |
| inputs | ["open GitHub issues (live via API, or fixture/stdin for offline use)"] |
| outputs | ["board records (taxonomy, effort, effort_weight, unestimated)","index.html (Voronoi + Pivot views)","board-data.json","README.md (generated, do-not-hand-edit)"] |
The board is a projection of the issue taxonomy, not an independent data
model: every field a board record carries is derived from taxonomy labels
(skills/taxonomy/SKILL.md), never invented locally.
The domain implementation lives at
src/packages/cnos.issues/commands/issues-map/
as its own Go module
(module github.com/usurobor/cnos/packages/cnos.issues/commands/issues-map),
co-located with this package, mirroring the
cnos#392 cdd-verify
precedent exactly:
src/go/go.mod via a require+replace pair;go.work's use (...) list;src/go/internal/cli/cmd_issues_map.go (argument
parsing + one-line delegation only — no domain logic).See src/packages/cnos.issues/SKILL.md §"Command-dispatch disposition" for
why this is Go-source co-location and not package-command exec-dispatch.
cn issues map --repo <owner/repo> --out docs/development/board
--fixture/--stdin for offline use);kind/*, area/*, P0–P3, status:*, dispatch:cell,
protocol:*, effort/* per the taxonomy;effort, effort_weight (S=1, M=2, L=4, XL=8), and
unestimated (missing effort ≠ small — nominal weight 1, visually flagged);kind/tracking from effort rollups by default;index.html, board-data.json, README.md into --out.docs/architecture/DESIGN-CONSTRAINTS.md §3.2).A recursive coherence methodology for cnos cell architectures and cell executions. It measures the three-cell system, each cell's CCNF kernel, typed contract/evidence surfaces, cell and wave FSMs, and an actual receipt stream without allowing a strong local layer to average away a broken cross-level projection.
Coherence-Driven Development. Use for substantial changes that require explicit selection, artifact flow, review, release, and post-release closure.
Measurement fixture for State-A execution path validation.
Measurement fixture for State-A execution-mode validation.
Measurement fixture for TSC-compatible methodology validation.
Measurement fixture for TSC-compatible methodology validation.