blueprint

Name: blueprint
Author: byungjunjang

114stars65forks

How to install blueprint?

byungjunjang/jangpm-meta-skills/blueprint

$npx -y skills add byungjunjang/jangpm-meta-skills --skill blueprint

Installs into the current project.

Summary

Agentic system design blueprint generator. Interviews the user to understand a task they want to automate, then produces a comprehensive integrated design document (.md file) that serves as a concrete implementation plan for Claude Code. The design document includes task context,

Files · 1

View on GitHub

SKILL.md

1	# Blueprint
2
3	## When NOT to use this skill
4
5	Simple task planning or to-do organizing — where a design document is not the deliverable — does not need this skill. Use blueprint only when the user wants an agentic system design document as the output.
6
7	## Overview
8
9	Conduct a structured interview to understand the user's automation task, then generate a complete agentic system design document. The deliverable is a single `.md` file ready for use as an implementation reference in Claude Code.
10
11	## Before Starting
12
13	Read both reference files before doing anything else. They contain the document structure and design rules you'll apply in Phase 2. Skip them and the output will be incomplete.
14
15	1. Read `references/document-template.md` — the full section-by-section template for the output file
16	2. Read `references/design-principles.md` — design rules for agent structure, validation, data transfer, skill vs sub-agent
17	3. (Optional) Skim `references/example-blueprint.md` — a fully annotated sample blueprint document for calibration
18
19	## Workflow
20
21	### Phase 1: Assess & Interview
22
23	Evaluate user input against these three areas. Ask only about gaps. If all sufficiency criteria are met, skip directly to Phase 2.
24
25	\| Area \| Sufficiency criteria (all must be answerable) \| Example question \|
26	\|------\|----------------------------------------------\|------------------\|
27	\| Goal & success criteria \| (1) 완료 상태를 판별하는 구체적 기준이 1개 이상 (2) 실패 상태를 판별할 수 있는가 \| "어떤 결과가 나와야 이 에이전트가 성공했다고 볼 수 있나요?" \|
28	\| Task procedure \| (1) 입력 형식과 출처가 특정됨 (2) 출력 형식과 저장 위치가 특정됨 (3) 분기 조건이 있다면 판단 기준이 명확함 \| "A 이후 B로 갈지 C로 갈지는 어떤 기준으로 판단하나요?" \|
29	\| Tools & constraints \| (1) 사용할 도구/API가 정해졌거나 추천 가능 (2) 기술적 제약(API 한도, 포맷 제한 등)이 파악됨 \| "지금 쓰는 도구가 있나요? 없다면 이런 방식들이 가능한데 어떤 게 맞을까요?" \|
30
31	> Agent organization(단일 vs 멀티 에이전트)은 인터뷰 대상이 아니다. `design-principles.md`의 "Agent Structure Choice" 기준에 따라 에이전트가 Phase 2에서 자체 결정하고, Phase 3에서 근거를 설명한다.
32
33	Interview rules:
34	- Questions must be specific and probing, never generic or formulaic
35	- If user says "모르겠다" or "알아서 해줘": apply reasonable defaults, state your choice and reasoning, ask only for unavoidable decisions
36	- Group related questions — never ask more than 3 questions per turn
37	- Maximum 4 turns total. If gaps remain after 4 turns, apply reasonable defaults, document them as assumptions in the design document, and proceed to Phase 2
38
39	### Phase 2: Generate Design Document
40
41	Once requirements are clear, map interview findings to document sections before writing:
42
43	\| Interview finding \| → Document section \|
44	\|---\|---\|
45	\| Why this is needed, what problem it solves \| § 1. 작업 컨텍스트 › 배경 및 목적 \|
46	\| What's in scope / out of scope \| § 1. 작업 컨텍스트 › 범위 \|
47	\| Input format, output format, trigger \| § 1. 작업 컨텍스트 › 입출력 정의 \|
48	\| Technical constraints, API limits \| § 1. 작업 컨텍스트 › 제약조건 \|
49	\| Domain-specific terminology \| § 1. 작업 컨텍스트 › 용어 정의 \|
50	\| Step-by-step process, branching logic \| § 2. 전체 흐름도 + 단계별 상세 \|
51	\| What the agent decides vs what code handles \| § 2. LLM 판단 vs 코드 처리 구분 \|
52	\| State transitions between steps \| § 2. 상태 전이 \|
53	\| What tools/APIs are used \| § 3. 스킬/스크립트 목록 \|
54	\| Failure conditions, retry expectations \| § 2. 단계별 상세 › 실패 시 처리 \|
55
56	> 에이전트가 자체 결정하는 섹션 (인터뷰 불필요): § 3. 에이전트 구조 (design-principles.md 기준 적용), § 3. 폴더 구조, § 3. CLAUDE.md 핵심 섹션 목록, § 3. 주요 산출물 파일. 이 섹션들은 인터뷰 결과를 종합하여 에이전트가 추론으로 채운다.
57
58	Fill every section using the template in `references/document-template.md`. Apply design rules from `references/design-principles.md`.
59
60	Save as `blueprint-<task-name>.md` in the current working directory.
61
62	Output rules:
63	- CLAUDE.md, AGENT.md, skill file contents are NOT written — only their names and roles
64	- Implementation spec covers structure and responsibilities, not code or prompts
65	- Every workflow step must have: success criteria, validation method, failure handling
66	- Always include a "CLAUDE.md 작성 원칙" section in the implementation spec. Apply the 4 principles (Think Before Coding, Simplicity First, Surgical Changes, Goal-Driven Execution) from `references/design-principles.md` › "CLAUDE.md / AGENTS.md 작성 원칙". Each principle must include a self-verification test. Include tradeoff statement and success metrics.
67	- Always include a "스킬 생성 규칙" section in every blueprint document. All skills defined in this document must be crea

