@fro.bot/systematic 1.22.8 → 1.23.1

package/skills/document-review/SKILL.md

@@ -1,17 +1,17 @@
 ---
 name: document-review
-description: This skill should be used to refine brainstorm or plan documents before proceeding to the next workflow step. It applies when a brainstorm or plan document exists and the user wants to improve it.
+description: This skill should be used to refine requirements or plan documents before proceeding to the next workflow step. It applies when a requirements document or plan document exists and the user wants to improve it.
 ---
 
 # Document Review
 
-Improve brainstorm or plan documents through structured review.
+Improve requirements or plan documents through structured review.
 
 ## Step 1: Get the Document
 
 **If a document path is provided:** Read it, then proceed to Step 2.
 
-**If no document is specified:** Ask which document to review, or look for the most recent brainstorm/plan in `docs/brainstorms/` or `docs/plans/`.
+**If no document is specified:** Ask which document to review, or look for the most recent requirements/plan in `docs/brainstorms/` or `docs/plans/`.
 
 ## Step 2: Assess
 
@@ -32,11 +32,12 @@ Score the document against these criteria:
 | Criterion | What to Check |
 |-----------|---------------|
 | **Clarity** | Problem statement is clear, no vague language ("probably," "consider," "try to") |
-| **Completeness** | Required sections present, constraints stated, open questions flagged |
-| **Specificity** | Concrete enough for next step (brainstorm → can plan, plan → can implement) |
-| **YAGNI** | No hypothetical features, simplest approach chosen |
+| **Completeness** | Required sections present, constraints stated, and outstanding questions clearly marked as blocking or deferred |
+| **Specificity** | Concrete enough for next step (requirements → can plan, plan → can implement) |
+| **Appropriate Level** | Requirements doc stays at behavior/scope level and does not drift into implementation unless the document is inherently technical |
+| **YAGNI** | Avoid speculative complexity whose carrying cost outweighs its value; keep low-cost, meaningful polish when it is easy to maintain |
 
-If invoked within a workflow (after `/workflows:brainstorm` or `/workflows:plan`), also check:
+If invoked within a workflow (after `/ce:brainstorm` or `/ce:plan`), also check:
 - **User intent fidelity** — Document reflects what was discussed, assumptions validated
 
 ## Step 4: Identify the Critical Improvement
@@ -56,7 +57,7 @@ Present your findings, then:
 Simplification is purposeful removal of unnecessary complexity, not shortening for its own sake.
 
 **Simplify when:**
-- Content serves hypothetical future needs, not current ones
+- Content serves hypothetical future needs without enough current value to justify its carrying cost
 - Sections repeat information already covered elsewhere
 - Detail exceeds what's needed to take the next step
 - Abstractions or structure add overhead without clarity
@@ -65,6 +66,10 @@ Simplification is purposeful removal of unnecessary complexity, not shortening f
 - Constraints or edge cases that affect implementation
 - Rationale that explains why alternatives were rejected
 - Open questions that need resolution
+- Deferred technical or research questions that are intentionally carried forward to the next stage
+
+**Also remove when inappropriate:**
+- Library choices, file structures, endpoints, schemas, or other implementation details that do not belong in a non-technical requirements document
 
 ## Step 6: Offer Next Action
 
@@ -85,3 +90,4 @@ Return control to the caller (workflow or user) after selection.
 - Do not add new sections or requirements the user didn't discuss
 - Do not over-engineer or add complexity
 - Do not create separate review files or add metadata sections
+

package/{commands/generate_command.md → skills/generate_command/SKILL.md}

@@ -7,7 +7,7 @@ disable-model-invocation: true
 
 # Create a Custom OpenCode Command
 
-Create a new slash command in `.opencode/commands/` for the requested task.
+Create a new skill in `.opencode/skills/` for the requested task.
 
 ## Goal
 
@@ -114,7 +114,7 @@ Implement #$ARGUMENTS following these steps:
 3. Implement
    - Follow existing code patterns (reference specific files)
    - Write tests first if doing TDD
-   - Ensure code follows AGENTS.md conventions
+   - Ensure code follows CLAUDE.md conventions
 
 4. Verify
    - Run tests: `bin/rails test`
