This document was inspired by Claude’s article documenting How Anthropic Teams Use Claude Code. When reading it, I found various ways That I can implement the workflow into my own everyday development life cycle.
Note
Before you start, ensure to follow most of the anthropic guidelines for utilizing Claude Code. This involves creating a series of claude.md files that will explain a lot of the repository scripts that are run often. This will allow for iterative development to speed up significantly in Claude Code and will save a lot of tokenization usage.
Valuable Workflows to Adopt
Triaging Tickets for a Sprint Should Include a Comprehensive Jira Check
In order to assist with agentic coding workflows, we need to ensure the triaging process for tickets within our sprints is comprehensive. Currently, the state of our tickets are usually one to two sentences with the title giving most of the description of changes that are necessary. We need to go ahead and make this change to actually include a lot of contextual information that can allow for agentic AI to create a rapid development prototype for us. Here’s an example of the following fields that should be filled out comprehensively and an example of how they can be filled out for a given feature.
| Ticket Property | Example Content |
|---|---|
| Ticket Name | PARKS-52: create collection model, interfaces, & tables for new collections feature |
| Ticket Description | Parks can be classified into different collections. Collections are a grouping of parks that have a similar attribute that connects them together. For example, consider the Mission Dolores Park and the Alta Plaza Park. Both of these are urban parks in neighborhoods that have a lot of commercial zoning. These parks also have views of San Francisco. Both of these parks can be classified into the collection “Sunset Views”. A park can relate to many different collections, and a collection can relate to many different parks. We need to design the initial interfaces and tables for storing collections and linking them with the current park model. The collection should have the following fields: int collectionIdstring collectionNamestring collectionDescriptionArray<int> linkedParksArray<int> parentCollectonsArray<int> childCollectionsA parent collection is a collection that will be comprised of other similar related collections that share a common domain. For example, the parent collection ‘Sports’ will contain the child collection tennis courts, soccer fields, basketball courts. This will allow users to sort through collections at a more rapid pace depending on the domains that they want to discover. From a visual perspective, when loading the base collections page, child collections will be held in a scrollable area under the parent collection name. The parent collections will be stacked on top of each other. It is vital that each child collection can only be a part of one parent collection. |
| Acceptance Criteria | - Create TypeScript interfaces for the Collections feature. - Create TypeScript model for the Collections feature. - Create Postgres DB tables/migrations for the Collections feature. - Create comprehensive unit tests for the Collections feature ensuring the desired behavior is functional without any bugs. |
| Current Implementation Patch | - N/A |
Approaching Unfamiliar Jira Tasks
I think one of the biggest hurdles in product development is being intimidated by a Jira ticket that you don’t have the subject area expertise it. I think a lot of this changes with the advent of Cloud Code and Cursor that is being used today.
Rather than not picking up the ticket, I think going ahead switching the model to a low-cost model, giving a brief understanding of the Jira ticket, and asking it to explore the code base and give a succinct understanding of what the ticket is addressing and how it’s currently implemented in the code base is a great start to the ticket and will allow you to get the information that’s necessary to iteratively develop on it.
Making this workflow successful
Making this workflow successful relies on the fact that the jira ticket is well documented. We should aim to keep tickets at the 4-5 sentence length at the minimum.
Enabling this Workflow:
- Identify the ticket/issue at hand and review the ticket information/description. The ticket should have the following fields filled out that will help the AI agent significantly:
ticketName,ticketDescription,acceptanceCriteria. If the fields are not filled out, please either fill them out yourself or reach out to a Product Manager or someone versed on the issue to get more context. It is not worth approaching a ticket blind. - Use a custom reusable prompt to transform the ticket information to something valuable that you can iterate on. I have designed this prompt for my use-case.
- Finish the session asking Claude to create high-level documentation for the area of code that it has worked in. Nothing about the specific implementation, rather the high-level structure that it can gain context quickly with later on.
- From here, you will pair program iteratively with Cursor or Claude code to accomplish your task. Claude has brought high level implementations into context and has accelerated the discovery workflow significantly.
- Use
/reviewat the end of your adjustments and iterate again with Claude.
Tip
At work, I have turned this workflow into a command line tool using the Claude slash commands. Take at the look at the following terminal session to see what I mean.
node RID
sfparks git(main): RID ⏺ Please supply an issue for me to spike.
sfparks git(main): RID > spike PARKS-52
sfparks git(main): RID ⏺ Pulling information from GitHub Issues...
sfparks git(main): RID ⏺ Cutting branch and assigning to agent....
sfparks git(PARKS-52): RID ⏺ Initializing Claude and feeding RID.md & PARKS-52
# lots of stuff in between...
sfparks git(PARKS-52): RID ⏺ Successfully achieved acceptance criteria for PARKS-52, opened #52 feat(PARKS-52): implemented collections model & tablesUsing RID with Subagents
Warning
The following method should be used only if your company approves it. It can be very costly if done wrong and should be carefully implemented.
This document outlines the specification for an automated development workflow system that integrates multiple development tools and processes to streamline daily development operations through intelligent orchestration and reporting.
Prerequisites
- Cloud Code API access token with appropriate permissions
- Jira API access with JQL query capabilities
- GitHub API integration for pull request management
- Slack API webhook/bot integration
- Documentation platform access (Obsidian or SharePoint) I’ll help you transform this into a more readable format with better flow. Here’s the revised version:
This document outlines the specification for an automated development workflow system that integrates multiple development tools and processes to streamline daily development operations through intelligent orchestration and reporting.
Prerequisites
The system requires several key integrations to function properly. You’ll need a Cloud Code API access token with appropriate permissions, along with Jira API access that supports JQL query capabilities. GitHub API integration is essential for pull request management, and you’ll need Slack API webhook or bot integration for notifications. Finally, ensure you have access to your documentation platform, whether that’s Obsidian or SharePoint.
Core Process Flow
Phase 1: Priority Extraction and Analysis
The workflow begins with stand-up data retrieval, where the system connects to your stand-up documentation platform to extract daily priorities assigned to the executing user. During this process, it parses and validates the priority information structure to ensure data integrity.
Once priorities are retrieved, the system performs priority classification by categorizing items based on urgency and dependency relationships. It identifies which items require immediate development attention and cross-references them with existing work items to avoid duplication and maintain consistency.
Phase 2: Jira Integration and Ticket Processing
The JQL query execution phase involves running targeted queries to find tickets in “To-Do” status. The system filters these results by assignee and priority alignment, then retrieves comprehensive ticket metadata for further processing.
Following query execution, ticket state validation ensures that each ticket hasn’t been previously processed by the workflow. The system checks for existing development artifacts or progress indicators and flags tickets that are ready for automated development initiation.
Phase 3: Automated Development Sequence
Development initiation triggers a rapid initial development sequence for all eligible tickets. The system executes pre-configured development workflow templates while continuously monitoring the development process completion status.
During artifact generation, the system creates initial code structures and documentation, generates pull requests with standardized formatting, and updates ticket status along with development tracking information.
Phase 4: Reporting and Documentation
The daily report compilation process aggregates all workflow activities and outcomes into a structured document following the specified format. This report is then stored in the designated documentation platform for future reference.
For notification distribution, the system sends the completed report through Slack API integration. These notifications include summary metrics and actionable insights, along with direct links to all generated artifacts for easy access.
Report Structure Specification
Daily Priority Overview The daily overview section presents priorities for the day and their current status. Each priority includes its ranking and description, current completion status, estimated time to completion, and any blocking dependencies that might impact progress.
Detailed Priority Documentation Each priority item links to a comprehensive sub-document that provides deep context and tracking information.
- Core Reference Links: The core reference links section provides immediate access to essential resources. This includes the GitHub Pull Request link for code review and collaboration, the Jira ticket link showing current status and history, and a context refresher document containing detailed technical documentation.
- Context Refresher Document: The context refresher document itself follows a structured format to ensure comprehensive coverage.
- Initial Research: begins with initial background research that explores the problem statement and scope analysis, along with mapping the relevant codebase domains affected by the change.
- Proposed Solution: The proposed solution section outlines the solution architecture and approach based on the background research, detailing the implementation strategy and reasoning behind key decisions.
- Implementation Details: Implementation details provide a walkthrough of the code structure and organization, explaining key technical decisions and their rationale. This section also covers integration points and dependencies to ensure smooth collaboration with existing systems.
- Acceptance Criteria: The acceptance criteria section maintains a checklist of completed requirements along with the testing strategy employed and results obtained, ensuring that all specified criteria have been met before marking the work as complete.
Linked Map of Contexts