Use IBM Bob to analyze the Galaxium Travels codebase and produce structured audit reports covering code quality, dependency health, technical debt, and compliance posture. Learn how to assemble stakeholder-ready documentation from AI-assisted analysis.

Software audits produce the documentary evidence that engineering teams, security reviewers, and compliance stakeholders rely on before shipping, acquiring, or certifying a system.

In this tutorial, you use Bob to systematically analyze the Galaxium Travels codebase and generate five structured artifacts:

A code quality summary: Highlights maintainability, complexity, and style issues across the codebase.

A dependency audit: Flags outdated, vulnerable, or unused third-party packages.

A technical debt assessment: Catalogs shortcuts, workarounds, and areas needing refactor.

Compliance documentation: Records findings against relevant regulatory or organizational standards.

A compiled stakeholder audit report that combines all findings: Consolidates the above into a single shareable document.

You structure your prompts to elicit detailed, evidence-backed findings without remediation suggestions.

By the end of this tutorial, you have a set of audit documents that you can share with stakeholders and use as a baseline for remediation planning.

In this tutorial, Bob's output may differ from the examples depending on the current state of the codebase. Use the generated reports as a starting point and refine the findings before distributing them to stakeholders.

Key features you learn

Context mentions: Reference specific files and folders in your prompts using the @ symbol. Context mentions let Bob know exactly which files to analyze for accurate, evidence-backed findings.

Agent mode: Let Bob write files autonomously to persist generated artifacts to your project.

Prompt engineering for structured output: Structure your prompt to include your desired output format to get stakeholder-ready documents rather than narrative prose.

Prerequisites

IBM Bob IDE

Download and install IBM Bob v2.x or later.

Git

Git is required to clone the example repository.

Set up your workspace

Clone the Galaxium Travels repository

In your terminal, run the following command to clone the Galaxium Travels example repository:

git clone https://github.com/IBM/galaxium-travels

This tutorial uses the repository's main branch, not bob-learning-path-branch. The Java hold service and other components this tutorial references are only present on main.

Launch IBM Bob

Launch the IBM Bob IDE on your computer.

Open the example project

In the Bob IDE, open the galaxium-travels folder you cloned. If Bob asks "Do you trust the authors of the files in the folder?", click Yes, I trust the authors.

Review the README.md file in the root directory to get an overview of the application architecture. Galaxium Travels is a full-stack space travel booking system with a Python FastAPI backend, a React/TypeScript frontend, and a Java Spring Boot inventory hold service.

Open the Bob chat interface

If the chat interface is not already open, click the Bob icon in the navigation bar or use the shortcut Option + Command + B (Mac) or Ctrl + Alt + B (Windows).

Initialize project context

Bob defaults to Agent mode on startup. If you have changed modes, switch to Agent mode before running the initialization command. Bob needs to write files to set up the project context. This tutorial uses Agent mode's default capabilities rather than scoping permissions per task, so Bob can read and write files without additional configuration.

Enter the /init command in the chat interface input field.

/init

If auto-approval is disabled, Bob asks your permission before reading files and writing changes. Approve these prompts when they appear — this applies to the /init command and to each report Bob writes later in the tutorial.

Bob reads the relevant files in the project and generates the main AGENTS.md file in the root directory, along with a .bob/ folder containing mode-specific AGENTS.md files. Verify that AGENTS.md and a .bob/ folder appear in the project root before continuing. Review the generated files to understand what Bob has inferred about the project structure, technology stack, and key patterns. This context directly improves the quality of the analysis in subsequent prompts.

Generate a code quality summary

A code quality summary gives engineers and reviewers a structured view of issues across the codebase: anti-patterns, missing safeguards, test coverage gaps, and inconsistencies that accumulate over the lifetime of a project. Unlike a linter report, a Bob-generated quality summary synthesizes findings across languages and layers with human-readable explanations and severity context.

The Galaxium Travels codebase spans three distinct stacks: Python (backend), TypeScript (frontend), and Java (hold service). Structure your prompt to analyze each service independently and then produce a unified findings table. Use context mentions to give Bob precise file scope rather than letting Bob guess which files are relevant.

Start a new task

Click the + button to start a new task. Starting fresh keeps this prompt's context limited to the files you mention here, rather than carrying over everything Bob read during /init.

Generate the code quality summary

