Verified:GitHub

plan

Create an implementation-ready HTML design document with acceptance criteria.

10|5|Updated Mar 3, 2026

Search Tags:#architecture #implementation planning #acceptance criteria #design document #code changes #html artifact #repository research

Ready to run

npx skills add https://github.com/JHostalek/dotclaude --skill plan-jhostalek

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: plan
Source: https://github.com/JHostalek/dotclaude/tree/main/skills/plan
Command: npx skills add https://github.com/JHostalek/dotclaude --skill plan-jhostalek

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill turns ambiguous coding requests into a reviewed, self-contained design contract that gives both humans and fresh coding agents a clear target before implementation begins.

Core Features & Use Cases

Evidence-Based Planning: Research repository patterns, relevant APIs, libraries, and prior art to resolve material design uncertainties.
Executor-Ready Contracts: Define behavior, interfaces, data, runtime expectations, acceptance criteria, scope, non-goals, and intentional file changes without prescribing statement-level implementation.
Visual Approval Artifacts: Create a semantic, self-contained HTML plan with decision-bearing visuals, repository citations, alternatives, mitigations, and observable acceptance boundaries.
Use Case: When a feature request spans multiple modules or involves consequential architectural choices, use this Skill to produce an approved design document that another coding agent can implement without rediscovering the requirements.

Quick Start

Use the plan skill to research the repository and create an implementation-ready HTML design document for the requested change.

Frequently Asked Questions about plan

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

FAQPage Schema

How do I create an implementation-ready design document for ambiguous coding tasks?▼

To create an implementation-ready design document, research repository patterns and relevant APIs to resolve uncertainties, then define behavior, acceptance criteria, and scope in a self-contained HTML plan. This ensures both humans and coding agents have a clear target before code changes begin.

What is the best way to plan code changes that span multiple files or module boundaries?▼

Planning code changes across multiple files requires an executor-ready contract that defines interfaces, data expectations, and intentional file modifications without prescribing statement-level implementation. This approach prevents rediscovering requirements and clarifies boundaries for fresh coding agents.

When do I need to generate an HTML artifact for architecture tradeoff decisions?▼

You need to generate an HTML artifact for architecture decisions when a feature involves consequential tradeoffs, unfamiliar APIs, or requires explicit human approval. The document provides visual decision aids, alternatives, and mitigations to secure approval before implementation.

How do I define acceptance criteria and non-goals for repository changes before implementation?▼

Define acceptance criteria and non-goals by establishing observable acceptance boundaries and a defined scope within a design document. Citing repository precedents and relevant external evidence ensures the behavioral contracts are justified and implementation-ready.

Does this approach support resolving unfamiliar APIs and ambiguous behavior in software engineering?▼

Yes, resolving unfamiliar APIs and ambiguous behavior is supported through evidence-based planning. It researches repository patterns, relevant libraries, and prior art to create a reviewed design contract that gives coding agents a clear implementation target.

What are the limitations of using a design document for implementation planning?▼

A design document for implementation planning does not prescribe statement-level implementation details. It focuses on resolving material design uncertainties and defining scope, meaning it should be paired with an executor agent to handle the actual code generation and behavioral contracts.