specify

Name: specify
Author: ghaida

519installs8forks

How to install specify?

ghaida/intent/specify

$npx -y skills add ghaida/intent --skill specify

Installs into the current project.

Summary

Bridges design and engineering by producing detailed specs, organized handoff packages, asset inventories, and cross-functional documentation. Part of the Intent design strategy system. Trigger when: writing design specs, preparing engineering handoffs, documenting for developmen

Files · 1

View on GitHub

SKILL.md

1	# Specify — Bridge Design to Engineering
2
3	## Overview
4
5	This skill transforms design work into actionable, implementation-ready documentation. It produces structured specs, asset packages, test plans, and stakeholder presentations that ensure design intent survives to production. Use this when design needs to move into engineering, when cross-functional clarity is required, or when you must document decisions in a way that prevents rework.
6
7	---
8
9	## Skill family
10
11	Specify works alongside the full Intent skill system:
12
13	- `/strategize`: Their briefs and hypotheses provide the "why" behind everything you specify. Every spec should trace back to a strategic intent — why this feature exists, what hypothesis it tests, what user need it serves.
14	- `/investigate`: Their research findings ground your use cases in evidence. Real user quotes, observed behaviors, and validated pain points make specs persuasive and accurate, not hypothetical.
15	- `/blueprint`: Their system architecture constrains and informs your specs. Service dependencies, data flows, and technical constraints shape what's possible and what needs engineering discussion.
16	- `/journey`: Their flows are what you're specifying — screen sequences, interaction transitions, state changes. Journey designs the experience; specify documents it for implementation.
17	- `/organize`: Their information architecture informs your navigation specs. Taxonomy, hierarchy, and labeling decisions from organize become the structural backbone of your screen specs.
18	- `/articulate`: Their copy work feeds directly into your copy matrices. Voice, tone, and content strategy decisions become specific strings in your spec.
19	- `/fortify`: Their edge case analysis becomes part of your spec. Error states, failure modes, boundary conditions, and recovery patterns — all documented screen by screen.
20	- `/include`: Their accessibility requirements go into every screen spec. ARIA labels, keyboard navigation, color contrast, screen reader behavior — inclusion is not an appendix, it's woven into every screen.
21	- `/evaluate`: Their assessment identifies gaps in your specs. Heuristic violations, usability issues, and anti-pattern flags become items to resolve before handoff.
22	- `/measure`: Their success metrics define your test plan criteria. Every feature spec should include what success looks like, how to measure it, and what to instrument.
23	- `/philosopher`: A cross-cutting cognitive mode for when specification reveals deeper problems. Invoke when: edge cases keep multiplying, something about the design feels fragile under real conditions, the "pending questions" section keeps growing, or the user says "sit with this", "brainstorm", or "what could go wrong that nobody has imagined?" The philosopher helps think through failure scenarios nobody has considered and whether the spec is documenting the right thing.
24
25	---
26
27	## Core capabilities
28
29	### 1. Detailed design specifications
30
31	Write comprehensive, screen-by-screen (or state-by-state) specifications that document:
32	- Visual design with specific measurements, colors, typography, spacing
33	- Interaction logic: what triggers what, in what order, with what conditions
34	- Copy: exact text, variants for different contexts/markets/edge cases
35	- States: default, hover, active, error, loading, empty, success — all documented visually and logically
36	- Constraints: device sizes, performance requirements, accessibility needs
37
38	Output should be a living spec document (HTML or markdown) that engineers can reference during implementation without guessing.
39
40	### 2. Organized engineering handoff packages
41
42	Structure deliverables so engineering knows exactly what to build and why:
43	- Clear ownership: who decided what and when
44	- Problem context: what user need or business problem does this solve
45	- Design approach: constraints considered, alternatives rejected and why
46	- Use cases: specific, not generic — real user scenarios that expose edge cases
47	- Assets: all files organized, named, versioned, with usage notes
48	- Test criteria: success metrics and audience-specific test plans
49
50	### 3. Copy and variant matrices
51
52	Document all copy variations in one place:
53	- Primary copy vs. secondary copy vs. microcopy (labels, hints, errors, empty states)
54	- Market variants: tone shifts, cultural considerations, regulatory language
55	- Edge cases

