simplellmfunc-developer

Category: Tools & Productivity | Uploader: NiJingzhe | Downloads: 0 | Version: v1.0（Latest）

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.

Changelog: Source: GitHub https://github.com/NiJingzhe/SimpleLLMFunc

Directory Structure

Current level: 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 839 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.4 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.2 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, Sphinx/MyST docs, and SimpleLLMFunc source tree available."
metadata:
  project: SimpleLLMFunc
  version: "0.7.6"
---

# 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.
- `docs/source/`: user docs, mostly Chinese source markdown with localized builds.
- `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 `docs/source/` 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.

## 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`

Comments 0

Latest | Hot

Please login before commenting.

No comments yet. Be the first one!

simplellmfunc-developer

Directory Structure

SKILL.md

Report

Notice