@@ -128,10 +128,10 @@ Implement #$ARGUMENTS following these steps:
 
 ## Creating the Command File
 
-1. **Create the file** at `.opencode/commands/[name].md` (subdirectories like `workflows/` supported)
+1. **Create the directory** at `.opencode/skills/[name]/SKILL.md`
 2. **Start with YAML frontmatter** (see section above)
-3. **Structure the command** using the template above
-4. **Test the command** by using it with appropriate arguments
+3. **Structure the skill** using the template above
+4. **Test the skill** by using it with appropriate arguments
 
 ## Command File Template
 

package/{commands/heal-skill.md → skills/heal-skill/SKILL.md}

@@ -145,3 +145,4 @@ Before completing:
 - Verify git commit created if option 1 was selected
 - Check no unintended files were modified
 </verification>
+

package/skills/lfg/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: lfg
+description: Full autonomous engineering workflow
+argument-hint: '[feature description]'
+disable-model-invocation: true
+---
+
+CRITICAL: You MUST execute every step below IN ORDER. Do NOT skip any required step. Do NOT jump ahead to coding or implementation. The plan phase (step 2, and step 3 when warranted) MUST be completed and verified BEFORE any work begins. Violating this order produces bad output.
+
+1. **Optional:** If the `ralph-wiggum` skill is available, run `/ralph-wiggum:ralph-loop "finish all slash commands" --completion-promise "DONE"`. If not available or it fails, skip and continue to step 2 immediately.
+
+2. `/systematic:ce-plan $ARGUMENTS`
+
+   GATE: STOP. Verify that the `ce:plan` workflow produced a plan file in `docs/plans/`. If no plan file was created, run `/systematic:ce-plan $ARGUMENTS` again. Do NOT proceed to step 3 until a written plan exists.
+
+3. **Conditionally** run `/systematic:deepen-plan`
+
+   Run the `deepen-plan` workflow only if the plan is `Standard` or `Deep`, touches a high-risk area (auth, security, payments, migrations, external APIs, significant rollout concerns), or still has obvious confidence gaps in decisions, sequencing, system-wide impact, risks, or verification.
+
+   GATE: STOP. If you ran the `deepen-plan` workflow, confirm the plan was deepened or explicitly judged sufficiently grounded. If you skipped it, briefly note why and proceed to step 4.
+
+4. `/systematic:ce-work`
+
+   GATE: STOP. Verify that implementation work was performed - files were created or modified beyond the plan. Do NOT proceed to step 5 if no code changes were made.
+
+5. `/systematic:ce-review`
+
+6. `/systematic:resolve_todo_parallel`
+
+7. `/systematic:test-browser`
+
+8. `/systematic:feature-video`
+
+9. Output `<promise>DONE</promise>` when video is in PR
+
+Start with step 2 now (or step 1 if ralph-wiggum is available). Remember: plan FIRST, then work. Never skip the plan.
+

package/{commands/report-bug.md → skills/report-bug/SKILL.md}

@@ -1,13 +1,13 @@
 ---
 name: report-bug
-description: Report a bug in the systematic plugin
+description: Report a bug in the compound-engineering plugin
 argument-hint: '[optional: brief description of the bug]'
 disable-model-invocation: true
 ---
 
-# Report a Systematic Plugin Bug
+# Report a Compounding Engineering Plugin Bug
 
-Report bugs encountered while using the systematic plugin. This command gathers structured information and creates a GitHub issue for the maintainer.
+Report bugs encountered while using the compound-engineering plugin. This command gathers structured information and creates a GitHub issue for the maintainer.
 
 ## Step 1: Gather Bug Information
 
