agentleFS
parkjui92parkjui92/rnd-proposal-kit/skills/rnd-proposal-writing/SKILL.md

rnd-proposal-writing

Skill4 starsChanged 43 days agoMITView on GitHub

정부 R&D 과제 제안서 본문 초안을 작성하는 스킬. RFP 분석 결과와 리서치 근거를 종합해 연구개발의 필요성·목표·내용·추진전략·추진체계·일정·기대효과·활용방안·수행역량을 표준 구조와 설득력 있는 논증 문체로 작성한다. 제안서/연구개발계획서/사업계획서 초안을 작성하거나 본문을 집필할 때 반드시 사용. 단순 글쓰기가 아닌 평가지표 정조준 제안서 집필에 적용.

The file

Files
SKILL.md

R&D 제안서 본문 집필

RFP 분석의 골격과 리서치 근거를 받아, 평가위원을 설득하는 제안서 본문을 쓴다. 모든 문장이 평가표의 어느 항목에 득점하는지 의식하며 작성한다.

집필 원칙

평가지표 정조준 — 01_rfp_analysis.md의 평가대응표를 옆에 두고, 각 섹션이 어느 평가항목에 득점하는지 확인하며 쓴다. 배점 높은 항목에 지면·논증을 집중한다.

계획형 서술 (결과 단정형 금지) — 제안서는 아직 안 한 일의 계획서다. 완성된 설계 결과를 서술하지 말고 "어떻게 수행하겠다"를 쓴다. 기본 골격은 추진방향 → 수행방법론·추진과정 → 결과예시(산출물 미리보기 표 + 삽도 프롬프트) 3단 — 상세는 references/plan-style-module.md를 Read하여 적용한다.

주장-근거-효과 구조 — 모든 핵심 단락은 ① 무엇을 할 것인가(주장/목표) ② 왜 타당한가(03_evidence.md의 근거·출처) ③ 무엇을 가져오는가(기대효과)로 논증한다.

정량화 — "성능 향상"이 아니라 "기존 X → 목표 Y, 30% 향상". 근거 수치가 없으면 조사관에게 요청하거나 [보강 필요]로 표시한다. 사실을 지어내지 않는다.

공고 용어 일치 — 01_rfp_analysis.md의 핵심 키워드를 본문에 그대로 사용한다. 평가위원은 공고와 제안서의 용어 일치를 신뢰 신호로 본다.

과장 배제 — 미사여구·최상급 남발은 신뢰를 깎는다. 구체와 수치로 말한다.

과제 유형별 골격 분기

집필 착수 전에 과제 유형을 판별하고 골격을 고른다 (01_rfp_analysis.md의 유형 분류를 따른다):

유형골격참조
기술개발형 (TRL·사업화 중심)아래 표준 6섹션references/proposal-structure.md
위탁·정책수립형 (수립지원·위탁연구)계획형 3단 (추진방향→방법론·과정→결과예시)references/plan-style-module.md
팀 공동 제안서의 담당 모듈계획형 3단 + 팀 서식 정합references/team-module-mode.md
지원사업 신청형 (지정 신청서식)서식 항목 순서 그대로 (서식이 곧 목차)서식 파싱 결과

문체·부호·방어 태그·표·삽도 프롬프트 규격은 유형 공통 — references/style-devices.md를 Read하여 적용한다.

표준 섹션 구조

발주처 지정 목차가 있으면 그것을 따른다. 없으면 01_rfp_analysis.md의 권장 목차를 쓰되, 아래 표준 구조가 기본이다. 각 섹션의 상세 작성법·문체·체크포인트는 필요 시 references/proposal-structure.md를 Read하여 적용한다.

  1. 연구개발의 필요성 — 배경, 문제 정의, 시장·정책 수요, 시급성
  2. 연구개발 목표 및 내용 — 최종목표(정량), 연차별 목표, 세부 개발내용
  3. 추진전략·체계·일정 — 추진방법, 연구조직·역할분담, 연차별 일정(간트)
  4. 기대효과 및 활용방안 — 기술적·경제적·사회적 효과, 사업화·실용화 계획
  5. 수행역량 — 연구진 실적, 인프라, 보유기술, 과거 수행 실적
  6. 예산 계획 — (요구 시) 비목별 산정 근거

출력

_workspace/04_proposal.md에 마크다운으로 저장한다:

  • 섹션 제목을 명확한 헤딩으로 구분 (변환가가 양식에 매핑하기 쉽게)
  • 출처는 (출처: …) 또는 각주로 본문에 명시
  • 채우지 못한 부분은 [보강 필요: 사유]로 표시
  • 문서 상단에 입력 자료 누락으로 인한 한계가 있으면 명기

문체

  • 공문서·제안서 규범의 정중한 서술체 또는 발주처 양식이 지정한 문체.
  • 한 단락 한 초점. 장황한 복문보다 명료한 단문.
  • 표·그림이 효과적인 곳(목표 체계도, 일정표, 비교표)은 마크다운 표로 작성하고, 변환가가 hwpx 표로 옮기도록 한다.

주의

  • 근거 없는 주장, 출처 없는 수치를 만들지 않는다.
  • 검수관의 수정 요청을 받으면 [필수·자격] → [필수·득점] → [권고] 순으로 해당 부분만 개정하고 파일을 갱신한다. 반론은 공고 원문이나 출처의 구체 위치(쪽·절·문장)를 짚어 제기한다 — 위치 없는 반론으로는 [필수]가 철회되지 않는다.
  • [보강 필요]는 요구 충족이 아니다. 필수 요구의 근거 자리에 [보강 필요]가 남으면 검수에서 자격형으로 잡힌다. 채울 수 없으면 무엇이 있어야 채워지는지(자료명·제공 주체)를 표시 안에 적어 사용자가 바로 판단할 수 있게 한다.
  • 조사 파일의 〔계산〕·〔추정〕 수치를 본문에 옮길 때 산식이나 방어 태그를 함께 옮긴다. 파생 수치를 원문 수치처럼 쓰지 않는다.
  • 핵심 문안은 복수 후보로: 제목·과업명·추진배경·목적 등 방향을 결정하는 문안은 단일 확정안이 아니라 강조점을 병기한 복수 후보로 제시하고 사용자 선택을 받는다. 간결한 안을 상위에 배치한다.
  • 사용자가 직접 수정 의사를 밝히면 파일 편집을 중단하고, 바로 붙여넣을 수 있는 개조식 문장 후보를 채팅으로 제공한다.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.