polyforgeai - npm Package Compare versions

Comparing version 0.1.10 to 0.2.0

skills/diagnose/SKILL.md

+---
+name: diagnose
+description: Use when the user asks to investigate, diagnose, analyze, or understand a specific problem — an exception, error, unexpected behavior, log entry, or stack trace. Determines root cause, severity, and whether it's a real bug or expected behavior.
+---
+
+# /diagnose — Problem Investigation
+
+You are PolyForge's diagnostician. Given a specific problem (exception, error, unexpected behavior), you investigate the root cause and determine if it's a real bug, expected behavior, or a configuration issue.
+
+## Usage
+
+```
+/diagnose "NullPointerException in UserService"
+/diagnose                                         Interactive — paste error/describe problem
+/diagnose --file src/services/auth.go:142         Investigate a specific code location
+```
+
+## Process
+
+### Step 1: Understand the Problem
+
+**If a description or error is provided:** Parse it for clues — exception type, file, line, stack trace, context.
+
+**If no arguments:** Ask:
+1. What's the problem? (paste error, describe behavior, or point to a file)
+
+### Step 2: Gather Context
+
+1. Read `CLAUDE.md` and `.claude/polyforge.json` for project context
+2. Find the relevant source code — follow the stack trace or search by error message
+3. Read the file(s) involved + surrounding context (callers, dependencies)
+4. Check git blame — was this recently changed?
+5. Search for related tests — do they cover this case?
+6. Check if there are existing issues about this (`gh issue list -S "{keywords}"` or `jira issue list -q"text ~ '{keywords}'"`)
+
+### Step 3: Analyze
+
+Investigate systematically:
+
+- **What triggers the problem?** — trace the execution path
+- **Is it reproducible?** — check if tests exist or can be written
+- **When was it introduced?** — `git log -p --follow {file}` for recent changes
+- **Is it expected behavior?** — check business rules, docs, comments
+- **What's the blast radius?** — how many users/flows does it affect?
+
+### Step 4: Present Diagnosis
+
+```
+## Diagnosis: {short title}
+
+**Verdict:** 🐛 Bug | ⚙️ Expected behavior | 🔧 Configuration issue | ⚠️ Edge case
+
+**Root cause:**
+{1-3 sentences explaining what's happening and why}
+
+**Evidence:**
+- `{file}:{line}` — {what the code does}
+- `{file}:{line}` — {what should happen vs what happens}
+
+**Severity:** {critical | high | medium | low}
+{justification}
+
+**Affected paths:**
+- {user flow or API endpoint affected}
+
+**Suggested fix:**
+{concrete, actionable fix — not vague}
+```
+
+### Step 5: Next Actions
+
+Present numbered options:
+
+1. Create an issue from this diagnosis → triggers `/report-issue` with pre-filled context
+2. Fix it now → triggers `/fix` with the diagnosis as context
+3. Write a test to reproduce it first
+4. Not a bug — close investigation
+5. Need more info — investigate deeper
+
+## Context Management
+
+- Delegate codebase search to a subagent if the problem spans multiple modules
+- Keep the diagnosis concise — the verdict + evidence is the deliverable
+- After presenting the diagnosis, compact the conversation
+
+## Important Behaviors
+
+- Never assume — verify every hypothesis against actual code
+- Check both the code AND the tests — a passing test doesn't mean no bug
+- Consider edge cases: null/empty inputs, race conditions, timezone issues, encoding
+- If the error is from a dependency, check the version and known issues
+- Don't jump to fixing — diagnose first, confirm with user, then fix
+- If the problem is ambiguous, present multiple hypotheses ranked by likelihood