In Agent mode, enter the following prompt in the chat input field:

Analyze the code quality of the Galaxium Travels application across all three
services.

For the Python backend, examine @booking_system_backend/server.py,
@booking_system_backend/models.py, @booking_system_backend/services, and
@booking_system_backend/tests.

For the TypeScript frontend, examine @booking_system_frontend/src.

For the Java hold service, examine
@booking_system_inventory_hold_service/src/main/java/com/galaxium/holdservice.

Produce a structured Markdown file named `docs/audit/code-quality-summary.md`.
The content should include the following sections:
1. An overview table listing each component, language, files analyzed, and
   issue count by severity (Critical, High, Medium, Low).
2. Per-component findings, each with: severity label, issue title, file and
   approximate line reference, description, and impact.

Focus on: missing input validation, inconsistent error handling, authentication
and credential storage patterns, test coverage gaps, type safety, and logging
practices. Do not suggest fixes — only report findings with evidence from the
source files.

Bob analyzes the three services, creates the docs/audit/ directory if it does not already exist, creates the Markdown file, and outputs a summary to the chat interface. The report contains the sections and structure you specified, with findings that reference specific files and lines of code as evidence.

Verify the report

Open docs/audit/code-quality-summary.md in the Bob file explorer to confirm the file was created with the overview table and per-component findings before you continue.

Run a dependency audit

A dependency audit establishes whether the libraries a project depends on are pinned to known-good versions, whether pinning strategies are consistent across the polyglot stack, and whether any dependency configuration practices introduce uncontrolled upgrade risk. This is distinct from a CVE scan: you are evaluating version management discipline, not just known vulnerabilities.

The Galaxium Travels project has three dependency manifests: booking_system_backend/requirements.txt (Python), booking_system_frontend/package.json (Node.js), and booking_system_inventory_hold_service/pom.xml (Java/Maven). Include all three in your context mentions.

Start a new task

Click the + button to start a new task.

Generate the dependency audit

In Agent mode, enter the following prompt in the chat input field:

Audit the dependency manifests for all three services in the Galaxium Travels
repository.

Analyze @booking_system_backend/requirements.txt,
@booking_system_frontend/package.json, and
@booking_system_inventory_hold_service/pom.xml.

Produce a structured Markdown file named `docs/audit/dependency-audit.md`.
The content should include these sections:
1. Per-manifest findings table: package name, declared version or range,
   pinning status (exact, caret/tilde range, or unpinned), and a brief
   finding note.
2. Cross-cutting findings: consistency issues, missing tooling (lock files,
   audit CI steps, vulnerability scanners), and version drift risks.
3. Findings that require immediate attention before a production deployment,
   listed with rationale.

Report findings only. Do not generate upgrade commands or patch suggestions.

Bob analyzes the manifests and writes the report. It includes a pinning-status table and a cross-cutting findings section.

Verify the report

Open docs/audit/dependency-audit.md to confirm the per-manifest tables and the cross-cutting findings section are present before you continue.

Assess technical debt

A technical debt assessment evaluates structural, architectural, and operational decisions that accumulate cost over time. Structure your prompt to separate debt into architecture, security, operational readiness, and code quality, and to rate each item's severity and remediation effort so leadership can prioritize it.

The following prompt includes AGENTS.md in the context mentions to give Bob insight into the inferred architecture and operational patterns, which can inform the assessment of architectural and operational debt. The /init command that you ran in the Initialize project context section created the AGENTS.md file.

Start a new task

Click the + button to start a new task.

Generate the technical debt assessment

In Agent mode, enter the following prompt in the chat input field:

Conduct a technical debt assessment of the Galaxium Travels application.
Analyze the full codebase across all three services:
@booking_system_backend, @booking_system_frontend, and
@booking_system_inventory_hold_service.

Also review @docker-compose.yml and @AGENTS.md for infrastructure and
operational context.

Produce a structured Markdown file named `docs/audit/technical-debt-assessment.md`.
The content should include these sections: Architecture Debt, Security Debt, Operational Readiness Debt, and Code Quality Debt.

For each debt item include:
- A severity label: [CRITICAL], [HIGH], [MEDIUM], or [LOW]
- An effort-to-resolve label: [DAYS], [WEEKS], or [MONTHS]
- A title
- The affected files or components
- A description of the debt and why it matters
- The consequence of leaving it unaddressed