@@ -42,10 +42,10 @@ Use the question tool to collect the following information:
 Automatically gather:
 ```bash
 # Get plugin version
-cat ~/.opencode/plugins/installed_plugins.json 2>/dev/null | grep -A5 "systematic" | head -10 || echo "Plugin info not found"
+cat ~/.config/opencode/plugins/installed_plugins.json 2>/dev/null | grep -A5 "compound-engineering" | head -10 || echo "Plugin info not found"
 
 # Get OpenCode version
-opencode --version 2>/dev/null || echo "OpenCode version unknown"
+claude --version 2>/dev/null || echo "Claude CLI version unknown"
 
 # Get OS info
 uname -a
@@ -64,7 +64,7 @@ Create a well-structured bug report with:
 ## Environment
 
 - **Plugin Version:** [from installed_plugins.json]
-- **OpenCode Version:** [from opencode --version]
+- **OpenCode Version:** [from claude --version]
 - **OS:** [from uname]
 
 ## What Happened
@@ -101,17 +101,17 @@ Use the GitHub CLI to create the issue:
 
 ```bash
 gh issue create \
-  --repo marcusrbrown/systematic \
-  --title "[systematic] Bug: [Brief description]" \
+  --repo EveryInc/compound-engineering-plugin \
+  --title "[compound-engineering] Bug: [Brief description]" \
   --body "[Formatted bug report from Step 3]" \
-  --label "bug,systematic"
+  --label "bug,compound-engineering"
 ```
 
 **Note:** If labels don't exist, create without labels:
 ```bash
 gh issue create \
-  --repo marcusrbrown/systematic \
-  --title "[systematic] Bug: [Brief description]" \
+  --repo EveryInc/compound-engineering-plugin \
+  --title "[compound-engineering] Bug: [Brief description]" \
   --body "[Formatted bug report]"
 ```
 
@@ -120,17 +120,17 @@ gh issue create \
 After the issue is created:
 1. Display the issue URL to the user
 2. Thank them for reporting the bug
-3. Let them know the maintainer will be notified
+3. Let them know the maintainer (Kieran Klaassen) will be notified
 
 ## Output Format
 
 ```
 ✅ Bug report submitted successfully!
 
-Issue: https://github.com/marcusrbrown/systematic/issues/[NUMBER]
-Title: [systematic] Bug: [description]
+Issue: https://github.com/EveryInc/compound-engineering-plugin/issues/[NUMBER]
+Title: [compound-engineering] Bug: [description]
 
-Thank you for helping improve the systematic plugin!
+Thank you for helping improve the compound-engineering plugin!
 The maintainer will review your report and respond as soon as possible.
 ```
 
@@ -149,3 +149,4 @@ This command does NOT collect:
 - File paths beyond basic OS info
 
 Only technical information about the bug is included in the report.
+

package/{commands/reproduce-bug.md → skills/reproduce-bug/SKILL.md}

@@ -13,8 +13,8 @@ Look at github issue #$ARGUMENTS and read the issue description and comments.
 
 Run the following agents in parallel to investigate the bug:
 
-1. Spawn explore agents to investigate logs and console output relevant to the issue.
-2. Spawn explore agents to investigate logs and console output relevant to the issue.
+1. task rails-console-explorer(issue_description)
+2. task appsignal-log-investigator(issue_description)
 
 Think about the places it could go wrong looking at the codebase. Look for logging output we can look for.
 
@@ -29,8 +29,8 @@ If the bug is UI-related or involves user flows, use Playwright to visually repr
 ### Step 1: Verify Server is Running
 
 ```
-mcp__playwright__browser_navigate({ url: "http://localhost:3000" })
-mcp__playwright__browser_snapshot({})
+mcp__plugin_compound-engineering_pw__browser_navigate({ url: "http://localhost:3000" })
+mcp__plugin_compound-engineering_pw__browser_snapshot({})
 ```
 
 If server not running, inform user to start `bin/dev`.
@@ -40,8 +40,8 @@ If server not running, inform user to start `bin/dev`.
 Based on the issue description, navigate to the relevant page:
 
 ```
-mcp__playwright__browser_navigate({ url: "http://localhost:3000/[affected_route]" })
-mcp__playwright__browser_snapshot({})
+mcp__plugin_compound-engineering_pw__browser_navigate({ url: "http://localhost:3000/[affected_route]" })
+mcp__plugin_compound-engineering_pw__browser_snapshot({})
 ```
 
 ### Step 3: Capture Screenshots
@@ -49,7 +49,7 @@ mcp__playwright__browser_snapshot({})
 Take screenshots at each step of reproducing the bug:
 
 ```
