fengming 0.3.9 → 0.3.11

package/skills/run-skill-generator/SKILL.md

@@ -1,179 +0,0 @@
----
-name: run-skill-generator
-description: Teach /run and /verify how to build and launch your project by recording a working recipe. Use once per project to capture the install commands, environment variables, and launch steps needed.
-when_to_use: "User runs /run-skill-generator explicitly, or says their project needs special setup for /run and /verify to work. Trigger phrases: generate run skill, teach how to build this, record the launch recipe, set up run commands for this project. Only invoke when explicitly requested — this is not automatic."
-context: fork
-user-invocable: true
-disable-model-invocation: true
----
-
-# Run Skill Generator
-
-Record how to build and launch this project, then generate a skill at `.claude/skills/run-<name>/SKILL.md` (or equivalent for FengMing) so that `/run` and `/verify` (and any other agent in this repo) can follow the recorded recipe instead of rediscovering it each time.
-
-## Why this is needed
-
-By default, `/run` and `/verify` infer the launch from your project type (CLI, server, TUI, browser) and from what's in your README, `package.json`, or `Makefile`. This inference is unreliable for projects that need anything beyond a standard launch: a database, an env file, a graphical session, a multi-step build, or any non-standard setup.
-
-This skill records the recipe so `/run`, `/verify`, and any agent in the repo follow it consistently.
-
-## Step 1: Discover the project structure
-
-Before building, understand the project:
-
-1. Read `README.md` for setup instructions, architecture, and dependencies
-2. Read `package.json` for scripts, dependencies, and project type hints
-3. Check for `Makefile`, `Dockerfile`, `docker-compose.yml`, `Makefile` or other build descriptors
-4. List the top-level directory structure to understand the project layout
-5. Identify: is this a monorepo? Does it need a database? Are there environment variables?
-
-Report findings:
-```
-Project: <name>
-Type: CLI / web server / TUI / browser app / library
-Language: TypeScript / Python / Go / etc.
-Dependencies: npm / pip / go modules / etc.
-Special requirements: database (which), env vars (.env required), etc.
-```
-
-## Step 2: Install from a clean state
-
-Demonstrate that the project can be installed:
-
-1. Delete existing artifacts: `node_modules`, `dist`, `build`, `__pycache__`, `.venv` etc.
-2. Install dependencies:
-   - Node.js: `npm install` (or `pnpm install`, `yarn`)
-   - Python: `pip install -r requirements.txt` (or `poetry install`)
-   - Go: `go mod download`
-3. Run any database setup: migrations, seed data
-4. Copy or create any required config files (`.env` template, config file)
-5. Verify installation succeeded: check for installed binaries, accessible commands
-
-Record the exact commands that succeeded. If something fails, diagnose and fix it — the recipe must be reproducible.
-
-## Step 3: Build
-
-Demonstrate that the project builds:
-
-1. Run the build command from package.json scripts, Makefile, or README
-2. If the build fails, fix the errors and try again
-3. Record the exact build command that succeeded
-
-## Step 4: Set up environment
-
-Document what environment the app needs:
-
-1. What environment variables are required? List them and their purpose
-2. Is there a `.env.example` or `.env.template` file? Note its location
-3. Do any services need to be running first? (database, redis, API proxy)
-4. What port does the app use? Can it be changed?
-
-## Step 5: Launch
-
-Demonstrate that the app can be launched:
-
-1. Set the required environment variables
-2. Start any required services (database, redis, etc.) if possible in this environment
-3. Run the launch command
-4. Verify the app is running:
-   - CLI: runs a command and produces correct output
-   - Server: responds to HTTP requests on the expected port
-   - TUI: displays without errors
-   - Browser: opens successfully in browser
-5. If any service is missing (e.g., no database), note that it must be started separately
-
-## Step 6: Generate the skill
-
-Create a skill file at `.claude/skills/run-<name>/SKILL.md` (or FengMing equivalent at `skills/run-<name>/SKILL.md`):
-
-```markdown
----
-name: run-<name>
-description: Build and launch <project-name>. Generated by /run-skill-generator on <date>.
-when_to_use: "When running, launching, starting, or verifying <project-name>. This skill contains the recorded launch recipe."
----
-
-# Run: <project-name>
-
-Generated by /run-skill-generator. This skill teaches /run and /verify how to build and launch this project.
-
-## Project
-
-- **Type**: <CLI / web server / TUI / browser app>
-- **Language**: <TypeScript / Python / Go / etc.>
-- **Entry point**: <path>
-
-## Install
-
-```bash
-cd <project-root>
-<exact install command>
-```
-
-<additional setup steps, like database migrations>
-
-## Build
-
-```bash
-<exact build command>
-```
-
-## Environment
-
-Required environment variables:
-
-| Variable | Purpose | Default |
-|----------|---------|---------|
-| ... | ... | ... |
-
-<if .env.example exists, mention it>
-
-## Launch
-
-```bash
-<exact launch command with any needed env vars>
-```
-
-The app runs at: <URL or description>
-
-## Dependencies
-
-These services must be running (or mocked):
-
-| Service | Required | How to start |
-|---------|----------|-------------|
-| ... | yes/no | <command> |
-```
-
-If the project root is not the skill directory location, use the absolute path in the instructions.
-
-## Step 7: Verify the skill works
-
-After generating the skill, test it:
-
-1. Close the running app if it's still up
-2. Follow the skill's instructions from scratch: install, build, launch
-3. Confirm it still works end-to-end
-
-This proves the recipe is reproducible.
-
-## Step 8: Report
-
-```
-## Run Skill Generated
-
-Skill: .claude/skills/run-<name>/SKILL.md
-What it records: install, build, env, launch for <project-name>
-Tested: ✅ reproducible end-to-end
-
-/run and /verify will now use this recipe for <project-name>.
-Run this command again if the build or launch process changes.
-```
-
-## Guidelines
-
-- Record what actually works, not what should work in theory
-- If a service (database, cache) is required but can't be started automatically, note it as a prerequisite
-- Use absolute paths when the project might be run from a different directory
-- If the project has multiple entry points (e.g., server + worker), generate a skill for each or document how to choose
-- Update the skill if the build process changes — stale launch recipes cause confusing failures

