agentsclimarketplace

Generate functional flows

Skill eroveda/blueprint-skills/skills/generate-functional-flows

Domain decomposition + IEEE SWEBOK documentation skills for Claude Code

Install
npx -y skills add eroveda/blueprint-skills --skill generate-functional-flows

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Creates FUNCTIONAL_FLOWS.md describing user-facing flows in plain language. Use when documenting for non-technical stakeholders (managers, PMs, clients). Do NOT use for technical architecture (use generate-architecture-doc) or API docs (use generate-api-catalog). Trigger with "generate functional flows", "document user flows", or "create FUNCTIONAL_FLOWS.md".

SKILL.md

3.0 KB, as published. Nobody here has run it

Generate Functional Flows Documentation

You create FUNCTIONAL_FLOWS.md that describes what the system does in language any business person can understand. NO technical jargon. NO code. NO HTTP details.

Document Structure

# Functional Flows — [Project Name]

## Actors

| Actor | Role | Permissions |
|---|---|---|
| ... | ... | ... |

## Flows by Actor

### [Actor Name]

#### Flow: [Flow name in plain language]

**Goal**: What the actor wants to achieve

**Steps**:
1. The actor [does something]
2. The system [validates/calculates/etc.]
3. The actor sees [result]
4. If [error condition], the actor sees [error message]

**Outcome**: What's been accomplished

**Possible errors**:
- Error 1 with how the user recovers
- Error 2 with how the user recovers

(Repeat for each flow)

## Cross-Actor Flows

Flows involving multiple actors:

### Flow: [Name]
- Actor A initiates by [action]
- Actor B receives notification and [responds]
- System updates [state]
- Both see [final state]

## State Machines

For entities with lifecycle states:

### [Entity] State Machine
- Initial state: ...
- Transitions:
  - From [state] → [state] (triggered by [actor action])
  - From [state] → [state] (triggered by [actor action])
- Forbidden transitions:
  - [state] cannot go directly to [state] — must pass through [state]

## Business Rules

Numbered list of rules that govern the system:

1. Only [actor] can [action]
2. [Entity] cannot be [action] until [condition]
3. [Validation rule in plain language]

Style Rules

  • ✅ "The Admin creates a new project"

  • ❌ "POST /api/projects with admin role"

  • ✅ "The system rejects the request and shows: 'You can only edit your own tasks'"

  • ❌ "Returns HTTP 403 Forbidden"

  • ✅ "A task moves from 'In Progress' to 'Review' when the team member submits it"

  • ❌ "PATCH /tasks/{id} sets status from IN_PROGRESS to REVIEW"

How to Generate

  1. Identify all actors from auth/role configuration
  2. For each actor, list the operations they can perform
  3. For each operation, describe it as a flow in plain language
  4. Identify state machines (entities with status fields)
  5. Extract business rules from validation logic
  6. Save as FUNCTIONAL_FLOWS.md

Quality Checklist

  • Every actor in the system is documented
  • Every system capability has a corresponding flow
  • State machines are diagrammed in plain text
  • Business rules are numbered and unambiguous
  • No technical terms (HTTP, JSON, JWT, SQL)
  • Error messages match actual UI/API responses
  • A non-technical person can read end-to-end and understand the system

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.