simplecore

Runs a Korean bid from the issued tender to the submitted package without the user steering each step - tender transcription, score simulation, kickoff decisions asked once, manuscript and figures, wireframe and evidence annexes, persona and Korean review, the SlideGlance proposal deck chapter by chapter, the presentation deck, the quantitative volume, expected Q&A and the packaged deliverables - and keeps a ledger so any session, Claude Code or Codex, resumes where the last one stopped. It orders the work and makes the calls; the standards it applies live in proposal-writing, slide-decks, korean-docs, svg-diagrams, wireframe-boards and slideglance-pptx. Use when starting a bid, resuming one, asking where a bid stands, or running a whole-document pass. Triggers - 입찰 착수, 새 제안서, 제안서 작성 시작, 제안서 이어서, 제안서 진행, 현재 상태, 원고 작성, 덱 조판, 발표본 작성, 계량 제안서, 예상 질의응답, 제출물 패키지, 전체 검토, 전체 교정.

Use when reconciling implemented screens against a project's wireframe board frame by frame, when building screens from a board no code reaches yet, when working through or resuming a parity / remaining-screens list, or when setting a project up for such a walk — 보드 대조 · 화면 대조 · 프레임 대조 · SCREEN-PARITY · 처리할 화면 · 남은 화면 대조 · 한 구역을 처리한다. Requires a project that already has a wireframe board; the application itself need not exist yet. NOT for authoring or syncing a board (simplecore:wireframe-boards), and NOT for auditing one feature area in one sitting (the project's own e2e skill).

Use when building an application from a wireframe board in dependency order — chapter by chapter, foundation first — and when running the persona journeys that close each chapter. Also for resuming a build across sessions, deciding which chapters may run in parallel, and generating or regenerating the chapter set from the board — 시나리오 개발 · 챕터 개발 · 단계별 개발 · 개발 순서 · 페르소나 시험 · 병렬 개발 · 어느 챕터부터 · 다음 챕터. Requires a wireframe board and a chapter set derived from it; the application itself need not exist yet. NOT for authoring or syncing the board itself (simplecore:wireframe-boards), and NOT for auditing one feature area in one sitting (the project's own e2e skill).

Use when writing, translating, proofreading, or reviewing a Korean document - README, docs/, design and planning documents, release notes, manuals, UI copy in i18n resources and wireframe board sources, SVG and diagram text labels - and for Korean glossary (GLOSSARY.md) management or an audit sweep. Also use when the user mentions 번역투, awkward Korean, terminology consistency, or asks to re-check documents against glossary rules (화면 문구 검토 · 카피 검수 · UX 라이팅 · 문구를 자연스럽게). NOT for ordinary chat replies, explanations, or reports in the conversation - those follow the habits block in the global instructions. 한국어 문서 작성·번역·교정·검수·화면 문구·용어사전 관리를 할 때 사용한다. 일반 답변에는 사용하지 않는다.

The content standard for a Korean bid proposal, its presentation summary and the technical documents around them - what a page must claim, how a requirement is answered in the panel's own words, controlled language for titles, body, tables, figure labels, captions and speaker notes, enumerations as lists, self-contained references and annex naming, honest reporting of tests and evidence, and the evaluator-persona review that judges the result. Use when writing, revising, translating, reviewing or auditing proposal or technical-document copy, when deciding how much a page or slide answers, when a requirement or evaluation item has to be traced to where it is answered, when transcribing an issued tender into Markdown the authors can cite, or when reviewing a document as its evaluators. Triggers - 제안서, 기술문서, 제안요청서, RFP 정리, RFP 문서화, 요구사항 정리, 요구사항 목록, 요구사항 대응, 평가항목, 평가위원, 발표본, 발표자 노트, 문구 검토, 카피 검수, 용어 통일, 열거, 별첨, 증빙, 페르소나 검토, 제안서 검토.

The typesetting standard for a deck compiled to PowerPoint - a portrait document volume such as a proposal, a technical document or an annex, and a landscape presentation summary. Carries the design contract, the page and slide rhythm, components and their catalogue, the running head, page fill and budget, figure boards and placement, the checks a deck must pass, and how editorial judgments are made and confirmed. Tool-independent; how a deck is written in its tool (markup, server, builder) is that tool's own skill, for SlideGlance the slideglance-pptx skill and its MCP server. Reads every path, board and check from the project's `.claude/slide-decks.json`. Use before editing anything under a deck directory, adding or allocating pages or slides, placing or redrawing a figure, fixing a cluttered or repetitive deck, or setting a new deck up. Triggers - 조판, 제안서, 발표본, 슬라이드, 요약본, 페이지 배분, 러닝헤드, 레이아웃, 도식 삽입, 발표자 노트, PPTX, sgx, slideglance.

Create diagrams as SVG (also ASCII) — flowcharts, sequence/state/class/ER, system and architecture diagrams, pipelines, network and infrastructure layouts. Use when asked to draw, render, or diagram a system, flow, or structure. Covers hand-crafted SVG and JSON-spec auto-layout for precise architecture pictures, Mermaid auto-layout for structured diagrams from text, and SVG checks that catch missing or oblique arrowheads, text overflow, and clipped content before delivery. Also covers figures embedded in a document — one canvas width and one type scale across the whole set, with the generator versioned in the project rather than written to a scratch directory, and bundles the full Lucide icon set for marking a component inside a figure (an AI part especially). Triggers on "draw diagram", "create flowchart", "show architecture", "system diagram", "visualize flow", "SVG diagram", "ASCII diagram", "mermaid", "다이어그램", "아키텍처 그림", "도식화", "구성도", "그림 그려", "문서에 넣을 그림", "그림 규격 통일", "아이콘 넣어", "AI 아이콘".

Use when drawing or changing low-fidelity PHONE, TABLET, or DESKTOP/WEB wireframes as one self-contained HTML board — wireframes, screen mockups, lo-fi screens, UI sketches, a screen inventory or flow board derived from a design or spec document, 와이어프레임 · 화면 목업 · 로파이 · 태블릿 화면 · 웹 화면 · PC 화면 · 데스크톱 화면 · 관리자 화면 — including when the word "wireframe" is absent but the deliverable is screen layouts drawn before implementation. Also use when implementing a screen from a board, checking an implementation against one, syncing a board after a screen / dialog / state / flow changes, or reviewing a board as its personas (페르소나 검토 · 사용자 관점 검토 · 담당자 관점 · UI/UX 관점 · 화면 사용성 검토). Propose it when a substantial new UI effort has no board yet. NOT for high-fidelity visual design or production React components.