-mcp__playwright__browser_take_screenshot({ filename: "bug-[issue]-step-1.png" })
+mcp__plugin_compound-engineering_pw__browser_take_screenshot({ filename: "bug-[issue]-step-1.png" })
 ```
 
 ### Step 4: Follow User Flow
@@ -65,7 +65,7 @@ Reproduce the exact steps from the issue:
 
 3. **Check for console errors:**
    ```
-    mcp__playwright__browser_console_messages({ level: "error" })
+   mcp__plugin_compound-engineering_pw__browser_console_messages({ level: "error" })
    ```
 
 ### Step 5: Capture Bug State
@@ -77,7 +77,7 @@ When you reproduce the bug:
 3. Document the exact steps that triggered it
 
 ```
-mcp__playwright__browser_take_screenshot({ filename: "bug-[issue]-reproduced.png" })
+mcp__plugin_compound-engineering_pw__browser_take_screenshot({ filename: "bug-[issue]-reproduced.png" })
 ```
 
 ## Phase 3: Document Findings
@@ -98,3 +98,4 @@ Add a comment to the issue with:
 3. **Screenshots** - Visual evidence of the bug (upload captured screenshots)
 4. **Relevant Code** - File paths and line numbers
 5. **Suggested Fix** - If you have one
+

package/{commands/resolve_todo_parallel.md → skills/resolve_todo_parallel/SKILL.md}

@@ -12,7 +12,7 @@ Resolve all TODO comments using parallel processing.
 
 Get all unresolved TODOs from the /todos/\*.md directory
 
-If any todo recommends deleting, removing, or gitignoring files in `docs/plans/` or `docs/solutions/`, skip it and mark it as `wont_fix`. These are systematic pipeline artifacts that are intentional and permanent.
+If any todo recommends deleting, removing, or gitignoring files in `docs/brainstorms/`, `docs/plans/`, or `docs/solutions/`, skip it and mark it as `wont_fix`. These are compound-engineering pipeline artifacts that are intentional and permanent.
 
 ### 2. Plan
 
@@ -35,3 +35,4 @@ Always run all in parallel subagents/Tasks for each Todo item.
 - Commit changes
 - Remove the TODO from the file, and mark it as resolved.
 - Push to remote
+

package/{commands/slfg.md → skills/slfg/SKILL.md}

@@ -10,15 +10,18 @@ Swarm-enabled LFG. Run these steps in order, parallelizing where indicated. Do n
 ## Sequential Phase
 
 1. **Optional:** If the `ralph-wiggum` skill is available, run `/ralph-wiggum:ralph-loop "finish all slash commands" --completion-promise "DONE"`. If not available or it fails, skip and continue to step 2 immediately.
-2. `/workflows:plan $ARGUMENTS`
-3. `/systematic:deepen-plan`
-4. `/workflows:work` — **Use swarm mode**: Make a Task list and launch an army of agent swarm subagents to build the plan
+2. `/systematic:ce-plan $ARGUMENTS`
+3. **Conditionally** run `/systematic:deepen-plan`
+   - Run the `deepen-plan` workflow only if the plan is `Standard` or `Deep`, touches a high-risk area (auth, security, payments, migrations, external APIs, significant rollout concerns), or still has obvious confidence gaps in decisions, sequencing, system-wide impact, risks, or verification
+   - If you run the `deepen-plan` workflow, confirm the plan was deepened or explicitly judged sufficiently grounded before moving on
+   - If you skip it, note why and continue to step 4
+4. `/systematic:ce-work` — **Use swarm mode**: Make a Task list and launch an army of agent swarm subagents to build the plan
 
 ## Parallel Phase
 
 After work completes, launch steps 5 and 6 as **parallel swarm agents** (both only need code to be written):
 
-5. `/workflows:review` — spawn as background Task agent
+5. `/systematic:ce-review` — spawn as background Task agent
 6. `/systematic:test-browser` — spawn as background Task agent
 
 Wait for both to complete before continuing.
@@ -30,3 +33,4 @@ Wait for both to complete before continuing.
 9. Output `<promise>DONE</promise>` when video is in PR
 
 Start with step 1 now.
+

package/{commands/test-browser.md → skills/test-browser/SKILL.md}

@@ -1,7 +1,7 @@
 ---
 name: test-browser
 description: Run browser tests on pages affected by current PR or branch
-argument-hint: '[PR number, branch name, or ''current'' for current branch]'
+argument-hint: '[PR number, branch name, ''current'', or --port PORT]'
 ---
 
 # Browser Test Command
@@ -122,31 +122,82 @@ Build a list of URLs to test based on the mapping.
 
 </file_to_route_mapping>
 
-### 4. Verify Server is Running
+### 4. Detect Dev Server Port
+
+<detect_port>
+
+Determine the dev server port using this priority order:
+
+**Priority 1: Explicit argument**
+If the user passed a port number (e.g., `/test-browser 5000` or `/test-browser --port 5000`), use that port directly.
+
+**Priority 2: AGENTS.md / project instructions**
+```bash
+# Check CLAUDE.md for port references
+grep -Eio '(port\s*[:=]\s*|localhost:)([0-9]{4,5})' CLAUDE.md 2>/dev/null | grep -Eo '[0-9]{4,5}' | head -1
+```
+
+**Priority 3: package.json scripts**
+```bash
+# Check dev/start scripts for --port flags
+grep -Eo '\-\-port[= ]+[0-9]{4,5}' package.json 2>/dev/null | grep -Eo '[0-9]{4,5}' | head -1
+```
+
+**Priority 4: Environment files**
+```bash
+# Check .env, .env.local, .env.development for PORT=
+grep -h '^PORT=' .env .env.local .env.development 2>/dev/null | tail -1 | cut -d= -f2
+```
+
+**Priority 5: Default fallback**
+If none of the above yields a port, default to `3000`.
+
+Store the result in a `PORT` variable for use in all subsequent steps.
+
+```bash
+# Combined detection (run this)
+PORT="${EXPLICIT_PORT:-}"
+if [ -z "$PORT" ]; then
+  PORT=$(grep -Eio '(port\s*[:=]\s*|localhost:)([0-9]{4,5})' CLAUDE.md 2>/dev/null | grep -Eo '[0-9]{4,5}' | head -1)
+fi
+if [ -z "$PORT" ]; then
+  PORT=$(grep -Eo '\-\-port[= ]+[0-9]{4,5}' package.json 2>/dev/null | grep -Eo '[0-9]{4,5}' | head -1)
+fi
+if [ -z "$PORT" ]; then
+  PORT=$(grep -h '^PORT=' .env .env.local .env.development 2>/dev/null | tail -1 | cut -d= -f2)
+fi
+PORT="${PORT:-3000}"
+echo "Using dev server port: $PORT"
+```
+
+</detect_port>
+
+### 5. Verify Server is Running
 
 <check_server>
 
-Before testing, verify the local server is accessible:
+Before testing, verify the local server is accessible using the detected port:
 
 ```bash
