Put input, output, and error rules into a script request for work

01Complete the task description before getting code

A good request contains concrete work rules rather than a long role instruction. “Organize the files nicely” does not decide which folder to read, what to name the result, how to handle duplicates, or whether to overwrite. This article limits the scope to a small task: combining one week of synthetic work logs by team. The result is a reusable request plus input and expected-result files.

02Split the work into six items

You also need to write what “time per item” actually means. In this synthetic example, all of the input minutes are defined as the work time corresponding to the row's completed count. If it includes waiting time or time on unfinished work, the meaning of this average changes, so fix the work definition first.

03Order for writing the request

1. Narrow the scope of automation to one result. Do not mix collecting files, tallying, and sending email at once; set this result as a per-team summary file.
2. Write the input's key names, data types, and units. State clearly, for example, that completed is an integer and time is an integer in minutes.
3. Instead of an original with real names and internal paths removed, create a synthetic sample. Data can be identified by transactions or unusual values even if names are changed, so write the whole example from scratch.
4. Calculate the sample's expected result yourself. Decide at this step whether to divide after summing or average by row.
5. Write the handling rules for errors, empty input, division by zero, and existing output files.
6. Before sending the request, look for conflicting instructions. Do not say all values are integers and then say to turn blanks into 0 on its own.

04Pair the input with the expected result

The design team has 5 items and 140 minutes, so the time per item is 28 minutes. If you use 27.5 minutes, the simple average of the per-row values of 30 and 25 minutes, the difference in item counts is not reflected. The operations team has 4 items, 80 minutes, and 20 minutes per item. The support team's 0 items means there is no average to calculate, so it is shown as null.

input-sample.json and expected-output.json are a pair that shows these differences. JSON is a format for structured data, and null is different from the number 0. This distinction can also be confirmed in the value mapping described in Python's official json documentation.

05A request you can edit and use right away

다음 조건을 만족하는 로컬 Python 스크립트를 작성해 주세요.

[업무 목적]
한 주의 작업 기록을 팀별로 합쳐 완료 건수, 작업 시간 합계(분), 건당 작업 시간(분/건)을 확인합니다.
이 요청의 모든 기록은 합성 샘플입니다. 실명, 고객 정보, 계약 내용, 사내 경로, 계정 키는 포함하지 않습니다.

[실행 환경과 범위]
Python 3 표준 라이브러리만 사용합니다. 외부 패키지 설치, 인터넷 접속, 유료 API 호출, 이메일 전송은 하지 않습니다.
현재 작업 폴더의 input.json만 읽습니다. 하위 폴더 탐색, 원본 수정, 파일 삭제는 하지 않습니다.
새 output.json을 만듭니다. output.json이 이미 있으면 덮어쓰지 말고 이유를 알려주며 종료합니다.

[입력 형식]
UTF-8 JSON 배열입니다. 각 행에는 record_id, team, completed, minutes 네 키만 있습니다.
record_id는 중복되지 않는 비어 있지 않은 문자열입니다.
team은 설계, 운영, 지원 가운데 하나입니다. 알 수 없는 팀은 임의로 바꾸지 않습니다.
completed와 minutes는 0 이상의 정수입니다. 문자열 숫자, true/false, null, 누락 값은 허용하지 않습니다.
입력 배열은 비어 있어도 됩니다. 한 행의 오류라도 있으면 전체 집계를 중단합니다.

[입력 샘플]
[
  {"record_id":"S001","team":"설계","completed":3,"minutes":90},
  {"record_id":"S002","team":"설계","completed":2,"minutes":50},
  {"record_id":"O001","team":"운영","completed":4,"minutes":80},
  {"record_id":"H001","team":"지원","completed":0,"minutes":0}
]

