agentleFS
neonwattyneonwatty/qa-skills/skills/submit-learnings/SKILL.md

submit-learnings

Skill34 starsChanged 7 months agoMITView on GitHub

Filters and submits accumulated QA learnings as a GitHub issue (with optional PR) on the plugin repo. Use when the user says "submit learnings", "share learnings", "report learnings upstream", or "open issue for learnings".

  • Commits and pushes

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 2 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Read .qa-learnings/ledger.md from the current project directory.

    line 15
  2. Very specific:

    If the file does not exist or has no entries (only the # QA Learnings Ledger header), inform the user:

    line 17
  3. Distinctive:

    Wait for user selection before proceeding.

    line 52
  4. Distinctive:

    Wait for user approval. If the user requests edits, apply them and re-preview.

    line 85
  5. Very specific:

    If the learnings label does not exist (command fails with label error), create it first:

    line 101
  6. Very specific:

    Read references/reflection-protocol.md and execute it before finishing.

    line 129

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Submit Learnings

You are a QA feedback coordinator. Your job is to help users submit valuable field observations from their QA sessions upstream to the plugin maintainers as structured GitHub issues.


Phase 1: Load & Parse

Read .qa-learnings/ledger.md from the current project directory.

If the file does not exist or has no entries (only the # QA Learnings Ledger header), inform the user:

No learnings recorded yet. Run QA sessions — each agent and skill automatically records observations to the ledger.

Then stop.

Parse each entry by splitting on ## headers. For each entry, extract:

  • Timestamp — the ISO timestamp after ##
  • Source — the agent or skill name after —
  • Observation — the body text
  • Suggested change — the line starting with **Suggested change:**

Phase 2: Filter

Present all entries grouped by source, numbered for selection:

Found [N] learnings from [M] sources:

### smoke-tester (3 entries)
  1. [2026-04-01] Cookie not checked after login redirect
  2. [2026-04-02] /dashboard 500 not caught by status check
  3. [2026-04-03] Auth flow timing out on slow connections

### ux-auditor (2 entries)
  4. [2026-04-01] Missing empty state not flagged
  5. [2026-04-02] Spacing check too strict on mobile viewports

Then ask:

Which observations do you want to include? Select by number (e.g., "1,3,5"), by source (e.g., "smoke-tester"), or say "all". Exclude anything project-specific that isn't relevant to the plugin itself.

Wait for user selection before proceeding.

Phase 3: Draft Issue

Format the selected observations into a GitHub issue body:

## QA Field Observations

**Entries:** [N selected] of [N total] from [comma-separated sources]
**Date range:** [earliest timestamp] to [latest timestamp]
**Submitted by:** [output of `gh api user --jq .login`]

### Observations

#### [Source 1]

- **[timestamp]:** [observation text]
  - **Suggested change:** [file] — [description]

- **[timestamp]:** [observation text]
  - **Suggested change:** [file] — [description]

#### [Source 2]

- **[timestamp]:** [observation text]
  - **Suggested change:** [file] — [description]

Preview the full issue body in the terminal. Then ask:

Does this look right? Let me know if you'd like to edit anything, or say "good" to submit.

Wait for user approval. If the user requests edits, apply them and re-preview.

Phase 4: Submit Issue

Construct the issue title: learnings: [N] observations from [sources]

Run:

gh issue create \
  --repo neonwatty/qa-skills \
  --title "[constructed title]" \
  --body "[approved body]" \
  --label "learnings"

If the learnings label does not exist (command fails with label error), create it first:

gh label create learnings --repo neonwatty/qa-skills --description "Field observations from QA sessions" --color "0E8A16"

Then retry the issue creation.

Display the issue URL to the user.

Phase 5: Optional PR

Ask:

Want me to also open a PR with the suggested edits from these observations? This will fork the repo, create a branch, apply the changes, and open a PR referencing the issue.

If yes:

  1. Fork neonwatty/qa-skills if not already forked: gh repo fork neonwatty/qa-skills --clone=false
  2. Clone the fork to a temp directory, create branch learnings/[short-slug]
  3. Apply each suggested edit by reading the target file in the cloned fork, making the change, and committing. Only modify files within the cloned fork directory — do not edit files in the user's project
  4. Push the branch and open a PR: gh pr create --repo neonwatty/qa-skills --title "fix(qa): apply learnings — [short description]" --body "Applies suggested changes from #[issue-number]."
  5. Display the PR URL

If no: skip.

Phase 6: Reflect

Read references/reflection-protocol.md and execute it before finishing.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.