-agent-browser open http://localhost:3000
+agent-browser open http://localhost:${PORT}
 agent-browser snapshot -i
 ```
 
 If server is not running, inform user:
 ```markdown
-**Server not running**
+**Server not running on port ${PORT}**
 
 Please start your development server:
 - Rails: `bin/dev` or `rails server`
 - Node/Next.js: `npm run dev`
+- Custom port: `/test-browser --port <your-port>`
 
 Then run `/test-browser` again.
 ```
 
 </check_server>
 
-### 5. Test Each Affected Page
+### 6. Test Each Affected Page
 
 <test_pages>
 
@@ -154,13 +205,13 @@ For each affected route, use agent-browser CLI commands (NOT Chrome MCP):
 
 **Step 1: Navigate and capture snapshot**
 ```bash
-agent-browser open "http://localhost:3000/[route]"
+agent-browser open "http://localhost:${PORT}/[route]"
 agent-browser snapshot -i
 ```
 
 **Step 2: For headed mode (visual debugging)**
 ```bash
-agent-browser --headed open "http://localhost:3000/[route]"
+agent-browser --headed open "http://localhost:${PORT}/[route]"
 agent-browser --headed snapshot -i
 ```
 
@@ -185,7 +236,7 @@ agent-browser screenshot --full page-name-full.png  # Full page
 
 </test_pages>
 
-### 6. Human Verification (When Required)
+### 7. Human Verification (When Required)
 
 <human_verification>
 
@@ -214,7 +265,7 @@ Did it work correctly?
 
 </human_verification>
 
-### 7. Handle Failures
+### 8. Handle Failures
 
 <failure_handling>
 
@@ -253,7 +304,7 @@ When a test fails:
 
 </failure_handling>
 
-### 8. Test Summary
+### 9. Test Summary
 
 <test_summary>
 
@@ -263,7 +314,7 @@ After all tests complete, present summary:
 ## Browser Test Results
 
 **Test Scope:** PR #[number] / [branch name]
-**Server:** http://localhost:3000
+**Server:** http://localhost:${PORT}
 
 ### Pages Tested: [count]
 
@@ -295,7 +346,7 @@ After all tests complete, present summary:
 ## Quick Usage Examples
 
 ```bash
