simplellmfunc-developer

分类: 工具与效率 | 上传者: NiJingzhe | 下载: 0 | 版本: v1.0（最新）

开发和维护 SimpleLLMFunc 框架本身。在更改框架内部结构、测试、文档、规格、运行时基元、装饰器行为、工具管道、事件流、PyRepl 集成或面向贡献者的项目结构和约定时使用。

更新日志: Source: GitHub https://github.com/NiJingzhe/SimpleLLMFunc

目录结构

当前层级: tree/master/skills/simplellmfunc-developer/

📁 examples/
- 📄 add_runtime_primitive_pattern.py 1.3 KB
- 📄 test_first_decorator_change.md 1016 B
- 📄 update_docs_checklist.md 844 B
📁 reference/
- 📁 spec/
  - 📄 meta.md 8.4 KB
  - 📄 overall-spec.md 5.4 KB
  - 📄 primitive-dev-api-plan.md 15.2 KB
  - 📄 project-map.md 9.7 KB
- 📄 AGENT.md 3.3 KB
- 📄 contributing.md 2.7 KB
- 📄 docs-and-examples.md 1.5 KB
- 📄 framework-gotchas.md 1.7 KB
- 📄 project-map.md 2.4 KB
- 📄 style-and-spec.md 1.2 KB
- 📄 testing-and-tdd.md 2.0 KB
📄 SKILL.md 5.4 KB

SKILL.md

---
name: simplellmfunc-developer
description: "Develop and maintain the SimpleLLMFunc framework itself. Use when changing framework internals, tests, docs, specs, runtime primitives, decorator behavior, tool plumbing, event streams, PyRepl integration, or contributor-facing project structure and conventions."
license: MIT
compatibility: "Python 3.12+ repo with pytest, Poetry, Mintlify docs, and SimpleLLMFunc source tree available."
metadata:
  project: SimpleLLMFunc
  version: "0.7.7"
---

# SimpleLLMFunc Framework Development

## When to use this skill
- Use this skill when the task changes the framework itself, not just an app built on it.
- Typical triggers: editing `SimpleLLMFunc/`, `tests/`, `docs/`, `spec/`, built-in tools, runtime primitives, decorator semantics, event-stream behavior, provider integration, TUI utilities, or contributor docs.

## Core development philosophy
- Preserve the framework's function-first design: `LLM as Function`, `Prompt as Code`, `Code as Doc`.
- Keep public behavior explicit and typed.
- Favor small, composable modules over hidden orchestration.
- Follow repo-grounded conventions instead of generic framework habits.
- When docs and code disagree, source and tests are the final authority.

## Default implementation workflow
1. Read the relevant docs, tests, and source before changing behavior.
2. Map the affected layer: decorator, base engine, runtime, tooling, interface, hooks, or docs/spec.
3. Write or update tests first for the behavior you are changing.
4. Make the smallest coherent implementation change.
5. Run targeted tests, then broader tests if the change touches shared behavior.
6. Update docs/examples/specs when user-facing behavior or architecture changed.

## TDD and validation loop
- Start with a failing or missing test that captures the new behavior.
- Use red -> green -> refactor.
- Prefer focused unit tests in the mirrored `tests/` location.
- Add or update a runnable example when the feature is user-facing.
- If behavior changes affect docs or spec, update them in the same change.

## Project map
- `SimpleLLMFunc/llm_decorator/`: public decorator entrypoints and stepwise orchestration.
- `SimpleLLMFunc/base/`: ReAct loop, message handling, structured parsing, tool-call execution.
- `SimpleLLMFunc/runtime/`: primitive registry, backend lifecycle, runtime call context.
- `SimpleLLMFunc/builtin/`: user-facing builtins such as `PyRepl`, `FileToolset`, and `SelfReference`.
- `SimpleLLMFunc/hooks/`: events, event bus, stream wrappers, abort support.
- `SimpleLLMFunc/interface/`: model interface abstractions and OpenAI-compatible transport.
- `SimpleLLMFunc/logger/` and `SimpleLLMFunc/observability/`: logs, trace context, Langfuse.
- `SimpleLLMFunc/utils/`: TUI and stdio helpers.
- `tests/`: mirror of behavior and architecture; often the fastest place to infer conventions.
- `mintlify_docs/`: Mintlify documentation source, including locale pages such as `en/...`.
- `spec/`: higher-level project map and repo conventions.

## Naming and style rules
- File names: `snake_case`.
- Functions: `snake_case`.
- Classes: `PascalCase`.
- Constants: `UPPER_SNAKE_CASE`.
- Public APIs should carry type annotations.
- Public user-facing callables should have useful docstrings.
- Follow the repo's existing formatting and PEP 8 style.

## Framework-specific development rules
- Prefer `async def` for decorated public patterns and tool implementations.
- Keep docstring-parsed contracts in sync with behavior. This matters for `@tool` and runtime primitives.
- Runtime primitive docstrings must include `Best Practices`; registration fails without them.
- Preserve history semantics in `llm_chat`: `history` and `chat_history` are special names.
- Preserve structured output parsing behavior unless the task explicitly changes it.
- Treat tests as executable API documentation for subtle cases like self-reference, event mode, and provider compatibility.

## Documentation and spec rules
- Update `mintlify_docs/` when user-facing behavior changes.
- Update `spec/` when module responsibilities, architecture map, or repo-wide guidance changes.
- Keep examples runnable and aligned with current behavior.
- Use progressive disclosure in skills and docs: concise guidance in the main file, details in reference docs.
- Keep `provider.json` format docs and `.env` / environment-variable docs aligned with actual loader and observability behavior.
- Keep the packaged `skills/` directory and the `simplellmfunc-skill` export CLI aligned so installed users can export the current skill contents correctly.
- Treat `AGENTS.md` as a feedback-loop artifact: when recurring agent mistakes reveal missing environmental guidance, update the file so the fix lives in the system instead of only in maintainer memory.

## Read these reference docs as needed
- Architecture and contributor map: `reference/project-map.md`
- TDD, tests, and validation expectations: `reference/testing-and-tdd.md`
- Coding conventions and naming rules: `reference/style-and-spec.md`
- Framework-specific gotchas: `reference/framework-gotchas.md`
- Docs and examples workflow: `reference/docs-and-examples.md`
- Maintainer workflow notes: `reference/AGENT.md`
- Contributor guide: `reference/contributing.md`
- Mirrored repo spec: `reference/spec/project-map.md`, `reference/spec/overall-spec.md`, `reference/spec/primitive-dev-api-plan.md`, `reference/spec/meta.md`
- Developer examples: `examples/add_runtime_primitive_pattern.py`, `examples/test_first_decorator_change.md`, `examples/update_docs_checklist.md`

登录后下载/点赞/收藏 ❤ 76 | ★ 0

simplellmfunc-developer

目录结构

SKILL.md

举报内容

提示