doc
- Repo stars 4
- License MIT
- Author repo product-factory-os
Doc
Write documentation that matches the project.
Process
- Read existing docs and code.
- Identify the audience: user, developer, operator, maintainer.
- Update the smallest relevant document.
- Include commands, environment variables, and examples when useful.
- Verify commands if practical.
Self-validation
Before final output, verify:
- Route, side-effect, and confirmation requirements match metadata.
- Required artifacts or read-only result are explicit.
- Verification, blockers, and next route are stated.
Rules
- Do not document features that do not exist.
- Do not create a new docs system for a small change.
- Keep generated docs concise and maintainable.
- Fluxly category
- Documentation
- Author-declared agents
- No explicit declaration found; this is not inferred or tested compatibility
- Static check
- 94 / 100 · heuristic scan, not runtime safety proof
- Author / version / license
- @hihol-labs · MIT
- Fluxly token estimate
- Lean
- Fluxly setup estimate
- Plug-and-play
- External API key
- No requirement detected
- Detected OS requirements
- Unspecified
- Runtime requirements
- Unspecified
- Detected file/system behavior
-
- Read-only
- Write / modify
- Env read
- Detected network behavior
- Local-only
- Install commands
- None (reference only)
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
The current SKILL.md does not define a fixed output example. Read existing docs and code. Identify the audience: user, developer, operator, maintainer. Update the smallest relevant document.
Before final output, verify: Route, side-effect, and confirmation requirements match metadata. Required artifacts or read-only result are explicit.
Do not document features that do not exist. Do not create a new docs system for a small change. Keep generated docs concise and maintainable.
# Doc
Write documentation that matches the project.
## Process
1. Read existing docs and code.
2. Identify the audience: user, developer, operator, maintainer.
3. Update the smallest relevant document.
4. Include commands, environment variables, and examples when useful.
5. Verify commands if practical.
## Self-validation
Before final output, verify:
- Route, side-effect, and confirmation requirements match metadata.
- Required artifacts or read-only result are explicit.
- Verification, blockers, and next route are stated.
## Rules
- Do not document features that do not exist.
- Do not create a new docs system for a small change.
- Keep generated docs concise and maintainable. Author text anchors workflow facts; Fluxly only indexes current sections, terms, files, and commands.
sections -> Process → Self-validation → Rules
terms -> Write documentation that matches the project. · 1. Read existing docs and code. · - Route, side-effect, and confirmation requirements match metadata. · - Do not document features that do not exist.
files/cmd -> no explicit files or commands
body sha256 -> 3eba1eadda74
Decide Fit First
Design Intent
How To Use It
Boundaries And Review