CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

flow-driven-scaffold

Materialise a definition of workflow as a working flow workspace — workflow.md with its graph, one step contract per step with real stubs, item cards, measures, integration bindings, platform context-pack and check stubs, and the first generated board — so a human or agent can take over from a running skeleton rather than a blank page. Use after defining or ingesting a workflow, when standing up a second stream, or when an existing workspace needs missing pieces filled in. Part of the flow-driven family.

Quality

84%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

81%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A tight, highly actionable procedure body: an eight-step sequence with lint-until-clean validation, explicit quality gates, and honest-state rules that constrain judgment rather than pad it. The main gaps are the unverifiable external references (templates, contract, and example all live outside this bundle) and script invocations given without full command lines.

DimensionReasoningScore

Conciseness

The body is lean and assumes competence — no space is spent explaining what workflows or boards are, and steps like "Write the flow-config block first — including unit and unit_outcome — and lint it before writing any prose" are pure directive. A few rhetorical asides could be trimmed without loss ("the first board is usually the most informative artefact the team has had in months", "not an embarrassment to paper over"), which keeps it at anchor 4 (efficient with minor trims) rather than anchor 5's every-token-earns-its-place.

4 / 5

Actionability

Guidance is concrete throughout: exact file paths ("steps/<id>.md", "platform/context/<pack>.md", "items/<slug>/item.md", "reviews/YYYY-MM-DD-scaffold.md"), exact fields ("exit evidence", "a rung with its reason", "run: human with an empty run_ref", "escalation contract for anything at rung 2+"), and named commands (flow_lint.py, flow_board.py, flow_next.py). It is not a 5 because the script invocations lack usage details (no full command line or arguments) and the templates that define the file formats live outside this bundle, so the guidance is not fully copy-paste ready on its own.

4 / 5

Workflow Clarity

The eight steps are explicitly sequenced (skeleton → config linted first → step contracts → platform stubs → item cards → history → board generation → brief) with built-in validation and a feedback loop ("flow_lint.py until clean, then flow_board.py, then flow_next.py", "lint it before writing any prose"), plus a dedicated Quality Gates checklist covering lint-zero-violations, stated unit/unit_outcome, sensible first run card, and complete step contracts. This matches the top anchor: clear sequence, explicit validation steps, feedback loop, and a checklist for a complex process.

5 / 5

Progressive Disclosure

The body is well organized (Outcome, Inputs, Workflow, Rules, Quality Gates, References) and the References section clearly signals one-level-deep pointers to templates, the workflow-definition contract, an example workspace, and the next skill. It is not a 5 because the referenced paths ("skills/flow-driven/templates/", "skills/flow-driven/references/workflow-definition.md", "skills/flow-driven/example/fiy-content-engine/") live outside the skill's own bundle — no references/, scripts/, or assets/ directories exist here — so none of the referenced material is verifiable, and the References section mixes file pointers with sibling-skill navigation.

4 / 5

Total

17

/

20

Passed

Description

81%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A dense, well-structured description with excellent specificity and completeness — it explicitly names every artifact produced and gives a concrete, multi-condition use-when clause in third person. Its main weakness is trigger vocabulary: the natural words a user would say ("scaffold", "set up", "create") are absent in favor of the unusual "Materialise" and family jargon like "second stream" and "context-pack".

Suggestions

Add the natural synonyms users would actually say — e.g. open with "Scaffolds (sets up) a definition of workflow as a working flow workspace" — so "scaffold"/"set up"/"create" appear as trigger terms, matching the skill's own name flow-driven-scaffold.

Replace or supplement the verb "Materialise" with a common verb ("Scaffolds", "Builds", "Turns ... into"), since it is not a phrase users naturally type when they need this skill.

Consider translating family jargon ("second stream", "context-pack", "run card") into at least one plain-language equivalent in the when-clause so the description triggers for users outside the flow-driven family.

DimensionReasoningScore

Specificity

The description enumerates concrete deliverables — "workflow.md with its graph, one step contract per step with real stubs, item cards, measures, integration bindings, platform context-pack and check stubs, and the first generated board" — a comprehensive, specific list of what the skill produces. This matches the anchor for multiple specific concrete items with comprehensive coverage; it is above anchor 4 because there are no noticeable coverage gaps in the artifact list.

5 / 5

Completeness

Both halves are explicit: the "what" is the enumerated materialization of the workspace, and the "when" is a dedicated trigger clause — "Use after defining or ingesting a workflow, when standing up a second stream, or when an existing workspace needs missing pieces filled in." That is a clear, explicit what-and-when pair with concrete trigger phrases, matching the top anchor exactly; the anchor below (4) applies only when the when-clause is less explicit or specific.

5 / 5

Trigger Term Quality

Relevant keywords exist ("definition of workflow", "workspace", "defining or ingesting a workflow", "existing workspace needs missing pieces filled in") but the natural terms a user would actually say are missing: "scaffold", "set up", "create", "initialize". The verb "Materialise" is unusual, and "second stream", "flow workspace", and "context-pack" are family jargon. This fits the anchor for some relevant keywords missing common variations and synonyms, rather than anchor 4's good coverage with only a few terms missing.

3 / 5

Distinctiveness Conflict Risk

The description carves a clear niche — scaffolding a workspace from an existing definition — and explicitly positions it against siblings ("Use after defining or ingesting a workflow", "Part of the flow-driven family"), reducing collision with define/ingest/run. It is not a 5 because the trigger vocabulary ("workflow", "workspace") is broad and overlaps with the closely related family skills, so a user's phrasing could still route to the wrong sibling.

4 / 5

Total

17

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

yyeret/portfolio-pdlc

Path

skills/flow-driven-scaffold/SKILL.md

Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.