navigator-execplan

Étoiles11

Forks4

Mis à jour28 avril 2026 à 19:50

Use when the user asks to plan a Navigator feature, write an implementation plan, create or update an ExecPlan, break down a substantial change into milestones, or prepare a self-contained specification before coding.

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.

Source

navigatorframework

navigatorframework/navigator

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

Téléchargement

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·SOC 15-1252

SKILL.md

readonly

name	navigator-execplan
description	Use when the user asks to plan a Navigator feature, write an implementation plan, create or update an ExecPlan, break down a substantial change into milestones, or prepare a self-contained specification before coding.

Navigator ExecPlan

Use this skill when the user asks for a plan for a feature or substantial repository change.

Required Reading

Read .agents/PLANS.md before writing, updating, or implementing an ExecPlan. That file is the source of truth for the required structure, tone, self-contained context, progress tracking, validation, and living-document rules.

If the plan involves core runtime behavior, also use navigator-architecture and read docs/ARCHITECTURE.md.

If the plan involves Navigator.Extensions.*, also use navigator-extension-authoring and read docs/EXTENSION-AUTHORING.md.

If the plan involves project or solution layout, also use navigator-solution.

Workflow

Clarify scope when needed. Ask concise questions if the expected behavior, public API, package target, or validation outcome is ambiguous.
Read the relevant source files before planning. Do not write a generic plan detached from the current code.
Produce a self-contained ExecPlan that a novice could follow with only the repository and the plan file.
Include user-visible purpose, exact files, concrete steps, validation commands, acceptance behavior, idempotence, and recovery notes.
Maintain the required living sections:
- Progress
- Surprises & Discoveries
- Decision Log
- Outcomes & Retrospective
If the user asks only for a plan, do not start implementation unless they explicitly ask to proceed.

Formatting Rules

Follow .agents/PLANS.md exactly.
When returning an ExecPlan directly in chat, wrap the whole plan in one fenced md code block.
When writing an ExecPlan to a Markdown file that contains only the plan, omit the outer fence.
Do not nest triple-backtick fences inside an ExecPlan.
Prefer prose-first milestones with checkboxes only in Progress.

Validation Policy

Plans for code changes should end with strict validation from src/ unless there is a documented reason not to:

dotnet restore
dotnet build -c Release --no-restore
dotnet test -c Release --no-build --verbosity normal

For documentation-only plans, specify a concrete review or consistency check instead of pretending a build proves the doc change.

Plus depuis ce dépôt

même dépôt

navigator-extension-authoring

navigatorframework/navigator

Use when creating, modifying, testing, packaging, or documenting Navigator.Extensions.* packages, extension options, extension services, pipeline steps, action builder methods, extension samples, or extension-specific README examples.

2026-05-0211

navigator-solution

navigatorframework/navigator

Use when working inside the Navigator repository to create, modify, or validate .NET projects, solution structure, tests, samples, extensions, or strategies. This skill defines the required `dotnet` CLI workflow, naming conventions, project placement, and validation commands for this solution.

2026-05-0211

navigator-architecture

navigatorframework/navigator

Use when working on Navigator core behavior, request processing, dependency injection, action resolution, execution pipelines, argument resolution, tracing, webhook handling, or any change that needs understanding of the framework runtime architecture.

2026-04-2811

Navigator ExecPlan

Use this skill when the user asks for a plan for a feature or substantial repository change.

Required Reading

If the plan involves core runtime behavior, also use navigator-architecture and read docs/ARCHITECTURE.md.

If the plan involves Navigator.Extensions.*, also use navigator-extension-authoring and read docs/EXTENSION-AUTHORING.md.

If the plan involves project or solution layout, also use navigator-solution.

Workflow

Clarify scope when needed. Ask concise questions if the expected behavior, public API, package target, or validation outcome is ambiguous.

Read the relevant source files before planning. Do not write a generic plan detached from the current code.

Produce a self-contained ExecPlan that a novice could follow with only the repository and the plan file.

Include user-visible purpose, exact files, concrete steps, validation commands, acceptance behavior, idempotence, and recovery notes.

Maintain the required living sections:

Progress
Surprises & Discoveries
Decision Log
Outcomes & Retrospective

If the user asks only for a plan, do not start implementation unless they explicitly ask to proceed.

Formatting Rules

Follow .agents/PLANS.md exactly.

When returning an ExecPlan directly in chat, wrap the whole plan in one fenced md code block.

When writing an ExecPlan to a Markdown file that contains only the plan, omit the outer fence.

Do not nest triple-backtick fences inside an ExecPlan.

Prefer prose-first milestones with checkboxes only in Progress.

Validation Policy

Plans for code changes should end with strict validation from src/ unless there is a documented reason not to:

dotnet restore dotnet build -c Release --no-restore dotnet test -c Release --no-build --verbosity normal

For documentation-only plans, specify a concrete review or consistency check instead of pretending a build proves the doc change.