From structured-english
Write specifications using Structured English Specification Format (SESF v4.1), a human-readable format that uses formal BEHAVIOR/PROCEDURE/RULE/STEP blocks for visual scaffolding, WHEN/THEN conditionals for scannable rules, and explicit data flow with → $variable declarations. Features @route decision tables, @config parameters, consolidated error tables, and 3-tier scaling. Optimized for human authors and readers. Triggers include "write a human spec", "create a human-readable specification", "SESF spec", "human-facing spec".
npx claudepluginhub reggiechan74/cc-plugins --plugin structured-englishThis skill uses the workspace's default tool permissions.
Generate well-structured specifications from user requests using formal BEHAVIOR/PROCEDURE/RULE/STEP blocks. Given a domain, complexity indicators, and user intent, produce a specification that uses explicit block syntax for visual scaffolding, WHEN/THEN conditionals for scannable rules, STEP with → $variable for data flow tracking, @route tables for multi-branch decisions, @config for centrali...
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Analyzes competition with Porter's Five Forces, Blue Ocean Strategy, and positioning maps to identify differentiation opportunities and market positioning for startups and pitches.
Generate well-structured specifications from user requests using formal BEHAVIOR/PROCEDURE/RULE/STEP blocks. Given a domain, complexity indicators, and user intent, produce a specification that uses explicit block syntax for visual scaffolding, WHEN/THEN conditionals for scannable rules, STEP with → $variable for data flow tracking, @route tables for multi-branch decisions, @config for centralized parameters, and consolidated error tables. Follows the correct tier format and passes structural validation.
Not in scope: executing the generated specs, providing domain expertise for spec content, maintaining the validator script, runtime interpretation of specs
@config validator_path: ${CLAUDE_PLUGIN_ROOT}/skills/sesf/scripts/validate_sesf.py reference_path: ${CLAUDE_PLUGIN_ROOT}/skills/sesf/assets/reference.md template_path: ${CLAUDE_PLUGIN_ROOT}/skills/sesf/assets/template.md examples_path: ${CLAUDE_PLUGIN_ROOT}/skills/sesf/references/examples.md authoring_guide_path: ${CLAUDE_PLUGIN_ROOT}/skills/sesf/assets/authoring-guide.md line_budget: micro: [20, 80] standard: [80, 200] complex: [200, 400] tier_threshold: route_min_branches: 3
user_request: string - what the user wants specified - requireddomain: string - subject area for the specification - requiredcomplexity_indicators: signals that inform tier selection (concern count, shared structures, overlapping rules, stateful behavior) - optionaltarget_tier: enum [micro, standard, complex] - explicit tier override - optionalspecification: string - the complete SESF v4.1 specification documentvalidation_result: pass/fail/warnings from the validatorextracted_assets: reference material extracted to assets/ if applicable@route tier_selection [first_match_wins] single concern, ≤5 rules, no shared types or functions → micro 2-5 concerns OR shared structures OR multi-phase procedures → standard overlapping rules needing precedence OR 5+ concerns → complex
→ standard
When the user explicitly requests a tier via target_tier, use that tier regardless of complexity indicators. When a spec exceeds its tier's line budget, suggest promotion to the next tier.
Use the @route table above. Default to standard when signals are ambiguous. A micro spec that grows past 80 lines SHOULD become standard. A complex spec with only one concern after refactoring SHOULD demote to micro.
Always required (all tiers):
Required for Standard and Complex only:
Optional (include only when they add value):
Removed entirely — do NOT include:
BEHAVIOR blocks group related declarative rules. Each BEHAVIOR contains one or more RULE entries that describe what should be true — not when to check it.
Syntax:
**BEHAVIOR** name: One-line description
**RULE** rule_name:
WHEN condition
THEN action
ELSE alternative
(Rationale: why this rule exists)
**RULE** simple_rule:
constraint MUST be true
(Rationale: explanation)
Guidelines:
Example:
**BEHAVIOR** validate_payment: Ensure payment requests meet processing requirements
**RULE** positive_amount:
payment.amount MUST be greater than zero
(Rationale: zero or negative payments indicate data entry errors)
**RULE** supported_currency:
WHEN payment.currency is not in $config.supported_currencies
THEN reject with unsupported_currency
(Rationale: unsupported currencies cannot be converted by our payment processor)
**RULE** high_value_approval:
WHEN payment.amount > $config.high_value_threshold
THEN require VP approval before processing
ELSE process normally
PROCEDURE blocks define ordered workflows. Each PROCEDURE contains STEP entries that execute sequentially.
Syntax:
**PROCEDURE** name: One-line description
**STEP** step_name: Description → $output_var
Detailed instructions for this step.
**STEP** next_step: Description
Uses $output_var from previous step.
Guidelines:
Example:
**PROCEDURE** process_invoice: Validate and route incoming invoice
**STEP** validate_fields: Check all required fields are present → $validated_invoice
Verify vendor_name, invoice_number, invoice_date, amount, and currency
are present and non-empty. If ANY field is missing, reject with
missing_required_field.
**STEP** classify: Determine invoice type → $invoice_type
Apply the invoice_classification @route table to $validated_invoice.
**STEP** route: Send to appropriate team
Using $invoice_type, apply the team_assignment @route table.
WHEN amount > $config.high_value_threshold THEN add VP approval flag.
Inside BEHAVIOR blocks, use WHEN/THEN/ELSE for conditional rules:
Use WHEN/THEN for 1-2 branch conditions. For 3+ branches, use an @route table instead.
These are identical to HSF v5 — they are the strongest parts of the format.
@route decision tables:
[first_match_wins] or [all_matches]* wildcard default when a meaningful default exists@config blocks:
$config.key or $config.nested.keyEdge cases only — boundary conditions, error paths, non-obvious behavior. If the happy path is obvious from the rules, do not exemplify it. Use the compact single-line format or multi-line worked examples.
Compact format: example_name: input_description → expected_outcome
Worked examples (for specs where derivation chain integrity matters):
[good_example]:
Input: [concrete values]
Expected: [concrete outcome]
Why: [explain which rule applies and the reasoning]
Consolidate ALL errors into a single ## Errors table at the end of the spec:
## Errors
| Error | Severity | Action |
|-------|----------|--------|
| missing_field | critical | halt and report which field is missing |
| over_budget | warning | review for redundancy, suggest promotion |
| empty_result | info | generate empty report, log the date range |
Severity values: critical (halt processing), warning (continue with degradation), info (log only).
Do NOT scatter error declarations inline after individual rules. This is a key improvement over SESF v4.
Rationale annotations explain why a rule exists. They are parenthetical and follow the rule they annotate:
**RULE** constant_time_compare:
Signature comparison MUST use a constant-time function.
(Rationale: prevents timing side-channel attacks that could leak signature bytes)
Add rationale to rules where the why is not obvious from the what. Skip rationale on self-evident rules like "amount MUST be positive."
**BEHAVIOR** blocks. Sequential workflows MUST be wrapped in **PROCEDURE** blocks. Do not use prose headers and bold list items — use the formal block syntax.**STEP** entries, not numbered lists.## Errors table, not scattered inline after rules.python3 $config.validator_path <spec.md> and fix all failuresassets/ and add a one-line pointer.name and description fields.| Check | Rule |
|---|---|
| Every behavior has a block | Rules grouped under **BEHAVIOR** name: |
| Every procedure has steps | Steps under **PROCEDURE** name: |
| WHEN/THEN for conditionals | Not prose "if/then" inside rules |
| @route only for 3+ branches | Fewer branches use WHEN/THEN/ELSE |
| @config only for 3+ values | Fewer values stated inline in the text |
| Errors consolidated | All errors in a single ## Errors table, not scattered inline |
| Rationale on non-obvious rules | Parenthetical after the rule |
| No empty sections | Omit unused sections entirely |
| RFC 2119 keywords preserved | MUST, SHOULD, MAY capitalized for precision |
| Line budget compliance | Micro ≤80, Standard ≤200, Complex ≤400 |
| Edge-case examples only | No happy-path examples |
| Section-level summaries | Each BEHAVIOR/PROCEDURE has a one-line description |
| Error | Severity | Action |
|---|---|---|
| missing_behavior_block | critical | Wrap declarative rules in a **BEHAVIOR** name: block |
| missing_procedure_block | critical | Wrap sequential steps in a **PROCEDURE** name: block |
| prose_conditional_in_rule | warning | Convert "if/then" prose to WHEN/THEN/ELSE syntax |
| numbered_list_in_procedure | warning | Convert numbered list items to **STEP** name: entries |
| empty_section | critical | Delete the empty section entirely |
| duplicate_constraint | warning | Remove the duplicate; keep only the instance in the block where it applies |
| route_under_threshold | warning | Convert @route with fewer than 3 branches to WHEN/THEN/ELSE in a RULE |
| config_under_threshold | warning | Inline @config values referenced fewer than 3 times |
| scattered_errors | critical | Move all inline error declarations to the consolidated ## Errors table |
| over_budget | warning | Review for redundancy, extract reference material, consolidate rules |
| vague_rule | critical | Rewrite with specific conditions and actions |
| missing_error_table | warning | Add consolidated error table at end of spec |
| validation_failure | critical | Fix structural issues identified by the validator |
| config_key_mismatch | critical | Add key to @config or fix the reference |
| missing_block_summary | warning | Add a one-line description after the BEHAVIOR/PROCEDURE name |
| missing_rationale | info | Consider adding a rationale annotation to non-obvious rules |