$npx -y skills add muratcankoylan/Agent-Skills-for-Context-Engineering --skill project-developmentThis skill should be used for project-level decisions about LLM-powered systems: whether an LLM is the right primitive for the task at hand, the shape of a multi-stage batch or agent pipeline, token and cost estimation, choosing between single-agent and multi-agent at the project
| 1 | # Project Development Methodology |
| 2 | |
| 3 | This skill covers the principles for identifying tasks suited to LLM processing, designing effective project architectures, and iterating rapidly using agent-assisted development. The methodology applies whether building a batch processing pipeline, a multi-agent research system, or an interactive agent application. |
| 4 | |
| 5 | The unit of work for this skill is the whole project or a multi-stage pipeline. Individual tool design (descriptions, schemas, error messages) belongs to `tool-design`. Per-skill activation routing belongs to the corresponding skill plus the corpus index. This skill owns the project-level questions: should you build this with an LLM at all, what shape should the pipeline take, what does it cost, how should it be iterated. |
| 6 | |
| 7 | ## When to Activate |
| 8 | |
| 9 | Activate this skill when the unit of work is a whole project or pipeline: |
| 10 | |
| 11 | - Deciding whether an LLM is the right primitive for a task at all (task-model fit before any code). |
| 12 | - Shaping a multi-stage batch or agent pipeline (acquire / prepare / process / parse / render). |
| 13 | - Estimating tokens, dollar cost, and timelines for an LLM-heavy project. |
| 14 | - Choosing between single-agent and multi-agent at the project level. |
| 15 | - Structuring agent-assisted iteration (where the agent helps build the project itself). |
| 16 | - Designing structured output at the pipeline contract level (cross-stage handoff format). |
| 17 | |
| 18 | Do not activate this skill for adjacent work owned by other skills: |
| 19 | |
| 20 | - Per-tool description, schema, naming, response format, error message: `tool-design`. |
| 21 | - Per-trajectory token-efficiency tactics (masking, partitioning, caching): `context-optimization`. |
| 22 | - Deciding to split work across sub-agents at the agent topology level: `multi-agent-patterns`. |
| 23 | - Designing the autonomous control loop (locked metrics, novelty gates, human approval boundaries): `harness-engineering`. |
| 24 | |
| 25 | ## Core Concepts |
| 26 | |
| 27 | ### Task-Model Fit Recognition |
| 28 | |
| 29 | Evaluate task-model fit before writing any code, because building automation on a fundamentally mismatched task wastes days of effort. Run every proposed task through these two tables to decide proceed-or-stop. |
| 30 | |
| 31 | **Proceed when the task has these characteristics:** |
| 32 | |
| 33 | | Characteristic | Rationale | |
| 34 | |----------------|-----------| |
| 35 | | Synthesis across sources | LLMs combine information from multiple inputs better than rule-based alternatives | |
| 36 | | Subjective judgment with rubrics | Grading, evaluation, and classification with criteria map naturally to language reasoning | |
| 37 | | Natural language output | When the goal is human-readable text, LLMs deliver it natively | |
| 38 | | Error tolerance | Individual failures do not break the overall system, so LLM non-determinism is acceptable | |
| 39 | | Batch processing | No conversational state required between items, which keeps context clean | |
| 40 | | Domain knowledge in training | The model already has relevant context, reducing prompt engineering overhead | |
| 41 | |
| 42 | **Stop when the task has these characteristics:** |
| 43 | |
| 44 | | Characteristic | Rationale | |
| 45 | |----------------|-----------| |
| 46 | | Precise computation | Math, counting, and exact algorithms are unreliable in language models | |
| 47 | | Real-time requirements | LLM latency is too high for sub-second responses | |
| 48 | | Perfect accuracy requirements | Hallucination risk makes 100% accuracy impossible | |
| 49 | | Proprietary data dependence | The model lacks necessary context and cannot acquire it from prompts alone | |
| 50 | | Sequential dependencies | Each step depends heavily on the previous result, compounding errors | |
| 51 | | Deterministic output requirements | Same input must produce identical output, which LLMs cannot guarantee | |
| 52 | |
| 53 | ### The Manual Prototype Step |
| 54 | |
| 55 | Always validate task-model fit with a manual test before investing in automation. Copy one representative input into the model interface, evaluate the output quality, and use the result to answer these questions: |
| 56 | |
| 57 | - Does the model have the knowledge required for this task? |
| 58 | - Can the model produce output in the format needed? |
| 59 | - What level of quality should be expected at scale? |
| 60 | - Are there obvious failure modes to address? |
| 61 | |
| 62 | Do this because a failed manual prototype predicts a failed automated system, while a successful one provides both a quality baseline and a prompt-design template. The test takes minutes and prevents hours of wasted development. |
| 63 | |
| 64 | ### Pipeline Architecture |
| 65 | |
| 66 | Structure LLM projects as staged pipelines because s |