Stride AI

View saved version →

---
name: "done"
description: "Finish the Stride story you are working on: check it against its acceptance criteria, record what changed, and move it to In Review."
---

# Finish the current Stride story

Stride is your team's delivery record. Use its MCP tools to read and update
the story. Their names end in the tool name: `update_story_status` appears as
`stride.update_story_status` or `stride_update_story_status`, depending on
your agent.

If the user named a story key in their message, that is the story.

1. **Find the story**: the ticket key the user named; else the story you
   picked up in this conversation; else the key in the current git branch
   name (`orb-526-export-csv` is `ORB-526`); else ask. Read it with
   `get_story_context` so you have its acceptance criteria. If Stride's tools
   are missing or not authorized, ask the user to open Stride AI in Plugins (`/plugins` in Codex CLI, or Plugins in ChatGPT) and connect it when prompted. A browser window opens to sign in to Stride.
2. **Check the work.** Run the repository's own tests and linters for the
   code you changed. If anything fails, report it and stop, unless the user
   tells you to go on.
3. **Check every acceptance criterion** against the change, and list each as
   met, or not met with the reason.
4. **Commit, if the user wants it.** If the changes are not committed yet,
   ask whether to commit them; if yes, commit on the story's branch with a
   message that starts with the key (`ORB-526: ...`). Push and open a pull
   request only when the user asks for it. When GitHub is connected to
   Stride, a branch or pull request whose name contains the key links to the
   story by itself.
5. **Record it in Stride.**
   - Every criterion met: call `update_story_status` with the key, status
     `IN_REVIEW`, and a comment that says what changed, which tests you ran,
     and the pull request URL if there is one.
   - Some not met: leave the status as it is, add a comment to the story
     with `create_comment` (entity type `story`) saying what is done and what
     remains, and ask the user how to go on.
   If Stride reports a conflict because a person edited the story, read it
   again with `get_story` and retry once. Never pass `force` without the
   user's explicit approval.
6. **Tell the user where the story stands**, with its key. To pick up the
   next one, they can run `$stride:next`.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: "next"
description: "Pick up your next Stride story: the one a teammate staged for you, or the top story assigned to you, with its acceptance criteria, designs and docs. Starts it in Stride and sets up a branch."
---

# Pick up the next Stride story

Stride is your team's delivery record. Use its MCP tools, never a guess, for
anything about a story. Their names end in the tool name: `next_task` appears
as `stride.next_task` or `stride_next_task`, depending on your agent.

If the user named a story key in their message, that is the story.

1. **Find the story.**
   - If the user named a story (a ticket key such as `ORB-526`), call
     `get_story_context` with that key.
   - Otherwise call `next_task`. It returns the story a teammate staged for
     you with "Hand to your agent" or, when nothing is staged, the top
     unstarted story assigned to the user (the active sprint first, then by
     priority), with its full context in the same call.
   - If there is nothing to work on, say so and stop. Suggest staging a
     story from its "Hand to your agent" panel in Stride, or assigning one to
     themselves, and running `$stride:next` again.
   - If Stride's tools are missing, or answer that the request is not
     authorized, the user needs to sign in to Stride. Ask them to open Stride AI in Plugins (`/plugins` in Codex CLI, or Plugins in ChatGPT) and connect it when prompted. A browser window opens to sign in to Stride.
2. **Brief the user** in a few lines: the key and title, the goal in a
   sentence or two, every acceptance criterion as a numbered list, and
   whatever is linked that changes the work (designs, documents, blocking or
   related stories, open defects).
3. **Start it in Stride.** If the story is still to do, call
   `update_story_status` with the key, status `IN_PROGRESS`, and a one-line
   comment that you have picked it up. Leave a story that is already in
   progress or further along where it is. If Stride reports a conflict
   because a person edited the story, read it again with `get_story` and
   retry once. Never pass `force` unless the user explicitly tells you to
   overwrite their teammate's edit.
4. **Set up the work.** In a git repository, create and switch to a branch
   named after the key and title, such as `orb-526-export-csv`, unless the
   user is already on a branch for this story. Never discard, reset or stash
   uncommitted work without asking.
5. **Implement it** against the acceptance criteria, keeping the user in the
   loop. When it is done, suggest `$stride:done` to check the work and hand it back
   for review.

Referenced files: 1 — file references are metadata, not package contents.