Project Development Methodology
Decide whether an LLM fits the job, then design a staged agent pipeline with predictable parsing, iteration, and cost control.
The material emphasizes cost control, manual validation, rollback planning, and provenance, but it does not define least privilege, user confirmation, sensitive-data handling, API-key protection, or data-flow boundaries. The clean stage can delete intermediate files without recovery, so points are deducted. No malware, credential theft, or covert exfiltration red line was found.
The methodology is largely self-consistent and the references include caching, parsing, error logging, and test patterns. However, the script visibly ends at “elif args.stage”, the API call remains a mock placeholder, and dependencies, recovery behavior, and key paths cannot be statically reproduced; substantial points are deducted and the static ceiling applies.
Activation criteria, non-fit cases, and routing to adjacent skills are clearly stated for batch processing, pipelines, cost estimation, and structured output. Chinese-language guidance, environment prerequisites, and explicit input/output contracts are missing, and cross-platform/Mainland-China fit has limited evidence, so points are deducted.
The documentation is well layered and includes concepts, practical templates, gotchas, references, a script, license metadata, creation/update dates, and a version. Maintenance ownership, update path, changelog, and complete dependency/install guidance are incomplete, with usability gaps between the documentation and script, so points are deducted.
The project-level decision framework, five-stage pipeline, filesystem state model, and parsing examples are directly useful as guidance. However, the script uses sample data and a mock LLM and is visibly incomplete, so direct production usability is unproven; points are conservatively deducted under the static ceiling.
The skill identifies Karpathy, Vercel, Manus, and Anthropic case studies and provides external source labels, with some separation between patterns and cases. There is no complete executable implementation, real CI, or committed key-path test coverage, and the reported case results cannot be independently reproduced in this static review, so points are deducted.
- The CLI implementation in scripts/pipeline_template.py is visibly truncated and should not be treated as runnable.
- call_llm returns a mock response; real integration needs secret management, permission isolation, timeouts, retries, rate limiting, and data-egress review.
- The clean stage directly deletes stage artifacts; production use should add confirmation, backups, or recoverable rollback.
- Case-study cost, success-rate, and performance figures should be revalidated against primary sources and the target environment.
What does this skill do, and when should you use it?
This Agent Skill addresses project-level decisions for LLM-powered systems and multi-stage pipelines. It covers task-model fit, manual validation, single-agent versus multi-agent selection, cost estimation, structured output, and agent-assisted iteration. Its recommended acquire, prepare, process, parse, render pipeline separates deterministic work from expensive, nondeterministic model calls. It is intended for batch systems, research pipelines, and interactive agent applications, while individual tool design, context optimization, and agent topology belong to other skills.
It guides the user through defining inputs, outputs, task type, acceptable error rates, and business value before implementation. It recommends testing one representative input manually, selecting a pipeline architecture, estimating token and API costs with a 20% to 30% buffer, and storing raw inputs, prompts, responses, and parsed results as filesystem artifacts. It also specifies structured-prompt elements and parser behaviors for handling minor variations in model output.
- An engineer planning large-scale document classification who needs to validate model fit and estimate API spend first.
- A team building a research pipeline that needs separate acquisition, prompt preparation, processing, parsing, and rendering stages.
- A report-generation developer who needs model responses to satisfy a downstream parsing contract.
- A technical lead deciding whether independent batch items need a single-agent pipeline or justified multi-agent execution.
- A team using coding agents to implement a project incrementally and test each component before expanding scope.
What are this skill's strengths and limitations?
- Provides an end-to-end planning sequence from task fit through deployment.
- Clearly separates deterministic stages from the expensive, nondeterministic processing stage.
- The filesystem state-machine pattern supports caching, debugging, parallelization, and selective reruns.
- Covers structured outputs, parser hardening, cost buffers, and model-generation changes.
- The README reports a 1.000 top-1 routing result for project-development after targeted rewriting.
- It is a methodology document, not a ready-to-run implementation or dedicated script package.
- It provides no task-specific quality or cost measurements for particular models or platforms.
- It recommends metrics, evaluation, and manual prototyping, but does not supply a complete implementation for every project.
- Detailed multi-agent topology, per-tool interfaces, and autonomous control loops are explicitly out of scope.
How do you install this skill?
Copy the complete skills/project-development directory into the host's skills directory. For example: mkdir -p .codex/skills && cp -R skills/project-development .codex/skills/. The same folder can be copied to .claude/skills/, .cursor/skills/, or .agents/skills/. Do not flatten SKILL.md into a single file, because the directory layout preserves relative references/ paths.
How do you use this skill?
Activate it for a whole project or multi-stage pipeline. Example prompt: “I need to classify a batch of independent documents, parse the model results, and render a report. First assess whether an LLM fits, propose the pipeline, and estimate cost.” Use tool-design for an individual tool contract, context-optimization for trajectory-level token tactics, and multi-agent-patterns for detailed agent topology.
How does this skill compare with similar options?
Compared with multi-agent-patterns, this skill decides at the project level whether to use one agent or multiple agents, but does not define supervisor, swarm, or hierarchical topologies. Compared with tool-design, it defines cross-stage pipeline contracts rather than individual tool descriptions, schemas, or error messages.