@ecology91/skills 0.1.1 → 0.1.3

package/README.md

@@ -156,7 +156,7 @@ Skills I use daily for code work.
 - **[tdd](./skills/engineering/tdd/SKILL.md)** — Test-driven development with a red-green-refactor loop. Builds features or fixes bugs one vertical slice at a time.
 - **[to-issues](./skills/engineering/to-issues/SKILL.md)** — Break any plan, spec, or PRD into independently-grabbable issues on the project issue tracker using vertical slices.
 - **[to-prd](./skills/engineering/to-prd/SKILL.md)** — Turn the current conversation context into a PRD and submit it to the project issue tracker. No interview — just synthesizes what you've already discussed.
-- **[to-qa](./skills/engineering/to-qa/SKILL.md)** — Create a local QA To Do session from completed child work under an explicit parent issue.
+- **[to-qa](./skills/engineering/to-qa/SKILL.md)** — Create a local QA To Do session from completed source work under an explicit issue, including older non-parent Beads issues.
 - **[zoom-out](./skills/engineering/zoom-out/SKILL.md)** — Tell the agent to zoom out and give broader context or a higher-level perspective on an unfamiliar section of code.
 - **[prototype](./skills/engineering/prototype/SKILL.md)** — Build a throwaway prototype to flesh out a design — either a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ecology91/skills",
-  "version": "0.1.1",
+  "version": "0.1.3",
   "description": "opencode agent skills for real engineering workflows.",
   "license": "MIT",
   "type": "module",

package/skills/engineering/README.md

@@ -11,6 +11,6 @@ Skills I use daily for code work.
 - **[tdd](./tdd/SKILL.md)** — Test-driven development with a red-green-refactor loop. Builds features or fixes bugs one vertical slice at a time.
 - **[to-issues](./to-issues/SKILL.md)** — Break any plan, spec, or PRD into independently-grabbable issues on the project issue tracker using vertical slices.
 - **[to-prd](./to-prd/SKILL.md)** — Turn the current conversation context into a PRD and submit it to the project issue tracker.
-- **[to-qa](./to-qa/SKILL.md)** — Create a local QA To Do session from completed child work under an explicit parent issue.
+- **[to-qa](./to-qa/SKILL.md)** — Create a local QA To Do session from completed source work under an explicit issue, including older non-parent Beads issues.
 - **[zoom-out](./zoom-out/SKILL.md)** — Tell the agent to zoom out and give broader context or a higher-level perspective on an unfamiliar section of code.
 - **[prototype](./prototype/SKILL.md)** — Build a throwaway prototype to flesh out a design — either a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route.

package/skills/engineering/to-qa/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: to-qa
-description: Create a local QA To Do session from completed child work under an explicit parent issue. Use when user runs `/to-qa <parent issue>` or asks to turn completed issue work into QA checks.
+description: Create a local QA To Do session from completed work under an explicit source issue, including older non-parent Beads issues. Use when user runs `/to-qa <issue>` or asks to turn completed issue work into QA checks.
 compatibility: opencode
 metadata:
   workflow: sandcastle-ralph-qa
@@ -8,38 +8,85 @@ metadata:
 
 # To QA
 
-Use this skill when the user runs `/to-qa <parent issue>`.
+Use this skill when the user runs `/to-qa <issue>`.
 
-The issue tracker workflow should have been provided to you — run `/setup-agent-skills` if `docs/agents/issue-tracker.md` is missing or if it does not explain how to fetch completed child work for a parent issue.
+For Beads, the issue can be a parent with child work, an older cumulative issue, a discovered-from source issue, or a completed standalone issue with no parent-child structure. For structured `.scratch`, the issue is normally a parent with child files.
 
-This skill reads from the configured issue tracker and writes to QA To Do. It does not mutate tracker issues.
+This skill reads completed implementation work from the configured issue tracker and writes a local QA session to QA To Do. It does not mutate tracker issues, pass/fail state, checklist items, evidence, archive state, or deletion state.
 
 ## Required Inputs
 
-- An explicit parent issue reference from the user.
-- A configured issue tracker workflow in `docs/agents/issue-tracker.md`.
-- A parent/child issue relationship where completed child work can be identified.
-- Completed implementation work only.
-- `qa-to-do` MCP server access.
+- An explicit source issue reference from the user.
+- The current repository path.
+- A configured issue tracker workflow in `docs/agents/issue-tracker.md`, or explicit source issue references from the user.
+- Completed implementation source work only.
+- Access to the `qa-to-do` MCP server.
+
+## Supported Paths
+
+- Prefer `qa-to-do.run_to_qa_parent` for normal `/to-qa` usage.
+- Use `qa-to-do.qa_session_create` only when you have manually built a complete, validated QA session payload.
+- `run_to_qa_parent` currently automates Beads and structured `.scratch` trackers.
+- The `parentIssueId` MCP field is legacy-named. For Beads, pass the requested source issue ID even when it is cumulative or standalone rather than a literal parent.
+- For GitHub, GitLab, or custom trackers, use the repo-documented parent/child convention to gather completed child work, then call `qa_session_create` with a concrete QA session payload.
 
 ## Workflow
 
