Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

write-design-doc

Estrellas0

Forks0

Actualizado11 de junio de 2026 a las 07:42

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.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Ejecutar en Manus

Fuente

lanesawyer

lanesawyer/ai-config

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Desarrolladores de softwareOcupaciones informáticas y matemáticas·SOC 15-1252

SKILL.md

readonly

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)

Write Design Doc

Produce a technical design doc / RFC grounded in the real codebase, with the trade-offs and open questions made explicit.

Step 1: Gather context

Establish the problem, constraints, and stakeholders.

If a Jira ticket is provided, follow the jira-read-ticket skill to pull intent and acceptance criteria.
Otherwise use the user's problem statement. If it's too vague to design from, ask one or two clarifying questions before continuing.

Write a one-paragraph problem statement and confirm it captures the goal.

Step 2: Ground the design in code

Explore the codebase so the design reflects reality, not assumptions:

Affected modules, entry points, and the current behavior being changed
Existing patterns and abstractions the design should reuse or extend
Constraints the current architecture imposes (data models, interfaces, deploy boundaries)

Step 3: Draft the doc

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.

Step 4: Surface the open questions

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.

Más de este repositorio

mismo repositorio

setup-astro-repo

lanesawyer/ai-config

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.

2026-07-100

add-ci-workflow

lanesawyer/ai-config

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.

2026-07-070

create-website

lanesawyer/ai-config

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.

2026-07-060

fly-new-app

lanesawyer/ai-config

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.

2026-07-060

gh-pages-deploy-workflow

lanesawyer/ai-config

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.

2026-07-060

fly-deploy-workflow

lanesawyer/ai-config

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.

2026-07-060

Write Design Doc

Produce a technical design doc / RFC grounded in the real codebase, with the trade-offs and open questions made explicit.

Step 1: Gather context

Establish the problem, constraints, and stakeholders.

If a Jira ticket is provided, follow the jira-read-ticket skill to pull intent and acceptance criteria.

Otherwise use the user's problem statement. If it's too vague to design from, ask one or two clarifying questions before continuing.

Write a one-paragraph problem statement and confirm it captures the goal.

Step 2: Ground the design in code

Explore the codebase so the design reflects reality, not assumptions:

Affected modules, entry points, and the current behavior being changed

Existing patterns and abstractions the design should reuse or extend

Constraints the current architecture imposes (data models, interfaces, deploy boundaries)

Step 3: Draft the doc

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.

Step 4: Surface the open questions

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.