From chief-skills
Co-writes top-down design specs for software projects by working layer-by-layer from vision to detail. Use when shaping vague ideas into clear project plans.
How this skill is triggered — by the user, by Claude, or both
Slash command
/chief-skills:shape-upThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Shape a vague idea into a clear design spec by working **top-down**: start from the big picture, confirm alignment at each layer, then go deeper. This is NOT an interview — it's collaborative writing where the agent drafts and the user shapes.
Shape a vague idea into a clear design spec by working top-down: start from the big picture, confirm alignment at each layer, then go deeper. This is NOT an interview — it's collaborative writing where the agent drafts and the user shapes.
/grill-design — when the scope isn't clear enough to grill on details yetOne layer at a time. Confirm before going deeper. Never jump ahead.
If the user can't answer something at the current layer, mark it [TBD] and move on. Don't drill down into unknowns — that's how people lose focus.
Ask the user to describe what they're building in plain language. Then co-write a short vision block:
Draft this as a short block (5-8 lines max). Show it to the user. Adjust until they say it's right.
Do NOT ask about tech stack, architecture, or implementation yet.
Now that the vision is clear, co-write the scope:
Draft and show. The user cuts, adds, moves things between in/out scope. Keep going until scope feels tight.
If scope is getting too big, say so: "This feels like it's growing — want to split it?"
Break the in-scope work into 3-7 big blocks. Each block is a major component, feature area, or workstream. For each block:
Show as a simple list or diagram. The user rearranges, renames, merges, splits. This is the skeleton — no detail yet.
If a block is unclear, mark it [TBD] and keep going. Don't stop the whole flow for one unknown.
For each block (in order the user chooses), co-write a short spec:
Each block spec should be half a page to one page max. If it's getting longer, it probably needs to be split into smaller blocks — go back to Layer 3.
The user can stop at any point and say "that's enough for now." Respect that. Not every block needs a spec in the first pass.
Write the spec to a file. The user decides the filename and location. If the user doesn't specify, suggest design-spec.md in the current directory.
The spec can have multiple drafts — e.g., draft/phase-1.md, draft/final-spec.md. Follow the user's lead on structure.
[TBD] items unless the user asksnpx claudepluginhub thaitype/chief --plugin chief-skillsGuides users through structured dialogue to turn fuzzy ideas into concrete, implementation-free project specs. Focuses on WHAT/WHY, never HOW.
Guides structured brainstorming to refine ideas into approved designs and specs via dialogue, expert consultation, and review loops before implementation. Enforces for all projects.
Guides structured brainstorming to explore user intent, requirements, and design before implementation. Prevents premature coding by enforcing design approval.