Conclude with a summary table: category, count by severity, and total items.
Report findings only. Do not generate implementation plans or code.

Bob analyzes the codebase and writes the report, labeling each debt item with severity and effort estimates.

Verify the report

Open docs/audit/technical-debt-assessment.md to confirm the four debt categories and the summary table are present before you continue.

Generate compliance documentation

Compliance documentation maps a codebase's current state against the controls that regulators, auditors, and enterprise security teams expect to find in a production system. For stakeholders who are not engineers, this document answers the question: "What does this system do with sensitive data, how is access controlled, and where are the gaps?"

Structure your prompt to cover data classification, authentication and access control, data protection, audit trail coverage, and license compliance.

Start a new task

Click the + button to start a new task.

Generate the compliance documentation

In Agent mode, enter the following prompt in the chat input field:

Generate compliance documentation for the Galaxium Travels application,
suitable for sharing with security reviewers and compliance stakeholders.

Analyze the following files and directories:
@booking_system_backend/models.py,
@booking_system_backend/server.py,
@booking_system_backend/services,
@booking_system_backend/requirements.txt,
@booking_system_inventory_hold_service/src/main/java/com/galaxium/holdservice/domain,
@booking_system_inventory_hold_service/pom.xml,
@booking_system_frontend/src,
@booking_system_frontend/package.json,
@LICENSE.

Produce a structured Markdown file named `docs/audit/compliance-documentation.md`. The content should include these sections:
1. Data Classification — table of data elements, classification tier, storage
   location, and retention policy.
2. Authentication and Access Control — table of controls, implementation status
   (Implemented / Partial / Not Implemented), and a source reference or gap note.
3. Data Protection — table of controls, implementation status, and notes.
4. Audit Trail Coverage — what is logged, what is not, and where audit records
   are stored.
5. License Compliance — table of key dependencies (Python, Node, and Java) with
   their license and a compliance note.
6. Regulatory Applicability — brief assessment of GDPR, SOC 2, and PCI DSS
   applicability given the data the system handles.

Use neutral, factual language. Do not recommend remediations.

Bob analyzes the source files and writes the report, mapping each control to an implementation status with a code reference.

Verify the report

Open docs/audit/compliance-documentation.md to confirm all six sections are present before you continue.

Compile a stakeholder audit report

With four separate analyses complete, ask Bob to assemble them into a single executive-facing audit report. A stakeholder report differs from the per-topic analyses: it leads with a findings summary, prioritizes the most actionable items, and provides a recommended remediation order that non-technical readers can act on.

The prompt uses context mentions to load the four reports Bob wrote to disk in the previous sections. Bob reads those files and synthesizes them into a single document rather than re-analyzing the source code, so the output reflects the findings you have already reviewed.

Start a new task

Click the + button to start a new task.

Generate the stakeholder audit report

In Agent mode, enter the following prompt in the chat input field:

Using @docs/audit/code-quality-summary.md, @docs/audit/dependency-audit.md,
@docs/audit/technical-debt-assessment.md,
and @docs/audit/compliance-documentation.md, compile a consolidated
stakeholder audit report for the Galaxium Travels application.

The audience is engineering leadership and security reviewers who need to
assess the system's production readiness and compliance posture without
reading four separate documents.

Structure the report as follows:
1. Executive Summary: 2-3 paragraphs covering overall state, most critical
   risks, and the highest-priority remediation categories.
2. Production Readiness Scorecard: a table scoring the system against six
   dimensions (Authentication, Data Protection, Observability, Dependency
   Health, Test Coverage, Operational Readiness) with a RAG status
   (Red / Amber / Green) and a one-line rationale for each.
3. Critical and High Findings: a consolidated table of all Critical and High
   severity findings from all four analyses, with category, finding title,
   affected component, and effort to resolve.
4. Recommended Remediation Sequence: an ordered list of the top 5 items to
   address first, with a brief rationale for the ordering.
5. Positive Findings: a brief section acknowledging controls and practices
   that are already well-implemented.

Do not repeat all findings in full. Reference the detailed documents for
complete findings. Save the report as `docs/audit/stakeholder-audit-report.md`.

Bob reads the four saved reports, synthesizes their findings, and creates docs/audit/stakeholder-audit-report.md. Because Bob works from the reports you already reviewed rather than re-analyzing the source code, the consolidated report stays consistent with the detailed findings.

