Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

Começar

plan

Estrelas7

Forks3

Atualizado23 de abril de 2026 às 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.

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

Aidbox

Aidbox/aidbox-hl7v2-example

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Especialistas em gestão de projetosNegócios e Operações Financeiras·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.

Mais deste repositório

mesmo repositório

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.