swe-workflow-skills 0.11.5 → 0.11.6

package/VERSION

@@ -1 +1 @@
-0.11.5
+0.11.6

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "swe-workflow-skills",
-  "version": "0.11.5",
+  "version": "0.11.6",
   "description": "A curated library of Claude Code Agent Skills covering the full software lifecycle, with orchestrator-routed activation that scales past the skill-listing budget.",
   "type": "module",
   "bin": {

package/skills/dependency-impact-analysis/SKILL.md

@@ -116,6 +116,8 @@ For each breaking change, define the coordination plan:
 - What is the migration deadline?
 - Is there a deprecation period?
 
+**Exit condition:** the dependents with their Step 3 classification, and the propagation plan, written in your reply before any design question or code. This is not a gate on delivering: when a design choice is open, give the map under your recommended option and put the question beside it. A choice dialog shows only its own text, so a question asked instead of the map hides it.
+
 ## Principles Applied
 
 - **Functional independence**: Minimize blast radius — prefer additive changes over breaking changes when both achieve the same goal

package/skills/dependency-impact-analysis/evals/evals.json

@@ -4,13 +4,13 @@
     {
       "id": 1,
       "prompt": "I want to rename the 'user_id' field to 'account_id' in our REST API response for GET /api/users. We have a mobile app, a web app, and two internal microservices that call this endpoint. What's the impact?",
-      "expected_output": "Dependency impact analysis identifying all four consumers, classifying the rename as breaking for all of them, recommending a versioning strategy, and producing a migration plan with coordination steps",
+      "expected_output": "Dependency impact analysis identifying all four consumers, classifying the rename as breaking for all of them, recommending a transition that keeps user_id working for old mobile app versions (expand-contract dual fields or a versioned endpoint), and producing a migration plan with coordination steps",
       "assertions": [
         "Identifies all four consumers (mobile app, web app, two microservices) as affected",
         "Classifies this as a breaking change for all consumers (field rename, not additive)",
         "Flags mobile app as highest risk (users may not update; old app versions still call the API)",
-        "Recommends API versioning (v1 keeps user_id, v2 uses account_id) for the mobile app case",
-        "Produces a migration sequence: add v2, migrate internal consumers, migrate web, sunset v1 after mobile migration window",
+        "Recommends a transition that keeps user_id working for old mobile app versions while account_id is introduced: both fields in the response (expand-contract) or a versioned endpoint (v1 keeps user_id, v2 uses account_id)",
+        "Produces a migration sequence: introduce account_id alongside user_id (or a v2), migrate the internal consumers and the web app, and remove user_id (or sunset v1) only after the mobile migration window",
         "Does not suggest a simultaneous big-bang rename as the only option"
       ]
     },
@@ -23,7 +23,7 @@
         "Notes that existing code ignores the new column and remains safe",
         "Flags that code selecting whole rows — ORM models, serializers — will start returning the new column",
         "Does not require complex coordination or versioning",
-        "Gives a clear 'safe to proceed' verdict with any minor caveats"
+        "Leads with a verdict, either safe to deploy or safe once named checks pass (such as positional SELECT * mapping or DTOs that reject unknown fields), rather than declining to answer without more information"
       ]
     },
     {

package/skills/dependency-management/SKILL.md

@@ -37,7 +37,11 @@ Then give each row a verdict:
 
 **Security-critical code:** never write your own cryptographic primitives. Thin protocol code over a crypto library you already ship can be owned, for example TOTP, a request signer, or a WebAuthn check that only accepts `none` attestation. Own it only when the user chooses to (ask), with a test per spec step, and with differential tests against the library kept as a dev-only dependency.
 
-**Exit condition:** the table with a verdict per row, in the same response. Steps 2–4 apply only to rows marked Adopt.
+**Exit condition:** the table with a verdict per row, written in your reply, in the same response. Steps 2–4 apply only to rows marked Adopt.
+
+- **The table goes in the message, not in a question.** A choice dialog shows only its own text, so a question whose option labels carry the comparison hides the table. Write the table and your recommendation first; the question that follows only names the options.
+- **A registry page fills no row.** The package existing, its licence and its last release are Steps 2–3. A verdict reached from them has skipped this step.
+- **Size the own module with the hard part in it.** If our version would have to rebuild what makes the library worth having (its typing, its protocol or OAuth flow, its parser), count that part, or the own module looks smaller than it is.
 
 ### Step 2: Verify the Package Exists (anti-slopsquatting)
 

package/skills/dependency-management/evals/evals.json

@@ -77,6 +77,20 @@
         "Delivers the implementation plan in the same response rather than stopping at the question",
         "If the verifier is owned, tests each verification step of the spec and cross-checks it against the library kept as a dev-only dependency"
       ]
