workflow

Guides work through roadmap, feature, spec, plan, and implementation stages with artifact classification rules.

Updated May 26, 2026
One-click install
npx skills add https://github.com/robot-denny/ai-sketchlab --skill workflow-robot-denny
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: workflow
Source: https://github.com/robot-denny/ai-sketchlab/tree/main/.agents/skills/workflow
Command: npx skills add https://github.com/robot-denny/ai-sketchlab --skill workflow-robot-denny

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams lose track of where work stands and accumulate misnamed or stale documentation when specs, plans, and feature docs lack a consistent flow. This Skill defines how work moves from roadmap through feature, spec, plan, and implementation, and how to classify each piece of work so it earns the right durable artifact. ## Core Features & Use Cases - Five-layer workflow spine: Routes work through Roadmap → Feature → Spec → Plan → Implement, with entry points like /spec, /plan, /implement-step, and /retrofit for changes that skipped the flow. - Work-type classification: Classifies work as new-capability, change-to an existing capability, or fix-infra, deciding whether a feature doc is created, updated, or skipped entirely. - Artifact lifecycle layout: Defines where artifacts live — evergreen capability docs in _features/, temporal increment bundles in _work/<slug>/, and durable runbooks in docs/. - Use Case: Before writing a spec for a new article-card placeholder behavior, consult this Skill to learn it is a change to the existing article-card capability doc rather than a new feature doc, keeping the capability catalog clean. ## Quick Start Ask the assistant to consult the workflow skill to classify a planned change and determine which feature doc or artifact it should produce.

Frequently Asked Questions about workflow

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I decide whether work needs a feature doc?

Classify the work first: new-capability earns a new feature doc named by area, change-to updates the existing capability's doc, and fix-infra earns no feature doc at all. The classification is recorded as a Work type line in the spec and carried through the plan.

What is the difference between a spec and a feature doc?

A spec is a historical record of original requirements and design rationale for one increment. A feature doc is living documentation of current system behavior, written as Given/When/Then scenarios grouped under business Rules.

How do I handle a change that skipped the spec and plan flow?

Run the /retrofit entry point before committing. It reconciles the actual diff against intent, runs reviewers, surfaces edge cases, and proposes the tests and doc updates the change would otherwise skip.

When should I create a new feature doc versus amend an existing one?

Apply the naming tell: if the doc name reads as a behavior rather than an area a stakeholder would name, it belongs as a Rule inside the area's doc. The classifier biases toward amending, since splitting later is cheap.

Where should specs, plans, and feature docs be stored?

By default, capability docs live in _features/<area>.md, increment bundles (spec, plan, notes, assets) live in _work/<slug>/ and archive to _work/shipped/, and durable runbooks live in docs/. All paths are overridable via the paths.md config slot.