[처리 규칙]
팀별 completed와 minutes를 각각 합합니다.
minutes_per_completed = 팀 작업 시간 합계 / 팀 완료 건수 합계입니다.
행별 평균을 다시 평균하지 않습니다. 건수가 0이면 minutes_per_completed는 JSON null입니다.
평균은 계산 후 Decimal의 ROUND_HALF_UP 방식으로 소수 둘째 자리까지 반올림해 JSON 숫자로 저장합니다.
출력에는 입력에 나타난 팀만 넣고, 팀 순서는 설계 → 운영 → 지원으로 고정합니다.
빈 입력의 출력은 빈 배열 []입니다.

[기대 결과]
[
  {"team":"설계","total_completed":5,"total_minutes":140,"minutes_per_completed":28.0},
  {"team":"운영","total_completed":4,"total_minutes":80,"minutes_per_completed":20.0},
  {"team":"지원","total_completed":0,"total_minutes":0,"minutes_per_completed":null}
]
JSON 숫자는 28과 28.0의 표기가 달라도 같은 값으로 비교합니다.

[오류 원칙]
파일 없음, 잘못된 JSON, 배열이 아닌 최상위 구조, 중복 record_id, 필수 키 누락,
추가 키, 허용되지 않은 팀, 음수/문자열/불리언 숫자를 발견하면 성공 결과를 만들지 않습니다.
오류 메시지는 행 번호(1부터 시작)와 필드 이름, 오류 이유만 출력하고 입력 내용 전체를 출력하지 않습니다.
입력 오류를 0으로 바꾸거나 잘못된 행을 조용히 건너뛰지 않습니다. 종료 코드는 실패를 나타내야 합니다.

[답변 형식]
먼저 목적, 입력, 출력, 오류 처리, 남은 가정을 짧게 요약합니다.
그 다음 완성 스크립트와 실행 방법, 이 샘플의 기대 결과를 제시합니다.
요구사항끼리 충돌하거나 업무 의미를 확정할 수 없으면 코드를 쓰기 전에 해당 쟁점만 질문합니다.
실제로 실행하지 않았다면 실행 완료라고 쓰지 않습니다.

When reusing this for other work, do not change only the team names; also change the purpose, the definition of the input, the formula, the meaning of 0 and blank values, and the expected result. If the input sample and expected result disagree, it becomes unclear which one the AI will treat as the reference.

06Check before sending

• Are the file name, read scope, and output location stated?
• Are the data type, unit, and allowed values set for every field?
• Can you see the average's denominator and when rounding happens?
• Are missing, duplicate, zero-count, and empty-array cases defined differently?
• Does the sample show the work structure without any real sensitive information?
• Can a person explain the sample result?
• Did you ask it not to claim it ran something it did not run?

OWASP explains checking both the input format and the business meaning of values. This article carries that distinction into the request by separately defining “is it an integer,” “is it 0 or greater,” and “is it an allowed team.” Writing these in the request does not mean the returned code actually implements those rules.

07Common causes of inconsistent answers

08What this material checked and next steps

A request is an agreement document for implementation. Whether the code runs correctly, handles files safely, and fits real work data must be checked separately in the code you receive. This material checked the synthetic sample's expected values with Python and checked that the request contains the required items. It does not include results from asking an AI service or running generated code.

• request.txt: the full request above
• input-sample.json: four rows of synthetic input with no sensitive information
• expected-output.json: expected result matching the hand calculation and Python check
• prompt-checklist.txt: checklist for writing requests
• README.txt: order for reading the files

References were checked on the official pages on September 19, 2026. The Python and OWASP documents support the input format and validation principles; they do not guarantee the answer quality of any AI service.

Execution and verification record

Windows local Python standard library; official sources checked 2026-09-19

• Independently calculated the per-team count and time totals and averages for the 4 synthetic input rows and compared them with expected-output.json
• Checked that the average for the support team with 0 items is null
• Checked the request's input, output, sample, error, and sensitive-information exclusion items and the JSON syntax

Site-wide writing and verification principles

References

The explanations and examples were written for this site. See the official sources below for the related behavior and concepts.

• Python official documentation, json module ↗ (New tab)
• OWASP, Input Validation Cheat Sheet ↗ (New tab)