init-context

What this skill does

# 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:

```markdown
# 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.
```