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

recipe-plan

Skill39 starsChanged 11 days agoMITView on GitHub

Creates a reviewed Work Plan with value-filtered integration/E2E test skeletons. Use when planning implementation from a Design Doc.

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

8 rules. About 0 are common, 5 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    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:

    Test skeleton generation with acceptance-test-generator

    line 36
  4. Distinctive:

    Follow the planning process below:

    line 43
  5. Very specific:

    Check for existence of design documents in docs/design/, notify user if none exist.

    line 48
  6. Distinctive:

    Verify generated artifact paths and pass them to Step 3.

    line 53
  7. Distinctive:

    Verify the returned Work Plan path and use it as the Step 4 review target

    line 57
  8. Distinctive:

    After explicit authorization, record the user's instruction and scope in Implementation Authorization

    line 73

≈ “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] documentation-criteria — Work Plan scope and template
  2. [LOAD IF NOT ACTIVE] implementation-approach — implementation ordering and verification strategy
  3. [LOAD IF NOT ACTIVE] subagents-orchestration-guide — agent coordination and workflow flow
  4. [LOAD IF NOT ACTIVE] llm-friendly-context — planning handoffs and artifact contract

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.

Context: Dedicated to the planning phase.

Orchestrator Definition

Core Identity: Coordinate the planning workflow and complete lightweight routing, file selection, approval recording, and status updates directly.

Execution Plan: Reuse the active execution plan. When the workflow has multiple dependent actions and no plan exists, create one that tracks them through final verification.

Execution Protocol:

  1. Invoke the named specialist for test generation, Work Plan creation, and semantic review. The orchestrator owns deterministic coordination and status changes.
  2. Follow subagents-orchestration-guide skill planning flow exactly:
    • Execute steps defined below
    • Present plan content and apply Work Plan Authorization; obtain missing implementation authority without repeating permission already granted.
  3. Scope: Complete when the reviewed plan's implementation authority is resolved

Scope Boundaries

Included in this skill:

  • Design document selection
  • Test skeleton generation with acceptance-test-generator
  • Work plan creation with work-planner
  • Work plan review with document-reviewer
  • Implementation authorization resolution

Responsibility Boundary: This skill completes with a reviewed plan and resolved implementation authority.

Follow the planning process below:

Execution Process

Step 1: Design Document Selection

Check for existence of design documents in docs/design/, notify user if none exist. Present options if multiple exist (can be specified with $ARGUMENTS).

Step 2: Integration/E2E Test Skeleton Selection

  • Invoke acceptance-test-generator agent: "Generate the value-selected integration/E2E test skeletons from Design Doc at [design-doc-path]."
  • Verify generated artifact paths and pass them to Step 3; an empty selection is valid

Step 3: Work Plan Creation

  • Invoke work-planner agent: "Create an implementation-focused work plan from design document at [design-doc-path]. Include generated test skeleton artifact paths from the previous step when present. Plan only repository implementation outcomes required by the Design Doc."
  • Verify the returned Work Plan path and use it as the Step 4 review target

Step 4: Work Plan Review

Review reception: Unnecessary repairs create lasting work. Before assigning a fix, use Review Resolution to judge no change, removal or narrowing, and reuse first; record why any retained or added mechanism is necessary. Invoke document-reviewer agent: "Review the work plan. doc_type: WorkPlan. target: [work-planner completed path]. Verify Design Doc implementation coverage, absence of added operational scope, dependency order, executable verification, optional Verification Focus, and Review Scope."

Branch on verdict.decision:

  • pass -> proceed to Step 5
  • needs_revision -> apply Review Resolution with work-planner, then review the updated plan
  • rejected -> apply Orchestrator Escalation Resolution using the cited governing sources

Step 5: Plan Authorization

  • Present the reviewed scope and apply Work Plan Authorization
  • Handle user-requested changes through subagents-orchestration-guide Work Plan Authorization
  • Summarize the implementation task set and any material choice the user is approving
  • After explicit authorization, record the user's instruction and scope in Implementation Authorization

Scope: Reviewed work plan and implementation authorization.

Completion Criteria

  • Design document identified and selected
  • Integration/E2E test skeleton selection completed and its artifact paths passed to work-planner
  • Work plan created via work-planner
  • Work plan reviewed via document-reviewer
  • User authorization for the implementation scope is recorded
  • Any required user decisions were resolved

Response at Completion

Planning phase completed.
- Work plan: docs/plans/[plan-name].md
- Review: pass
- Implementation authorization: [user instruction and scope]

Continue implementation when already requested; otherwise this planning recipe is complete.

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.