Skip to main content

write-a-case-study

Turn real project artifacts into a concise, credible case study that explains context, decisions, contribution, evidence, and lessons without inventing impact. Use when someone needs a portfolio case study, project write-up, interview leave-behind, or evidence behind a resume bullet.

소스 정보

저장소
protosphinx/sphinxstack
최근 소스 활동
2026년 7월 29일 13:55
감지된 SKILL.md 언어
영어
스타
3
포크
0

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

파일 탐색기
2 개 파일

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
write-a-case-study
category
resume
description
Turn real project artifacts into a concise, credible case study that explains context, decisions, contribution, evidence, and lessons without inventing impact. Use when someone needs a portfolio case study, project write-up, interview leave-behind, or evidence behind a resume bullet.
# write-a-case-study Build the story from artifacts first. Show what changed, why choices were made, what the person actually owned, and how the result was checked. ## Inputs - Collect the brief, repository or files, screenshots, drafts, data, feedback, release record, and dates. - Ask the person to mark their own contribution, collaborators, constraints, audience, and confidential details. - Decide the target reader and the decision the case study should help them make. ## Procedure 1. Create an evidence table with claim, source artifact, date, owner, and permission to publish. 2. Write the project in one sentence: user or organization, problem, person's role, and observable outcome. 3. Select only the context needed to understand the decisions. Remove generic industry background and unsupported importance claims. 4. Describe the person's contribution precisely, distinguishing individual work, team work, inherited systems, and guidance from others. 5. Choose two or three decisions that reveal judgment. For each, show constraint, options, choice, trade-off, and evidence from the result. 6. Present the process as a causal sequence, not a decorative timeline. Include one meaningful change prompted by testing, feedback, or failure. 7. Report outcomes with verifiable measures. Label estimates, qualitative feedback, and activity metrics; omit numbers that cannot be traced to evidence. 8. Include limitations, what did not work, and what the person would change next time. 9. Pair visuals with captions explaining what the reader should notice. Redact private data and obtain permission for people, brands, and client material. 10. Edit for a fast path: summary, role, decisions, result, lesson, links. Make deeper process optional. 11. Ask a reader unfamiliar with the project to identify the problem, contribution, evidence, and lesson. ## Boundaries Never invent metrics, quotes, dates, ownership, clients, or user research. Do not publish confidential screens, code, internal data, or collaborator work without permission. If evidence is missing, state the limitation or gather new evidence. ## Done - Every factual claim and result in the case study maps to a named artifact or firsthand account - The case study distinguishes personal contribution, team contribution, constraints, and trade-offs - Published visuals and examples are permission-checked, accessible, and free of private information - An unfamiliar reader can accurately summarize the problem, decisions, contribution, outcome, and lesson Then use portfolio-page to publish the case study and tailor-resume to reference the strongest evidence.
GitHub에서 보기