init-context

name	init-context
description	Initialize project context document for faster AL development workflows. One-time setup that reduces workflow runtime by 40-60%.

Init Context Workflow

You are an engineering manager orchestrating the creation of a shared project context document. This document accelerates all downstream workflows by giving agents pre-indexed knowledge of the codebase.

Output

File: .dev/project-context.md (at the project root, NOT inside a task subfolder — this is shared across all workflows).

Procedure

Step 1: Check for Existing Context

Check if .dev/project-context.md already exists.

• If it exists, present the user with three options:
  • Update — Incrementally update only sections that are stale (check file modification dates, recent git commits).
  • Regenerate — Delete and rebuild from scratch.
  • Cancel — Abort the workflow.
• If it does not exist, proceed to Step 2.

Step 2: Explore the Project

Spawn a subagent (medium thoroughness) to explore the AL project. The agent must document:

1. Directory structure — Top-level layout, src/ organization, test folders, build artifacts.
2. All custom objects — Object IDs, names, types (table, page, codeunit, enum, etc.), and one-line purpose for each.
3. Architectural patterns — How the project handles validation, table extensions, error handling, event subscriptions, permissions.
4. Base app integration — Which standard tables are extended, which standard events are subscribed to, which standard procedures are called.
5. Common code locations — Where utilities live, where business logic concentrates, where UI logic lives.
6. Dependencies — app.json dependencies, runtime version, target platform.
7. Testing infrastructure — Test codeunits, test runners, any test helper utilities.

Instruct the agent to be thorough but not exhaustive — aim for the information another developer (or agent) would need to start contributing within minutes.

Step 3: Validate

Review the generated context for:

• Missing objects (compare object count against actual .al files).
• Incorrect object IDs or names.
• Empty sections (every section should have content or an explicit "None identified").

If gaps are found, send the agent back to fill them.

Step 4: Confirm

Present the user with a summary:

• Number of objects indexed.
• Key architectural patterns found.
• Any warnings or gaps.
• File path of the generated context.

---

Project Context Template

The generated .dev/project-context.md must follow this structure:

# Project Context

> Auto-generated by init-context workflow. Last updated: YYYY-MM-DD HH:MM.
> Do not edit manually — re-run the init-context workflow to update.

## Project Overview

- **App Name**: (from app.json)
- **Publisher**: (from app.json)
- **Version**: (from app.json)
- **Runtime**: (from app.json)
- **Target**: (from app.json)
- **Brief Description**: One paragraph summarizing what this app does.

## Directory Structure

project-root/ ├── src/ │ ├── ... ├── test/ │ ├── ... ├── .dev/ │ └── project-context.md ← you are here ├── app.json └── ...

## Key Objects Registry

| Type | ID | Name | Purpose |
|------|----|------|---------|
| table | 50100 | "Example Table" | Stores ... |
| page | 50100 | "Example Card" | Card page for ... |
| codeunit | 50100 | "Example Mgt." | Business logic for ... |
| ... | ... | ... | ... |

## Architectural Patterns

### Validation
How field validation is implemented (ValidatingTrigger, OnValidate subscribers, etc.).

### Extension Pattern
How table/page extensions are structured and named.

### Error Handling
Error vs. FieldError usage, try-functions, error messages pattern.

### Event Subscriptions
Subscriber naming conventions, which publishers are used.

### Permissions
Permission set structure, how permissions are assigned.

## Base App Integration Points

### Extended Tables
| Base Table | Extension Object | Fields Added |
|-----------|-----------------|--------------|
| ... | ... | ... |

### Subscribed Events
| Publisher Object | Event | Subscriber Codeunit | Purpose |
|-----------------|-------|--------------------:|---------|
| ... | ... | ... | ... |

### Called Procedures
Notable calls to base app procedures and their context.

## Common Code Locations

| Category | Path / Object | Notes |
|----------|--------------|-------|
| Business logic | ... | ... |
| UI logic | ... | ... |
| Utilities | ... | ... |
| Setup / configuration | ... | ... |

## Dependencies

| App Name | Publisher | Version | Purpose |
|----------|----------|---------|---------|
| (from app.json dependencies) | ... | ... | ... |

## Testing Infrastructure

- **Test codeunits**: List with object IDs and what they test.
- **Test helpers / libraries**: Any shared test utilities.
- **Test data setup**: How test data is created.
- **How to run tests**: Commands or configuration needed.

## Recent Changes Log

| Date | Commit / Change | Summary |
|------|----------------|---------|
| (last 5-10 relevant commits) | ... | ... |

## Instructions for Agents

- Always read this file before starting work on a task.
- If this file is more than 7 days old, suggest running init-context to refresh it.
- Object IDs in the registry are authoritative — use the next available ID when creating new objects.
- Follow the architectural patterns documented above; do not invent new patterns without explicit approval.
- Check Base App Integration Points before modifying extension objects.