Project Management

Almirah offers two ways to manage project work, and they are not mutually exclusive: track it natively with decision records, or integrate almost any task/issue tracking software — or combine both.

Decision records: project management without a tracker

The framework’s native, GenAI-ready way needs no extra tool at all. Work is captured as decision records — Markdown files (ADR / ISSUE / ENH) living in the decisions/ folder, versioned right next to the specifications and tests they affect.

The key idea: these records are not tasks. They are decisions that led to implementation, testing, or other activities — even a software defect is a decision record, because it requires an investigation and, at the end, a decision on whether to fix it. Each record carries its own status history (Proposed → Accepted → In-Progress → Implemented), a Scope table that breaks the decision down into work items with owners, dependencies, and effort estimates, and an Affected Documents table that links the record into the project’s traceability graph. Almirah renders every record as an HTML page plus a summary overview — a project backlog generated from plain files, with no data silo and no tokens burned on extracting context from a separate tool.

See Decision Records for the full anatomy, or explore a live demo.

Using a task/issue tracker

Prefer a tracker your organization already runs? Feel free to use the Almirah framework with any task/issue tracking software if this software meets the following requirements:

1. Task/Issue Tracking Software Component shall allow to create different WBS Item types;
2. Task/Issue Tracking Software Component shall allow to create a custom WBS Item states for each item type;
3. Task/Issue Tracking Software Component shall allow to create a custom workflow for each WBS Item type;
4. Task/Issue Tracking Software Component shall allow to write a description for each WBS Item.

Sometimes, task/issue tracking software satisfies all the requirements listed above. However, access to these features requires admin rights.

Combining both: mapping decision records to WBS items

Decision records do not compete with a tracker — they can be mapped onto it. A decision record then remains the single place where the decision and its context live (visible to reviewers and GenAI assistants alike), while the tracker manages the execution:

• each row of the record’s Scope table corresponds to a WBS item in the tracker, carrying the same owner, dependencies, and estimates;
• the record’s status history mirrors the WBS item workflow (Proposed → Accepted → In-Progress → Implemented);
• the References section of the record points at the tracker items, so the two stay connected in both directions.

This way teams that must keep a corporate tracker still get the traceability and the GenAI-native context of decision records — and teams that do not can simply skip the tracker altogether.