Verify the report

Open docs/audit/stakeholder-audit-report.md to confirm the executive summary, the scorecard, and the five sections are present. You now have a complete set of audit documents in docs/audit/ to share with stakeholders and use as a baseline for remediation planning.

Troubleshooting

Bob's analysis omits a service or file

If Bob's output is missing findings for a component you expected to see covered, the most likely cause is that the prompt did not include the file or directory in the context mention, or the context window was too full for Bob to read all the referenced content in a single pass.

Check your context mentions

Verify that the @ mention in your prompt resolves to the correct path. In the Bob chat interface, Bob may indicate whether a context mention was resolved. If Bob does not recognize the mention, the path may be misspelled or the directory may not exist in your local clone.

For directories with many files, Bob may read only a subset. Narrow the scope to the most relevant subdirectory or enumerate specific files rather than referencing the entire folder.

Split the analysis into focused prompts

Instead of a single prompt covering all three services, run three separate prompts, one per service, and then ask Bob to merge the findings. For example, here is the third focused prompt after completing the Python and TypeScript passes:

The code quality analysis we ran earlier covered the Python backend and
TypeScript frontend. Run the same analysis for the Java hold service only,
using @booking_system_inventory_hold_service/src. Use the same output format
and severity labels as the earlier reports.

After each focused analysis is complete, ask Bob to merge them:

Combine the three per-service code quality analyses into a single unified
report using the same format we used for the initial report.

Reports contain conflicting findings across prompts

When running a multi-prompt session, later prompts may produce findings that appear to contradict earlier ones. This can happen if Bob draws different inferences from different file reads, or if an earlier finding was imprecise.

Identify the conflicting claims

Quote both findings in a new prompt and ask Bob to resolve the discrepancy with a specific file reference. For example:

In the code quality summary you stated that error handling in server.py is
inconsistent. In the technical debt assessment you described the same issue
as absent error handling. Review @booking_system_backend/server.py and clarify
which description is more accurate, with a specific line reference.

Update the affected report

After Bob has produced the authoritative finding, ask Bob to update the specific section in the saved report file. For example, if the technical debt assessment is more accurate, ask Bob to update the code quality summary:

Update the error handling finding in docs/audit/code-quality-summary.md to
use the corrected description. Do not change any other section.

Bob adds unsolicited recommendations to the analysis

When a prompt asks Bob to "analyze" or "assess" without explicit constraints, Bob often includes remediation suggestions alongside findings. For a compliance or audit report, unsolicited recommendations may be problematic: they may be incorrect, they may reflect assumptions about the target environment, and they may confuse stakeholders who expect a findings-only document.

Add the instruction "Report findings only. Do not generate implementation plans, code, or remediation suggestions." to any analysis prompt where this matters. If Bob has already generated a report with mixed content, ask Bob to strip the recommendations. For example, if the code quality summary contains recommendations, enter the following prompt:

Remove all remediation suggestions, implementation guidance, and code examples
from docs/audit/code-quality-summary.md. Keep all finding descriptions,
severity labels, file references, and impact statements exactly as written.

Clean up

To remove the artifacts created in this tutorial:

Delete the docs/audit/ directory, which contains the five generated reports.

If you do not want to keep the project context Bob generated, delete the AGENTS.md file and the .bob/ folder that the /init command created.

Delete the galaxium-travels directory you cloned in Set up your workspace.

Next steps

In this tutorial, you used IBM Bob to:

Initialize project context with /init so Bob's analysis reflects the project's structure and technology stack

Generate four focused audit artifacts, a code quality summary, a dependency audit, a technical debt assessment, and compliance documentation. Each backed by evidence from the source files

Compile the four analyses into a single stakeholder audit report with a production readiness scorecard and a recommended remediation sequence

Use Agent mode and context mentions to persist each report to disk, keeping the analyses self-contained and token-efficient

Continue with the following resources:

Follow Audit code and generate reports to produce machine-readable SARIF and OSCAL artifacts that developer tooling and AI agents can act on.

Use the findings as a baseline, then follow Generate secure code with an actor-critic workflow to remediate without reintroducing the issues this audit surfaced.

Read Bob best practices for more effective prompting strategies.

Generate audit reports and compliance documentation

IBM Bob IDE

Git

On this page