-# Test current branch changes
+# Test current branch changes (auto-detects port)
 /test-browser
 
 # Test specific PR
@@ -303,6 +354,9 @@ After all tests complete, present summary:
 
 # Test specific branch
 /test-browser feature/new-dashboard
+
+# Test on a specific port
+/test-browser --port 5000
 ```
 
 ## agent-browser CLI Reference

package/{commands/test-xcode.md → skills/test-xcode/SKILL.md}

@@ -323,10 +323,11 @@ mcp__xcodebuildmcp__shutdown_simulator({ simulator_id: "[uuid]" })
 /xcode-test current
 ```
 
-## Integration with /workflows:review
+## Integration with /systematic:ce-review
 
-When reviewing PRs that touch iOS code, the `/workflows:review` command can spawn this as a subagent:
+When reviewing PRs that touch iOS code, the `/systematic:ce-review` command can spawn this as a subagent:
 
 ```
-task general-purpose("Run /xcode-test for scheme [name]. Build, install on simulator, test key screens, check for crashes.")
+Task general-purpose("Run /xcode-test for scheme [name]. Build, install on simulator, test key screens, check for crashes.")
 ```
+

package/{commands/triage.md → skills/triage/SKILL.md}

@@ -132,7 +132,7 @@ Do you want to add this to the todo list?
    ## Work Log
 
    ### {date} - Approved for Work
-   **By:** Systematic Triage System
+   **By:** Claude Triage System
    **Actions:**
    - Issue approved during triage session
    - Status changed from pending → ready
