@metmirr/prlen 0.1.0 → 1.0.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@metmirr/prlen",
-  "version": "0.1.0",
+  "version": "1.0.0",
   "description": "CLI for publishing PR Lens posts from pull requests",
   "type": "module",
   "files": [

package/skills/prlen/SKILL.md

@@ -7,94 +7,71 @@ description: Publish or create PR Lens posts for a GitHub pull request. Use when
 
 Use this skill when the user wants an agent to publish a PR Lens post for a pull request.
 
-## Goal
+## Critical rule
 
-Use the fastest reliable workflow:
-
-1. Resolve the PR reference (`#12`, `12`, or a full GitHub PR URL)
-2. Read enough PR context to draft a good short post
-3. Draft the PR Lens post text yourself
-4. Publish non-interactively via the CLI using stdin
-
-The agent is already an LLM, so do **not** wait for the CLI to generate the text.
-
-## Preferred publish command
+**You MUST fetch the PR Lens system prompt before writing any post text.** Run:
 
 ```bash
-printf '%s' "<draft post text>" | prlen post 12 --prompt-stdin --yes
+prlen template
 ```
 
-## PR Lens post style
-
-Write like a real developer talking to Claude/Cursor/Copilot:
+The system prompt defines the exact style, tone, length, and rules for every post. Do not skip this step. Do not rely on your own judgment for post style. The template is the authority.
 
-- casual and direct
-- 2–3 sentences max
-- specific technologies, file paths, and decisions when visible
-- under 500 chars
-- instruction-style wording, not release notes
-- no quotes, no labels
-
-Good:
+## Workflow
 
-```text
-Add CLI publishing for PR Lens with browser-approved login, backend-fetched PR metadata, and non-interactive posting for agents. Keep it simple: login in the browser once, then let the CLI publish directly from the terminal.
-```
+Follow these steps in order. Do not skip or reorder them.
 
-Bad:
+### Step 1: Fetch the system prompt
 
-```text
-This PR adds several new features to improve the PR Lens platform.
+```bash
+prlen template
 ```
 
-## Workflow
+Read the output carefully. It contains:
+- the voice and tone to use
+- the maximum character limit
+- what to include and what to avoid
 
-### 1. Resolve the PR
+You must follow every rule in the system prompt when drafting the post.
 
-Prefer the user's PR reference directly.
+### Step 2: Resolve the PR
 
-- `#12`
-- `12`
-- `https://github.com/org/repo/pull/12`
+Use the PR reference the user gave you:
 
-### 2. Inspect the PR
+- `#12`, `12`, or `https://github.com/org/repo/pull/12`
 
-Read enough context to write a high-quality short post:
+### Step 3: Inspect the PR
 
-- PR title
-- PR description/body
-- changed files
-- important parts of the diff
-- notable implementation constraints or design choices
+Read enough context to write a high-quality post:
 
-### 3. Optionally fetch the PR Lens prompt template
+- PR title and description
+- changed files and important parts of the diff
+- notable design decisions or constraints
 
-If you want style guidance, fetch:
+### Step 4: Draft the post following the system prompt
 
-```text
-GET /api/v1/prompt-template
-```
+Write the post text applying every rule from the system prompt you fetched in step 1.
 
-Do not block on this if you already have enough context to write the post.
+Key rules from the template (these may change — always re-read the actual output):
+- sound like a developer typing in a chat box
+- ~280 characters, never exceed 500, 2-3 sentences max
+- name specific technologies, file paths, patterns from the diff
+- write the INSTRUCTION that produced the code, not a description of what it does
+- output only the prompt text, no quotes, no labels
 
-### 4. Publish via CLI
+### Step 5: Publish
 
-Use stdin to avoid shell-escaping problems.
+Use stdin to avoid shell-escaping problems:
 
 ```bash
-printf '%s' "<draft post text>" | prlen post 12 --prompt-stdin --yes
+printf '%s' "<your drafted post text>" | prlen post 12 --prompt-stdin --yes
 ```
 
-### 5. Report the result
+### Step 6: Report
 
 Tell the user the post was published and include the returned URL.
 
-## Auth expectations
-
-PR Lens CLI auth usually comes from:
-
-- `~/.config/prlen/auth.json`
-- `PRLEN_TOKEN`
+## Auth
 
 If auth is missing, tell the user to run:
 
@@ -102,12 +79,10 @@ If auth is missing, tell the user to run:
 prlen login
 ```
 
-`prlen login` opens a browser approval page on PR Lens. If the user is already signed in on the website, they can approve the CLI login there without manually handling GitHub tokens.
-
 ## Notes
 
-- `prlen post` fetches PR metadata through PR Lens using the user's connected GitHub account.
-- The target repository must already be connected in PR Lens.
+- `prlen post` auto-connects repos that aren't connected yet.
 - The pull request must not already have a PR Lens post.
+- The daily post limit is enforced server-side.
 
 See [reference.md](reference.md) for examples and fallback behavior.

package/skills/prlen/reference.md

@@ -1,25 +1,41 @@
 # PR Lens Skill Reference
 
+## Full workflow example
+
+```bash
+# 1. Always fetch the system prompt first
+prlen template
+
+# 2. Read the output and draft a post that follows its rules
+
+# 3. Publish
+printf '%s' "Add browser-approved CLI login that replaces GitHub device flow. The backend issues a challenge URL, the CLI opens it, and the user clicks approve — no tokens needed in the terminal." | prlen post 12 --prompt-stdin --yes
+```
+
 ## Common commands
 
-### Log in once
+### Fetch the system prompt (mandatory before every post)
 
 ```bash
-prlen login
+prlen template
 ```
 
-This opens a browser approval page on PR Lens.
+### Log in
+
+```bash
+prlen login
+```
 
-### Publish PR #12 with agent-authored text
+### Publish a post
 
 ```bash
-printf '%s' "Add API-backed PR Lens publishing for pull requests with browser-approved login and non-interactive agent mode." | prlen post 12 --prompt-stdin --yes
+printf '%s' "<post text following the system prompt rules>" | prlen post 12 --prompt-stdin --yes
 ```
 
 ### Full PR URL instead of number
 
 ```bash
-printf '%s' "Add API-backed PR Lens publishing for pull requests with browser-approved login and non-interactive agent mode." | prlen post https://github.com/org/repo/pull/12 --prompt-stdin --yes
+printf '%s' "<post text>" | prlen post https://github.com/org/repo/pull/12 --prompt-stdin --yes
 ```
 
 ## Fallbacks
@@ -27,27 +43,26 @@ printf '%s' "Add API-backed PR Lens publishing for pull requests with browser-ap
 ### If prompt text is already available as a string
 
 ```bash
-prlen post 12 --prompt "<draft post text>" --yes
+prlen post 12 --prompt "<post text>" --yes
 ```
 
 `--prompt-stdin` is still safer for agents.
 
 ## What to write
 
-Aim for:
+Follow the system prompt from `prlen template`. The key points:
 
-- the instruction that produced the code
-- constraints or design choices
-- names of files/tech when relevant
-- no markdown formatting
-- no surrounding quotes
+- write the instruction that produced the code
+- sound like a developer in a chat box
+- be specific about technologies, file paths, design choices
+- ~280 chars target, never exceed 500
+- no markdown, no quotes, no labels
 
 ## If publishing fails
 
 Check:
 
 1. PR Lens auth exists (`prlen login`)
-2. the repo is connected in PR Lens
-3. the PR does not already have a post
-4. the daily post limit has not been reached
-5. the PR Lens server URL is correct if using a local instance (`PRLEN_BASE_URL`)
+2. the PR does not already have a post
+3. the daily post limit has not been reached
+4. the PR Lens server URL is correct if using a local instance (`PRLEN_BASE_URL`)