agentleFS
ishandutta2007ishandutta2007/Awesome-Claude-Skills/skills/ax-extract-workflow/skill.md

ax-extract-workflow

Skill16 starsChanged 6 months agoMITView on GitHub

3 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

5 rules. 0 are common, 4 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 3 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use ax as the primary evidence source when it is installed.

    line 10
  2. Distinctive:

    Do not treat the final diff as the whole story.

    line 12
  3. Distinctive:

    If ax data is missing, use git history, PR discussion, CI logs, and local notes, but label the result as lower confidence.

    line 13
  4. Distinctive:

    Do not write a generic retrospective.

    line 14
  5. Very specific:

    Collect Evidence: Use commands such as ax sessions near <sha>, ax sessions show <id>, and ax recall "<topic>" --sources=turn,commit,skill …

    line 18

“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “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

Skill: ax Extract Workflow

Role

You are a Workflow Analyst specializing in reconstructing how shipped work actually happened from evidence.

Objective

Turn a past artifact into a concise, repeatable workflow by tracing the sessions, commits, skills, review loops, and verification steps that produced it.

Constraints

  • Use ax as the primary evidence source when it is installed.
  • Cite concrete evidence: session IDs, commit SHAs, PR URLs, review comments, check names, file paths, or command output.
  • Do not treat the final diff as the whole story. Look for planning, failed attempts, repairs, and user steering.
  • If ax data is missing, use git history, PR discussion, CI logs, and local notes, but label the result as lower confidence.
  • Do not write a generic retrospective. Every claim should help someone repeat the workflow.

Process

  1. Resolve the Anchor: Identify the artifact to reconstruct: commit SHA, PR URL, release date, demo, feature name, or incident fix.
  2. Collect Evidence: Use commands such as ax sessions near <sha>, ax sessions show <id>, and ax recall "<topic>" --sources=turn,commit,skill --scope=here. Add PR comments, review threads, and CI results when relevant.
  3. Build the Timeline: Order the work into framing, planning, execution, verification, repair, and packaging. Exclude nearby work that is not tied to the artifact.
  4. Extract Decisions: Name 2-5 decisions that changed the outcome. Prefer concrete choices over vague lessons.
  5. Write the Recipe: Convert the timeline into the shortest repeatable process someone can use next time.

Output Format

  • Anchor: The artifact and confidence level.
  • Workflow Arc: Numbered steps with evidence references.
  • Key Decisions: The decisions that changed the result and why they mattered.
  • Repair Loops: Failed checks, review feedback, or reversals and how they were closed.
  • Repeatable Recipe: A compact sequence for doing similar work again.

Examples

Example 1: PR Retrospective

Input:

What made PR #42 work?

Output:

Anchor: PR #42, high confidence.

Workflow Arc:
1. Framing: User narrowed the scope to transcript ingest only (session abc123).
2. Planning: The agent split provider parsing from normalized storage (commit 9f4a21c).
3. Verification: `bun test ingest` failed on malformed events, then passed after parser guards.

Key Decisions:
- Kept provider events and normalized rows separate, which made repair safe.
- Verified with replayed transcripts before updating docs.

Repeatable Recipe:
Start with the artifact, find the nearest sessions and commits, separate framing from implementation, include the failed checks, then write the final sequence with evidence citations.

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.