Help us improve
Share bugs, ideas, or general feedback.
From solid-coder
Cluster a spec's acceptance criteria into cohesion groups using a 4-signal extraction + 2-signal transitive clustering rule, and label each group as a candidate split boundary. Internal skill — invoked by validate-spec Phase C.
npx claudepluginhub swift-gurus/solid-coderHow this skill is triggered — by the user, by Claude, or both
Slash command
/solid-coder:cohesion-cluster <spec-path> <output-dir><spec-path> <output-dir>This skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
- SPEC_PATH: `$ARGUMENTS[0]` — absolute path to the spec's `Spec.md`
Mandates invoking relevant skills via tools before any response in coding sessions. Covers access, priorities, and adaptations for Claude Code, Copilot CLI, Gemini CLI.
Share bugs, ideas, or general feedback.
$ARGUMENTS[0] — absolute path to the spec's Spec.md$ARGUMENTS[1] — absolute path to the output directory; the skill writes cohesion.json there.1.1 Read the spec file in full.
1.2 Locate the user-stories section. Canonical heading is ## User Stories; also accept any H2 whose label contains "Stories" or "Scenarios". Within that section, identify each user story:
### ) introducing the story. The canonical convention is ### US-N: <title>, but variations like ### Story N, ### Scenario N, or just ### <title> are valid.## User Stories with no H3 boundaries, treat the whole section as a single story. 1.3 For each story, list its acceptance criteria — bullets (-, *, or +) describing observable behavior, typically in a When ... then ... shape. Continue collecting bullets until the next H2 or H3 heading. Ignore obvious meta-bullets (the story narrative paragraph, sub-explanations).
1.4 Assign each AC a stable id. Prefer the canonical form US-{n}.{m} when stories are numbered (e.g. ### US-2: ... → US-2.1, US-2.2, ...). Otherwise fall back to STORY-{n}.{m} using the story's 1-based ordinal position within the section. m is always the 1-based bullet index within the story.
1.5 For each AC, extract the four signals:
| Signal | What to look for |
|---|---|
| Data type / model | Concrete types or models the AC reads, writes, or transforms. Use the spec's own naming (e.g. SessionEvent, LogsProviderError). |
| Screen / view | Named screen or view the AC is observable on. null if no UI involvement. |
| External integration | Library, package, protocol, or external API the AC relies on (e.g. JSONLineReaderBuilder, AsyncSequence, URLSession). |
| Lifecycle phase | One of: construction, subscribe, observation, cancel, mutation, teardown. Pick the phase the AC operates in — when in doubt use subscribe for runtime observable behavior. |
Multi-value signals are allowed (e.g. an AC may touch two data types).
group_count to the band table from README § Scope Metrics:
1 → COMPLIANT2 → MINOR3+ → SEVERE{OUTPUT_DIR}/cohesion.json matching output.schema.json. Include group_count, severity, groups (each with label, acs, shared_signals), and spec_path.screen signal is null (not "main view").US-{n}.{m} or STORY-{n}.{m}).