Skip to main content
Glama
seonmikii

gdc-claude-plugin

by seonmikii

create_task

Creates a task in a GDC project with a structured description, status, priority, dates, assignee, and progress. Automatically validates enums and project membership.

Instructions

태스크를 생성한다. 필수: project(프로젝트 ID), title.

[입력 수집 권장 흐름 — Desktop·Code 공통] 호출 전에 사용자에게 컬럼을 선택지로 하나씩 물어보고 고른 값을 넘긴다:

  1. get_context로 현재 프로젝트 확인 → get_project_enums로 status/priority/task_type/members 조회.

  2. 제목·내용(description)·예상 시작/종료일만 자유 입력으로 받는다.

  3. status/priority/task_type/관련자는 **선택 질문(AskUserQuestion)**으로 제시 — 보기는 한글 label, 각 질문에 반드시 "건너뛰기" 포함(실제 값 최대 3개, 나머지는 "기타"로). 고른 값의 name(관련자는 user id)을 넘긴다.

  4. 담당자(assignee)는 묻지 않는다(생략 시 로그인 사용자로 자동 등록 = 작성자와 동일).

[description — 라벨 섹션 템플릿(평문)] 본문은 평문 한 문단으로 넣지 말고 아래 템플릿으로 작성해 넘긴다. 도구가 GDC 리치텍스트(HTML)로 변환한다(라벨→볼드 문단, -→목록, 섹션 사이 빈 문단). [요약] 요청 내용 한두 줄 요약

[AS-IS]        ← 선택(TO-BE와 짝): 구현 전 상황이 실제로 드러날 때만
구현 전 상황

[TO-BE]        ← 선택(AS-IS와 짝)
구현 후 상황

[작업 내용]
- 실제 산출물 단계를 블렛(`-`)으로 한 줄씩

※ [요약]·[작업 내용]=필수, [AS-IS]/[TO-BE]=선택(짝) — 전/후 상황이 불명확하면 생략(추측·빈말 금지). ※ 체크박스 표시([ ]/[x])는 넣지 않는다(진행 상태는 progress 필드가 담당). ※ 빌드·타입체크·검증·테스트·lint·커밋·배포·버전 범프·'INDEX.md 이력 추가' 같은 프로세스 메타 단계는 넣지 않는다(실제 산출물 단계만). ※ 이미 HTML(태그로 시작)을 넘기면 변환 없이 그대로 저장된다.

값 형식: status/priority/task_type은 해당 프로젝트 enum의 'name', 날짜는 'YYYY-MM-DD'. assignee·participant_ids는 user id 또는 멤버 이름(full_name/username)을 넘기면 자동으로 id로 해석한다.

확장 필드(사용자가 명시할 때만 전달 — 질문으로 강요하지 않음): parent(상위 태스크 id), customer(고객사 id 또는 이름 — 이름은 현재 워크스페이스에서 자동 해석, 모호하면 후보 안내), actual_start_date/actual_end_date, progress(0~100), weight(비중 % — WBS 프로젝트 전용, 비WBS는 호출 전 차단. 형제 그룹 비중 합 100 초과는 서버가 검증).

태그는 지정할 수 없다 — 서버가 태스크의 태그를 본문·댓글의 tagMention에서만 동기화하므로 태그 id를 보내도 무시된다(읽기는 get_task의 tags로 가능).

제약(미충족 시 호출 전 ValueError로 안내·차단): 예상/실제 시작일 ≤ 종료일, 실제 종료일 미래 불가, 담당자/관련자는 해당 프로젝트 멤버만 지정 가능.

완료 보정: status가 완료 계열(category=='done')이면 progress=100·실제 종료일=오늘을 자동 주입한다 (progress/actual_end_date를 직접 전달한 경우 그 값이 우선).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleYes
parentNo
statusNo
weightNo
projectYes
assigneeNo
customerNo
priorityNo
progressNo
task_typeNo
descriptionNo
actual_end_dateNo
participant_idsNo
planned_end_dateNo
actual_start_dateNo
planned_start_dateNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears the full burden and does so richly. It discloses automatic assignee assignment, description HTML conversion, tag synchronization behavior, auto-injection of progress/actual_end_date on completion, and name-to-id resolution, among other behavioral nuances.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Although long, the description is well-structured with clear sections, bullet lists, and a template, making it easy to parse. It is front-loaded with the core purpose and required fields, and every section adds necessary value for a complex 16-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is complete for the tool's complexity: all 16 parameters are semantically covered, validation rules are explicit, and the output schema exists so return values need not be described. This provides an agent with sufficient context to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description compensates comprehensively. It explains every parameter, including value formats (enum names, YYYY-MM-DD dates, user ids or names), the description template, and special rules for weight, customer, and participant_ids.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with '태스크를 생성한다' (creates a task), using a specific verb and resource that clearly distinguishes it from siblings like update_task. It also specifies required fields (project, title) upfront, making the tool's purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context on when to use this tool, including a recommended input-collection flow via get_context and get_project_enums, and states validation constraints that should block invocation. It doesn't explicitly mention alternatives like update_task, but the creation-focused purpose and detailed workflow make usage conditions clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/seonmikii/gdc-claude-plugin'

If you have feedback or need assistance with the MCP directory API, please join our Discord server