一键导入
split-specs
This skill should be used when converting a single-file spec to directory-based format for better organization of large specifications
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
This skill should be used when converting a single-file spec to directory-based format for better organization of large specifications
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
This skill should be used when the user wants to switch between projects in a monorepo - lists projects from .groundwork.yml and sets the active project
Generate implementation tasks from architecture document. Usage /groundwork:create-tasks
Create detailed product requirements document (PRD) for a feature. Usage /groundwork:design-product
Create design system with foundations, brand identity, and UX patterns. Usage /groundwork:ux-design
Build a feature from description with worktree isolation and TDD. Usage /groundwork:build-unplanned "Add user login"
Verify alignment between code and specs. Usage /groundwork:check-specs-alignment
| name | split-specs |
| description | This skill should be used when converting a single-file spec to directory-based format for better organization of large specifications |
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.
design-product and source-product-specs-from-code when the single-file PRD crosses 500 lines or 15 features (feature sections matching ### \d+\.\d+)/groundwork:split-specs.groundwork.yml exist at the repo root?
{{project_name}} non-empty?
Skill(skill="groundwork:select-project") to select a project, then restart this skill.{{project_name}}, specs at {{specs_dir}}/.{{specs_dir}}/product_specs.md must exist
{{specs_dir}}/product_specs.md. Nothing to split." and stop.{{specs_dir}}/product_specs/ must not already exist
{{specs_dir}}/product_specs/. Nothing to do." and stop.^### \d+\.\d+).Parse the single-file PRD into sections and write each to its own file under {{specs_dir}}/product_specs/.
{{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 log
_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.N subsection. The filename is derived from the feature's PRD code:
### 3.1 Text Search (PRD-SRCH) → PRD-SRCH.md### 3.5 Signature Display → signature-display.md### 3.N ... heading in the file04-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 in 05-open-questions.md as well.
---) as they appear in the source.After all directory files are written and verified:
_index.md and at least two feature files to confirm they look correct.{{specs_dir}}/product_specs.md using rm.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.
When invoked automatically (not by the user), the caller has already verified that at least one threshold is crossed:
wc -l on {{specs_dir}}/product_specs.md >= 500### \d+\.\d+ headings >= 15No 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.