메뉴
Author a technical design doc / RFC from a problem statement or Jira ticket, grounded in the actual codebase. Use when: writing a design doc, drafting an RFC, proposing a technical approach, documenting a system design before building.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Scaffold a web repo with pnpm, Astro, and astro-bulma — plus Drizzle when the site needs a database — including package.json scripts for build/lint/test/fmt (and db:migrate when db-backed). Use when: setting up a new Astro project, scaffolding a web repo, initializing the standard web stack. Building block for create-website.
Add a GitHub Actions CI workflow running build, lint, test, and fmt checks with pnpm. Use when: adding CI, setting up GitHub Actions checks, adding a build/lint/test workflow. Building block for create-website.
Create a new website end-to-end: Astro repo with pnpm/astro-bulma; GitHub Pages for static sites, or Turso + Fly.io when the site needs a database; GitHub Actions for CI and deploy. Use when: creating a new website, spinning up a new web project, new site, scaffolding a static or full-stack Astro project.
Create a new app on Fly.io for the current project without deploying it, generating fly.toml and a Dockerfile. Use when: creating a Fly.io app, setting up Fly hosting, fly launch. Building block for create-website.
Add a GitHub Actions workflow that builds a static site and deploys it to GitHub Pages, with an optional custom domain. Use when: deploying a static site, GitHub Pages hosting, static site with a custom domain. Building block for create-website.
Add a GitHub Actions workflow that deploys to Fly.io on merge to main, with db migrations run as a Fly release_command. Use when: adding a deploy workflow, deploying on merge, setting up continuous deployment to Fly.io. Building block for create-website.
| name | write-design-doc |
| description | Author a technical design doc / RFC from a problem statement or Jira ticket, grounded in the actual codebase. Use when: writing a design doc, drafting an RFC, proposing a technical approach, documenting a system design before building. |
| argument-hint | A problem statement or Jira ticket key (e.g. DT-1234) |
Produce a technical design doc / RFC grounded in the real codebase, with the trade-offs and open questions made explicit.
Establish the problem, constraints, and stakeholders.
jira-read-ticket skill to pull intent and acceptance criteria.Write a one-paragraph problem statement and confirm it captures the goal.
Explore the codebase so the design reflects reality, not assumptions:
Output a single markdown doc with this skeleton. Omit a section only if genuinely not applicable.
# <Title>
## Problem
What's broken or missing, and why it matters now.
## Goals & non-goals
Explicit in-scope outcomes; explicit out-of-scope items.
## Proposed approach
The design. Reference concrete files/modules (`path:line`). Include a diagram or
data-flow sketch if it clarifies.
## Alternatives considered
Each alternative with why it was rejected. At least one.
## Risks & trade-offs
What this approach costs, what could go wrong, blast radius.
## Rollout & testing
Sequencing, feature flags/migrations, how it gets verified.
## Open questions
Unresolved decisions, ordered by how much they block progress.
After the doc, restate the open questions as a short list for the user to resolve, flagging which ones block starting implementation. Do not paper over a real decision with a guess.