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

recipe-fullstack-implement

Skill39 starsChanged 9 days agoMITView on GitHub

Run the full-cycle implementation workflow for one outcome spanning backend and frontend layers.

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

3 rules. About 0 are common, 1 is distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    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:

    After implementation approval, work stopped only for a genuine user-owned escalation condition.

    line 44

≈ “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 — Fullstack (Monorepo) Flow, approvals, and autonomous execution
  2. [LOAD IF NOT ACTIVE] documentation-criteria — scale-selected document path
  3. [LOAD IF NOT ACTIVE] requirement-convergence — outcome, exclusions, and rough-cost challenge
  4. [LOAD IF NOT ACTIVE] llm-friendly-context — cross-agent handoffs and Small 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. Supply only the exact artifacts needed by that specialist.

Requirements or continuation instruction: $ARGUMENTS

Entry

  • New or scope-changing requirements: apply the subagents-orchestration-guide Requirement Evidence Handoff and invoke requirement-analyzer for compact scope/cost evidence; user selections establish requirements and exclusions, while the orchestrator judges readiness and determines scale and layer routing.
  • Existing PRD, UI Spec, Design Docs, Work Plan, or tasks: resume at the next incomplete Fullstack (Monorepo) Flow phase. Restart requirement analysis when the outcome, requirements, or exclusions change.
  • Quality failure during an existing implementation: resume its task cycle and Orchestrator Escalation Resolution.

For a requirements 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.

Resolve the entry from supplied artifacts and repository state. Ask only when different interpretations require a change to user-required outcomes, explicit constraints, or execution authority.

Flow

Apply subagents-orchestration-guide's references/monorepo-flow.md with backend, frontend, and shared routing. The orchestrator directly owns artifact/path resolution, execution-plan updates, approval recording, task-set computation, commits, and lightweight checks; invoke the named specialists for analysis, authoring, implementation, review, and quality judgment.

Reuse the active execution plan or register the material remaining phases once. Follow the Fullstack (Monorepo) Flow's document approvals. After implementation-scope approval, execute tasks autonomously through its filename routing, Per-Task Change Set, quality gate, commit, and Post-Implementation Review.

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.

External evidence, prototypes, and repository environment preparation remain conditional under the canonical flow. A missing optional input does not create a stop.

Completion Check

  • The existing workflow state was resumed rather than duplicated.
  • Backend, frontend, and shared work used the Fullstack (Monorepo) Flow routing.
  • Required document approvals and quality-before-commit gates were preserved.
  • After implementation approval, work stopped only for a genuine user-owned escalation condition.
  • Final code/security verification and completion reporting finished.

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.