design-doc

Writes Japanese software design documents with structured sections and decision criteria.

2|Updated Sep 25, 2011
One-click install
npx skills add https://github.com/pokutuna/dotfiles --skill design-doc-pokutuna
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: design-doc
Source: https://github.com/pokutuna/dotfiles/tree/main/claude/skills/design-doc
Command: npx skills add https://github.com/pokutuna/dotfiles --skill design-doc-pokutuna

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Turning agreed specifications and requirements into a clear, reviewable design document is time-consuming, and important design decisions, risks, and open questions are often left undocumented. This Skill produces a well-structured Japanese Design Doc that readers can review and give feedback on without extra explanation. ## Core Features & Use Cases - Structured Design Doc Generation: Creates documents with standard sections such as Objective, Background, Goals, Non-Goals, Scenarios, Security, and Open Issues, following project templates when they exist. - Cost-of-Being-Wrong Prioritization: Adjusts the depth of each design decision based on how expensive a mistake would be, asking the user about high-stakes choices and filling in reasonable defaults for low-stakes ones. - Gap and Risk Review: Uses the section catalog as a checklist to surface missing considerations, unresolved issues, and security/privacy/legal concerns. - Use Case: When you have settled on a feature specification, ask for a Design Doc and receive a complete Japanese document with measurable SLOs, threat scenarios, alternatives considered, and open issues ready for team review. ## Quick Start Use the design-doc skill to write a Design Doc in Japanese for the caching layer feature we just specified.

Frequently Asked Questions about design-doc

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

FAQPage Schema
How do I write a software design document in Japanese?

Invoke the skill with /design-doc and describe the feature or system you are designing. It produces a Japanese document with sections like Objective, Background, Goals, Scenarios, and Open Issues, following your project template if one exists.

What sections should a design doc include?

Core sections are Title, Objective, Background, Goals, and Non-Goals. Additional sections such as Scenarios, Interfaces, Security, SLOs, Monitoring, and Open Issues are selected based on the design target and the cost of being wrong; irrelevant sections are omitted rather than left blank.

How detailed should design decisions be in a design doc?

Detail is proportional to the cost of being wrong. Decisions that are expensive to reverse, like programming language or storage choices, get constraints, options, and trade-offs; easily changed decisions get a reasonable choice without lengthy discussion.

Can it review an existing design doc for missing considerations?

Yes. When asked to check for gaps, it uses its section catalog as a checklist to identify missing considerations and high-stakes undecided issues. For review-only requests it returns findings without rewriting the whole document.

Does it follow an existing project design doc template?

Yes. If the project has a template or notation rules, it follows that structure and section naming, applying only the guidance for each section's content. Without a template it uses its standard section set with English headings and Japanese body text.