package.json

 {
   "name": "polyforgeai",
-  "version": "0.1.10",
+  "version": "0.2.0",
   "description": "Self-adaptive Claude Code plugin for automated software development workflows",
@@ -5,0 +5,0 @@ "bin": {

README.md

@@ -39,2 +39,3 @@ [![npm version](https://img.shields.io/npm/v/polyforgeai.svg)](https://www.npmjs.com/package/polyforgeai)
 | `/analyse-code` | Full codebase analysis — patterns, security, performance, config issues |
+| `/diagnose` | Investigate a specific error or behavior — determine root cause and if it's a real bug |
 | `/report-issue` | Detect and create issues on GitHub/Jira/GitLab |
@@ -41,0 +42,0 @@ | `/feature #N` | Build a feature from an issue — plan, implement, test, PR |

rules/golden-principles.md

@@ -16,9 +16,10 @@ # PolyForge Golden Principles
 8. Commits are atomic — one logical change per commit
-9. Commit messages never include `Co-Authored-By` — PolyForge branding goes in PR descriptions only (`⚒ Forged with PolyForge`)
-10. Documentation stays in sync with code changes
-11. Flag breaking changes explicitly with migration steps
+9. Commit messages never include `Co-Authored-By` — PolyForge branding goes in PR/issue descriptions only
+10. PolyForge branding adapts to the platform: GitHub/GitLab (markdown) → `*⚒ Forged with [PolyForge](https://github.com/Vekta/polyforge)*` · Jira → no branding (keep tickets clean for the team)
+11. Documentation stays in sync with code changes
+12. Flag breaking changes explicitly with migration steps
 
 ## Resilience
-12. Retry a failing approach at most 3 times — then try a different angle or ask for help
-13. Same error with same fix twice means the approach is wrong — switch strategy
-14. Scope investigations to specific files or directories — avoid reading the entire codebase
+13. Retry a failing approach at most 3 times — then try a different angle or ask for help
+14. Same error with same fix twice means the approach is wrong — switch strategy
+15. Scope investigations to specific files or directories — avoid reading the entire codebase

skills/brainstorm/SKILL.md

@@ -51,3 +51,3 @@ ---
 # Brainstorm: {title}
-> Date: {date}
+> ⚒ Forged with [PolyForge](https://github.com/Vekta/polyforge) on {date}
 > Context: {1-2 sentence summary of the discussion}
@@ -54,0 +54,0 @@

skills/feature/SKILL.md

@@ -122,3 +122,7 @@ ---
 - After 2 failed attempts, compact context before the 3rd try
-- If still failing after 3 total attempts, show the error and ask for guidance — do not loop further
+- If still failing after 3 total attempts, categorize each remaining failure:
+  - 🟢 **Quick fix** → fix it now
+  - 🟡 **Needs investigation** → create an issue via `/report-issue`
+  - 🔴 **Pre-existing / infra** → create an issue via `/report-issue` tagged as infra
+- Never ignore remaining failures — every one gets a fix or an issue
 
@@ -189,2 +193,12 @@ ### Step 6: Clean Up Commits
 
+### Step 9: Wait for CI and Act on Results
+
+```bash
+gh pr checks --watch
+```
+
+If CI passes → done, report success.
+
+If CI fails → run `/fix-ci` automatically to diagnose and fix. Do not leave the PR with a failing CI.
+
 ## Context Management
@@ -191,0 +205,0 @@

skills/fix-ci/SKILL.md

@@ -125,5 +125,12 @@ ---
 
-### Remaining Issues (if any)
-- {what still fails and why it needs human intervention}
+### Remaining Failures
 
+For EACH remaining failure, categorize and propose an action:
+
+| Failure | Category | Proposed Action |
+|---------|----------|-----------------|
+| {test/check name} | 🟢 Quick fix | {concrete fix — do it now} |
+| {test/check name} | 🟡 Needs investigation | {what to investigate — create issue with `/report-issue`} |
+| {test/check name} | 🔴 Infrastructure/config | {what's missing — create issue assigned to team/ops} |
+
 ---
@@ -133,2 +140,15 @@ *⚒ Forged with [PolyForge](https://github.com/Vekta/polyforge)*
 
+After presenting the report, ask for each category:
+
+**🟢 Quick fixes found:** "I can fix {N} failures right now. Proceed?"
+- If yes → fix them, re-run pipeline
+
+**🟡 Needs investigation:** "Create `/diagnose` issues for these {N} failures?"
+- If yes → create issues via `/report-issue` with the failure context pre-filled
+
+**🔴 Infrastructure/config:** "Create issues for these {N} infra problems?"
+- If yes → create issues via `/report-issue` tagged as infra/config
+
+**Never leave failures unaddressed.** Every remaining failure must result in either a fix or an issue.
+
 ## Context Management
@@ -135,0 +155,0 @@

skills/fix/SKILL.md

@@ -100,3 +100,7 @@ ---
 - After 2 failed attempts, compact context before the 3rd try
-- If still failing after 3 total attempts, show the error and ask for guidance — do not loop further
+- If still failing after 3 total attempts, categorize each remaining failure:
+  - 🟢 **Quick fix** → fix it now
+  - 🟡 **Needs investigation** → create an issue via `/report-issue`
+  - 🔴 **Pre-existing / infra** → create an issue via `/report-issue` tagged as infra
+- Never ignore remaining failures — every one gets a fix or an issue
 
@@ -154,3 +158,3 @@ ### Step 6: Clean Up Commits
 
-### Step 7: Update Issue
+### Step 8: Update Issue
 
@@ -169,2 +173,12 @@ **GitHub:**
 
+### Step 9: Wait for CI and Act on Results
+
+```bash
+gh pr checks --watch
+```
+
+If CI passes → done, report success.
+
+If CI fails → run `/fix-ci` automatically to diagnose and fix. Do not leave the PR with a failing CI.
+
 ## Context Management
@@ -171,0 +185,0 @@

skills/generate-doc/SKILL.md

@@ -54,3 +54,3 @@ ---
 Config: `.claude/polyforge.json`
-Commands: /forge, /pr-review, /analyse-db, /analyse-code, /report-issue, /fix, /fix-ci, /brainstorm, /generate-doc
+Commands: /forge, /pr-review, /analyse-db, /analyse-code, /diagnose, /report-issue, /feature, /fix, /fix-ci, /brainstorm, /generate-doc, /squash, /add-rule
 ```
@@ -57,0 +57,0 @@

skills/init/SKILL.md

@@ -53,2 +53,10 @@ ---
 - Look for Linear: `.linear` config
+- Detect issue title prefix from recent issues:
+  ```bash
+  # GitHub
+  gh issue list --limit 10 --json title --jq '.[].title' | grep -oP '^\[.*?\]' | sort | uniq -c | sort -rn | head -1
+  # Jira
+  jira issue list --plain --columns summary -q"ORDER BY created DESC" 2>/dev/null | head -10 | grep -oP '^\[.*?\]' | sort | uniq -c | sort -rn | head -1
+  ```
+  If a consistent prefix is found (e.g., `[pnp-api]`), store as `issueTracker.config.titlePrefix` in `polyforge.json`
 
@@ -152,3 +160,3 @@ ### Git Workflow
 - PolyForge commands (use these exact names):
-  `/forge`, `/pr-review`, `/analyse-db`, `/analyse-code`, `/report-issue`, `/feature`, `/fix`, `/fix-ci`, `/brainstorm`, `/generate-doc`, `/squash`, `/add-rule`
+  `/forge`, `/pr-review`, `/analyse-db`, `/analyse-code`, `/diagnose`, `/report-issue`, `/feature`, `/fix`, `/fix-ci`, `/brainstorm`, `/generate-doc`, `/squash`, `/add-rule`
 
@@ -171,3 +179,3 @@ If a `CLAUDE.md` already exists:
 - End the summary with: "**Restart Claude Code** to load the new configuration (settings, rules, and permissions take effect on session start)."
-- When listing available commands, use the exact slash command names: `/forge`, `/pr-review`, `/analyse-db`, `/analyse-code`, `/report-issue`, `/feature`, `/fix`, `/fix-ci`, `/brainstorm`, `/generate-doc`, `/squash`, `/add-rule` — never prefix with `polyforge-`
+- When listing available commands, use the exact slash command names: `/forge`, `/pr-review`, `/analyse-db`, `/analyse-code`, `/diagnose`, `/report-issue`, `/feature`, `/fix`, `/fix-ci`, `/brainstorm`, `/generate-doc`, `/squash`, `/add-rule` — never prefix with `polyforge-`
 - Do not keep raw scan data in context — extract what's needed and discard
@@ -174,0 +182,0 @@

skills/report-issue/SKILL.md

@@ -94,4 +94,8 @@ ---
 ```bash
+# Check for title prefix in polyforge.json → issueTracker.config.titlePrefix
+# If set (e.g., "[pnp-api]"), prepend to title: "[pnp-api] {title}"
+# If not set, use title as-is
+
 gh issue create \
-  --title "{title}" \
+  --title "{prefix} {title}" \
   --body "{body from template}" \
@@ -104,8 +108,13 @@ --label "{severity},{type}" \
 ```bash
+# Get current user for auto-assignment
+JIRA_USER=$(jira me --raw | jq -r '.displayName // .emailAddress')
+
+# Check for title prefix in polyforge.json → issueTracker.config.titlePrefix
 jira issue create \
   --type "{Bug|Task|Story}" \
-  --summary "{title}" \
+  --summary "{prefix} {title}" \
   --body "{body}" \
   --priority "{priority}" \
-  --label "{labels}"
+  --label "{labels}" \
+  --assignee "$JIRA_USER"
 ```
@@ -112,0 +121,0 @@

No alert changes

Improved metrics

Total package byte prevSize

96005

7.52%

Number of package files

24

4.35%

Number of lines in readme file

157

0.64%

No dependency changes