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

recipe-fullstack-build

Skill39 starsChanged 10 days agoMITView on GitHub

Execute an approved fullstack Work Plan autonomously with layer-aware task routing, quality fixes, commits, and final verification.

1 other project uses 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 16
  3. Distinctive:

    Use the active execution plan when one exists.

    line 58
  4. Distinctive:

    Remove consumed task files after final verification and preserve the Work Plan as the progress record.

    line 82

≈ “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. coding-rules
  2. testing
  3. ai-development-guide
  4. subagents-orchestration-guide
  5. llm-friendly-context

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. Supply exact artifact paths.

Orchestrator Role

The orchestrator owns plan selection, approval dialogue, task-set computation, filename routing, commits, and completion reporting. Invoke specialist agents for task decomposition, implementation, test review, quality repair, and final verification. A user-requested plan revision follows Work Plan Authorization.

Work plan: $ARGUMENTS

1. Resolve the Work Plan

Apply subagents-orchestration-guide Work Plan Resolution with the backend, frontend, and shared patterns from Step 4 as the managed task patterns, excluding basenames that start with integration-tests-.

Report a missing Work Plan as the exact missing prerequisite.

2. Approval Gate

Apply subagents-orchestration-guide Work Plan Authorization. When user authorization to implement is absent from both the conversation and plan, ask before agent invocation or task analysis:

Approve this Work Plan as the implementation scope and authorize task decomposition, implementation, quality fixes, and per-task commits? [path]

Record the user's instruction and scope in Implementation Authorization and proceed to Step 3. A requested change returns through work-planner and document review before this gate.

3. Conditional Environment Preparation

Proceed directly to task generation. Run recipe-prepare-implementation only when the user explicitly requests repository-local setup. If task-local execution later identifies a concrete missing repository capability, resolve it through Orchestrator Escalation Resolution and run the preparation side path when that is the smallest authorized resolution.

4. Compute the Consumed Task Set

Use only:

  • docs/plans/tasks/{plan-name}-backend-task-*.md
  • docs/plans/tasks/{plan-name}-frontend-task-*.md
  • docs/plans/tasks/{plan-name}-task-*.md for shared or non-layered tasks

Matching implementation task files whose basename does not start with integration-tests- form the managed set. The pending set contains managed files with at least one unchecked task checkbox.

When the managed set is empty, invoke task-decomposer with the exact approved Work Plan path and require layer-aware filenames. Verify the generated task files, then recompute both sets. Batch approval already authorizes decomposition. When the managed set exists and the pending set is empty, proceed to final verification.

Order pending tasks by declared dependencies.

5. Execution Plan

Use the active execution plan when one exists. When none exists, create one after the task set is known with one step per task cycle and a final verification step. Update the same plan throughout execution.

6. Layer Routing

Route *-frontend-task-* to frontend agents and backend/shared task names to general agents.

7. Autonomous Task Cycle

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.

Execute each pending task through the subagents-orchestration-guide autonomous task cycle using the filename-routed executor and quality fixer. Pass the exact task file and preserve the canonical Per-Task Change Set. After a successful implementation commit, update the Task File, corresponding Work Plan task and phase, and execution plan locally; keep Task Files and the Work Plan outside the implementation commit.

8. Requirement Changes During Build

Apply subagents-orchestration-guide Requirement Change Detection During Flow and resume from its named artifact while preserving unaffected completed work.

9. Final Verification

Apply subagents-orchestration-guide Post-Implementation Review to the actual files changed by completed tasks and their governing documents. Route required fixes through the layer-selected 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.

10. Cleanup and Report

Remove consumed task files after final verification and preserve the Work Plan as the progress record. A cleanup failure is reported with its exact path and leaves completed implementation valid.

Report the Work Plan path, layer counts, completed tasks, commits, verification results, and any verification limitation that could not be exercised in the available environment.

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.