ferueda/harness · Archived

create-plan

Write a plan when explicitly requested or when safe execution needs durable sequencing, cutover, risk controls, or an executor handoff. File count alone does not justify planning.

First seen Jun 26, 2026

Installation

$ npx skills add ferueda/harness --skill create-plan

Stronger alternatives

This repository is archived — consider an actively maintained alternative.

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from ferueda/harness · top by installs.

npx skills add ferueda/harness

Browse all from ferueda/harness

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 3
License LICENSE
Default branch main
Open issues 0
Status Archived

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 2,756 B
  • docs SUMMARY.md 198 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 13 installs

SKILL.md

Create Plan

Write the minimum sufficient plan for a capable, context-limited executor with repository access but without prior context about the task at hand.

Entry and authority

Use for a requested plan or an established execution need. Clear build/fix work may proceed directly; no router is needed to obtain permission. Planning does not authorize implementation or publication.

Accepted requirements govern within host permissions and explicit safety constraints. Repository intent is the baseline, not a veto on an approved change to it. Explain such changes and their review boundaries. Proposals are context.

Make the plan executable

Inspect relevant code, callers, contracts, tests, and current documentation. Read intent sources when direction or ownership matters. Separate existing and requested behavior; resolve material design choices. Ask only for a human prerequisite preventing a useful plan. Routine execution-time discovery belongs to the executor.

Choose the smallest coherent change. Preserve accepted owners, removals, cutover order, and compatibility. Prefer vertical outcome slices that can be verified, reviewed, and landed independently. Explain an indivisible migration or minimum shared prerequisite when horizontal delivery is necessary.

Use [the plan template](references/plan-template.md). Keep evidence and proof beside their change. Name verified paths or symbols instead of copying source or prescribing shell choreography. Name a verified executor skill only when it adds non-obvious guidance for a concrete decision; do not assume sibling installs.

Connect each material outcome or forbidden effect to an exact proof action and expected observable evidence. Prefer the highest existing stable test seam; another seam needs a distinct failure mode. Separate acceptance evidence from the repository gate and avoid duplicate commands. State mock/source-check limits. Async work needs terminal evidence, not only acceptance or enqueueing. Live proof needs explicit authority, prerequisites, assertions, stop conditions, redaction, disposable data, cleanup, and stated uncertainty.

Deliver

Write under dev/plans/ using the target repository's naming, index, and retirement policy. Prune repeated context, empty sections, speculative hardening, and tests unrelated to acceptance or verified risk. Report unavailable proof.

For plan-only work, finish with the reviewable plan. Continue further review or execution only when already authorized, rather than stopping after naming it.