agentleFS
shinprshinpr/codex-workflows/.agents/skills/recipe-implement/SKILL.md

recipe-implement

Skill39 starsChanged 10 days agoMITView on GitHub

Orchestrate the complete implementation lifecycle from requirements through verified repository implementation.

2 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 2 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Before loading required skills, use wc -c to size the files and set both exec_command.max_output_tokens and the outer // @exec: …

    line 8
  2. Very specific:

    Invocation rule: Start each named agent with spawn_agent and fork_turns="none".

    line 15
  3. Distinctive:

    Follow the scale-selected flow and its user approval points from subagents-orchestration-guide.

    line 25
  4. Distinctive:

    Verify acceptance-test-generator artifact paths and pass them to work-planner.

    line 64

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Required Skills [LOAD BEFORE EXECUTION]

Before loading required skills, use wc -c to size the files and set both exec_command.max_output_tokens and the outer // @exec: {"max_output_tokens": N} budget to accommodate their contents, including the combined output of batched reads. Split oversized reads upfront; recover any truncated content before proceeding.

  1. [LOAD IF NOT ACTIVE] subagents-orchestration-guide — agent coordination and workflow routing
  2. [LOAD IF NOT ACTIVE] documentation-criteria — scale-selected document path
  3. [LOAD IF NOT ACTIVE] requirement-convergence — outcome, exclusion, and rough-cost convergence before design
  4. [LOAD IF NOT ACTIVE] llm-friendly-context — cross-agent handoffs and task carrier

Invocation rule: Start each named agent with spawn_agent and fork_turns="none". When invoking the same named agent again within this flow, use followup_task on its existing instance with the inputs specified for the current invocation.

Full-Cycle Implementation

$ARGUMENTS

Orchestrator Definition

Core Identity: Coordinate the lifecycle, complete lightweight workflow operations directly, and invoke named specialists for their domain work.

Follow the scale-selected flow and its user approval points from subagents-orchestration-guide.

Step 1: Requirement Analysis

Apply the subagents-orchestration-guide Requirement Evidence Handoff, then invoke requirement-analyzer for compact scope evidence, cost evidence, and affected-layer evidence.

At the requirements stop, the orchestrator compares the evidence with its retained user record and applies subagents-orchestration-guide Requirement Convergence. User selections establish requirements and exclusions; the orchestrator judges readiness, determines Structural Scale and affected layers, and selects the canonical route.

Immediately before the stop, read requirement-convergence's references/scope-confirmation.md and render that output from the retained user record and analyzer evidence. Record Structural Scale and workflow routing under Workflow.

[STOP — BLOCKING] Present the Scope Confirmation to the user, then proceed after explicit confirmation.

Step 2: Canonical Workflow Routing

Apply the subagents-orchestration-guide Basic Flow for Work Planning using scale as the primary route. Use affectedLayers only to select the layer-specific additions and agents within that route:

affectedLayersLayer-specific routing
["backend"] onlyBackend agents
["frontend"] onlyUI Spec when required by the canonical flow, then frontend designer, executor, and quality fixer
["backend", "frontend"]Fullstack monorepo flow with complete-scope codebase analysis plus layer-specific design and task routing

The scale-selected Large, Medium, or Small flow remains authoritative for document creation, codebase analysis, design verification, planning, and execution.

Autonomous Execution Mode

Enter autonomous execution when the subagents-orchestration-guide Work Plan Authorization is satisfied.

Per-Task Execution Cycle

For a fullstack task set, apply subagents-orchestration-guide's references/monorepo-flow.md filename routing. For a single-layer task set, use the executor and quality fixer selected by affectedLayers. Execute each task through the canonical autonomous task cycle.

Post-Implementation Review (After All Tasks Complete)

Apply subagents-orchestration-guide Post-Implementation Review to the actual repository changes and governing documents. Use the active Small task file as the governing source when no durable document exists. Resolve required fixes through the normal task cycle.

Apply a security-reviewer finding only when leaving it unresolved would violate an explicit governing requirement or repository rule, or leave a concrete material security failure in the actual reachable trust model. The violated requirement, rule, or failure defines implementation scope: route the smallest correction that resolves it, treating the reviewer's suggestion as one candidate implementation.

Test Information Communication

Verify acceptance-test-generator artifact paths and pass them to work-planner.

Completion Criteria

  • Scope/cost evidence was collected, the user selected requirements and exclusions, and orchestrator readiness, scale, and routing decisions were recorded
  • Layer routing determined (backend / frontend / fullstack)
  • Correct workflow followed per layer routing
  • codebase-analyzer included before Design Doc creation for Medium/Large flows
  • code-verifier discrepancies passed through Review Resolution before Design Doc review
  • All stopping points honored with user confirmation obtained
  • Quality-fixer invoked before every commit
  • All tasks committed or user input requested

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.