Case Study Writer
Overview
Use this skill to turn private project work into public-safe proof: concise case studies that explain the problem, workflow, outcome, and adaptation value without exposing source code, credentials, raw prompts, logs, databases, client data, or private implementation details.
Workflow
- Clarify the public artifact target: GitHub case study, website system page, portfolio note, demo companion, or README section.
- Read
references/case-study-template.md and use its section order unless the destination already has a stronger house style.
- Read
references/safety-boundary-examples.md before writing the opening boundary note and final Safety Boundary section.
- Extract only public-safe facts:
- Problem the system solves.
- What the system does at workflow level.
- Human review and approval points.
- General stack categories when useful.
- Outcome stated qualitatively or with approved aggregate numbers.
- What a similar client could adapt.
- Rewrite private details into generic, reusable language. Do not copy raw notes, prompts, logs, exports, database rows, or source code.
- Produce the case study in Markdown and include a short safety verdict:
BLOCK, REVIEW, or READY.
Case Study Shape
Use these sections by default:
- Title
- Boundary note
- Public page or demo links, if already approved and live
- Problem
- What The System Does
- Workflow
- Outcome
- What Can Be Adapted For Clients
- Safety Boundary
Keep the case study short enough to scan quickly. Prefer six to eight workflow steps and three to five client-adaptation bullets.
Safety Rules
- Never include source code, private prompts, API keys, credentials, databases, logs, exports, client messages, account identifiers, local paths, or screenshots with private UI.
- Do not name clients, prospects, internal codenames, domains, or people unless the user confirms they are approved for public use.
- Use broad stack categories such as Python, SQLite, browser automation, queue dashboard, or LLM API instead of exact private architecture when details are not needed.
- Mention human approval explicitly when the system drafts, scores, publishes, sends, spends, or changes a system of record.
- If the user provides risky source material, return
BLOCK with removal instructions before writing the publishable draft.
Output Format
Return:
- Safety verdict:
BLOCK, REVIEW, or READY.
- Short note on what was excluded or generalized.
- The Markdown case study.
- Remaining checks before publication.
If the user asks you to edit files, write the draft into the requested location or a sanitized staging folder, then recommend running a public-safety scan before commit.
1---2name: case-study-writer3description: Write public-safe case studies from private projects, automations, agent workflows, internal tools, demos, or client-facing systems. Use when the user asks to turn project work into a case study, create client proof, write a sanitized GitHub case study, summarize an internal system publicly, document an automation without sharing source code, or explain a workflow while removing credentials, raw prompts, logs, databases, client data, local paths, and private implementation details.4---56# Case Study Writer78## Overview910Use this skill to turn private project work into public-safe proof: concise case studies that explain the problem, workflow, outcome, and adaptation value without exposing source code, credentials, raw prompts, logs, databases, client data, or private implementation details.1112## Workflow13141. Clarify the public artifact target: GitHub case study, website system page, portfolio note, demo companion, or README section.152. Read `references/case-study-template.md` and use its section order unless the destination already has a stronger house style.163. Read `references/safety-boundary-examples.md` before writing the opening boundary note and final Safety Boundary section.174. Extract only public-safe facts:18 - Problem the system solves.19 - What the system does at workflow level.20 - Human review and approval points.21 - General stack categories when useful.22 - Outcome stated qualitatively or with approved aggregate numbers.23 - What a similar client could adapt.245. Rewrite private details into generic, reusable language. Do not copy raw notes, prompts, logs, exports, database rows, or source code.256. Produce the case study in Markdown and include a short safety verdict: `BLOCK`, `REVIEW`, or `READY`.2627## Case Study Shape2829Use these sections by default:3031- Title32- Boundary note33- Public page or demo links, if already approved and live34- Problem35- What The System Does36- Workflow37- Outcome38- What Can Be Adapted For Clients39- Safety Boundary4041Keep the case study short enough to scan quickly. Prefer six to eight workflow steps and three to five client-adaptation bullets.4243## Safety Rules4445- Never include source code, private prompts, API keys, credentials, databases, logs, exports, client messages, account identifiers, local paths, or screenshots with private UI.46- Do not name clients, prospects, internal codenames, domains, or people unless the user confirms they are approved for public use.47- Use broad stack categories such as Python, SQLite, browser automation, queue dashboard, or LLM API instead of exact private architecture when details are not needed.48- Mention human approval explicitly when the system drafts, scores, publishes, sends, spends, or changes a system of record.49- If the user provides risky source material, return `BLOCK` with removal instructions before writing the publishable draft.5051## Output Format5253Return:54551. Safety verdict: `BLOCK`, `REVIEW`, or `READY`.562. Short note on what was excluded or generalized.573. The Markdown case study.584. Remaining checks before publication.5960If the user asks you to edit files, write the draft into the requested location or a sanitized staging folder, then recommend running a public-safety scan before commit.
jqaisystems