mobile-debug-mcp 0.30.1 → 0.30.2

package/skills/rfc-review/SKILL.md

@@ -1,52 +0,0 @@
-# RFC Review skill
-
-name: rfc-review
-version: 0.1.1
-summary: Reusable workflow for reviewing RFCs/specs in this repository with a consistent readiness rubric and output template.
-
-# Purpose
-Help an agent review an RFC for clarity, implementation readiness, and alignment with the current codebase. Use a common template so reviews stay consistent across documents and reviewers.
-
-# Activation conditions
-Activate when an agent needs to:
-- review a new or revised RFC
-- assess whether an RFC is implementation-ready
-- identify whether feedback is an RFC issue or an implementation issue
-- compare a spec against the current `src/` contract surface and docs
-
-# Surface area (actions)
-- locate-rfc
-- compare-against-code
-- assess-contract-completeness
-- classify-gaps
-- produce-review
-
-# Core guidance
-1. Read the RFC first, then compare it against the relevant code, docs, and tests.
-2. Separate **spec gaps** from **implementation gaps**.
-3. Check for: problem clarity, scope boundaries, explicit contracts, acceptance criteria, non-goals, and consistency with existing behavior.
-4. Prefer precise feedback that names the missing contract, unclear rule, or inconsistent behavior.
-5. Use the shared review template in `references/rfc-review-template.md` for the final output.
-6. If the RFC is not ready, say exactly what must be clarified before implementation can start.
-7. Classify each blocker as either a **spec gap** or an **implementation contract gap** and stop at that boundary.
-
-# Inputs & outputs
-- review-rfc(input: { rfcPath, relatedPaths?, focusAreas? }) -> { verdict, risks, specGaps, implementationGaps, recommendations }
-- compare-against-code(input: { rfcPath, codePaths[] }) -> { matches, mismatches, notes }
-- produce-review(input: { rfcPath, findings[] }) -> { summary, verdict, checklist, nextStep }
-
-# Failure handling
-- If the RFC file is missing, stop and report the missing path explicitly.
-- If the RFC is ambiguous, classify each concern as either "spec" or "implementation" instead of blending them.
-- If the review cannot be grounded in the current repo, state that the RFC is not reviewable yet.
-
-# Progressive disclosure
-- Keep this file short.
-- Load the reference template only when writing the final review.
-
-# References
-- `references/rfc-review-template.md` — standard review format and verdict rubric
-- `references/rfc-review-checklist.md` — questions to apply while reviewing an RFC
-
-# License
-Same as repository (MIT).

package/skills/rfc-review/references/rfc-review-checklist.md

@@ -1,12 +0,0 @@
-# RFC Review Checklist
-
-Ask these questions while reviewing:
-
-1. Is the problem statement specific and grounded in current failures?
-2. Are non-goals explicit?
-3. Are contracts concrete enough to implement?
-4. Are acceptance criteria testable?
-5. Does the RFC define the source of truth for new fields or behaviors?
-6. Does it match existing code paths and public tool surfaces?
-7. Can each open concern be classified as a spec issue or an implementation issue?
-8. Is the RFC ready to implement without further interpretation?

package/skills/rfc-review/references/rfc-review-template.md

@@ -1,28 +0,0 @@
-# RFC Review Template
-
-Use this structure for every RFC review:
-
-## Verdict
-- Ready / Needs clarification / Needs implementation contract / Not ready
-
-## Summary
-- One short paragraph on the RFC's current quality.
-
-## What is good
-- List the strongest parts of the RFC.
-
-## Issues
-For each issue, include:
-- **Type:** spec / implementation / implementation contract / doc
-- **Severity:** low / medium / high
-- **Why it matters:** one sentence
-- **Fix:** exact change needed
-
-## Missing contract surfaces
-- List any API shapes, response fields, state transitions, or invariants that are still undefined.
-
-## Codebase alignment
-- Note whether the RFC matches current `src/`, docs, and tests.
-
-## Next step
-- State the smallest next action needed to move the RFC forward.