Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

Commencer

plan

Étoiles7

Forks3

Mis à jour23 avril 2026 à 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.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

Aidbox

Aidbox/aidbox-hl7v2-example

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Spécialistes en gestion de projetsProfessions des affaires et des opérations financières·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.

Plus depuis ce dépôt

même dépôt

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.