mirror of
https://github.com/x1xhlol/system-prompts-and-models-of-ai-tools.git
synced 2026-08-16 21:24:09 +00:00
Compare commits
4 Commits
4c80306a38
...
70b741ae78
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
70b741ae78 | ||
|
|
2054f580b1 | ||
|
|
a6d1e2162b | ||
|
|
67fe3ac5e0 |
33
README.md
33
README.md
@ -30,6 +30,15 @@
|
||||
|
||||
---
|
||||
|
||||
## Security Notice for AI Startups
|
||||
|
||||
> **Warning:** If you're an AI startup, make sure your data is secure. Exposed prompts or AI models can easily become a target for hackers.
|
||||
|
||||
> **Important:** Interested in securing your AI systems?
|
||||
> Check out **[ZeroLeaks](https://zeroleaks.ai/)**, a service designed to help startups **identify and secure** prompt injection and system prompt extraction risks.
|
||||
|
||||
---
|
||||
|
||||
## Support the Project
|
||||
|
||||
If you find this collection valuable and appreciate the effort involved in obtaining and sharing these insights, please consider supporting the project.
|
||||
@ -47,15 +56,6 @@ Thank you for your support!
|
||||
|
||||
---
|
||||
|
||||
## Security Notice for AI Startups
|
||||
|
||||
> **Warning:** If you're an AI startup, make sure your data is secure. Exposed prompts or AI models can easily become a target for hackers.
|
||||
|
||||
> **Important:** Interested in securing your AI systems?
|
||||
> Check out **[ZeroLeaks](https://zeroleaks.ai/)**, a service designed to help startups **identify and secure** prompt injection and system prompt extraction risks.
|
||||
|
||||
---
|
||||
|
||||
# Sponsors
|
||||
|
||||
Sponsor the most comprehensive repository of AI system prompts and reach thousands of developers.
|
||||
@ -68,7 +68,7 @@ Sponsor the most comprehensive repository of AI system prompts and reach thousan
|
||||
|
||||
> Open an issue.
|
||||
|
||||
> **Latest Update:** 10/05/2026
|
||||
> **Latest Update:** 12/07/2026
|
||||
|
||||
---
|
||||
|
||||
@ -76,17 +76,6 @@ Sponsor the most comprehensive repository of AI system prompts and reach thousan
|
||||
|
||||
- **X:** [Lucknite](https://x.com/Lucknite)
|
||||
- **Discord**: `x1xhlol`
|
||||
- **Email**: `lucasvalbuena@pm.me`
|
||||
|
||||
|
||||
## Star History
|
||||
|
||||
<a href="https://www.star-history.com/#x1xhlol/system-prompts-and-models-of-ai-tools&Date">
|
||||
<picture>
|
||||
<source media="(prefers-color-scheme: dark)" srcset="https://api.star-history.com/svg?repos=x1xhlol/system-prompts-and-models-of-ai-tools&type=Date&theme=dark" />
|
||||
<source media="(prefers-color-scheme: light)" srcset="https://api.star-history.com/svg?repos=x1xhlol/system-prompts-and-models-of-ai-tools&type=Date" />
|
||||
<img alt="Star History Chart" src="https://api.star-history.com/svg?repos=x1xhlol/system-prompts-and-models-of-ai-tools&type=Date" />
|
||||
</picture>
|
||||
</a>
|
||||
- **Email**: `lucasvalbuena@pm.me
|
||||
|
||||
**Drop a star if you find this useful!**
|
||||
|
||||
@ -292,7 +292,7 @@
|
||||
},
|
||||
|
||||
"write_phases": {
|
||||
"description": "Use this tool to break any sizeable coding task—refactor or new feature—into *independently executable phases* that **always leave the codebase compiling and all tests green**. Stay laser-focused on code-level work; skip phases that belong to infra provision, deployment, monitoring, or other non-development concerns.\n\n### Phase-sizing guidelines\n\n* Treat each phase like a well-scoped pull request: one coherent chunk of work that reviewers can grasp at a glance.\n* If a single file refactor (or similarly small change) completes the task, keep it to one phase—don't force extra steps.\n* Conversely, split phases when a change grows too large or mixes unrelated concerns.\n\n### Core principles\n\n1. **Shadow, don't overwrite**\n * Introduce parallel symbols (e.g., `Thing2`) instead of modifying the legacy implementation.\n * Keep the original path alive and functional until the final "cut-over" phase.\n\n2. **Phase-by-phase integrity**\n * Every phase must compile, run existing tests, and, where necessary, add new ones.\n * Do not advance while dead code, broken interfaces, or failing checks remain.\n * For example, if an API's return type changes, update all its consumers in the same phase.\n\n3. **Leverage the legacy reference**\n * Continuously compare new code to the old implementation.\n * Can add explicit phases or instructions in phases to do this at critical junctures.\n\n4. **Final phase**\n * This phase needs to verify that the required behavior is fully reproduced.\n * Rename or swap entry points, remove `Thing` vs `Thing2` duplication, and delete obsolete paths once the new code is proven.\n\nNote: Before coming up with phase breakdown, step back to make sure you are following the core principles and guidelines.",
|
||||
"description": "Use this tool to break any sizeable coding task—refactor or new feature—into *independently executable phases* that **always leave the codebase compiling and all tests green**. Stay laser-focused on code-level work; skip phases that belong to infra provision, deployment, monitoring, or other non-development concerns.\n\n### Phase-sizing guidelines\n\n* Treat each phase like a well-scoped pull request: one coherent chunk of work that reviewers can grasp at a glance.\n* If a single file refactor (or similarly small change) completes the task, keep it to one phase—don't force extra steps.\n* Conversely, split phases when a change grows too large or mixes unrelated concerns.\n\n### Core principles\n\n1. **Shadow, don't overwrite**\n * Introduce parallel symbols (e.g., `Thing2`) instead of modifying the legacy implementation.\n * Keep the original path alive and functional until the final \"cut-over\" phase.\n\n2. **Phase-by-phase integrity**\n * Every phase must compile, run existing tests, and, where necessary, add new ones.\n * Do not advance while dead code, broken interfaces, or failing checks remain.\n * For example, if an API's return type changes, update all its consumers in the same phase.\n\n3. **Leverage the legacy reference**\n * Continuously compare new code to the old implementation.\n * Can add explicit phases or instructions in phases to do this at critical junctures.\n\n4. **Final phase**\n * This phase needs to verify that the required behavior is fully reproduced.\n * Rename or swap entry points, remove `Thing` vs `Thing2` duplication, and delete obsolete paths once the new code is proven.\n\nNote: Before coming up with phase breakdown, step back to make sure you are following the core principles and guidelines.",
|
||||
"parameters": {
|
||||
"howDidIGetHere": {
|
||||
"description": "Keep this section under 150 words, and use markdown format. Document the investigative steps and discoveries that shaped the phase plan. Do not mention exact tool names, instead mention that as a verb. E.g. list_files tool call can be described as 'I listed the files'.",
|
||||
|
||||
Loading…
Reference in New Issue
Block a user