This skill should be used when creating plan files, writing Gherkin requirements, or parsing plan file structure. Provides the plan file template and format specifications.
From tommymorgannpx claudepluginhub tommymorgan/claude-plugins --plugin tommymorganThis skill uses the workspace's default tool permissions.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Creates persona-targeted CodeTour .tour files with real file and line anchors for onboarding, architecture, PR, RCA tours, and structured explanations.
Specification for plan files used by the tommymorgan plugin. Plan files capture feature requirements as Gherkin scenarios with TODO/DONE tracking.
Plan files serve as the single source of truth for feature development:
<!-- TODO --> / <!-- DONE --> comment markersPlan files live in the project's plans directory:
<project>/plans/YYYY-MM-DD-<slug>.md
Where:
<project> is the project path (e.g., apps/web, libs/shared, tools/cli)YYYY-MM-DD is the creation date<slug> is a kebab-case version of the feature nameExample: apps/web/plans/2025-12-15-user-authentication.md
# Feature: <Title>
**Created**: YYYY-MM-DD
**Goal**: <One-sentence description of user-facing outcome>
## User Requirements
<!-- TODO -->
# Living: <project>/features/<file>.feature::<scenario-name>
# Action: creates|replaces|extends|removes|deprecates
# Status: TODO
# Living updated: NO
Scenario: <user-focused behavior>
Given <user context>
When <user action>
Then <user outcome>
## Technical Specifications
<!-- TODO -->
# Living: <project>/features/<file>.feature::<scenario-name>
# Action: creates|replaces|extends|removes|deprecates
# Status: TODO
# Living updated: NO
Scenario: <technical requirement>
Given <system state>
When <technical action>
Then <technical outcome>
## Affected Documentation
- [ ] Update <path> — <brief description of needed update>
## Notes
<Design decisions, constraints, and context for future sessions>
Required fields:
**Created**: Date in YYYY-MM-DD format**Goal**: Single sentence describing user-facing outcomeLanguage/framework agnostic Gherkin scenarios describing user-facing behavior.
Rules:
Implementation-specific Gherkin scenarios with actual technology versions.
Rules:
Each scenario has metadata comments:
# Living: <project>/features/<file>.feature::<scenario-name>
# Action: creates|replaces|extends|removes|deprecates
# Status: TODO
# Living updated: NO
Living: Path to the corresponding living specification file, or none (initial implementation) for new features.
Action: Relationship to existing living specs:
creates — New, independent scenarioreplaces — Completely replaces an existing scenarioextends — Adds to an existing scenarioremoves — Deletes an existing scenario from the living specdeprecates — Marks an old scenario as obsoleteStatus: TODO or DONE — matches the <!-- TODO --> / <!-- DONE --> HTML comment marker.
Living updated: NO, YES, or N/A — whether the living spec file has been updated.
Markdown checklist of documentation files affected by the planned changes. Appears after Technical Specifications and before Notes.
## Affected Documentation
- [ ] Update README.md — describe new feature in usage section
- [ ] Update CLAUDE.md — document new commands
If no documentation is affected:
## Affected Documentation
No existing documentation is affected by these changes.
Preserve context for future sessions:
Progress is tracked via HTML comment markers above each scenario:
<!-- TODO --> — Scenario not yet implemented<!-- DONE --> — Scenario implemented and verifiedThe status and work commands parse these markers to determine progress.
Coverage requirements:
Writing tips:
Plan file validation:
# Feature:<!-- TODO --> or <!-- DONE --> marker