+    },
+    {
+      "id": 3,
+      "prompt": "We're adding a small MCP server in Python 3.12 in front of our existing REST API, so Claude's scheduled tasks can call five tools over Streamable HTTP. People sign in with Google Workspace accounts limited to our domain, and Claude's connectors need OAuth with refresh tokens so unattended runs keep working. I'm leaning towards FastMCP; the other option is the official `mcp` SDK plus our own OAuth authorization server. FastMCP is on PyPI, Apache-2.0, and had a release last week, so it's probably fine. Check it before we add it.",
+      "pressure": [
+        "authority"
+      ],
+      "expected_behavior": "Runs Step 1 rather than stopping at the facts the user offered: compares FastMCP with the official SDK plus an own OAuth server on what each covers, what FastMCP pulls in, and how big and how risky the own side is. The own side is mostly an OAuth authorization server delegating to Google, which is security-critical. The comparison and the recommendation are written out in the reply, not compressed into a one-line verdict or a bare question.",
+      "assertions": [
+        "Compares FastMCP with the official `mcp` SDK plus an own OAuth server on what each covers here (the MCP transport, the OAuth flow delegating to Google, refresh tokens, token storage), rather than concluding from the PyPI listing, licence and release date",
+        "Gives a rough size for the own-module side and says its bulk is the OAuth authorization server, which is security-critical code",
+        "Says what FastMCP pulls in (transitive packages, install size or maintainer groups), or says it must be checked",
+        "Writes the comparison out in the reply with a recommendation, its primary reason and the risks accepted, rather than a one-line verdict or only a question"
+      ]
     }
   ]
 }

package/skills/feature-planning/SKILL.md

@@ -67,7 +67,7 @@ Decompose the feature into implementation tasks. Each task should:
 
 Use this structure for each task — see [templates/task.md](templates/task.md).
 
-When a task adds a library, run `dependency-management`'s Step 1 on it before writing the task, and put the verdict in the plan's **New dependencies** section: own module, adopt, or a question for the user. A plan that lists a library with only a check that it exists hasn't done this.
+When a task adds a library, run `dependency-management`'s Step 1 on it before writing the task, including a library an RFC, ADR or issue already names, and put the verdict in the plan's **New dependencies** section: own module, adopt, or a question for the user. A plan that lists a library with only a check that it exists hasn't done this, and neither has one that schedules the check as a later task.
 
 ### Step 4: Map Dependencies
 

package/skills/skill-router/SKILL.md

@@ -53,7 +53,10 @@ performance…) are exactly what the skills are for. When in doubt, route.
 **Naming a new library is a routing point**, even mid-plan or mid-build and even
 when nobody asked about dependencies. Invoke `dependency-management` before the
 library goes into a plan, an ADR, or an install command. Its first question is
-whether you need the library at all.
+whether you need the library at all. A library an RFC, ADR, issue or earlier plan
+already names is a candidate, not a decision. Writing "run
+`dependency-management`" as a later step of the plan doesn't count: the plan
+names the library only after the check has run.
 
 Skip **only** for genuinely trivial, conversational, or information-lookup
 requests where no workflow adds value, or when the user tells you not to use a