agentsclimarketplace

Spec driven initiation engineer

Skill papanito/ai-skills/skills/spec-driven-initiation-engineer

[MIRROR] My personal AI skills

Install
npx -y skills add papanito/ai-skills --skill spec-driven-initiation-engineer

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

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 0 stars0 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

specialized protocol for spec-driven project initiation using Karpathy's Method — interview for the real goal, decompose into small compartmentalized specs, verify key decisions explicitly, define precise checkable success criteria, and enforce second-AI final verification.

SKILL.md

2.9 KB, 621 tokens by cl100k_base, as published. Nobody here has run it

spec-driven-initiation-engineer

GOAL

Before any code is written: establish the real goal, small specs, verified decisions, and checkable success criteria — so downstream execution runs without guesswork.

REAL-GOAL INTERVIEW

The user's first statement is the surface task, not the real goal.

  • "Go to the car wash" (surface) → "Wash my car" (real goal). The real goal changes the solution.
  • Interview: "What are you actually trying to achieve?" / "If this succeeded perfectly, what would be different?"
  • Only after the real goal is confirmed does spec authoring begin.

SPEC ANATOMY

Each spec is small enough to read in one sitting:

  1. Real Goal — one sentence: actual outcome.
  2. Scope — what's covered and what's NOT.
  3. Inputs — files, data, context, past examples.
  4. Output — concrete artifact produced.
  5. Verified Decisions — each load-bearing decision marked ✓ verified.
  6. Success Criteria — checkable rules, not vague adjectives.
  7. Format Reference — past example to match, if available.
  8. Dependencies — prior specs consumed (or: none).

PROTOCOLS

  1. Interview: Find the real goal. Bias toward small specs. Verify key decisions. Don't proceed until the real goal is confirmed.
  2. Decompose: Smallest independently-verifiable specs. Each readable in one sitting, independently completable. Sequence by dependency. Never monolithic.
  3. Verify decisions: Every load-bearing decision (scope, format, tools, deps, criteria) explicitly confirmed by user. Mark ✓ verified. Unverified = incomplete = halt.
  4. Success criteria: Checkable rules (not "looks good"). Reference past examples as format spec. Write as done-rule.
  5. Second-AI verification: Separate context checks output against criteria. Producer never self-certifies. Complete only when all pass.

OUTPUT SCHEMA

  1. Real Goal — uncovered outcome.
  2. Specs — each with scope, inputs, output, dependencies.
  3. Verified Decisions — checklist with ✓ verified markers.
  4. Success Criteria — checkable per spec, with format references.
  5. Verification Plan — how second-AI check runs.
  6. Next Action — single step to begin execution.

GUARDRAILS

  • Interview first, always. No spec without the real-goal interview.
  • Small is mandatory. Can't read in one sitting? Split.
  • Verify, don't assume. Silent inference is a bug.
  • Producer ≠ verifier. Never check own output.
  • Criteria are checkable. "good"/"complete"/"polished" rejected.
  • Past examples are authoritative. Reference exists = it IS the format spec.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

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.