CtrlK
BlogDocsLog inGet started
Tessl Logo

software-lifecycle

How to work in a Software Lifecycle project (the `software-lifecycle` starter pack): proposals → decisions → specs → postmortems, plus guides. Read when the project has these folders, or when asked how this project is organized. Carries the doc lifecycle, status flows, and per-folder agent behaviors so that guidance does not live inside template bodies or folder descriptions. The five workflows — frame a proposal, write a spec, record a decision, write a postmortem, review a design — each ship as their own sibling skill in this pack. Complements the platform `open-knowledge` skill; does not replace it.

68

Quality

85%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Low

Low-risk findings worth noting

SKILL.md
Quality
Evals
Security

Quality

Content

82%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, well-organized instruction skill: lean token use, concrete per-folder rules with naming patterns and status flows, and clean delegation to sibling skills. The main gaps are an un-enumerated template set and the absence of validation checkpoints around status transitions.

Suggestions

List the full set of shipped template names (proposal, decision, spec/plan/tasks, postmortem, guide/onboarding-guide/runbook) in the Templates section so `write({ document: { template } })` calls are unambiguous.

Add a brief validation step before irreversible transitions (e.g., what to confirm before a proposal is accepted or a decision frozen) to strengthen the lifecycle's checkpoints.

DimensionReasoningScore

Conciseness

The ~46-line body is lean and load-bearing: compact shape attributions ('MADR / Nygard shape', 'Google SRE shape', 'Diátaxis how-to') instead of explaining what postmortems or ADRs are, and no padded sections. It assumes Claude's competence, matching anchor 5; anchor 4 would require noticeable over-explanation that could be trimmed, which is not the case here.

5 / 5

Actionability

Concrete naming patterns ('0001-feature-name.md'), explicit status flows ('draft → fcp → accepted/rejected'), a copy-paste-able call ('write({ document: { path, template: "<name>" } })'), and conditional agent directives ('more than 14 days, surface it') make the guidance mostly executable. The gap keeping it below anchor 5: template names for proposals, decisions, specs, and postmortems are never enumerated — only the three guide templates are named.

4 / 5

Workflow Clarity

The lifecycle is clearly sequenced with an explicit flow diagram and status gates (accepted, derived, when things break), and the table routes each task type to a sibling skill. It sits at anchor 4 rather than 5 because there are no validation or recovery checkpoints (e.g., what to check before freezing a decision or advancing a status), though no destructive/batch cap applies.

4 / 5

Progressive Disclosure

The body appropriately keeps per-folder rules inline while delegating workflow detail one level deep to sibling skills, clearly signaled via the workflow table — good structure per anchor 4. It misses anchor 5 because template discovery is implicit (names scattered across sections rather than a clear index), and no bundle files exist to verify the referenced paths against.

4 / 5

Total

17

/

20

Passed

Description

83%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 strong description with explicit what and when clauses, concrete folder-level specifics, and deliberate boundary-setting against the platform and sibling skills. Its weaknesses are minor: missing natural synonyms (RFC, ADR) and residual routing ambiguity with the five sibling workflow skills it names.

Suggestions

Add natural synonyms users would say — 'RFC', 'ADR', 'runbook' — to the description's trigger vocabulary so anchor-5 trigger coverage is reached.

Sharpen the routing boundary for the five workflow terms (e.g., 'for *doing* one of these, use the sibling skill named below') so 'write a postmortem' unambiguously triggers the workflow skill rather than this orientation skill.

DimensionReasoningScore

Specificity

The description lists several concrete elements ('proposals → decisions → specs → postmortems, plus guides', 'doc lifecycle, status flows, and per-folder agent behaviors'), but describes structure more than actions, leaving minor coverage gaps. It exceeds anchor 3 (which expects only 1-2 concrete actions) but falls short of anchor 5's comprehensive coverage.

4 / 5

Completeness

It explicitly answers both what ('How to work in a Software Lifecycle project... carries the doc lifecycle, status flows, and per-folder agent behaviors') and when ('Read when the project has these folders, or when asked how this project is organized'). The when-clause is explicit with concrete trigger conditions, matching anchor 5 rather than the less-explicit anchor 4.

5 / 5

Trigger Term Quality

Natural terms like 'postmortems', 'spec', 'proposal', and 'how this project is organized' give good keyword coverage, but common synonyms users would say (RFC, ADR, runbook) are absent from the description. Solid anchor 4: good coverage with a few natural terms missing, not the comprehensive synonym coverage of anchor 5.

4 / 5

Distinctiveness Conflict Risk

It explicitly disambiguates from the platform skill ('Complements the platform `open-knowledge` skill; does not replace it') and routes the five workflows to sibling skills. However, terms like postmortem, spec, and proposal naturally overlap with those sibling skills' triggers, so it is 'mostly distinct with minor overlap risk' (anchor 4) rather than minimal-conflict anchor 5.

4 / 5

Total

17

/

20

Passed

Validation

93%

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

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

Total

15

/

16

Passed

Repository
inkeep/open-knowledge
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.