Create force-multiplier delivery skill#153
Conversation
Plugin Validation Summary —
|
| Check | Result |
|---|---|
plugin.json manifest (name, semver 2.1.0, required fields) |
✅ Valid |
Version consistency across plugin.json / marketplace.json / CHANGELOG.md |
✅ All 2.1.0 |
CHANGELOG entry for 2.1.0 (Keep a Changelog format) |
✅ Present (CHANGELOG.md:8) |
Directory structure / auto-discovery (skills/force-multiplier/SKILL.md) |
✅ Compliant |
Progressive-disclosure layout (references/, examples/, evals/) |
✅ Compliant |
| All files referenced from SKILL.md exist | ✅ All 8 resolve |
| README.md present and lists the new skill | ✅ Present |
No unnecessary files (.DS_Store, node_modules, etc.) |
✅ Clean |
| Hardcoded credentials | ✅ None found |
Note: The repo validation scripts (validate-plugin-structure.sh, validate-marketplace.sh) required shell-exec approval in this environment and were not run directly; every check they perform was verified manually against the underlying files, and all passed.
2. Skill Review (skill-reviewer) — force-multiplier/SKILL.md
| Check | Result |
|---|---|
YAML frontmatter (name, description present & valid) |
✅ Valid; name matches directory |
| Description quality (third-person, specific, ~261 chars) | ✅ Strong |
| Body word count (~1,244 words; target 1,000–3,000) | ✅ In range, lean |
| Writing style (imperative/infinitive, well-organized) | ✅ Strong |
Progressive disclosure (heavy detail deferred to references/, worked campaigns in examples/) |
✅ Textbook |
| Referenced files exist | ✅ All present |
Sibling Skill(...) dependencies exist (perform-preflight, committing-changes, labeling-changes, creating-pull-request) |
✅ All 4 present |
| Anti-patterns (vague triggers, bloat, missing examples) | ✅ None |
Warnings (non-blocking, informational — should-fix at most):
- [
SKILL.md:4] —when_to_usefield. Current skill-development guidance leans toward folding trigger phrases intodescription. The trigger phrases here are excellent but live in a separatewhen_to_usefield. Optional hardening: merge them intodescription(would land ~480 chars, still under the 500 guideline). The current split is valid and functional — not an error. - [
SKILL.md:5–6] —argument-hint/allowed-toolsfrontmatter. These command-style fields are meaningful here (the skill is invoked with arguments and scopes its toolset) and permitted by the repo's own conventions. Flagged only so a loader run confirms the keys are tolerated without warnings.
3. Security Validation (reviewing-claude-config)
| Check | Result |
|---|---|
| Committed secrets (API keys, tokens, private keys, high-entropy strings) | ✅ None (regex scan clean) |
| Hardcoded credentials in examples/fixtures | ✅ None |
settings.local.json committed |
✅ N/A — not present |
| Dangerous command auto-approvals | ✅ None — content is documentation/advice, not executable settings |
| Overly broad file/tool access | ✅ allowed-tools is appropriately scoped (Bash, Read, Write, Edit, Glob, Grep, Agent + 4 named Skills) |
| Prompt-injection safety | ✅ Explicitly addressed |
The skill itself codifies notably strong security practices, which is a positive signal rather than a concern:
- Untrusted-input handling (CWE-1427) — target content (file bodies,
CLAUDE.md, PR templates, CI workflows) is treated as data, never instructions; sub-agents flag rather than obey embedded directives (references/safety-and-self-checks.md:54–61). - Least privilege — read to enumerate, write to open draft PRs, never merge; reuses the existing
ghsession and forbids token injection (safety-and-self-checks.md:68–71). - Secrets-scan before every commit with a concrete no-scanner fallback; any hit aborts that target's commit (
safety-and-self-checks.md:63–66). - Safe-by-default fan-out — draft PRs only, never auto-merge, never force-push, never commit on a default branch;
WebFetch/WebSearchforbidden for sub-agents unless genuinely required. [TICKET]/<TICKET>are documented placeholders, explicitly instructed to be substituted with a real key, never committed literally.
Overall Assessment
APPROVE. All three validation passes succeed with zero errors. The manifest, version bump, and changelog satisfy the repo's mandatory versioning policy (2.1.0 consistent across all three required files); the skill follows progressive disclosure cleanly with all referenced files present; and no secrets, dangerous auto-approvals, or broad-access issues were found. The two warnings under Skill Review are optional hardening suggestions, not defects.
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
| @@ -0,0 +1,46 @@ | |||
| # Example — Migrate the fleet from npm to pnpm | |||
There was a problem hiding this comment.
❓ Did you use https://bitwarden.atlassian.net/browse/PM-35701?focusedCommentId=157547 at all? That was my attempt and helping show a prompt.
There was a problem hiding this comment.
No, I did not. I pointed Claude at https://pnpm.io/ website and let it go. I had Claude put a note here in the example. Perhaps in a follow-up commit I'll have it go through the commment e2e and see what comes of it.
# Conflicts: # README.md
…creator + evals looping.
2 participants
🎟️ Tracking
N/A
📔 Objective
Adds
force-multipliertobitwarden-delivery-tools— a skill for applying one intent across many targets as N consistent, idempotent, SSH-signed draft PRs across the Bitwarden GitHub enterprise.The central design principle: the checks are the product. Making the edit is trivial. Making 74 edits provably correct, consistent, and reversible — and being able to prove what was done — is the actual hard part. The skill is built around that proof.
What ships:
SKILL.md— a lean 71-line playbook built on a fixed pipeline:SELECT → CHECK YOURSELF → PILOT → FAN-OUT → REPORT → REMEDIATE. The skill never freestyles across the fleet; it compiles any user intent into a structured campaign spec and executes it deterministically.references/campaign-spec.md— generic campaign schema: intent + target selector + recipe + validation + PR spec + safety policyreferences/finding-targets.md— discovery library keyed by signal type (file-existence, content match, manifest inspection, topic/language filter), grounded ingh ... --owner bitwardenreferences/pipeline.md— per-stage mechanics: shallow-clone isolation, validation gates, idempotency rules, rate-limit handling, dry-run semanticsreferences/safety-and-self-checks.md— the full checks-and-balances model: three reality-check brackets (before / on one / after), the mandatory pilot gate, the per-target second pass, the reference-check pre-step for destructive recipesexamples/workflow-edit.md,examples/npm-to-pnpm.md,examples/settings-json-patch.md— fully-worked campaigns; named-change specifics live here, never in the skill bodyThe skill is deliberately generic — a compiled engine, not a catalogue. It composes with the existing delivery skills rather than reinventing them:
perform-preflight → committing-changes → labeling-changes → creating-pull-request, per target, in that order.Plugin README updated to include
force-multiplierin the Mechanics skill table.🧪 Testing
Executed end-to-end against a live AppSec remediation: VULN-649 —
[VULN-649] ci: Remove deprecated scan workflow..github/workflows/scan.ymlvia per-repo contents API (not flaky code search)bitwarden/admin: branch cut,git rm, full diff read line by line, PR spec locked before any fan-outgit rm, second-pass diff-shape check (exactly one deleted file — anything more stops that target), secrets-scan, commit, draft PRMick Letofsky <mletofsky@bitwarden.com>via Secure Enclave, no Claude attributionTotal human input after confirming the pilot diff: one thumb on Touch ID per commit.