@@ -309,3 +309,4 @@ What would you like to do next?
 2. commit the todos
 3. nothing, go chill
 ```
+

package/skills/workflows-brainstorm/SKILL.md

@@ -0,0 +1,11 @@
+---
+name: workflows:brainstorm
+description: '[DEPRECATED] Use /ce:brainstorm instead — renamed for clarity.'
+argument-hint: '[feature idea or problem to explore]'
+disable-model-invocation: true
+---
+
+NOTE: /workflows:brainstorm is deprecated. Please use /ce:brainstorm instead. This alias will be removed in a future version.
+
+/ce:brainstorm $ARGUMENTS
+

package/{commands/workflows/compound.md → skills/workflows-compound/SKILL.md}

@@ -1,7 +1,7 @@
 ---
 name: workflows:compound
-description: "[DEPRECATED] Use /ce:compound instead — renamed for clarity."
-argument-hint: "[optional: brief context about the fix]"
+description: '[DEPRECATED] Use /ce:compound instead — renamed for clarity.'
+argument-hint: '[optional: brief context about the fix]'
 disable-model-invocation: true
 ---
 

package/{commands/workflows/plan.md → skills/workflows-plan/SKILL.md}

@@ -1,7 +1,7 @@
 ---
 name: workflows:plan
-description: "[DEPRECATED] Use /ce:plan instead — renamed for clarity."
-argument-hint: "[feature description, bug report, or improvement idea]"
+description: '[DEPRECATED] Use /ce:plan instead — renamed for clarity.'
+argument-hint: '[feature description, bug report, or improvement idea]'
 disable-model-invocation: true
 ---
 

package/{commands/workflows/review.md → skills/workflows-review/SKILL.md}

@@ -1,7 +1,7 @@
 ---
 name: workflows:review
-description: "[DEPRECATED] Use /ce:review instead — renamed for clarity."
-argument-hint: "[PR number, GitHub URL, branch name, or latest]"
+description: '[DEPRECATED] Use /ce:review instead — renamed for clarity.'
+argument-hint: '[PR number, GitHub URL, branch name, or latest]'
 disable-model-invocation: true
 ---
 

package/{commands/workflows/work.md → skills/workflows-work/SKILL.md}

@@ -1,7 +1,7 @@
 ---
 name: workflows:work
-description: "[DEPRECATED] Use /ce:work instead — renamed for clarity."
-argument-hint: "[plan file, specification, or todo file path]"
+description: '[DEPRECATED] Use /ce:work instead — renamed for clarity.'
+argument-hint: '[plan file, specification, or todo file path]'
 disable-model-invocation: true
 ---
 

package/agents/workflow/every-style-editor.md

@@ -1,66 +0,0 @@
----
-name: every-style-editor
-description: Reviews and edits text content to conform to Every's editorial style guide. Use when written content needs style compliance checks for headlines, punctuation, voice, and formatting.
-tools: Task, Glob, Grep, LS, ExitPlanMode, Read, Edit, MultiEdit, Write, NotebookRead, NotebookEdit, WebFetch, TodoWrite, WebSearch
-mode: subagent
-temperature: 0.1
----
-
-You are an expert copy editor specializing in Every's house style guide. Your role is to meticulously review text content and suggest edits to ensure compliance with Every's specific editorial standards.
-
-When reviewing content, you will:
-
-1. **Systematically check each style rule** - Go through the style guide items one by one, checking the text against each rule
-2. **Provide specific edit suggestions** - For each issue found, quote the problematic text and provide the corrected version
-3. **Explain the rule being applied** - Reference which style guide rule necessitates each change
-4. **Maintain the author's voice** - Make only the changes necessary for style compliance while preserving the original tone and meaning
-
-**Every Style Guide Rules to Apply:**
-
-- Headlines use title case; everything else uses sentence case
-- Companies are singular ("it" not "they"); teams/people within companies are plural
-- Remove unnecessary "actually," "very," or "just"
-- Hyperlink 2-4 words when linking to sources
-- Cut adverbs where possible
-- Use active voice instead of passive voice
-- Spell out numbers one through nine (except years at sentence start); use numerals for 10+
-- Use italics for emphasis (never bold or underline)
-- Image credits: _Source: X/Name_ or _Source: Website name_
-- Don't capitalize job titles
-- Capitalize after colons only if introducing independent clauses
-- Use Oxford commas (x, y, and z)
-- Use commas between independent clauses only
-- No space after ellipsis...
-- Em dashes—like this—with no spaces (max 2 per paragraph)
-- Hyphenate compound adjectives except with adverbs ending in "ly"
-- Italicize titles of books, newspapers, movies, TV shows, games
-- Full names on first mention, last names thereafter (first names in newsletters/social)
-- Percentages: "7 percent" (numeral + spelled out)
-- Numbers over 999 take commas: 1,000
-- Punctuation outside parentheses (unless full sentence inside)
-- Periods and commas inside quotation marks
-- Single quotes for quotes within quotes
-- Comma before quote if introduced; no comma if text leads directly into quote
-- Use "earlier/later/previously" instead of "above/below"
-- Use "more/less/fewer" instead of "over/under" for quantities
-- Avoid slashes; use hyphens when needed
-- Don't start sentences with "This" without clear antecedent
-- Avoid starting with "We have" or "We get"
-- Avoid clichés and jargon
-- "Two times faster" not "2x" (except for the common "10x" trope)
-- Use "$1 billion" not "one billion dollars"
-- Identify people by company/title (except well-known figures like Mark Zuckerberg)
-- Button text is always sentence case -- "Complete setup"
-
-**Output Format:**
-
-Provide your review as a numbered list of suggested edits, grouping related changes when logical. For each edit:
-
-- Quote the original text
-- Provide the corrected version
-- Briefly explain which style rule applies
-
-If the text is already compliant with the style guide, acknowledge this and highlight any particularly well-executed style choices.
-
-Be thorough but constructive, focusing on helping the content shine while maintaining Every's professional standards.
-