package/skills/verify/SKILL.md

@@ -1,103 +0,0 @@
----
-name: verify
-description: Build and run the application to confirm a code change does what it should. Unlike testing or type-checking, this launches the app and drives the actual changed behavior. Use after implementing a feature or fix to prove it works.
-when_to_use: "User wants to confirm their change works, verify behavior after editing code, prove a fix is correct, or validate a feature. Trigger phrases: verify this, confirm it works, check if that fixed it, does this actually work, prove the fix works, validate the change. Activate automatically after edits when user wants behavioral confirmation."
----
-
-# Verify
-
-Confirm that a code change produces the correct behavior by building, running, and interacting with the application — not by running tests or type-checking.
-
-This skill is about behavioral verification: proving your change works in the actual running application.
-
-## Step 1: Identify what needs verification
-
-Read the recent changes to understand what should be verified:
-
-1. Check the diff: `git diff` or `git diff --cached` to see uncommitted changes
-2. Identify the changed behavior: what feature was added, what bug was fixed, what was refactored
-3. Determine how to test it: what input triggers the changed code path, what output proves it works
-
-If the user specifies a particular behavior to verify (e.g., "verify that login works"), focus only on that.
-
-## Step 2: Build (if applicable)
-
-For compiled or build-step projects:
-
-1. Run the project's build command (from package.json scripts, Makefile, etc.)
-2. If the build fails, report the error and stop — the change is not verified
-3. If the build succeeds, note any warnings
-
-For interpreted languages (Python, JavaScript directly, Ruby), skip this step.
-
-## Step 3: Run the application
-
-Launch the application using the same approach as `/run`:
-
-1. Detect the project type and launch method
-2. Start the application
-3. Verify it starts without errors
-
-## Step 4: Drive the changed behavior
-
-Now the critical step: execute the specific scenario that exercises the change:
-
-**For a new feature**: Use the feature as an end user would
-- Run the new command with the expected arguments
-- Call the new API endpoint with sample input
-- Interact with the new UI element
-
-**For a bug fix**: Reproduce the original bug scenario
-- Run the exact input that used to trigger the bug
-- Confirm the error no longer occurs
-- Verify the correct output is produced
-
-**For a behavior change**: Test the old behavior and the new behavior
-- Test with inputs that should match the old behavior (if it still applies)
-- Test with inputs that should match the new behavior
-
-## Step 5: Confirm correctness
-
-For each verification:
-
-1. State what you expected to happen
-2. Show the actual result (output, response, behavior)
-3. Confirm they match
-
-```
-Expected: POST /login with valid credentials returns 200 and a session token
-Actual:   POST /login returned 200 with { token: "xxx", user: {...} }
-✅ Login endpoint working correctly
-```
-
-If the actual doesn't match the expected:
-- Report the mismatch with expected vs actual
-- Diagnose why (see `/debug`)
-- Do not claim verification passed
-
-## Step 6: Report
-
-Summarize the verification:
-
-```
-## Verify: <change description>
-
-Build: ✅ passed (or N/A)
-Run: ✅ app started on port 3000
-Verification: ✅ confirmed <what was verified>
-```
-
-## Verification is NOT
-
-- Running the test suite and checking if tests pass — that's testing, not verification
-- Running the type checker and confirming no type errors — that's type-checking
-- Reading the code and reasoning that it should work — that's code review
-
-Verification means the app actually runs and does the right thing.
-
-## Guidelines
-
-- Prefer the shortest path to verification: the minimum action to confirm the change works
-- Clean up: stop the running application after verification, unless the user wants it kept running
-- If you can't run the app (e.g., it requires a database you don't have access to), say so and suggest alternative verification
-- Be honest: if the verification fails, report it. Don't claim success when the behavior is wrong

package/src/agents/templates/HEARTBEAT.md

@@ -1,3 +0,0 @@
-# Keep this file empty (or with only comments) to skip heartbeat API calls.
-
-# Add tasks below when you want the agent to check something periodically.