People who liked this also viewed

6 picks

Type

specify

519installs8forks

View on GitHub

How to install specify?

ghaida/intent/specify

$npx -y skills add ghaida/intent --skill specify

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Specify — Bridge Design to Engineering
2
3	## Overview
4
5	This skill transforms design work into actionable, implementation-ready documentation. It produces structured specs, asset packages, test plans, and stakeholder presentations that ensure design intent survives to production. Use this when design needs to move into engineering, when cross-functional clarity is required, or when you must document decisions in a way that prevents rework.
6
7	---
8
9	## Skill family
10
11	Specify works alongside the full Intent skill system:
12
13	- `/strategize`: Their briefs and hypotheses provide the "why" behind everything you specify. Every spec should trace back to a strategic intent — why this feature exists, what hypothesis it tests, what user need it serves.
14	- `/investigate`: Their research findings ground your use cases in evidence. Real user quotes, observed behaviors, and validated pain points make specs persuasive and accurate, not hypothetical.
15	- `/blueprint`: Their system architecture constrains and informs your specs. Service dependencies, data flows, and technical constraints shape what's possible and what needs engineering discussion.
16	- `/journey`: Their flows are what you're specifying — screen sequences, interaction transitions, state changes. Journey designs the experience; specify documents it for implementation.
17	- `/organize`: Their information architecture informs your navigation specs. Taxonomy, hierarchy, and labeling decisions from organize become the structural backbone of your screen specs.
18	- `/articulate`: Their copy work feeds directly into your copy matrices. Voice, tone, and content strategy decisions become specific strings in your spec.
19	- `/fortify`: Their edge case analysis becomes part of your spec. Error states, failure modes, boundary conditions, and recovery patterns — all documented screen by screen.
20	- `/include`: Their accessibility requirements go into every screen spec. ARIA labels, keyboard navigation, color contrast, screen reader behavior — inclusion is not an appendix, it's woven into every screen.
21	- `/evaluate`: Their assessment identifies gaps in your specs. Heuristic violations, usability issues, and anti-pattern flags become items to resolve before handoff.
22	- `/measure`: Their success metrics define your test plan criteria. Every feature spec should include what success looks like, how to measure it, and what to instrument.
23	- `/philosopher`: A cross-cutting cognitive mode for when specification reveals deeper problems. Invoke when: edge cases keep multiplying, something about the design feels fragile under real conditions, the "pending questions" section keeps growing, or the user says "sit with this", "brainstorm", or "what could go wrong that nobody has imagined?" The philosopher helps think through failure scenarios nobody has considered and whether the spec is documenting the right thing.
24
25	---
26
27	## Core capabilities
28
29	### 1. Detailed design specifications
30
31	Write comprehensive, screen-by-screen (or state-by-state) specifications that document:
32	- Visual design with specific measurements, colors, typography, spacing
33	- Interaction logic: what triggers what, in what order, with what conditions
34	- Copy: exact text, variants for different contexts/markets/edge cases
35	- States: default, hover, active, error, loading, empty, success — all documented visually and logically
36	- Constraints: device sizes, performance requirements, accessibility needs
37
38	Output should be a living spec document (HTML or markdown) that engineers can reference during implementation without guessing.
39
40	### 2. Organized engineering handoff packages
41
42	Structure deliverables so engineering knows exactly what to build and why:
43	- Clear ownership: who decided what and when
44	- Problem context: what user need or business problem does this solve
45	- Design approach: constraints considered, alternatives rejected and why
46	- Use cases: specific, not generic — real user scenarios that expose edge cases
47	- Assets: all files organized, named, versioned, with usage notes
48	- Test criteria: success metrics and audience-specific test plans
49
50	### 3. Copy and variant matrices
51
52	Document all copy variations in one place:
53	- Primary copy vs. secondary copy vs. microcopy (labels, hints, errors, empty states)
54	- Market variants: tone shifts, cultural considerations, regulatory language
55	- Edge cases

People who liked this also viewed

6 picks

Type