Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

Comenzar

plan

Estrellas7

Forks3

Actualizado23 de abril de 2026 a las 13:28

Create a checkbox task plan for a feature or fix. Output is a markdown file that `/work` executes one task at a time.

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

Aidbox

Aidbox/aidbox-hl7v2-example

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Especialistas en gestión de proyectosOperaciones empresariales y financieras·SOC 13-1082

SKILL.md

readonly

name	plan
description	Create a checkbox task plan for a feature or fix. Output is a markdown file that `/work` executes one task at a time.

Plan

Write an implementation plan as a markdown file of checkbox tasks. The plan is executed by /work, one task at a time with user checkpoints.

Output

Location: ai/tickets/YYYY-MM-DD-short-name.md

If the ticket already has upstream sections (e.g. # Requirements from a prior phase), leave them in place and append the plan as its own section. Reference upstream content by heading — don't duplicate it.

Process

If the request is ambiguous, ask only the questions that genuinely block exploration. Many questions are better deferred to step 3.

Explore the codebase. Read CLAUDE.md directly. For unfamiliar areas, spawn an Explore agent via the Agent tool:

Agent({
  description: "Explore <area>",
  subagent_type: "Explore",
  prompt: "Find <what you need>. Focus: <files or patterns>. Report under 200 words."
})

Present findings and propose the implementation shape. Confirm with the user before writing tasks.
Write the plan using the structure below.

Structure

# Plan: [Name]

## Overview
[2–4 sentences: what and why]

## Validation
- `bun test:local`
- `bun run typecheck`

## Task 1: [Name]
- [ ] Specific action with file/function reference
- [ ] ...
- [ ] Write/update tests
- [ ] Run validation — must pass
- [ ] Stop for user review before next task

## Task 2: ...

## Task N: Cleanup
- [ ] Update docs (CLAUDE.md, inline comments) if patterns changed
- [ ] Final `bun test:all`

Task rules

One concern per task. If a task has 3 unrelated bullets, split it. Target 3–7 checkboxes.
Every task ends with a validation gate + user checkpoint.
Order by dependency — types before consumers, shared code before users, tests alongside implementation, cleanup last.
Reference concrete files (src/foo/bar.ts:42), not "the bar module."

Planning rules

Ask the user only about business/product decisions — what the feature should do, what behavior is acceptable. Decide technical tradeoffs (file layout, helper extraction, naming) yourself.
No open questions at finalization. If the user defers an answer, mark it OPEN: inline in the plan rather than leaving implicit ambiguity.
Plan ≠ code. Don't implement anything while writing the plan.

Más de este repositorio

mismo repositorio

check-errors

Aidbox/aidbox-hl7v2-example

Check recent HL7v2 processing errors in Aidbox, diagnose root causes, suggest fixes. Use when asked to check errors, diagnose failures, or troubleshoot message processing.

2026-04-247

fhir-info

Aidbox/aidbox-hl7v2-example

Look up FHIR R4 resource/datatype fields, types, cardinality, reference targets, and coded enums (including custom resources like IncomingHL7v2Message, OutgoingBarMessage). Use when writing converters or verifying FHIR compliance.

2026-04-247

hl7v2-to-fhir-pipeline

Aidbox/aidbox-hl7v2-example

Build a new HL7v2→FHIR message converter or extend an existing one. Orchestrates requirements gathering, then delegates to `/plan` and `/work`.

2026-04-247

work

Aidbox/aidbox-hl7v2-example

Execute a plan produced by `/plan` — one task at a time, with tests and an independent review after each task.

2026-04-237

aidbox-request

Aidbox/aidbox-hl7v2-example

Authenticate ad-hoc curl requests to the local Aidbox using the root Client secret from docker-compose.yaml. Use for debugging and one-off queries from the shell (not from app code — `src/aidbox.ts` already wraps auth).

2026-04-227

hl7v2-info

Aidbox/aidbox-hl7v2-example

Look up HL7v2 segment fields, datatypes, components, tables, and message structures. Use when writing converters, checking field positions/optionality, or verifying HL7v2 spec compliance.

2026-04-227

Plan

Write an implementation plan as a markdown file of checkbox tasks. The plan is executed by /work, one task at a time with user checkpoints.

Output

Location: ai/tickets/YYYY-MM-DD-short-name.md

Process

If the request is ambiguous, ask only the questions that genuinely block exploration. Many questions are better deferred to step 3.

Explore the codebase. Read CLAUDE.md directly. For unfamiliar areas, spawn an Explore agent via the Agent tool:

Agent({
  description: "Explore <area>",
  subagent_type: "Explore",
  prompt: "Find <what you need>. Focus: <files or patterns>. Report under 200 words."
})

Present findings and propose the implementation shape. Confirm with the user before writing tasks.

Write the plan using the structure below.

Structure

# Plan: [Name] ## Overview [2–4 sentences: what and why] ## Validation - `bun test:local` - `bun run typecheck` ## Task 1: [Name] - [ ] Specific action with file/function reference - [ ] ... - [ ] Write/update tests - [ ] Run validation — must pass - [ ] Stop for user review before next task ## Task 2: ... ## Task N: Cleanup - [ ] Update docs (CLAUDE.md, inline comments) if patterns changed - [ ] Final `bun test:all`

Task rules

One concern per task. If a task has 3 unrelated bullets, split it. Target 3–7 checkboxes.

Every task ends with a validation gate + user checkpoint.

Order by dependency — types before consumers, shared code before users, tests alongside implementation, cleanup last.

Reference concrete files (src/foo/bar.ts:42), not "the bar module."

Planning rules

Ask the user only about business/product decisions — what the feature should do, what behavior is acceptable. Decide technical tradeoffs (file layout, helper extraction, naming) yourself.

No open questions at finalization. If the user defers an answer, mark it OPEN: inline in the plan rather than leaving implicit ambiguity.

Plan ≠ code. Don't implement anything while writing the plan.