# How Timeline and Workitems Get Populated in a Reverse-Skill Case: A Complete Guide

> Discover how timeline and workitems populate in a reverse-skill case. Learn how case-init.ps1 and skill phases create and update these crucial files for your reverse-skill workflow.

- Repository: [ZhaoXu/reverse-skill](https://github.com/zhaoxuya520/reverse-skill)
- Tags: how-to-guide
- Published: 2026-08-13

---

**The [`timeline.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/timeline.md) and [`workitems.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/workitems.md) files in a reverse-skill case are created once during initialization by `case-init.ps1` using PowerShell here-strings, then populated through append-only updates by each subsequent skill phase.**

This article explains the exact mechanism that populates these two critical artifacts in the [reverse-skill](https://github.com/zhaoxuya520/reverse-skill) repository. Understanding this flow is essential for anyone building custom skills or auditing case progress.

---

## Initial Creation During Case Initialization

Both files are born at the same moment: immediately after the case directory is created. The `skills/scripts/case-init.ps1` script generates deterministic baseline templates using **PowerShell here-strings** and writes them with `[System.IO.File]::WriteAllText`.

### How timeline.md Is Created

The timeline receives a standard header and a single entry documenting the init phase:

```powershell

# From skills/scripts/case-init.ps1 (lines 247-273)

$timeline = @"

# Timeline (append-only)

## $created | lead | init

- action: case-init
- command_or_ref: skills/scripts/case-init.ps1
- result_summary: $timelineSummary
- artifacts: [scope.md, workitems.md]
- evidence_ids: []
- next: $timelineNext
"@

[System.IO.File]::WriteAllText((Join-Path $caseRoot 'timeline.md'), $timeline, $utf8)

```

### How workitems.md Is Created

The workitems file receives a markdown table with one initial row plus a **Coverage** checklist:

```powershell

# From skills/scripts/case-init.ps1 (lines 259-274)

$workitems = @"

# Work Items

| ID | title | role | targets | surface | status | evidence | notes |
|----|-------|------|---------|---------|--------|----------|-------|
| WI-001 | Establish scope and auth | lead | case | process | in_progress | | |

## Coverage

- [ ] Recon/analysis complete for in_scope assets
- [ ] Critical/High candidates triaged and assigned to leads
- [ ] Evidence files created, annotated, and mapped to work items
- [ ] Exploit/path documentation captured before memory fades
- [ ] Final report links back to complete timeline and all work items
"@

[System.IO.File]::WriteAllText((Join-Path $caseRoot 'workitems.md'), $workitems, $utf8)

```

**Key design decision**: Both files are created with final, UTF-8-encoded content in a single atomic write. This eliminates partial-write risks and establishes a known-good starting state.

---

## Subsequent Population: The Append-Only Model

After initialization, how do timeline and workitems get populated in a reverse-skill case? Through **strict append-only operations** performed by each skill phase.

### Timeline Structure for New Entries

Every skill phase adds a block following this exact schema:

```markdown

## <ISO8601 timestamp> | <role> | <phase>

- action: <what was done>
- command_or_ref: <script or command reference>
- result_summary: <outcome description>
- artifacts: [<list of files produced>]
- evidence_ids: [<E-XXX reference IDs>]
- next: <next phase name>

```

### Workitem Updates

| Operation | Method |
|-----------|--------|
| **New work item** | Append row to markdown table |
| **Status change** | Add new row with updated status (append-only history) |
| **Coverage progress** | Convert `- [ ]` to `- [x]` in place ( Markdown allows this) |

---

## Practical Example: Creating and Populating a Case

### Step 1: Run Initialization

```powershell
.\skills\scripts\case-init.ps1 -CaseName demo -Primary pentest-tools

```

This creates [`work/demo/timeline.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/work/demo/timeline.md) and [`work/demo/workitems.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/work/demo/workitems.md) with the baseline content shown above.

### Step 2: A Skill Appends Timeline Data

During a recon phase, a skill script adds:

```powershell
$phaseEntry = @"

## $(Get-Date -Format o) | pwn-specialist | recon

- action: download & triage binary
- command_or_ref: file pwn1; checksec --file=./pwn1
- result_summary: ELF 64-bit, no PIE, NX enabled, partial RELRO
- artifacts: [pwn1, checksec.json]
- evidence_ids: [E-001]
- next: static-analysis
"@

Add-Content (Join-Path $CaseRoot 'timeline.md') $phaseEntry

```

### Step 3: Same Skill Updates Workitems

```powershell
$newWorkItem = "| WI-002 | Triage pwn1 binary | pwn-specialist | pwn1 | binary | done | E-001 | checksec shows NX+no-PIE |"
Add-Content (Join-Path $CaseRoot 'workitems.md') $newWorkItem

```

---

## Schema Enforcement and Validation

The format for both files is formally specified in **[`skills/ops/timeline-workitem.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/timeline-workitem.md)**, which documents:

- Required section headings (`# Timeline (append-only)`, `# Work Items`)

- Mandatory fields for timeline entries (timestamp, role, phase, action, command_or_ref, result_summary, artifacts, evidence_ids, next)
- Table column order for work items (ID, title, role, targets, surface, status, evidence, notes)
- Coverage checklist items that must be satisfied before phase transition

The **`skills/scripts/verify-routing-coherence.ps1`** script validates that:

1. Both [`timeline.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/timeline.md) and [`workitems.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/workitems.md) exist in the case directory
2. Required fields are present in the latest timeline entry
3. The Coverage checklist has been completed for the current phase

---

## Evidence Integration Flow

A typical skill execution chains these operations:

```

skill script runs
    ├── executes commands (produces raw output)
    ├── calls scripts/append-evidence.ps1 → creates E-XXX files
    ├── appends timeline entry with evidence_ids: [E-XXX]
    └── appends/updates workitems.md with status and evidence reference

```

This creates **bidirectional traceability**: evidence files reference their source commands via filenames, while the timeline references evidence IDs.

---

## Summary

- **`case-init.ps1`** creates both files using here-strings and atomic `WriteAllText` operations
- **Timeline** receives append-only entries with complete context (timestamp, role, action, results, artifacts, evidence IDs, next step)
- **Workitems** grows with new rows and status updates, plus a Coverage checklist tracking phase completion
- **Schema enforcement** comes from [`ops/timeline-workitem.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/ops/timeline-workitem.md) and `verify-routing-coherence.ps1`
- **Evidence integration** links the narrative timeline to concrete technical artifacts

---

## Frequently Asked Questions

### What happens if a skill overwrites instead of appends?

The system design assumes append-only behavior. Overwriting would destroy audit history and break the `verify-routing-coherence.ps1` validation. Always use `Add-Content` or equivalent append operations in skill scripts.

### Can I customize the initial workitems template?

Yes, by modifying the `$workitems` here-string in `skills/scripts/case-init.ps1` (lines 259-274), though this affects all future cases. For per-case customization, append additional rows after initialization.

### How do I reference evidence in the timeline?

Include evidence IDs in the `evidence_ids` field as a bracketed list: `evidence_ids: [E-001, E-002]`. These correspond to files created by `scripts/append-evidence.ps1` in the case's `evidence/` directory.

### Why is the Coverage checklist in workitems.md instead of a separate file?

Colocating the checklist with work items ensures visibility: every status review of the workitem table surfaces coverage gaps. This design prevents "checklist blindness" where separate files are forgotten.