lov-project-port

Project Port Generator

Generate a stable and unique port number for the project (range 3000-8999); the same project name always returns the same port.

Port generation algorithm

def generate_port(project_name: str) -> int:
    hash_value = sum(ord(c) * (i + 1) for i, c in enumerate(project_name))
    return 3000 + (hash_value % 6000)

Usage scenarios

1. Query the project port

When the user asks about the port, calculate it directly and inform them:

项目 "skill-publisher" 的端口号是：7965

2. Update the project configuration

Detect and update the port configuration file in the project:

File	Configuration method
.env / .env.local	PORT=<port>
package.json	In scripts --port <port>
vite.config.ts	server.port: <port>
next.config.js	Usually use .env

When updating, prefer the .env method, for minimal intrusiveness.

3. Start the development server

PORT=$(scripts/hashport.sh) pnpm dev

Script

Run scripts/hashport.sh [project-name] to generate the port:

# 使用当前目录名
./scripts/hashport.sh
# 输出: 7965

# 指定项目名
./scripts/hashport.sh my-project
# 输出: 5123

Port conflict handling

If the port is occupied:

1. Tell the user which process is occupying the port
2. Suggest using lsof -i :<port> to check
3. A suffix can be appended to generate a backup port:generate_port("project-dev")

Runtime context (shared)

Before running, read this Skill package's skill.yaml, with the host providing the skill-runtime/v1 context. The field resolution order is: current request, project context, personal Preferences, brand Profile, general defaults.

• Use only fields declared in the Manifest; Profile stores public brand facts, Preferences stores personal work preferences.
• required: true When a field is missing, ask the user one focused question according to the Manifest's question configuration; save the answer only after the user explicitly agrees.
• Errors provide a copyable context_id, field path, and source; diagnostic content avoids secrets, full private paths, and raw configuration.

General feedback loop

When the user raises modification feedback during a Skill-driven task, before continuing with the current artifact you must:

1. First determine whether the feedback is task-specific(this time only) or reusable(reusable across tasks).
2. task-specific Only modify the current task, do not change the Skill.
3. reusable First determine the scope: for domain rules, first update the corresponding canonical Skill; for rules that apply to all Skills, first update the shared specification.
4. After completing the rule update, versioning, lint, and distribution verification, then apply the modification to the current task.
5. reusable A modification invalidates previous "confirm", "continue", and "send it" responses; after completing the current artifact modification and read-back, you must stop and wait for the user's next instruction, and must not automatically proceed to publishing, committing, or other external writes.