Cómo escribir tus propios workflows con Codex Skills: de prompts repetidos a SKILL.md reutilizable

1
2
3
4
5

convertir un post chino en un artículo publicable
convertir logs en un informe diario
revisar un PR por seguridad, regresiones y tests faltantes
ejecutar un flujo de deploy con build, sync, purge y submit
normalizar imágenes de producto

1
2

my-workflow/
  SKILL.md

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

my-workflow/
  SKILL.md
  references/
    checklist.md
    examples.md
  scripts/
    validate.ps1
    collect-data.py
  assets/
    report-template.md

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

---
name: my-workflow
description: Use when the user asks to <specific trigger>. Handles <input>, produces <output>, and verifies <completion criteria>.
---

# My Workflow

## Purpose

Explain what repeated task this skill solves and what it does not solve.

## When To Use

- Use when the user explicitly mentions this task.
- Use when the task needs fixed steps, fixed output, or fixed validation.
- Do not use for ordinary Q&A.

## Inputs

- What must the user provide?
- What can be discovered from the repository?
- What should be assumed or asked if missing?

## Workflow

1. Check current state.
2. Read required files.
3. Perform the core task.
4. Run lightweight validation.
5. Report results and remaining work.

## Constraints

- Which files must not be changed?
- Which commands must not be run?
- Which fields must be preserved?
- How should conflicts be handled?

## Verification

- Check output files.
- Check format.
- Check commands.
- Check residual risks.

## Reporting

Final response should include:

- what changed
- what did not change
- validation result
- risks for the user

1

description: Help with reports.

1

description: Use when the user asks to turn Git commits, issue updates, or daily work notes into a weekly engineering report with sections for completed work, risks, blockers, and next actions.

1

You are a senior engineer. Please review this change and focus on edge cases and tests.

1
2
3
4
5
6
7
8

## Workflow

1. Run `git status --short`.
2. Read the relevant diff.
3. Identify behavior changes before style issues.
4. List findings by severity.
5. Prioritize bugs, regressions, security issues, and missing tests.
6. If no issues are found, say so and list residual test gaps.

1
2
3
4
5

## References

- Read `references/report-rubric.md` only when judging report quality.
- Read `assets/weekly-report-template.md` when generating a full report.
- Do not load the full example library for a short summary.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

---
name: weekly-report
description: Use when the user asks to create a weekly work report from Git commits, notes, issue updates, or chat summaries. Produces a concise Chinese report with completed work, impact, blockers, and next week plan.
---

# Weekly Report

## Workflow

1. Confirm the report date range. If missing, use the current week.
2. Collect source material from user-provided notes first.
3. If the user asks to include Git work, run `scripts/collect-git-summary.ps1`.
4. Group work by project or theme, not by raw commit order.
5. Produce a concise Chinese report using `assets/weekly-report-template.md`.
6. Mark uncertain items as uncertain instead of inventing progress.

## Constraints

- Do not expose private commit hashes unless the user asks.
- Do not claim shipped work if the source only shows drafts or experiments.
- Keep blockers separate from completed work.

## Reporting

Return the report content and list which sources were used.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

---
name: focused-code-review
description: Use when the user asks for a code review of the current working tree, a commit, or a pull request. Prioritize bugs, regressions, security risks, and missing tests; do not rewrite code unless asked.
---

# Focused Code Review

## Workflow

1. Inspect `git status --short`.
2. Read the relevant diff.
3. Identify behavior changes before style issues.
4. List findings first, ordered by severity.
5. Include file and line references when possible.
6. If no issues are found, say so directly and mention remaining test gaps.

## Constraints

- Do not make code edits during review.
- Do not focus on formatting unless it can cause a real bug.
- Do not summarize before findings.

1

$weekly-report create a report from this week's commits

1

Create a weekly report from this week's git commits.