skillnet-ai 0.0.1__py3-none-any.whl → 0.0.2__py3-none-any.whl

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
skillnet_ai/prompts.py ADDED
@@ -0,0 +1,885 @@
1
+ """
2
+ This module contains the prompt templates used for generating skills from trajectories.
3
+ """
4
+
5
+ # Prompt to extract metadata (candidates) from a raw trajectory
6
+ CANDIDATE_METADATA_SYSTEM_PROMPT = "You are a helpful assistant."
7
+
8
+ CANDIDATE_METADATA_USER_PROMPT_TEMPLATE = """
9
+ Your goal is to analyze an interaction trajectory and extract **reusable Skills**.
10
+
11
+ A "Skill" is a modular, self-contained package that extends the agent's capabilities (e.g., "PDF Processor", "Market Analyzer", "Code Reviewer").
12
+
13
+ # Core Objective
14
+ 1. Analyze the trajectory to identify distinct **capabilities** or **workflows**.
15
+ 2. For EACH distinct capability, extract exactly ONE corresponding **Skill Metadata** entry.
16
+
17
+ *Note: Avoid over-fragmentation. If the trajectory is a coherent workflow (e.g., "analyze PDF and summarize"), create ONE skill for the whole process rather than splitting it into tiny steps, unless the steps are distinct independent domains.*
18
+
19
+ # Input Data
20
+ **Execution Trajectory:**
21
+ {trajectory}
22
+
23
+ # Step 1: Skill Identification
24
+ Identify skills that are:
25
+ - **Reusable**: Useful for future, similar requests.
26
+ - **Modular**: Self-contained with clear inputs and outputs.
27
+ - **Domain Specific**: Provides specialized knowledge or workflow logic.
28
+
29
+ # Step 2: Metadata Extraction Rules
30
+ For EACH identified skill, generate metadata with:
31
+
32
+ ### `name` requirements:
33
+ - **kebab-case** (e.g., `financial-report-generator`, `code-refactor-tool`).
34
+ - Concise but descriptive.
35
+
36
+ ### `description` requirements (CRITICAL):
37
+ This description acts as the **Trigger** for the AI to know WHEN to use this skill.
38
+ It must be a **When-To-Use** statement containing:
39
+ 1. **Context**: The specific situation or user intent (e.g., "When the user asks to analyze a PDF...").
40
+ 2. **Capabilities**: What the skill provides (e.g., "...extracts text and summarizes financial metrics").
41
+ 3. **Triggers**: Specific keywords or file types associated with this skill.
42
+
43
+ # Output Format:
44
+ [
45
+ {{
46
+ "name": "example-skill-name",
47
+ "description": "Comprehensive trigger description explaining precisely WHEN and WHY to load this skill."
48
+ }},
49
+ ...
50
+ ]
51
+
52
+ Keep your output in the format below:
53
+ <Skill_Candidate_Metadata>
54
+ your generated candidate metadata list in JSON format here
55
+ </Skill_Candidate_Metadata>
56
+ """
57
+
58
+ # Prompt to generate actual file content for a specific skill
59
+ SKILL_CONTENT_SYSTEM_PROMPT = "You are an expert Technical Writer specializing in creating SKILL for AI agents."
60
+
61
+ SKILL_CONTENT_USER_PROMPT_TEMPLATE = """
62
+ Your task is to generate a **skill package** based on the provided execution trajectory, skill name, and skill description.
63
+ This includes the main `SKILL.md` orchestration file and any necessary bundled resources (scripts, references, assets).
64
+
65
+ # Input Data
66
+ 1. **Trajectory:** {trajectory}
67
+ 2. **Skill Name:** {name}
68
+ 3. **Skill Description:** {description}
69
+
70
+ # Skill Structure Standard
71
+ You must output the skill using the following directory structure:
72
+
73
+ ```text
74
+ skill-name/
75
+ ├── SKILL.md (required)
76
+ │ ├── YAML frontmatter metadata (required)
77
+ │ │ ├── name: (required)
78
+ │ │ └── description: (required)
79
+ │ └── Markdown instructions (required)
80
+ └── Bundled Resources (optional)
81
+ ├── scripts/ - Executable code (Python/Bash/etc.)
82
+ ├── references/ - Documentation intended to be loaded into context as needed
83
+ └── assets/ - Files used in output (templates, icons, fonts, etc.)
84
+ ```
85
+
86
+ # Core Design Principles
87
+ 1. Context is a Public Good: Be concise. Only add context in SKILL.md that is essential.
88
+ 2. Progressive Disclosure:
89
+ - Keep SKILL.md lean.
90
+ - Offload heavy documentation/schemas to references/.
91
+ - Offload repeatable, deterministic logic to scripts/.
92
+ 3. Degrees of Freedom:
93
+ - Use scripts (Low Freedom) for fragile, error-prone, or strict sequence tasks found in the trajectory.
94
+ - Use text instructions (High Freedom) for creative decisions.
95
+
96
+ # Output Format (STRICT)
97
+ You must output the files using the following strict format so that a script can parse and save them.
98
+ For every file (including SKILL.md, scripts, references, etc.), use this exact pattern:
99
+
100
+ ## FILE: <directory_name>/<path_to_file>
101
+ ```<language_tag_if_applicable>
102
+ <file_content_here>
103
+ ```
104
+
105
+ **Example Output:**
106
+
107
+ ## FILE: pdf-processor/SKILL.md
108
+ ```yaml
109
+ ---
110
+ name: pdf-processor
111
+ description: Extracts text from PDFs and summarizes them.
112
+ ---
113
+ # Instructions
114
+ 1. Run the extraction script.
115
+ 2. Summarize the output.
116
+ ```
117
+
118
+ ## FILE: pdf-processor/scripts/extract.py
119
+ ```python
120
+ import pdfplumber
121
+ # ... code ...
122
+ ```
123
+
124
+ ## FILE: pdf-processor/references/api_docs.md
125
+ ```markdown
126
+ # API Documentation
127
+ ...
128
+ ```
129
+
130
+ Now, generate the complete skill package based on the provided trajectory, name, and description.
131
+ """
132
+
133
+
134
+ SKILL_EVALUATION_PROMPT = """You will evaluate an AI Agent Skill using the metadata and (if present) the SKILL.md content, reference files, and scripts snippets below.
135
+ - Judge clarity, safety, and practical usability based on what is explicitly stated.
136
+ - If information is missing, reflect that in the rating and explain the uncertainty in the reason.
137
+
138
+ === METADATA ===
139
+ - Name: {skill_name}
140
+ - Description: {skill_description}
141
+ - Category: {category}
142
+
143
+ === SKILL.md ===
144
+ {skill_md_block}
145
+
146
+ === REFERENCES/ ===
147
+ {references_block}
148
+
149
+ === SCRIPTS/ ===
150
+ {scripts_block}
151
+
152
+ === SCRIPT EXECUTION RESULTS ===
153
+ {script_exec_block}
154
+
155
+ Rating scale (3 levels only):
156
+ - Good: Clear, safe-by-default, and practically usable as described; low ambiguity; low risk.
157
+ - Average: Some ambiguity, missing caveats, or limited detail; likely usable but with notable gaps/risks.
158
+ - Poor: Vague, risky, misleading, or missing critical information; likely unsafe or impractical as described.
159
+
160
+ Evaluation dimensions and how to judge them (apply these rules even if the overall description looks polished; audit formulas/code/allowed_tools line-by-line and err on the side of conservative, lower ratings when you find subtle but impactful issues):
161
+
162
+ 1) Safety
163
+ Assess potential harm and misuse given what is described.
164
+ Signals for Good:
165
+ - Avoids destructive actions by default; includes safety checks/confirmations; mentions scope limits.
166
+ - Does not encourage credential exfiltration, system damage, bypassing security, or unsafe automation.
167
+ Signals for Average:
168
+ - Benign domain, but no mention of safeguards for operations that could be risky (e.g., deployments, deletions).
169
+ Signals for Poor:
170
+ - Mentions or implies dangerous actions without safeguards (e.g., "delete/reset/disable security/steal/exploit").
171
+ - Encourages unsafe tool usage or bypassing best practices.
172
+ Additional guidance for Safety:
173
+ - If allowed_tools grants broader permissions than what the Skill clearly needs (e.g., allows "bash" or other powerful tools but the described workflow and examples do not require them), reduce safety by at least one level compared to what it would otherwise be.
174
+ - For health/medical-related Skills that provide advice or recommendations without an explicit disclaimer that it is NOT medical advice and NOT a substitute for professional diagnosis or treatment, safety MUST NOT be "Good" (its maximum allowed level is "Average").
175
+
176
+ 2) Completeness
177
+ Assess whether the description covers the essential steps/constraints to achieve its stated goal.
178
+ Signals for Good:
179
+ - Clear goal + clear steps/inputs/outputs; mentions prerequisites (env, packages, permissions) when relevant.
180
+ - Mentions failure modes or edge cases at least briefly when they matter.
181
+ Signals for Average:
182
+ - Goal is clear, but steps/prereqs/outputs are underspecified; assumes context the user may not have.
183
+ Signals for Poor:
184
+ - Too vague to act on; missing core steps; unclear what "done" looks like.
185
+ Additional guidance for Completeness:
186
+ - If the core workflow lacks basic input validation that can obviously lead to crashes or meaningless outputs (e.g., division by zero for height <= 0, missing sanity checks on critical parameters), set completeness to at most "Average"; set it to "Poor" if this is likely to occur in realistic usage.
187
+ - If you detect a CRITICAL CORRECTNESS ERROR in a core formula, algorithm, or code snippet (e.g., steps and code that contradict in a way that would cause wrong results), set completeness to at most "Average" and usually "Poor" if the error is central to the stated goal.
188
+ - If the SKILL.md promises significant capabilities (e.g., multiple types of conversions, edits, or analyses) but the provided scripts and references only implement trivial placeholders (e.g., echoing input or “pretend success” messages) with no real logic for those capabilities, completeness MUST NOT be "Good" and is usually "Poor" because the implementation does not actually cover the described behavior.
189
+
190
+ 3) Executability
191
+ Assess whether an agent could realistically execute the described workflow with typical tools.
192
+ Signals for Good:
193
+ - Concrete actions and artifacts (commands, files, parameters); minimal ambiguity.
194
+ - Avoids "hand-wavy" steps like "just configure X" without specifying how/where.
195
+ - If script execution results are provided, successful runs support a higher rating.
196
+ - **Instruction-only skills**: When the skill is designed to be executed purely through text instructions (e.g., guidelines, policies, brainstorming, design workflows) and does NOT require code execution, the absence of runnable scripts is acceptable. If SKILL.md provides clear, actionable guidance that an agent can follow using typical LLM tools (read files, apply guidelines, reason about content), rate executability as Good.
197
+ Signals for Average:
198
+ - Generally executable, but contains ambiguous steps or missing tool/environment assumptions.
199
+ Signals for Poor:
200
+ - Non-actionable ("optimize it", "make it work") with no operational detail; depends on unspecified systems.
201
+ - If script execution results show failures/timeouts/missing dependencies, treat them as evidence about executability but do NOT automatically set executability to Poor. First classify whether the failure is due to unmet prerequisites in the evaluation/runtime environment (e.g., missing dependencies, missing input files/arguments, placeholders) versus a genuine defect or contradiction in the Skill's workflow/scripts; then adjust the rating accordingly.
202
+ - If script execution was skipped due to missing required inputs, reflect missing prerequisites in the rating (usually Average).
203
+ Additional guidance for Executability:
204
+ - **Do NOT rate Poor solely because "No runnable python scripts found"**. Many skills (security guidelines, ideation, policies, design workflows) are instruction-only: the agent reads SKILL.md and follows the guidance with typical tools. For such skills, if the instructions are clear and actionable, executability should be Good.
205
+ - If script execution fails due to an obvious documentation placeholder in an example command (e.g., tokens like "[options]", "<file>", "<pattern>", "{{path}}") or an argument parsing error caused by such placeholders, do NOT automatically set executability to Poor. Prefer Average and explain that the script likely needs real inputs or a concrete runnable example; only use Poor if there is additional evidence the workflow is not realistically executable.
206
+ - If you detect any CRITICAL CORRECTNESS ERROR in a core formula, algorithm, or code snippet (e.g., Python using "^" for exponentiation or other language-level mistakes that would produce wrong results or runtime failures), executability MUST be "Poor".
207
+ - If allowed_tools grants broader permissions than what the Skill clearly needs (e.g., allows "bash" or other powerful tools but the described workflow and examples do not require them), reduce executability by at least one level due to environment/permission ambiguity.
208
+ - When reading formulas and code snippets, audit them line-by-line in the context of their target language and typical runtime environment; if you find subtle traps or inconsistencies that would mislead an implementer or cause incorrect behavior, choose a lower (more conservative) executability rating.
209
+ - Do not treat a trivially successful script (e.g., one that only prints or echoes input without implementing the promised behavior) as strong evidence of executability; if the artifacts do not actually implement the key capabilities claimed in SKILL.md, executability should be at most "Average" and often "Poor".
210
+
211
+ 4) Modifiability
212
+ Assess how easy it would be to adjust/reuse/compose this Skill as described.
213
+ Signals for Good:
214
+ - Narrow, modular scope; clearly defined inputs/outputs; low coupling; safe to combine with other Skills.
215
+ - Mentions configuration points or parameters rather than hard-coding assumptions.
216
+ Signals for Average:
217
+ - Some reusable parts, but unclear boundaries or assumptions; moderate coupling to a specific repo/tooling.
218
+ Signals for Poor:
219
+ - Overly broad or tightly coupled; unclear how to adapt; likely to conflict with other workflows.
220
+ Additional guidance for Modifiability:
221
+ - If the described capabilities are broad but the provided implementation is only a thin or trivial placeholder with no clear structure for where real logic should go, do not rate modifiability as "Good"; prefer "Average" because significant work is required to build the promised behavior safely and predictably.
222
+
223
+ 5) Cost-awareness
224
+ Assess whether the described approach is mindful of time/compute/money and operational overhead, given its domain.
225
+ For clearly lightweight domains (e.g., documentation, brainstorming, simple text-only workflows) with no heavy data/infra hints:
226
+ - Good: The task is inherently low-cost and the description does not suggest heavy loops, huge datasets, or expensive external services.
227
+ For potentially heavy domains (e.g., data processing, infra, large-scale agents, external APIs, long-running jobs):
228
+ - Good: Explicitly mentions batching/limits/caching/scope control or otherwise shows cost awareness.
229
+ - Average: No explicit cost control is mentioned, but nothing suggests obviously wasteful behavior.
230
+ - Poor: Encourages wasteful or unrealistic workflows without acknowledging cost/limits (e.g., "run huge jobs repeatedly", "scan all repos constantly").
231
+ Examples:
232
+ - Good: A batch processing Skill that explicitly limits file sizes or page counts and suggests sampling or pagination to control cost.
233
+ - Average: A simple text summarizer that does not mention limits, but whose described usage clearly targets small inputs and occasional calls.
234
+ - Poor: A monitoring Skill that recommends continuously re-scanning all repositories or documents at high frequency without any bounds or caching.
235
+
236
+ === CONCRETE EVALUATION EXAMPLES ===
237
+
238
+ Example 1: BMI calculator Skill (health-related, wrong formula, no disclaimer)
239
+ - Observations:
240
+ - SKILL.md provides a BMI formula using `weight / (height ^ 2)` in Python, which is a language-level error because `^` is bitwise XOR, not exponentiation.
241
+ - It provides health-related recommendations (e.g., suggesting lifestyle or exercise changes) but does NOT include any disclaimer that this is not medical advice and not a substitute for a doctor.
242
+ - There is no input validation for invalid heights (e.g., height <= 0) or obviously unrealistic values.
243
+ - There are no runnable scripts that implement the calculation; only a faulty example snippet in SKILL.md.
244
+ - Expected ratings:
245
+ - safety: "Average"
246
+ - Reason: The domain is benign, but the Skill gives health advice without an explicit medical disclaimer or scope limits, creating a risk of over-reliance.
247
+ - completeness: "Poor"
248
+ - Reason: The core formula is incorrect in the target language and there is no input validation or handling of special cases, so critical detail is missing for reliable use.
249
+ - executability: "Poor"
250
+ - Reason: Following the formula as written in Python would not produce correct results, and there are no real scripts or commands to execute successfully.
251
+ - modifiability: "Average"
252
+ - Reason: Inputs and outputs (height, weight, BMI category) are conceptually clear, but the incorrect example and lack of validation make safe modification non-trivial.
253
+ - cost_awareness: "Good"
254
+ - Reason: The task is a simple numeric calculation with no heavy data or external services, so it is inherently low-cost.
255
+
256
+ Example 2: Quick task helper Skill (broad promise, placeholder implementation)
257
+ - Observations:
258
+ - SKILL.md claims multiple capabilities (format conversion, simple file edits, brief summaries) but only lists high-level steps like "apply a minimal transformation" without concrete rules.
259
+ - The only script (scripts/do_anything.py) merely echoes input or prints a success message; it does not implement any real conversion, editing, or summarization logic.
260
+ - The domain is benign and there is no mention of dangerous tools or destructive actions.
261
+ - Expected ratings:
262
+ - safety: "Good"
263
+ - Reason: The operations are benign and the script does not perform destructive or risky actions.
264
+ - completeness: "Poor"
265
+ - Reason: The Skill promises a wide range of behaviors but does not specify formats, transformation rules, or error handling, and the implementation does not cover the described capabilities.
266
+ - executability: "Poor"
267
+ - Reason: Although the script technically runs, it is only a trivial placeholder; an agent following this Skill would not achieve the advertised conversions or edits.
268
+ - modifiability: "Average"
269
+ - Reason: The script is small and easy to edit, but there is no structure or guidance on where to implement the promised behaviors, so substantial work is needed to make it truly useful.
270
+ - cost_awareness: "Good"
271
+ - Reason: The intended tasks are quick, lightweight transformations with no indication of heavy computation or large-scale processing.
272
+
273
+ Example 3: Well-scoped document summarizer Skill (mostly solid)
274
+ - Observations:
275
+ - SKILL.md describes a Skill that summarizes user-provided documents up to a clear size limit (e.g., "up to 10 pages or 5,000 words") and specifies that it will not access external systems.
276
+ - It outlines concrete steps: load the document, chunk by paragraphs, generate summaries per chunk, then combine them, and mentions basic handling for unsupported file types.
277
+ - There is no script, but the steps are specific and actionable with typical LLM tools.
278
+ - Expected ratings:
279
+ - safety: "Good"
280
+ - Reason: The Skill operates on user-provided content, does not touch external systems, and has no destructive actions.
281
+ - completeness: "Good"
282
+ - Reason: Inputs, steps, and limits are clearly specified, including handling for unsupported types and size bounds.
283
+ - executability: "Good"
284
+ - Reason: The workflow is concrete and can be followed using standard tools (e.g., text reading and summarization) without ambiguity.
285
+ - modifiability: "Good"
286
+ - Reason: The scope is narrow and modular, with clear points where chunking strategy or summary length can be adjusted.
287
+ - cost_awareness: "Good"
288
+ - Reason: The Skill explicitly caps document size and describes a strategy (chunking) that avoids unbounded compute.
289
+
290
+ Example 4: Instruction-only guideline Skill (e.g., security standards)
291
+ - Observations:
292
+ - SKILL.md provides guidance on how to handle global security when working on code. It points to an external standards document for details.
293
+ - There are no runnable Python scripts; script execution shows "No runnable python scripts found".
294
+ - The workflow is: agent reads SKILL.md, loads the referenced document, and applies the guidelines when editing code.
295
+ - Expected ratings:
296
+ - executability: "Good"
297
+ - Reason: This is an instruction-only skill. The agent can execute the workflow by reading SKILL.md and the referenced file, then applying the guidelines with typical LLM tools. The absence of runnable scripts is acceptable because the skill does not require code execution.
298
+
299
+ Example 5: Overpowered deployment cleaner Skill (risky but technically executable)
300
+ - Observations:
301
+ - SKILL.md describes a deployment cleanup tool that can delete old resources and restart services in production environments.
302
+ - It grants broad permissions via allowed_tools (e.g., unrestricted shell access) and includes commands that can stop or remove services without confirmation.
303
+ - Scripts implement the described behavior and script_execution results show successful runs on sample environments.
304
+ - Expected ratings:
305
+ - safety: "Poor"
306
+ - Reason: The Skill can perform destructive actions (deleting resources, stopping services) without explicit safeguards, confirmations, or guardrails.
307
+ - completeness: "Average"
308
+ - Reason: The main steps are described, but it does not clearly document rollback procedures, scoping rules, or safe usage patterns.
309
+ - executability: "Good"
310
+ - Reason: The scripts and commands are concrete and executable; script_execution results demonstrate that they run and perform real work.
311
+ - modifiability: "Average"
312
+ - Reason: While the scripts can be edited, the tight coupling to specific infrastructure and lack of configuration points make safe adaptation non-trivial.
313
+ - cost_awareness: "Average"
314
+ - Reason: The Skill does not appear to be compute-heavy, but it also does not explicitly address operational risk or cost; it neither optimizes nor clearly wastes resources.
315
+
316
+ Output requirements:
317
+ - Return STRICT JSON only (no prose, no markdown).
318
+ - Use exactly these keys: safety, completeness, executability, modifiability, cost_awareness.
319
+ - Each key must contain: level (Good/Average/Poor) and reason (1-2 sentences).
320
+ - The reason must cite concrete evidence from the provided content (metadata/SKILL.md/scripts), not imagined details.
321
+
322
+ Return the evaluation results in JSON format exactly like this:
323
+ {{
324
+ "safety": {{
325
+ "level": "Good/Average/Poor",
326
+ "reason": "Reason for the rating (1-2 sentences)"
327
+ }},
328
+ "completeness": {{
329
+ "level": "Good/Average/Poor",
330
+ "reason": "Reason for the rating (1-2 sentences)"
331
+ }},
332
+ "executability": {{
333
+ "level": "Good/Average/Poor",
334
+ "reason": "Reason for the rating (1-2 sentences)"
335
+ }},
336
+ "modifiability": {{
337
+ "level": "Good/Average/Poor",
338
+ "reason": "Reason for the rating (1-2 sentences)"
339
+ }},
340
+ "cost_awareness": {{
341
+ "level": "Good/Average/Poor",
342
+ "reason": "Reason for the rating (1-2 sentences)"
343
+ }}
344
+ }}
345
+
346
+ Remember: STRICT JSON only. """
347
+
348
+
349
+
350
+ # GitHub Repository to Skill Prompts
351
+
352
+ GITHUB_SKILL_SYSTEM_PROMPT = """You are an expert Technical Writer specializing in creating Skills for AI agents.
353
+ Your task is to analyze a GitHub repository and generate a comprehensive skill package that captures the repository's functionality and usage patterns.
354
+
355
+ CRITICAL REQUIREMENTS:
356
+ 1. Generate COMPLETE content - do not truncate or abbreviate sections
357
+ 2. Include ALL installation steps with actual commands from README
358
+ 3. Extract CONCRETE code examples from README - copy them exactly, don't invent new ones
359
+ 4. List specific models, APIs, or tools mentioned in the repository
360
+ 5. For scripts/: Generate REAL, RUNNABLE Python code that demonstrates library usage
361
+ 6. For references/: Generate DETAILED API documentation with actual function signatures
362
+ 7. Follow the SkillNet skill structure standard exactly
363
+ 8. Output files in parseable format with ## FILE: markers
364
+
365
+ SCRIPT QUALITY REQUIREMENTS:
366
+ - Scripts must be self-contained and runnable (no os.system('conda activate'))
367
+ - Scripts should demonstrate actual library API usage, not shell command wrappers
368
+ - Include proper imports, error handling, and docstrings
369
+ - If the library requires specific data, use placeholder paths with clear comments
370
+
371
+ REFERENCE QUALITY REQUIREMENTS:
372
+ - API references must include actual function signatures from code analysis
373
+ - Include parameter types, return types, and brief descriptions
374
+ - Organize by module/class hierarchy
375
+ - Reference the source file locations
376
+
377
+ Your output will be parsed by a script, so maintain strict formatting."""
378
+
379
+ GITHUB_SKILL_USER_PROMPT_TEMPLATE = """
380
+ Your task is to generate a complete skill package from the provided GitHub repository information.
381
+ This includes the main `SKILL.md` orchestration file and any necessary bundled resources.
382
+
383
+ # Input Data: GitHub Repository
384
+
385
+ ## Repository Info
386
+ - **Name:** {repo_name}
387
+ - **URL:** {repo_url}
388
+ - **Description:** {repo_description}
389
+ - **Primary Language:** {language}
390
+ - **Languages Breakdown:** {languages_breakdown}
391
+ - **Stars:** {stars}
392
+ - **Topics:** {topics}
393
+
394
+ ## README Content
395
+ {readme_content}
396
+
397
+ ## File Structure
398
+ {file_tree}
399
+
400
+ ## Code Analysis Summary
401
+ {code_summary}
402
+
403
+ # Skill Structure Standard
404
+ You must output the skill using the following directory structure:
405
+
406
+ ```text
407
+ skill-name/
408
+ ├── SKILL.md (required)
409
+ │ ├── YAML frontmatter metadata (required)
410
+ │ │ ├── name: (required)
411
+ │ │ └── description: (required)
412
+ │ └── Markdown instructions (required)
413
+ └── Bundled Resources (required)
414
+ ├── scripts/ - Executable Python code demonstrating library usage
415
+ └── references/ - API documentation with function signatures
416
+ ```
417
+
418
+ # SKILL.md Content Requirements (MUST INCLUDE ALL)
419
+
420
+ ## 1. YAML Frontmatter (REQUIRED)
421
+ ```yaml
422
+ ---
423
+ name: skill-name-in-kebab-case
424
+ description: A when-to-use trigger statement explaining when this skill should be activated
425
+ ---
426
+ ```
427
+
428
+ ## 2. When to Use Section (REQUIRED)
429
+ Clear description of scenarios where this skill should be activated. Include:
430
+ - Primary use cases
431
+ - Types of tasks it handles
432
+ - Keywords that should trigger this skill
433
+
434
+ ## 3. Quick Reference Section (REQUIRED)
435
+ - Official documentation links
436
+ - Demo/playground URLs if available
437
+ - Key resources and references
438
+
439
+ ## 4. Installation/Setup Section (REQUIRED - WITH ACTUAL COMMANDS)
440
+ Include complete installation commands exactly as shown in README:
441
+ - Prerequisites (Python version, system requirements)
442
+ - pip install commands
443
+ - Docker commands if available
444
+ - Environment setup steps
445
+
446
+ ## 5. Core Features Section (REQUIRED)
447
+ List the main features/capabilities:
448
+ - Feature 1: Description
449
+ - Feature 2: Description
450
+ - Include any sub-modules or specialized tools
451
+
452
+ ## 6. Usage Examples Section (REQUIRED - EXTRACT FROM README)
453
+ Include ACTUAL code examples from the README:
454
+ - Quick start code
455
+ - Common usage patterns
456
+ - Command-line examples
457
+
458
+ ## 7. Key APIs/Models Section (REQUIRED)
459
+ List specific models, classes, or APIs mentioned:
460
+ - Model names (e.g., specific neural network architectures)
461
+ - API endpoints or function signatures
462
+ - Configuration options
463
+
464
+ ## 8. Common Patterns & Best Practices (OPTIONAL)
465
+ Tips for effective usage
466
+
467
+ # scripts/ File Requirements (CRITICAL - HIGH QUALITY)
468
+
469
+ Generate Python scripts that ACTUALLY demonstrate how to use the library's API.
470
+
471
+ GOOD SCRIPT EXAMPLE (demonstrates actual API usage):
472
+ ```python
473
+ #!/usr/bin/env python3
474
+ \"\"\"
475
+ Usage Example: Interacting with OpenAI API to Generate Text Responses
476
+
477
+ This script demonstrates how to use the OpenAI Python library to interact with
478
+ OpenAI's language models for text generation tasks.
479
+ Requires: pip install openai
480
+ \"\"\"
481
+
482
+ import os
483
+ from openai import OpenAI
484
+
485
+ def setup_api_key():
486
+ \"\"\"
487
+ Configure the environment with the OpenAI API key.
488
+ \"\"\"
489
+ os.environ["OPENAI_API_KEY"] = "YOUR_OPENAI_API_KEY" # Replace with your actual API key
490
+
491
+ def generate_response(prompt: str, model: str = "gpt-4") -> str:
492
+ \"\"\"
493
+ Generate a text response using OpenAI's model with a given prompt.
494
+
495
+ Args:
496
+ prompt: The text input to pass to the model.
497
+ model: The model identifier (e.g., "gpt-4", "gpt-3.5-turbo").
498
+
499
+ Returns:
500
+ The generated text from the model.
501
+ \"\"\"
502
+ try:
503
+ client = OpenAI(api_key=os.getenv("OPENAI_API_KEY"))
504
+ response = client.chat.completions.create(
505
+ model=model,
506
+ messages=[
507
+ {{"role": "system", "content": "You are a helpful assistant."}},
508
+ {{"role": "user", "content": prompt}}
509
+ ]
510
+ )
511
+ return response.choices[0].message.content
512
+ except Exception as e:
513
+ print(f"An error occurred while generating a response: {{e}}")
514
+ return ""
515
+
516
+ if __name__ == "__main__":
517
+ setup_api_key()
518
+ response_text = generate_response("Explain quantum computing in simple terms.")
519
+ print(f"Model Response: {{response_text}}")
520
+ ```
521
+
522
+ # references/ File Requirements (CRITICAL - HIGH QUALITY)
523
+
524
+ Generate detailed API documentation based on the code analysis provided.
525
+
526
+ GOOD API REFERENCE EXAMPLE:
527
+ ```markdown
528
+ # OpenAI Python Client API Reference
529
+
530
+ ## Module: openai
531
+
532
+ ### Class: OpenAI
533
+
534
+ Handles synchronous communications with OpenAI API for text generation, chat, and more.
535
+
536
+ **Constructor:**
537
+ ```python
538
+ OpenAI(
539
+ api_key: str = None,
540
+ base_url: str = None,
541
+ **kwargs
542
+ )
543
+ ```
544
+
545
+ **Parameters:**
546
+ - `api_key` (str, optional): The API key for authenticating requests. Defaults to OPENAI_API_KEY environment variable.
547
+ - `base_url` (str, optional): Override the default API base URL.
548
+ - `kwargs`: Additional configuration options.
549
+
550
+ **Methods:**
551
+
552
+ #### chat.completions.create(model: str, messages: List[dict], **kwargs) -> ChatCompletion
553
+ Create a chat completion using the specified model.
554
+
555
+ **Parameters:**
556
+ - `model` (str): Model identifier (e.g., "gpt-4", "gpt-3.5-turbo").
557
+ - `messages` (List[dict]): List of message dictionaries with 'role' and 'content'.
558
+ - `temperature` (float, optional): Sampling temperature (0-2).
559
+ - `max_tokens` (int, optional): Maximum tokens to generate.
560
+
561
+ **Returns:**
562
+ - `ChatCompletion`: Response object containing generated text and metadata.
563
+
564
+ **Example:**
565
+ ```python
566
+ from openai import OpenAI
567
+
568
+ client = OpenAI()
569
+ response = client.chat.completions.create(
570
+ model="gpt-4",
571
+ messages=[
572
+ {{"role": "system", "content": "You are a helpful assistant."}},
573
+ {{"role": "user", "content": "Hello!"}}
574
+ ]
575
+ )
576
+ print(response.choices[0].message.content)
577
+ ```
578
+
579
+ ---
580
+
581
+ ### Class: AsyncOpenAI
582
+
583
+ Handles asynchronous interactions with OpenAI's API for efficient concurrent operations.
584
+
585
+ **Constructor:**
586
+ ```python
587
+ AsyncOpenAI(
588
+ api_key: str = None,
589
+ **kwargs
590
+ )
591
+ ```
592
+
593
+ **Parameters:**
594
+ - `api_key` (str, optional): The API key for authenticating requests.
595
+ - `kwargs`: Additional configuration options including HTTP client setups.
596
+
597
+ **Methods:**
598
+ - Same as `OpenAI` but returns awaitable objects.
599
+
600
+ **Example:**
601
+ ```python
602
+ import asyncio
603
+ from openai import AsyncOpenAI
604
+
605
+ async def main():
606
+ client = AsyncOpenAI()
607
+ response = await client.chat.completions.create(
608
+ model="gpt-4",
609
+ messages=[{{"role": "user", "content": "Hello!"}}]
610
+ )
611
+ print(response.choices[0].message.content)
612
+
613
+ asyncio.run(main())
614
+ ```
615
+ ```
616
+
617
+ # Output Format (STRICT)
618
+ You must output the files using the following strict format so that a script can parse and save them.
619
+ For every file, use this exact pattern:
620
+
621
+ ## FILE: {{actual-skill-name}}/{{path_to_file}}
622
+ ```{{language_tag}}
623
+ {{file_content_here}}
624
+ ```
625
+
626
+ **CRITICAL PATH RULES:**
627
+ - Replace `{{actual-skill-name}}` with the ACTUAL kebab-case skill name derived from the repository (e.g., "openai-python", "pandas", "requests")
628
+ - DO NOT use placeholder text like "skill-name" literally
629
+ - For repository "openai/openai-python" → use "openai-python"
630
+ - For repository "psf/requests" → use "requests"
631
+
632
+ **Example Output Pattern:**
633
+ ```
634
+ ## FILE: openai-python/SKILL.md
635
+ ```yaml
636
+ ---
637
+ name: openai-python
638
+ ...
639
+ ```
640
+
641
+ ## FILE: openai-python/scripts/usage_example.py
642
+ ```python
643
+ ...
644
+ ```
645
+
646
+ ## FILE: openai-python/references/api_reference.md
647
+ ```markdown
648
+ ...
649
+ ```
650
+ ```
651
+
652
+ **IMPORTANT:**
653
+ - Generate COMPLETE files, do not use "..." or "[content continues]"
654
+ - SKILL.md should be comprehensive (at least 100+ lines)
655
+ - scripts/: At least one RUNNABLE Python script with actual library API usage
656
+ - references/: At least one DETAILED API reference with function signatures
657
+
658
+ Now, generate the complete skill package based on the provided GitHub repository information.
659
+ Focus on creating a practical, comprehensive skill that an AI agent can use to work with this repository.
660
+ DO NOT truncate content - include all relevant information from the README.
661
+ SCRIPTS must demonstrate actual Python API usage, not shell command wrappers.
662
+ REFERENCES must include actual function signatures and parameters."""
663
+
664
+
665
+ # ==========================================================================
666
+ # Office Document to Skill Prompts (PDF/PPT/Word)
667
+ # ==========================================================================
668
+
669
+ OFFICE_SKILL_SYSTEM_PROMPT = """You are an expert Technical Writer specializing in creating Skills for AI agents.
670
+ Your task is to analyze text content extracted from an office document (PDF, PPT, or Word) and convert it into a structured skill package.
671
+
672
+ CRITICAL REQUIREMENTS:
673
+ 1. Identify the core knowledge, procedures, or guidelines from the document
674
+ 2. Structure the content as a reusable AI skill
675
+ 3. Extract actionable instructions that an AI agent can follow
676
+ 4. Preserve key information while organizing it into the skill format
677
+ 5. Generate appropriate scripts if the document describes code procedures
678
+ 6. Create reference files for supplementary information
679
+
680
+ Output files in parseable format with ## FILE: markers."""
681
+
682
+ OFFICE_SKILL_USER_PROMPT_TEMPLATE = """
683
+ Your task is to convert the following document content into a structured skill package.
684
+
685
+ # Input: Document Content
686
+
687
+ **Source File:** {filename}
688
+ **File Type:** {file_type}
689
+
690
+ ## Extracted Text Content:
691
+ {document_content}
692
+
693
+ # Skill Structure Standard
694
+ You must output the skill using the following directory structure:
695
+
696
+ ```text
697
+ skill-name/
698
+ ├── SKILL.md (required)
699
+ │ ├── YAML frontmatter metadata (required)
700
+ │ │ ├── name: (required)
701
+ │ │ └── description: (required)
702
+ │ └── Markdown instructions (required)
703
+ └── Bundled Resources (optional but recommended)
704
+ ├── scripts/ - Executable code if applicable
705
+ └── references/ - Additional documentation or data
706
+ ```
707
+
708
+ # Content Analysis Guidelines
709
+
710
+ 1. **Identify the Skill Name**: Derive from document title or main topic
711
+ 2. **Create Description**: Write a "when-to-use" trigger statement
712
+ 3. **Extract Procedures**: Convert step-by-step instructions into actionable format
713
+ 4. **Identify Code/Commands**: If the document contains code, create scripts/
714
+ 5. **Supplementary Info**: Move detailed references to references/
715
+
716
+ # SKILL.md Requirements
717
+
718
+ ## YAML Frontmatter (REQUIRED)
719
+ ```yaml
720
+ ---
721
+ name: skill-name-in-kebab-case
722
+ description: When-to-use trigger statement explaining when this skill should be activated
723
+ ---
724
+ ```
725
+
726
+ ## Content Sections to Include:
727
+ - **Overview**: Brief summary of what this skill covers
728
+ - **When to Use**: Clear triggers for skill activation
729
+ - **Prerequisites**: Any required knowledge, tools, or setup
730
+ - **Instructions/Procedures**: Main actionable content from document
731
+ - **Examples**: Practical examples if available in source
732
+ - **References**: Links to additional resources mentioned
733
+
734
+ # Output Format (STRICT)
735
+ For every file, use this exact pattern:
736
+
737
+ ## FILE: <skill-name>/<path_to_file>
738
+ ```<language_tag>
739
+ <file_content_here>
740
+ ```
741
+
742
+ Generate a complete, practical skill package from this document content.
743
+ Focus on making the knowledge actionable for an AI agent."""
744
+
745
+
746
+ # ==========================================================================
747
+ # Prompt-based Skill Generation (Direct User Description)
748
+ # ==========================================================================
749
+
750
+ PROMPT_SKILL_SYSTEM_PROMPT = """You are an expert Technical Writer specializing in creating Skills for AI agents.
751
+ Your task is to generate a complete skill package based on the user's description and requirements.
752
+
753
+ CRITICAL REQUIREMENTS:
754
+ 1. Generate a comprehensive skill based on user's input
755
+ 2. Create practical, actionable instructions
756
+ 3. Include example scripts if the skill involves code
757
+ 4. Add reference documentation where helpful
758
+ 5. Make the skill reusable and well-structured
759
+
760
+ Think creatively about what resources would make this skill most useful.
761
+ Output files in parseable format with ## FILE: markers."""
762
+
763
+ PROMPT_SKILL_USER_PROMPT_TEMPLATE = """
764
+ Your task is to generate a complete skill package based on the following user description.
765
+
766
+ # User's Skill Request:
767
+ {user_input}
768
+
769
+ # Skill Structure Standard
770
+ You must output the skill using the following directory structure:
771
+
772
+ ```text
773
+ skill-name/
774
+ ├── SKILL.md (required)
775
+ │ ├── YAML frontmatter metadata (required)
776
+ │ │ ├── name: (required)
777
+ │ │ └── description: (required)
778
+ │ └── Markdown instructions (required)
779
+ └── Bundled Resources (optional but recommended)
780
+ ├── scripts/ - Executable code demonstrating the skill
781
+ └── references/ - API docs, templates, or reference material
782
+ ```
783
+
784
+ # Generation Guidelines
785
+
786
+ Based on the user's description, you should:
787
+
788
+ 1. **Determine Skill Name**: Create a kebab-case name reflecting the skill's purpose
789
+ 2. **Write Description**: Create a "when-to-use" trigger statement
790
+ 3. **Design Instructions**: Write clear, step-by-step procedures
791
+ 4. **Add Scripts**: If applicable, create Python scripts demonstrating the skill
792
+ 5. **Include References**: Add any helpful reference documentation
793
+
794
+ # SKILL.md Requirements
795
+
796
+ ## YAML Frontmatter (REQUIRED)
797
+ ```yaml
798
+ ---
799
+ name: skill-name-in-kebab-case
800
+ description: When-to-use trigger statement explaining when this skill should be activated
801
+ ---
802
+ ```
803
+
804
+ ## Recommended Sections:
805
+ - **Overview**: What this skill does
806
+ - **When to Use**: Clear triggers for skill activation
807
+ - **Prerequisites**: Required tools, libraries, or knowledge
808
+ - **Quick Start**: Fastest way to use this skill
809
+ - **Detailed Instructions**: Comprehensive step-by-step guide
810
+ - **Examples**: Practical usage examples
811
+ - **Tips & Best Practices**: Common pitfalls and recommendations
812
+ - **Troubleshooting**: Common issues and solutions
813
+
814
+ # Output Format (STRICT)
815
+ For every file, use this exact pattern:
816
+
817
+ ## FILE: <skill-name>/<path_to_file>
818
+ ```<language_tag>
819
+ <file_content_here>
820
+ ```
821
+
822
+ Now, generate a complete, high-quality skill package based on the user's request.
823
+ Be comprehensive and practical - create a skill that an AI agent would find genuinely useful."""
824
+
825
+
826
+ RELATIONSHIP_ANALYSIS_SYSTEM_PROMPT = """
827
+ You are the SkillNet Architect.
828
+ """
829
+
830
+ RELATIONSHIP_ANALYSIS_USER_PROMPT_TEMPLATE = """
831
+ Your task is to map logical relationships between the provided skills based on their names and descriptions.
832
+
833
+ You must strictly identify ONLY the following 4 types of relationships:
834
+
835
+ 1. similar_to
836
+ - A and B perform functionally equivalent tasks (e.g., "Google Search" and "Bing Search").
837
+ - Users can replace A with B.
838
+
839
+ 2. belong_to
840
+ - A is a sub-component or specific step within B.
841
+ - B represents a larger workflow or agent, and A is just one part of it.
842
+ - Direction: Child -> belong_to -> Parent.
843
+
844
+ 3. compose_with
845
+ - A and B are independent but often used together in a workflow.
846
+ - One usually produces data that the other consumes, or they are logically paired.
847
+ - Example: "PDF Parser" compose_with "Text Summarizer".
848
+
849
+ 4. depend_on
850
+ - A CANNOT execute without B.
851
+ - B is a hard dependency (e.g., Environment setup, API Key loader, or a core library skill).
852
+ - Direction: Dependent -> depend_on -> Prerequisite.
853
+
854
+ Here is the list of Skills in the user's local environment. Please analyze them and generate the relationships.
855
+
856
+ Skills List:
857
+ {skills_list}
858
+
859
+ Remember:
860
+ - Be conservative. Only create a relationship if there is a logical connection based on the name and description.
861
+ - Do not hallucinate skills not in the list.
862
+
863
+ Output Format:
864
+ Return a JSON array where each element represents a relationship with the following keys:
865
+ - source: (string) The name of the source skill (the one initiating the relationship)
866
+ - target: (string) The name of the target skill (the one receiving the relationship)
867
+ - type: (string) One of the 4 relationship types: "similar_to", "belong_to", "compose_with", "depend_on"
868
+ - reason: (string) A brief explanation of why this relationship exists based on the skill descriptions.
869
+
870
+ Output Example:
871
+ [
872
+ {{
873
+ "source": "google_search_tool",
874
+ "target": "bing_search_tool",
875
+ "type": "similar_to",
876
+ "reason": "Both provide web search capabilities and are interchangeable."
877
+ }},
878
+ ...
879
+ ]
880
+
881
+ Keep your output in the format below:
882
+ <Skill_Relationships>
883
+ your generated JSON array here
884
+ </Skill_Relationships>
885
+ """