agentsclimarketplace

Plan create

Skill yarlson/yarstack/plugins/yarstack/skills/plan-create

Engineering workflows and standards for Codex and Claude Code: plan, implement, test, review, and deliver repository changes.

Install
npx -y skills add yarlson/yarstack --skill plan-create

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Create a final implementation-ready plan from a user brief, settled decisions, and repository evidence. Use when work needs ordered phases, concrete deliverables, dependencies, risks, and validation before coding.

SKILL.md

2.6 KB, as published. Nobody here has run it

Plan Creation

Synthesize an implementation-ready plan rather than repeating discovery, architecture sparring, or research.

Workflow

  1. Confirm the brief, authoritative repository evidence, applicable instructions, output location, and whether writing a repository plan file is authorized.
  2. Identify only decisions whose absence changes the implementation path. Resolve them with the user or record a blocker; keep safe assumptions explicit.
  3. Use architecture-refine for unresolved architecture decisions and technical-spike for blocking unfamiliar or version-sensitive behavior.
  4. Lock ownership boundaries, non-goals, compatibility, rollout order, validation gates, risks, and unresolved blockers.
  5. For behavior-changing work, name the authoritative contract, invariants and required progress, environmental assumptions, failure model, and material correctness claims. Map each claim to evidence; use test-design when selecting verification methods is non-trivial and technical-spike when a high-consequence design may need unfamiliar model checking or proof.
  6. For work affecting long-running or distributed workloads, settle the source of truth and invariants; graceful and abrupt restart behavior; rolling replacement and mixed-version overlap; concurrent-replica ownership and coordination; duplicate, stale, or out-of-order work; partial dependency failure, retry exhaustion, ambiguous outcomes, and recovery. Require observable acceptance evidence for the applicable cases and omit the rest.
  7. Divide work into implementation-sized phases ordered by real dependencies.
  8. Give each phase a goal, concrete deliverables, dependencies, steps, acceptance evidence, and structural traps to avoid.
  9. Reread the plan for hidden assumptions, missing prerequisites, contradictory acceptance criteria, failure and recovery gaps, and duplicate ownership.

Use the repository's established plan format. Omit empty ceremony. Name concrete subsystems, files, interfaces, migrations, UI surfaces, or test layers only where they remove implementation ambiguity.

Do not implement, validate, commit, push, or release. Keep a local behavior-preserving structural plan proportionate to its actual risk.

Finish when implementation-changing decisions are settled or explicit blockers, phases are dependency-ordered, and every phase has observable acceptance evidence.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.