ralph-prd 1.0.4 → 1.0.6

package/skills/ship-check/SKILL.md

@@ -1,80 +0,0 @@
----
-name: ship-check
-description: Run the standard post-change validation flow after a fix, refactor, or new feature. Use when implementation work is done and you should validate the latest changes by invoking the repo's review skills, starting with review-changes and then repo-doc-maintainer, before giving the final close-out.
-disable-model-invocation: true
----
-
-# Ship Check
-
-## Overview
-
-Run the repo's end-of-task validation flow after code or documentation changes.
-
-This is an orchestration skill. It does not replace the specialized review skills. It tells the agent which checks to run, in what order, and how to summarize the result before final handoff.
-
-## Standard Flow
-
-Use this flow after finishing a fix, refactor, or feature:
-
-1. Review the latest changes with `$review-changes`.
-2. Check whether project documentation needs maintenance with `$repo-doc-maintainer`.
-3. Report the combined outcome clearly.
-4. If code changed, remind the user about any validation commands not yet run.
-
-## Invocation Pattern
-
-When this skill is invoked, explicitly use the other repo-local skills in sequence.
-
-Start with:
-
-`Use $review-changes to review the latest changes against the project's guidelines and report findings first.`
-
-Then run:
-
-`Use $repo-doc-maintainer to review the latest changes and decide whether project documentation should be updated.`
-
-Do not skip either step unless the user explicitly narrows the scope.
-
-## How To Interpret Results
-
-### If `review-changes` finds issues
-
-- present the findings first
-- do not claim the work is validated
-- if the issues are actionable and local, fix them before final handoff when appropriate
-- rerun validation after fixes if you changed the code again
-
-### If `review-changes` finds no issues
-
-- say that the changes comply with the current repo guidance
-- still run `$repo-doc-maintainer`
-
-### If `repo-doc-maintainer` says docs should change
-
-- update the docs if the current task includes making those maintenance edits
-- otherwise report that documentation maintenance is recommended
-
-### If `repo-doc-maintainer` says no doc update is needed
-
-- state that explicitly in the final close-out
-
-## Output Expectations
-
-The final close-out should combine both checks:
-
-- whether the implementation passed the repo-rule review
-- whether documentation maintenance was needed
-- whether project validation commands were run or remain outstanding
-
-Keep the output compact. Prefer a brief status summary over a long checklist unless there are actual findings.
-
-## Constraints
-
-- Treat `$review-changes` as the source of truth for repo-rule compliance review.
-- Treat `$repo-doc-maintainer` as the source of truth for doc-maintenance decisions.
-- Do not invent a separate third review rubric here.
-- Use this skill at the end of work, not before implementation starts.
-
-## Reference
-
-Read [references/validation-flow.md](references/validation-flow.md) if you need the exact end-of-task checklist.

package/skills/ship-check/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Ship Check"
-  short_description: "Run the repo's final validation flow"
-  default_prompt: "Use $ship-check to run the post-change validation flow for this repo, including $review-changes and $repo-doc-maintainer."

package/skills/ship-check/references/validation-flow.md

@@ -1,26 +0,0 @@
-# Validation Flow
-
-Use this checklist after finishing implementation work.
-
-## Required Review Skills
-
-1. `$review-changes`
-2. `$repo-doc-maintainer`
-
-## Default Sequence
-
-1. Inspect the latest working tree or commit range.
-2. Run the repo-rule review via `$review-changes`.
-3. Run the doc-maintenance review via `$repo-doc-maintainer`.
-4. Summarize both results.
-
-## Final Close-Out Should Cover
-
-- whether the changes respect the project's documented guidelines
-- whether project documentation needed updates
-- whether validation commands (lint, test, analyze) were run
-- any residual risks, such as unrun tests or manual-only verification gaps
-
-## When To Re-Run
-
-Re-run the flow if you make additional code or doc edits after the first validation pass.

package/skills/write-a-prd/SKILL.md

@@ -1,74 +0,0 @@
----
-name: write-a-prd
-description: Create a PRD through user interview, codebase exploration, and module design, then submit as a GitHub issue. Use when user wants to write a PRD, create a product requirements document, or plan a new feature.
----
-
-This skill will be invoked when the user wants to create a PRD in ./docs/<feature-name>/PRD.md. You may skip steps if you don't consider them necessary.
-
-1. Ask the user for a long, detailed description of the problem they want to solve and any potential ideas for solutions.
-
-2. Explore the repo to verify their assertions and understand the current state of the codebase.
-
-3. Interview the user relentlessly about every aspect of this plan until you reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one.
-
-4. Sketch out the major modules you will need to build or modify to complete the implementation. Actively look for opportunities to extract deep modules that can be tested in isolation.
-
-A deep module (as opposed to a shallow module) is one which encapsulates a lot of functionality in a simple, testable interface which rarely changes.
-
-Check with the user that these modules match their expectations. Check with the user which modules they want tests written for.
-
-5. Once you have a complete understanding of the problem and solution, use the template below to write the PRD. The PRD should be submitted as a GitHub issue.
-
-<prd-template>
-
-## Problem Statement
-
-The problem that the user is facing, from the user's perspective.
-
-## Solution
-
-The solution to the problem, from the user's perspective.
-
-## User Stories
-
-A LONG, numbered list of user stories. Each user story should be in the format of:
-
-1. As an <actor>, I want a <feature>, so that <benefit>
-
-<user-story-example>
-1. As a mobile bank customer, I want to see balance on my accounts, so that I can make better informed decisions about my spending
-</user-story-example>
-
-This list of user stories should be extremely extensive and cover all aspects of the feature.
-
-## Implementation Decisions
-
-A list of implementation decisions that were made. This can include:
-
-- The modules that will be built/modified
-- The interfaces of those modules that will be modified
-- Technical clarifications from the developer
-- Architectural decisions
-- Schema changes
-- API contracts
-- Specific interactions
-
-Do NOT include specific file paths or code snippets. They may end up being outdated very quickly.
-
-## Testing Decisions
-
-A list of testing decisions that were made. Include:
-
-- A description of what makes a good test (only test external behavior, not implementation details)
-- Which modules will be tested
-- Prior art for the tests (i.e. similar types of tests in the codebase)
-
-## Out of Scope
-
-A description of the things that are out of scope for this PRD.
-
-## Further Notes
-
-Any further notes about the feature.
-
-</prd-template>

package/skills/write-a-prd/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Write a PRD"
-  short_description: "Interview, design, and draft PRDs"
-  default_prompt: "Use $write-a-prd to interview me, inspect the repo, and turn a feature idea into a PRD GitHub issue."