split-specs
Skill45 starsChanged 4 days agoMITView on GitHub
This skill should be used when converting a single-file spec to directory-based format for better organization of large specifications
In this repository43 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- build-unplannedSkill
- check-specs-alignmentSkill
- create-tasksSkill
- debugSkill
- design-architectureSkill
- design-it-twiceSkill
- design-productSkill
- domain-modelingSkill
- doubt-driven-developmentSkill
- finalize-taskSkill
- groundwork-checkSkill
- groundwork-helpSkill
- handoffSkill
- implement-taskSkill
- instrument-observabilitySkill
- just-do-itSkill
- just-do-it-swarmingSkill
- plan-taskSkill
- review-prSkill
- select-projectSkill
- setup-repoSkill
- shipSkill
- skillsSkill
- source-architecture-from-codeSkill
- source-product-specs-from-codeSkill
- source-ux-design-from-codeSkill
- split-architectureSkill
- staged-rolloutSkill
- statuslineSkill
- swarm-debugSkill
- swarm-design-architectureSkill
- task-validation-loopSkill
- test-driven-developmentSkill
- understanding-feature-requestsSkill
- use-git-worktreeSkill
- using-groundworkSkill
- ux-designSkill
- validateSkill
- vertical-sliceSkill
- work-on-next-taskSkill
- work-onSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
13 rules. About 0 are common, 6 are distinctive, and 7 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
7
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 13
Manually: when the user invokes /groundwork:split-specs
- Very specific: line 18
If yes → Is {{project_name}} non-empty?
- Very specific: line 19
If empty → Invoke Skill(skill="groundwork:select-project") to select a project, then restart this skill.
- Very specific: line 20
If set → Project is {{project_name}}, specs at {{specs_dir}}/.
- Distinctive: line 21
If no → Continue (single-project repo).
- Very specific: line 27
If missing → output "No single-file PRD found at {{specs_dir}}/product_specs.md.
- Very specific: line 29
If it exists → output "PRD is already in directory format at {{specs_dir}}/product_specs/.
- Very specific: line 65
If no code in parentheses, use a slug of the feature name: ### 3.5 Signature Display → signature-display.md
- Distinctive: line 74
If a section is missing from the source file, skip that output file (don't create empty files).
- Distinctive: line 80
After all directory files are written and verified:
- Distinctive: line 101
When invoked automatically (not by the user), the caller has already verified that at least one threshold is crossed:
- Distinctive: line 106
No user confirmation is needed — the split happens silently and the caller reports what happened.
- Distinctive: line 108
When invoked manually by the user, skip threshold checks and split unconditionally.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Split Specifications Skill
Converts a single-file product spec ({{specs_dir}}/product_specs.md) into a directory-based format ({{specs_dir}}/product_specs/) for better organization and targeted context loading.
When to Use
- Automatically by
design-productandsource-product-specs-from-codewhen the single-file PRD crosses 500 lines or 15 features (feature sections matching### \d+\.\d+) - Manually when the user invokes
/groundwork:split-specs
Step 0: Resolve Project Context
- Monorepo check: Does
.groundwork.ymlexist at the repo root?- If yes → Is
{{project_name}}non-empty?- If empty → Invoke
Skill(skill="groundwork:select-project")to select a project, then restart this skill. - If set → Project is
{{project_name}}, specs at{{specs_dir}}/.
- If empty → Invoke
- If no → Continue (single-project repo).
- If yes → Is
- Proceed with the resolved project context.
Step 1: Validate Preconditions
- Check single file exists:
{{specs_dir}}/product_specs.mdmust exist- If missing → output "No single-file PRD found at
{{specs_dir}}/product_specs.md. Nothing to split." and stop.
- If missing → output "No single-file PRD found at
- Check directory does NOT exist:
{{specs_dir}}/product_specs/must not already exist- If it exists → output "PRD is already in directory format at
{{specs_dir}}/product_specs/. Nothing to do." and stop.
- If it exists → output "PRD is already in directory format at
- Read the file and count lines and features (sections matching
^### \d+\.\d+).
Step 2: Split the File
Parse the single-file PRD into sections and write each to its own file under {{specs_dir}}/product_specs/.
Directory Structure
{{specs_dir}}/product_specs/
├── _index.md # Header, metadata, and section 0 (EARS cheat sheet)
├── 01-product-context.md # Section 1: Product context
├── 02-non-functional.md # Section 2: Non-functional & cross-cutting requirements
├── 03-features/ # Section 3: One file per feature
│ ├── _index.md # Section 3 header ("## 3) Feature list (living backlog)")
│ └── <feature-code>.md # e.g., PRD-SRCH.md, PRD-AUTH.md
├── 04-traceability.md # Section 4: Traceability
└── 05-open-questions.md # Section 5: Open questions logParsing Rules
_index.md— Everything from the start of the file up to (but not including)## 1). Include the YAML-style header block (Doc status, Last updated, Owner, Audience) and section 0 (EARS cheat sheet).01-product-context.md— From## 1)up to (but not including)## 2).02-non-functional.md— From## 2)up to (but not including)## 3).03-features/_index.md— The## 3)heading line and any text before the first### 3.subsection. Typically just:## 3) Feature list (living backlog)03-features/<feature-code>.md— One file per### 3.Nsubsection. The filename is derived from the feature's PRD code:- Extract the code from the heading, e.g.,
### 3.1 Text Search (PRD-SRCH)→PRD-SRCH.md - If no code in parentheses, use a slug of the feature name:
### 3.5 Signature Display→signature-display.md - Preserve the full
### 3.N ...heading in the file
- Extract the code from the heading, e.g.,
04-traceability.md— From## 4)up to (but not including)## 5).05-open-questions.md— From## 5)to the end of the file, or up to## 6)if present. If there is a## 6)(e.g., "Out of scope"), include it in05-open-questions.mdas well.
Edge Cases
- If a section is missing from the source file, skip that output file (don't create empty files).
- Preserve all horizontal rules (
---) as they appear in the source. - Preserve trailing newlines — each output file should end with a single newline.
Step 3: Delete the Single File
After all directory files are written and verified:
- Verify — Read back
_index.mdand at least two feature files to confirm they look correct. - Delete — Remove
{{specs_dir}}/product_specs.mdusingrm. - Confirm — Output a summary:
Split product_specs.md into directory format:
{{specs_dir}}/product_specs/
├── _index.md
├── 01-product-context.md
├── 02-non-functional.md
├── 03-features/ (N feature files)
├── 04-traceability.md
└── 05-open-questions.md
The single file has been removed. All skills (design-product, source-product-specs-from-code, etc.) already support directory mode.Auto-Split Thresholds
When invoked automatically (not by the user), the caller has already verified that at least one threshold is crossed:
- Line count:
wc -lon{{specs_dir}}/product_specs.md>= 500 - Feature count: Number of
### \d+\.\d+headings >= 15
No user confirmation is needed — the split happens silently and the caller reports what happened.
When invoked manually by the user, skip threshold checks and split unconditionally.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