People who liked this also viewed

6 picks

Type

blueprint

114stars65forks

View on GitHub

How to install blueprint?

byungjunjang/jangpm-meta-skills/blueprint

$npx -y skills add byungjunjang/jangpm-meta-skills --skill blueprint

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Blueprint
2
3	## When NOT to use this skill
4
5	Simple task planning or to-do organizing — where a design document is not the deliverable — does not need this skill. Use blueprint only when the user wants an agentic system design document as the output.
6
7	## Overview
8
9	Conduct a structured interview to understand the user's automation task, then generate a complete agentic system design document. The deliverable is a single `.md` file ready for use as an implementation reference in Claude Code.
10
11	## Before Starting
12
13	Read both reference files before doing anything else. They contain the document structure and design rules you'll apply in Phase 2. Skip them and the output will be incomplete.
14
15	1. Read `references/document-template.md` — the full section-by-section template for the output file
16	2. Read `references/design-principles.md` — design rules for agent structure, validation, data transfer, skill vs sub-agent
17	3. (Optional) Skim `references/example-blueprint.md` — a fully annotated sample blueprint document for calibration
18
19	## Workflow
20
21	### Phase 1: Assess & Interview
22
23	Evaluate user input against these three areas. Ask only about gaps. If all sufficiency criteria are met, skip directly to Phase 2.
24
25	\| Area \| Sufficiency criteria (all must be answerable) \| Example question \|
26	\|------\|----------------------------------------------\|------------------\|
27	\| Goal & success criteria \| (1) 완료 상태를 판별하는 구체적 기준이 1개 이상 (2) 실패 상태를 판별할 수 있는가 \| "어떤 결과가 나와야 이 에이전트가 성공했다고 볼 수 있나요?" \|
28	\| Task procedure \| (1) 입력 형식과 출처가 특정됨 (2) 출력 형식과 저장 위치가 특정됨 (3) 분기 조건이 있다면 판단 기준이 명확함 \| "A 이후 B로 갈지 C로 갈지는 어떤 기준으로 판단하나요?" \|
29	\| Tools & constraints \| (1) 사용할 도구/API가 정해졌거나 추천 가능 (2) 기술적 제약(API 한도, 포맷 제한 등)이 파악됨 \| "지금 쓰는 도구가 있나요? 없다면 이런 방식들이 가능한데 어떤 게 맞을까요?" \|
30
31	> Agent organization(단일 vs 멀티 에이전트)은 인터뷰 대상이 아니다. `design-principles.md`의 "Agent Structure Choice" 기준에 따라 에이전트가 Phase 2에서 자체 결정하고, Phase 3에서 근거를 설명한다.
32
33	Interview rules:
34	- Questions must be specific and probing, never generic or formulaic
35	- If user says "모르겠다" or "알아서 해줘": apply reasonable defaults, state your choice and reasoning, ask only for unavoidable decisions
36	- Group related questions — never ask more than 3 questions per turn
37	- Maximum 4 turns total. If gaps remain after 4 turns, apply reasonable defaults, document them as assumptions in the design document, and proceed to Phase 2
38
39	### Phase 2: Generate Design Document
40
41	Once requirements are clear, map interview findings to document sections before writing:
42
43	\| Interview finding \| → Document section \|
44	\|---\|---\|
45	\| Why this is needed, what problem it solves \| § 1. 작업 컨텍스트 › 배경 및 목적 \|
46	\| What's in scope / out of scope \| § 1. 작업 컨텍스트 › 범위 \|
47	\| Input format, output format, trigger \| § 1. 작업 컨텍스트 › 입출력 정의 \|
48	\| Technical constraints, API limits \| § 1. 작업 컨텍스트 › 제약조건 \|
49	\| Domain-specific terminology \| § 1. 작업 컨텍스트 › 용어 정의 \|
50	\| Step-by-step process, branching logic \| § 2. 전체 흐름도 + 단계별 상세 \|
51	\| What the agent decides vs what code handles \| § 2. LLM 판단 vs 코드 처리 구분 \|
52	\| State transitions between steps \| § 2. 상태 전이 \|
53	\| What tools/APIs are used \| § 3. 스킬/스크립트 목록 \|
54	\| Failure conditions, retry expectations \| § 2. 단계별 상세 › 실패 시 처리 \|
55
56	> 에이전트가 자체 결정하는 섹션 (인터뷰 불필요): § 3. 에이전트 구조 (design-principles.md 기준 적용), § 3. 폴더 구조, § 3. CLAUDE.md 핵심 섹션 목록, § 3. 주요 산출물 파일. 이 섹션들은 인터뷰 결과를 종합하여 에이전트가 추론으로 채운다.
57
58	Fill every section using the template in `references/document-template.md`. Apply design rules from `references/design-principles.md`.
59
60	Save as `blueprint-<task-name>.md` in the current working directory.
61
62	Output rules:
63	- CLAUDE.md, AGENT.md, skill file contents are NOT written — only their names and roles
64	- Implementation spec covers structure and responsibilities, not code or prompts
65	- Every workflow step must have: success criteria, validation method, failure handling
66	- Always include a "CLAUDE.md 작성 원칙" section in the implementation spec. Apply the 4 principles (Think Before Coding, Simplicity First, Surgical Changes, Goal-Driven Execution) from `references/design-principles.md` › "CLAUDE.md / AGENTS.md 작성 원칙". Each principle must include a self-verification test. Include tradeoff statement and success metrics.
67	- Always include a "스킬 생성 규칙" section in every blueprint document. All skills defined in this document must be crea

People who liked this also viewed

6 picks

Type