Forked clean from public hackathon repo (Starfire-AgentTeam, BSL 1.1) with full rebrand to Molecule AI under github.com/Molecule-AI/molecule-monorepo. Brand: Starfire → Molecule AI. Slug: starfire / agent-molecule → molecule. Env vars: STARFIRE_* → MOLECULE_*. Go module: github.com/agent-molecule/platform → github.com/Molecule-AI/molecule-monorepo/platform. Python packages: starfire_plugin → molecule_plugin, starfire_agent → molecule_agent. DB: agentmolecule → molecule. History truncated; see public repo for prior commits and contributor attribution. Verified green: go test -race ./... (platform), pytest (workspace-template 1129 + sdk 132), vitest (canvas 352), build (mcp). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
3.2 KiB
3.2 KiB
| name | description |
|---|---|
| update-docs | Review recent edits and update all documentation including architecture docs, API specs, and edit history. Creates missing docs for new implementations. |
Update Documentation
Review recent code changes and update ALL relevant documentation in the /docs folder.
Steps
-
Read today's edit history
- Check
docs/edit-history/for the current date's session file - Identify all files that were modified
- Check
-
Analyze changes
- Read the modified files to understand what changed
- Categorize changes: new features, bug fixes, architecture changes, API changes, config changes
-
Update edit-history session file
- Add a summary section at the top describing what was accomplished
- Group related changes under descriptive headings
- Add any missing context about why changes were made
-
Update CLAUDE.md if needed
- New commands or scripts added
- Architecture or key modules changed
- New environment variables required
- New routes or endpoints added
- Test counts when new test files were added
-
Update PLAN.md (repo root) if needed
- When a planned phase ships, mark it complete and add any follow-ups
- When new architectural decisions are made, update the relevant phase
- Keep the current status / next steps section in sync with reality
- If a feature was reverted, document the reversal and reasoning
-
Update README.md (repo root) if needed
- New features visible to users (canvas tabs, deploy flows, etc.)
- Changed setup or quickstart instructions
- Updated tech stack list (when adding/removing major dependencies)
- Updated test counts in the status badges
- License or branding changes
-
Update README.zh-CN.md (repo root) if README.md was updated
- Mirror any user-visible changes from README.md
- Keep the Chinese translation in sync — don't let it drift
- Update the same sections in both files (status, features, setup, license)
-
Update .env.example (repo root) if needed
- Every new env var read by code must be documented in
.env.example - Include a comment describing the var and its expected format
- When removing an env var from code, remove from
.env.example - Keep default values consistent with code defaults
- Every new env var read by code must be documented in
-
Update docs/README.md if needed
- New features or capabilities
- Changed setup instructions
- Updated project overview
-
Update docs/ files Review and update all architecture documentation to match current implementation
For each doc:
- Check if documented features match actual code implementation
- Update outdated sections to reflect current code
- Add NEW sections for features that are implemented but not documented
- Remove or mark deprecated features that no longer exist
- Ensure code examples match actual implementation
-
Create new docs if needed
- If a significant new feature or module was added but has no documentation, create appropriate documentation
- Follow existing documentation style and structure
-
Report summary
- List all documentation files updated
- Note any new documentation files created
- Summarize key changes documented