Six playbooks. Each step gives you the input to paste, the playbook prompt to run, and the output to expect.
Macro: !brd_helper <your requirement>
Use case: Turns a rough requirement into a structured business requirements document in Confluence. This makes the requirement traceable before coding starts.
Copy and paste:
!brd_helper Members cannot narrow provider search results. Add specialty and
accepting-new-patients filters. Combine them with name search, reject invalid
values, and keep p95 response time below 500 ms.
Prompt:
Playbook: BRD Helper
## Overview
Work with the requester to turn a rough requirement into a complete Business
Requirements Document (BRD) and publish it to Confluence.
## What's Needed From User
- The requirement in whatever form they have it (a sentence, a doc, a Slack thread)
- APM ID and application/product owner (the playbook asks for these if not provided)
- Target Confluence space (default to the team's BRD space)
## Procedure
1. Restate the requirement back to the user and confirm the problem being solved.
2. Ask only the questions needed to fill gaps: scope, in/out of scope, affected
systems, users/personas, success metrics, compliance or PHI considerations.
3. Search Confluence and Jira for related existing BRDs and link them instead of
duplicating content.
4. Draft the BRD: Summary, Background, Goals/Non-goals, Requirements (functional
and non-functional), Acceptance Criteria, Dependencies, Risks, Open Questions.
5. Share the draft with the user and incorporate one round of feedback.
6. Publish the BRD to the specified Confluence space and return the page link.
## Specifications
- Every requirement is testable and individually numbered (REQ-1, REQ-2, ...).
- Open questions are listed explicitly rather than guessed at.
- Deliverable: a published Confluence page link.
## Forbidden Actions
- Do not invent requirements, owners, or dates the user did not confirm.
- Do not include real PHI/PII in examples.
Expected output: A published BRD in Confluence.
Macro: !brd_to_jira <BRD link or requirement> <Jira project key>
Use case: Converts an approved BRD into a Jira epic with stories and subtasks. This gives the team work that it can start immediately.
Copy and paste:
!brd_to_jira <BRD_CONFLUENCE_URL> Jira project: PDIR. Create one epic and two
stories: filter implementation and search performance. Link each issue to its BRD
requirement.
Prompt:
Playbook: BRD to Jira Breakdown
## Overview
Convert a BRD into a Jira epic with child stories and subtasks that trace back to
the BRD's requirements.
## What's Needed From User
- Link to the BRD (Confluence page) or the requirement text
- Target Jira project key and, if known, the epic to attach to
- Optional: team conventions (labels, components, story point scale); otherwise
follow the patterns visible on existing issues in the project
## Procedure
1. Read the BRD and list every numbered requirement and acceptance criterion.
2. Propose the breakdown structure (epic -> stories -> subtasks) in chat and get
approval before creating anything in Jira.
3. Create the epic with a summary, description, and link back to the BRD.
4. Create one story per user-facing capability, each with acceptance criteria in
Given/When/Then form and a reference to its BRD requirement ID.
5. Create subtasks for implementation, testing, and any migration or config work.
6. Apply labels, components, and estimates per team conventions; flag dependencies
between issues with Jira links.
7. Post the epic link and a summary table of created issues.
## Specifications
- Every BRD requirement maps to at least one Jira issue; note any that do not.
- No duplicate issues: search the project before creating.
- Deliverable: epic link plus list of created issue keys.
## Forbidden Actions
- Do not create Jira issues before the user approves the proposed breakdown.
- Do not modify or close existing unrelated issues.
Expected output: Epic PDIR-100 with PDIR-101 and PDIR-102.
Macro: !implement_dev_ticket <Jira ticket> <repo URL> <base branch>
Use case: Implements a well-scoped Jira ticket from start to finish. The output includes code, tests, and a pull request.
Copy and paste:
!implement_dev_ticket PDIR-101 <REPO_URL> main
Prompt:
Playbook: Development Implementation
## Overview
Implement a Jira ticket end to end on the specified branch and open a pull request.
## What's Needed From User
- Jira ticket key
- Repository and base branch
- Optional: environment or credential requirements beyond the standard setup
## Procedure
1. Read the Jira ticket, its acceptance criteria, and linked BRD or parent epic.
2. Explore the codebase to locate the files and patterns involved; follow existing
conventions rather than introducing new ones.
3. Create a branch off the specified base branch using the team's naming convention.
4. Implement the change in focused commits, touching only files the ticket requires.
5. Add or update tests covering each acceptance criterion.
6. Run the repo's lint, type-check, build, and test commands and fix all failures.
7. Open a pull request that references the ticket, summarizes the change and its
rationale, and lists how it was verified.
8. Comment the PR link on the Jira ticket and report it back.
## Specifications
- All acceptance criteria are implemented and covered by tests.
- Lint, type-check, and test suites pass locally before the PR is opened.
- Deliverable: PR link plus Jira comment.
## Forbidden Actions
- Do not change tests to make them pass or weaken assertions.
- Do not commit secrets, credentials, or generated artifacts.
- Do not expand scope beyond the ticket; raise a follow-up ticket instead.
Macro: !pr_review_context <PR link> <review context>
Use case: Reviews a pull request against its ticket and requirements. The review adds consistent, actionable inline comments instead of surface-level nits.
Copy and paste:
!pr_review_context <PR_URL> Review against PDIR-101.
Prompt:
Playbook: Pull Request Review
## Overview
Review a pull request against its implementation context and leave actionable
inline comments.
## What's Needed From User
- PR link
- Review context: the Jira ticket, BRD, or a description of intended behavior
- Optional: team-specific review standards to enforce beyond the defaults below
## Procedure
1. Read the PR description, diff, and linked ticket or BRD to establish intent.
2. Explore the surrounding code to judge whether the change fits existing patterns
and does not break callers.
3. Review for correctness first: logic errors, unhandled edge cases, error handling,
concurrency, and data integrity.
4. Then review for security (input validation, authz, secrets, PHI handling),
performance, and test coverage against the acceptance criteria.
5. Leave inline comments on specific lines. Each comment states the problem, why
it matters, and a concrete suggested fix.
6. Post a summary comment with an overall assessment and the must-fix items ranked
by severity.
## Specifications
- Every comment is actionable and tied to a line or file.
- Severity is labeled (blocking / should-fix / nit) so the author can triage.
- Deliverable: inline comments plus one summary comment on the PR.
## Forbidden Actions
- Do not approve or merge the pull request.
- Do not push commits to the author's branch.
- Do not leave style nits already enforced by the linter.
Macro: !qa_agent <Jira ticket> <repo URL> <branch or PR link>
Use case: Evaluates test coverage against a ticket's acceptance criteria. It strengthens the automated tests and creates traceable test plans and test data.
Copy and paste:
!qa_agent PDIR-101 <REPO_URL> <PR_URL>
Prompt:
Playbook: QA Engineering Agent
## Overview
Assess and strengthen test coverage for a Jira ticket, and produce a test plan and
test data traceable to its acceptance criteria.
## What's Needed From User
- Jira ticket key and repository
- Branch or PR link containing the implementation to assess
- Optional: test environment or test-data constraints not documented in the repo
## Procedure
1. Extract the acceptance criteria from the ticket and linked BRD.
2. Check out the provided branch or PR, and discover the repo's test frameworks and
how to run each suite (unit, integration, e2e) from its docs and config.
3. Map existing tests to those criteria and produce a coverage gap table.
4. Write a test plan covering happy path, edge cases, negative cases, and
non-functional checks, each row referencing its acceptance criterion.
5. Implement the missing automated tests following the repo's existing test patterns.
6. Generate synthetic test data or fixtures for the new cases — never real PHI/PII.
7. Run all affected suites and confirm the new tests pass and fail for the right
reasons (verify by temporarily breaking the behavior under test).
8. Open a pull request with the new tests and the test plan, and attach the coverage
gap table to the Jira ticket.
## Specifications
- Every acceptance criterion maps to at least one automated test or an explicitly
noted manual test.
- New tests are deterministic — no reliance on sleeps, live services, or ordering.
- Deliverable: PR link, test plan, and coverage traceability table.
## Forbidden Actions
- Do not weaken or delete existing tests to get a green suite.
- Do not use production data or real member/patient data as test data.
Macro: !dev_scoping_and_execution <Jira ticket> <repo URL> <base branch>
Use case: Produces an implementation plan before coding starts. After a human approves the plan, it implements ambiguous or higher-risk work.
Copy and paste:
!dev_scoping_and_execution PDIR-102 <REPO_URL> main
Prompt:
Playbook: Development Planning and Execution
## Overview
Scope a Jira ticket into an implementation plan, get human approval, then execute
the approved plan.
## What's Needed From User
- Jira ticket key
- Repository and base branch
- Optional: constraints (deadlines, systems that must not be touched)
## Procedure
1. Read the ticket and all linked context (BRD, epic, prior PRs, related tickets).
2. Investigate the codebase and confirm — do not assume — how the affected code
works today.
3. Write a plan covering: files to change, approach, test strategy, risks,
migrations or config changes, and anything still unclear.
4. Post the plan and stop. Wait for explicit approval; ask about any open questions
in the same message.
5. Once approved, implement the plan on a branch off the specified base branch.
6. Add tests, then run lint, type-check, build, and test commands until green.
7. Open a pull request linking the ticket and the approved plan, and note any
deviation from the plan with the reason.
8. Comment the PR link on the Jira ticket.
## Specifications
- Nothing is implemented before approval is given.
- The plan states assumptions explicitly and separates verified facts from guesses.
- Deliverable: approved plan plus PR link.
## Forbidden Actions
- Do not silently deviate from the approved plan; report and get agreement first.
- Do not begin coding while open questions remain unanswered.