-1. Inspect the explicit parent issue in the current repo.
-2. Using `docs/agents/issue-tracker.md`, find completed source work only: closed/completed/done Beads child issues, structured `.scratch` child files, GitHub/GitLab child issues if the repo documents that convention, or another repo-documented completed-child convention.
-3. Read commits, changed files, and implementation context only as needed to write concrete QA checks.
-4. Create human-verifiable QA checks with title, runnable steps, expected result, source issue ID, source evidence, stable ID, and fingerprint.
-5. Call the `qa-to-do` MCP server to create the QA session.
-6. Report the session title, source parent, item count, and warnings.
+1. Inspect the explicit source issue in the current repo.
+2. Read `docs/agents/issue-tracker.md` to understand how this repo identifies completed source work.
+3. Find completed source work only: closed/completed/done Beads child issues, discovered-from issues, older cumulative or standalone Beads issues, structured `.scratch` child files, or another repo-documented convention.
+4. Exclude open, blocked, incomplete, or unrelated work and keep those exclusions as warnings for the final report.
+5. Prefer acceptance criteria, QA notes, and source issue evidence over changed-file inference when creating checks.
+6. Read commits, changed files, and implementation context only as needed to make checks concrete and human-verifiable.
+7. Create QA checks with title, runnable steps, expected result, source issue ID, source evidence, stable ID, and fingerprint.
+8. Call the `qa-to-do` MCP server to create the QA session.
+9. Report the session title, source issue, item count, and warnings.
+
+## MCP Usage
+
+For Beads or structured `.scratch` repos, call `qa-to-do.run_to_qa_parent` with:
+
+```json
+{
+  "parentIssueId": "<requested issue id>",
+  "repoPath": "<absolute repo path>",
+  "repoName": "<optional repo name>",
+  "tracker": "auto"
+}
+```
+
+Set `tracker` to `beads` or `scratch` only when the repo or user explicitly requires one. Use `auto` by default.
+
+If `run_to_qa_parent` reports that no supported tracker was detected, multiple trackers require a choice, or no completed source work exists, stop and report the issue clearly. Do not invent QA checks from unrelated closed work. Do not fail only because a Beads issue has no parent-child children; older Beads issues may be cumulative or standalone.
+
+When manually calling `qa_session_create`, the payload must include only completed source work and must preserve source evidence. Do not use it to mutate existing QA To Do state.
+
+## Beads Guidance
+
+- If the repo uses Beads and local automation is available, prefer `run_to_qa_parent` with `tracker: "auto"` or `tracker: "beads"`.
+- If you must inspect Beads manually, start with `bd show <issue-id> --json`, then fetch parent-child candidates with `bd list --parent <issue-id> --status all --json --limit 0` when the repo supports parent structure.
+- If no parent-child children exist, fetch the full Beads issue set with `bd list --status all --json --limit 0`, look for completed `discovered-from` dependencies that point to the requested issue, then fall back to the requested issue itself when it is closed, completed, or done.
+- Include only source issues whose status is closed, completed, or done according to the repo's Beads vocabulary.
+- Read included source issues with `bd show <issue-id> --json` and `bd comments <issue-id> --json` when extra evidence is needed.
+- Look for related implementation commits only when issue evidence is not enough to write a concrete QA check.
+- Do not require parent-child relationships for Beads; older Sandcastle/RALPH Beads may be cumulative or standalone.
+- Do not create, update, label, comment on, close, or claim Beads issues during `/to-qa`.
+
+## Scratch Guidance
+
+- If the repo uses structured `.scratch` issues, prefer `run_to_qa_parent` with `tracker: "auto"` or `tracker: "scratch"`.
+- Include only `.scratch` child files with frontmatter that identifies `id`, `title`, `status`, and the requested parent relationship.
+- Prefer `## Acceptance notes` or `## Acceptance criteria` bullets for expected results.
+- Do not create, edit, rename, move, close, or delete `.scratch` files during `/to-qa`.
 
 ## Rules
 
-- Do not create checks from open/incomplete child work; warn about excluded children.
+- Do not create checks from open, blocked, incomplete, review-only, or unrelated work.
+- Do not create checks from planning or PRD text alone; checks must trace to completed implementation source work.
 - If there is no completed source work, fail clearly and do not create a session.
-- If `docs/agents/issue-tracker.md` does not define how to find completed children for the parent issue, ask the user for explicit child issue references; do not infer from unrelated closed work.
-- For Beads, fetch children with `bd list --parent <parent-id> --status all --json --limit 0`, include only closed/completed/done children, read each child with `bd show <child-id> --json` and `bd comments <child-id> --json`, and look for related RALPH commits with `git log --grep="RALPH:.*<child-id>" --oneline`.
-- Create QA checks from acceptance criteria and QA notes before changed files. Do not create QA checks for parent PRDs, open children, blocked children, or review-only refactor commits unless they changed user-visible behavior.
+- If `docs/agents/issue-tracker.md` does not explain how to find completed source work and Beads cumulative/standalone fallback does not apply, ask the user for explicit source issue references.
 - Do not write vague checks like "verify implementation" or "works as expected".
 - Do not mutate pass/fail/skip/edit/archive/delete state through MCP.
-- Do not file, close, or update tracker issues during `/to-qa`.
-- QA To Do owns checklist execution, evidence, pass/fail state, and archive.
-- No app-managed secrets are stored by this setup.
+- Do not file, close, claim, label, comment on, or update tracker issues during `/to-qa`.
+- QA To Do owns checklist execution, evidence, pass/fail state, edits, archive, and deletion.
+- Do not store app-managed secrets; rely on user environment, existing provider config, or provider-native auth.