recipe-prepare-implementation
Skill39 starsChanged 10 days agoMITView on GitHub
Prepare repository-local execution tools when the user requests setup or a concrete build capability is unavailable.
In this repository30 other files it gives its agents.
- ai-development-guideSkill
- coding-rulesSkill
- documentation-criteriaSkill
- external-resource-contextSkill
- implementation-approachSkill
- integration-e2e-testingSkill
- llm-friendly-contextSkill
- recipe-add-integration-testsSkill
- recipe-buildSkill
- recipe-designSkill
- recipe-diagnoseSkill
- recipe-front-adjustSkill
- recipe-front-buildSkill
- recipe-front-designSkill
- recipe-front-planSkill
- recipe-front-reviewSkill
- recipe-fullstack-buildSkill
- recipe-fullstack-implementSkill
- recipe-implementSkill
- recipe-outcome-watchSkill
- recipe-planSkill
- recipe-quality-profileSkill
- recipe-reverse-engineerSkill
- recipe-reviewSkill
- recipe-update-docSkill
- requirement-convergenceSkill
- reviewee-judgmentSkill
- subagent-delegationSkill
- subagents-orchestration-guideSkill
- testingSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 4 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 8
Before loading required skills, use wc -c to size the files and set both exec_command.max_output_tokens and the outer // @exec: …
- Distinctive: line 14
Run this optional side path when the user explicitly requests setup or Orchestrator Escalation Resolution identifies one concrete missing …
- Distinctive: line 25
test runner, browser harness, fixtures, and seed commands already referenced by the Work Plan or governing Design Doc
- Distinctive: line 33
Read repository manifests, lockfiles, checked-in setup documentation, and scripts that control commands used by the Work Plan.
- Distinctive: line 39
Use the active execution plan when one exists.
≈ “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.
Files
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.
- [LOAD IF NOT ACTIVE]
subagents-orchestration-guide— capability failure resolution and caller-return rules
Purpose
Run this optional side path when the user explicitly requests setup or Orchestrator Escalation Resolution identifies one concrete missing repository-local capability. Prepare existing repository-local tools needed to execute the approved Work Plan, then return a capability summary to the caller.
Work plan: $ARGUMENTS
Scope
Repository-local preparation includes existing project mechanisms for:
- dependency installation
- local containers or services
- repository-provided bootstrap commands
- test runner, browser harness, fixtures, and seed commands already referenced by the Work Plan or governing Design Doc
- non-secret local configuration derived from checked-in examples
Feature implementation, new product behavior, external account creation, credential acquisition, organizational approval, production access, deployment, and release execution remain in their owning workflows. The caller continues with the capabilities available after this side path.
Process
- Resolve the exact Work Plan path from
$ARGUMENTS, or from the build caller when invoked as its side path. - Read repository manifests, lockfiles, checked-in setup documentation, and scripts that control commands used by the Work Plan.
- Select the smallest existing setup commands that enable the planned repository checks.
- Execute those commands and capture their observable results.
- Classify each planned capability as
availableorunavailablewith concrete evidence. - Return the capability summary to the caller. In a build flow, unavailable capabilities become task-local verification limitations handled through Orchestrator Escalation Resolution. The approved Work Plan and its implementation task set remain unchanged.
Use the active execution plan when one exists. When setup has multiple dependent commands and no plan exists, create one and update it through completion.
Output
Environment Preparation Result
Status: completed
Work Plan: [path]
Available:
- [capability]: [command or evidence]
Unavailable:
- [capability]: [concrete reason]
Caller action: continue with available capabilitiesCompletion Check
- The exact Work Plan is identified.
- Selected commands come from repository-owned setup mechanisms.
- Command results provide evidence for every reported capability.
- The Work Plan remains unchanged.
- The capability summary is returned to the caller.
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
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.

