arckit-story
$
npx mdskill add tractorjuice/arc-kit/arckit-storyCrafts governance-backed project stories with timeline analysis
- Creates historical project records from inception to completion
- Depends on PRIN artifacts for governance standards and constraints
- Uses scan results to verify external docs before generation
- Delivers ARC-{PROJECT_ID}-STORY-v1.0.md with visualizations
SKILL.md
.github/skills/arckit-storyView on GitHub ↗
---
name: arckit-story
description: "Generate comprehensive project story with timeline analysis, traceability, and governance achievements (project)"
---
You are helping an enterprise architect **generate a comprehensive project story** that documents the journey of an ArcKit-managed project from inception to completion, with heavy emphasis on timeline analysis and governance achievements.
This command creates a **ARC-{PROJECT_ID}-STORY-v1.0.md** document that serves as:
- A historical record of the project's evolution through the ArcKit governance framework
- A detailed timeline analysis with multiple visualization types (Gantt, flowchart, table, pie chart)
- A demonstration of end-to-end traceability from stakeholder needs to delivery plans
- A showcase of governance quality and compliance achievements
## User Input
```text
$ARGUMENTS
```
## Instructions
> **Note**: Before generating, scan `projects/` for existing project directories. For each project, list all `ARC-*.md` artifacts, check `external/` for reference documents, and check `000-global/` for cross-project policies. If no external docs exist but they would improve output, ask the user.
### Step 0: Read existing artifacts from the project context
**MANDATORY** (warn if missing):
- **PRIN** (Architecture Principles, in `projects/000-global/`)
- Extract: Governance standards, technology constraints, compliance framework
- If missing: warn user to run `$arckit-principles` first — principles are the foundation of the ArcKit governance framework
**RECOMMENDED** (read if available, note if missing):
- **STKE** (Stakeholder Analysis) — personas, goals, priorities
- **RISK** (Risk Register) — risks, mitigations, risk appetite
- **SOBC** (Business Case) — benefits, costs, ROI
- **REQ** (Requirements) — BR/FR/NFR/INT/DR traceability
- **DATA** (Data Model) — entities, relationships, governance
- **DIAG** (Architecture Diagrams) — C4, deployment, data flow
- **RSCH** / **AWSR** / **AZUR** — technology research
- **WARD** (Wardley Map) — strategic positioning
- **PLAN** (Project Plan) — timeline, phases, gates
- **SOW** / **DOS** — procurement documents
- **EVAL** (Evaluation Criteria) — vendor evaluation
- **HLDR** / **DLDR** (Design Reviews)
- **TCOP** (TCoP Assessment)
- **SECD** / **MSBD** — security assessments
- **DPIA** (DPIA)
- **AIPB** (AI Playbook)
- **ATRS** (ATRS record)
- **BKLG** (Product Backlog)
- **DEVOPS** (DevOps Strategy)
- **TRAC** (Traceability Matrix)
- **ROAD** (Roadmap)
- **ANAL** (Governance Analysis)
**Minimum artifact check**: A meaningful project story requires at least 3-5 artifacts. If the project has fewer than 3, warn:
```text
⚠️ Warning: This project only has [N] artifacts.
A comprehensive story typically requires at least:
- Architecture principles (global)
- Stakeholder analysis
- Requirements or Risk Register
Consider running more ArcKit commands before generating the story, or proceed
with a limited story based on available artifacts.
```
### Step 0b: Read external documents and policies
- Read any **external documents** listed in the project context (`external/` files) — extract project history, key milestones, lessons learned, user research insights, governance decisions
- Read any **enterprise standards** in `projects/000-global/external/` — extract enterprise reporting templates, programme dashboards, cross-project narrative standards
- If no external docs exist but they would enrich the project story, ask: "Do you have any project reports, user research findings, or governance decision records? I can read PDFs directly. Place them in `projects/{project-dir}/external/` and re-run, or skip."
- **Citation traceability**: When referencing content from external documents, follow the citation instructions in `.arckit/references/citation-instructions.md`. Place inline citation markers (e.g., `[PP-C1]`) next to findings informed by source documents and populate the "External References" section in the template.
### Step 1: Identify the target project
- Use the **ArcKit Project Context** (above) to find the project matching the user's input (by name or number)
- If no match, create a new project:
1. Use Glob to list `projects/*/` directories and find the highest `NNN-*` number (or start at `001` if none exist)
2. Calculate the next number (zero-padded to 3 digits, e.g., `002`)
3. Slugify the project name (lowercase, replace non-alphanumeric with hyphens, trim)
4. Use the Write tool to create `projects/{NNN}-{slug}/README.md` with the project name, ID, and date — the Write tool will create all parent directories automatically
5. Also create `projects/{NNN}-{slug}/external/README.md` with a note to place external reference documents here
6. Set `PROJECT_ID` = the 3-digit number, `PROJECT_PATH` = the new directory path
### Step 2: Comprehensive Project Artifact Scan
Scan the project directory to find ALL artifacts:
```bash
# Find all .md files in the project directory
find "$PROJECT_DIR" -type f -name "*.md" | sort
```
**Expected Artifacts** (categorize by type):
**Foundation Artifacts**:
- `ARC-*-STKE-*.md` - Stakeholder analysis
- `ARC-000-PRIN-*.md` in `projects/000-global/` - Architecture principles (global)
- `ARC-*-RISK-*.md` - Risk assessment
**Business Case Artifacts**:
- `ARC-*-SOBC-*.md` - Strategic Outline Business Case
- `ARC-*-DATA-*.md` - Data model and ERD
**Requirements Artifacts**:
- `ARC-*-REQ-*.md` - BR/FR/NFR/INT/DR requirements
**Strategic Planning Artifacts**:
- `ARC-*-RSCH-*.md` - Technology research and build vs buy
- `wardley-maps/ARC-*-WARD-*.md` - Wardley maps
- `diagrams/ARC-*-DIAG-*.md` - C4 and deployment diagrams
- `ARC-*-PLAN-*.md` - Project plan with timeline
**Procurement Artifacts**:
- `ARC-*-SOW-*.md` - Statement of Work
- `ARC-*-DOS-*.md` - Digital Outcomes and Specialists
- `ARC-*-EVAL-*.md` - Vendor evaluation framework
- `vendors/*/scoring.md` - Vendor scoring sheets
**Design Review Artifacts**:
- `vendors/*/reviews/ARC-*-HLDR-*.md` - High-Level Design reviews
- `vendors/*/reviews/ARC-*-DLDR-*.md` - Detailed Design reviews
**Delivery Artifacts**:
- `ARC-*-BKLG-*.md` - Product backlog with user stories
- `ARC-*-SNOW-*.md` - ServiceNow CMDB and SLA design
**Compliance Artifacts**:
- `ARC-*-TCOP-*.md` - Technology Code of Practice
- `ARC-*-SVCASS-*.md` - GDS Service Assessment
- `ARC-*-SECD-*.md` - Security assessment
- `ARC-*-SECD-MOD-*.md` - MOD security (if defence)
- `ARC-*-AIPB-*.md` - AI Playbook (if AI system)
- `ARC-*-ATRS-*.md` - ATRS (if algorithmic)
- `ARC-*-JSP936-*.md` - MOD AI assurance (if MOD AI)
**Governance Artifacts**:
- `ARC-*-TRAC-*.md` - End-to-end traceability
- `ARC-*-ANAL-*.md` - Governance quality analysis
For each artifact found, note:
- File path
- File name (maps to ArcKit command used)
- Date created (from file modification time or git log)
- Size (as proxy for completeness)
### Step 3: Extract Comprehensive Timeline
**Preferred Method: Git Log Analysis**
If the project is under git version control, extract the timeline from git history:
```bash
cd "$PROJECT_DIR"
# Get detailed git log with timestamps for all project files
git log --follow --format="%ai | %s" --name-only -- . | grep -E "(\.md|^[0-9]{4})"
```
This will show:
- Timestamps (YYYY-MM-DD HH:MM:SS)
- Commit messages (which often contain ArcKit command names like "$arckit-requirements")
- Files changed
**Parse this data to create timeline events**:
- Event date/time
- Command used (extract from commit message)
- Artifact created/modified
- Days from project start
**Fallback Method: File Modification Dates**
If git log is not available or sparse, use file modification times:
```bash
# Get file modification times
stat -c "%y %n" "$PROJECT_DIR"/*.md | sort
stat -c "%y %n" "$PROJECT_DIR"/vendors/*/*.md | sort
stat -c "%y %n" "$PROJECT_DIR"/diagrams/ARC-*-DIAG-*.md | sort
stat -c "%y %n" "$PROJECT_DIR"/wardley-maps/ARC-*-WARD-*.md | sort
```
**Extract Timeline Metrics**:
- **Project start date**: Earliest file/commit date
- **Project end date**: Latest file/commit date (or "Ongoing")
- **Total duration**: Days between start and end
- **Total artifacts**: Count of all .md files found
- **Commands executed**: Count of unique artifacts (proxy for commands)
- **Phase durations**: Calculate time spent in each phase based on artifact types
- **Velocity**: Artifacts per week, commands per week
- **Longest phase**: Which phase took most time and why
- **Shortest phase**: Which phase was fastest and why
**Timeline Data Structure**:
Create an internal data structure like:
```text
Timeline Events:
[
{
date: "2024-01-15",
days_from_start: 0,
event_type: "Foundation",
command: "$arckit-principles",
artifact: "ARC-000-PRIN-v1.0.md",
description: "Established enterprise architecture principles"
},
{
date: "2024-01-18",
days_from_start: 3,
event_type: "Foundation",
command: "$arckit-stakeholders",
artifact: "ARC-{PROJECT_ID}-STKE-v1.0.md",
description: "Analyzed 8 stakeholders, 12 goals, 15 outcomes"
},
...
]
```
### Step 4: Analyze Each Artifact
For each artifact found, **read the file** and extract key information:
**Stakeholder Analysis (`ARC-*-STKE-*.md`)**:
- Count: Number of stakeholders, goals, outcomes
- Key stakeholders: List names/roles
- Primary goals: Extract top 3-5 goals
- Measurable outcomes: Extract metrics
**Risk Register (`ARC-*-RISK-*.md`)**:
- Total risks: Count
- Risk breakdown: High/medium/low counts
- Top risks: Extract top 3-5 risks with scores
- Mitigation status: How many risks have mitigation plans
**SOBC (`ARC-*-SOBC-*.md`)**:
- NPV: Net Present Value
- ROI: Return on Investment
- BCR: Benefit-Cost Ratio
- Strategic alignment: Key strategic objectives
- Procurement route: G-Cloud/DOS/Traditional
**Requirements (`ARC-*-REQ-*.md`)**:
- BR count: Count of BR-xxx requirements
- FR count: Count of FR-xxx requirements
- NFR count: Count of NFR-xxx requirements (breakdown by NFR-P, NFR-SEC, NFR-S, NFR-A, NFR-C)
- INT count: Count of INT-xxx integrations
- DR count: Count of DR-xxx data requirements
- Priority breakdown: Must/Should/Could/Won't counts
- Key requirements: Extract top priority requirements
**Data Model (`ARC-*-DATA-*.md`)**:
- Entity count: Number of entities defined
- Relationship count: Number of relationships
- GDPR compliance: Lawful basis, data subject rights
- Key entities: List primary entities
**Research Findings (`ARC-*-RSCH-*.md`)**:
- Options evaluated: Count and list
- Build vs Buy decision: BUILD/BUY/HYBRID
- Rationale: Why decision was made
- Recommended vendor: If buy option chosen
**wardley-maps/ARC-*-WARD-*.md**:
- Map count: How many maps created
- Map types: Current state, future state, gap analysis, vendor comparison, etc.
- Evolution insights: Key components and their evolution stages
- Strategic recommendations: Build vs buy alignment
**diagrams/ARC-*-DIAG-*.md**:
- Diagram types: C4 context/container/component, deployment, sequence
- Component count: Number of system components
- Technology stack: Technologies identified in diagrams
- Integration points: External systems
**ARC-*-SOW-*.md**:
- Procurement route: G-Cloud/DOS/Traditional
- Requirement count: How many requirements in SOW
- Deliverables: Key deliverables listed
- Commercial terms: Payment structure, KPIs
**ARC-*-EVAL-*.md & vendors/*/scoring.md**:
- Vendors evaluated: Count
- Evaluation criteria: Technical/commercial/social value weights
- Winner: Vendor name and score
- Score breakdown: Individual vendor scores
**vendors/*/reviews/ARC-*-HLDR-*.md**:
- Verdict: APPROVED/APPROVED WITH CONDITIONS/REJECTED
- Principles compliance: Percentage
- Requirements coverage: Percentage
- Strengths: Count of strengths
- Concerns: Count of concerns
- Gaps: Count of gaps
**vendors/*/reviews/ARC-*-DLDR-*.md**:
- Verdict: APPROVED/APPROVED WITH CONDITIONS/REJECTED
- Implementation readiness: Assessment
- Security controls: Status
- Performance optimizations: Status
**ARC-*-BKLG-*.md**:
- User story count: Total stories
- Sprint count: Number of sprints
- Sprint length: Weeks per sprint
- Estimated duration: Total weeks/months
- Story breakdown: Must/Should/Could/Won't
**ARC-*-SNOW-*.md**:
- CMDB CIs: Count of configuration items
- SLA count: Number of SLAs defined
- SLA targets: P1/P2/P3/P4 response and resolution times
- Integration: ServiceNow integration approach
**Compliance artifacts** (ARC-*-TCOP-*.md, ARC-*-SVCASS-*.md, ARC-*-SECD-*.md, etc.):
- Compliance score: X/Y points
- Compliance percentage: Score as percentage
- Status: PASS/PARTIAL/FAIL or READY/NOT READY
- Key findings: List main findings
- Framework name: TCoP, GDS Service Standard, NCSC CAF, etc.
**Traceability Matrix (`ARC-*-TRAC-*.md`)**:
- Traceability coverage: Percentage
- Traceability counts: How many links in each traceability chain
- Gaps: Any gaps in traceability
**ARC-*-ANAL-*.md**:
- Artifacts analyzed: Count
- Completeness: Percentage
- Quality score: Overall governance quality
- Recommendations: Key recommendations
### Step 5: Build Traceability Chains
Using the data extracted from artifacts, map the traceability chains:
**Chain 1: Stakeholder → Requirements**
- Stakeholder Goals → Business Requirements (BR-xxx)
- Count: How many goals mapped to how many BRs
**Chain 2: Requirements → Design**
- Business Requirements → Functional Requirements
- Functional Requirements → Architecture Components (from diagrams)
- Non-Functional Requirements → NFR specifications
**Chain 3: Requirements → Vendor**
- Requirements → SOW Requirements
- SOW Requirements → Evaluation Criteria
- Evaluation Criteria → Vendor Selection
**Chain 4: Requirements → Delivery**
- Functional Requirements → User Stories
- User Stories → Sprint Backlog
**Chain 5: Data Flow**
- Data Model Entities → Data Requirements (DR-xxx)
- Data Requirements → CMDB Configuration Items
**Chain 6: Compliance Flow**
- Requirements → Compliance Assessments
- Architecture Principles → Design Reviews
- Risk Register → Security Assessments
### Step 5b: Load Mermaid Syntax References
Read `.arckit/skills/mermaid-syntax/references/gantt.md`, `.arckit/skills/mermaid-syntax/references/flowchart.md`, `.arckit/skills/mermaid-syntax/references/pie.md`, `.arckit/skills/mermaid-syntax/references/timeline.md`, and `.arckit/skills/mermaid-syntax/references/mindmap.md` for official Mermaid syntax — date formats, task statuses, node shapes, edge labels, pie chart syntax, timeline formatting, mindmap indentation, and styling options.
### Step 6: Generate Timeline Visualizations
Create **4 types of timeline visualizations** using the timeline data extracted:
**Visualization 1: Gantt Chart**
Use Mermaid gantt syntax to create a visual timeline by phase:
```mermaid
gantt
title [PROJECT_NAME] Project Timeline
dateFormat YYYY-MM-DD
section Foundation
Architecture Principles :done, principles, [START_DATE], [DURATION]
Stakeholder Analysis :done, stakeholders, after principles, [DURATION]
Risk Assessment :done, risk, after stakeholders, [DURATION]
section Business Case
Strategic Outline Business Case :done, sobc, [DATE], [DURATION]
Data Model :done, data, after sobc, [DURATION]
section Requirements
Requirements Definition :done, req, [DATE], [DURATION]
Wardley Mapping :done, wardley, after req, [DURATION]
Technology Research :done, research, after req, [DURATION]
section Procurement
Statement of Work :done, sow, [DATE], [DURATION]
Vendor Evaluation :done, eval, after sow, [DURATION]
section Design
Architecture Diagrams :done, diagrams, [DATE], [DURATION]
High-Level Design Review :done, hld, after diagrams, [DURATION]
Detailed Design Review :done, dld, after hld, [DURATION]
section Delivery
Product Backlog :done, backlog, [DATE], [DURATION]
ServiceNow Design :done, snow, after backlog, [DURATION]
section Compliance
Service Assessment :done, assessment, [DATE], [DURATION]
Secure by Design :done, secure, after assessment, [DURATION]
section Governance
Traceability Matrix :done, trace, [DATE], [DURATION]
Quality Analysis :done, analyze, after trace, [DURATION]
```
**Important**: Use actual dates from timeline data. Calculate durations between events. Only include phases/commands that actually exist in the project.
**Visualization 2: Linear Command Flow Timeline**
Use Mermaid flowchart with dates on each command node:
```mermaid
flowchart TD
Start([Project Initiated<br/>[START_DATE]]) --> Principles
Principles["arckit.principles<br/>[DATE]<br/>Architecture Principles"] --> Stakeholders
Stakeholders["arckit.stakeholders<br/>[DATE]<br/>Stakeholder Analysis"] --> Risk
Risk["arckit.risk<br/>[DATE]<br/>Risk Register"] --> SOBC
[... continue for all commands actually executed ...]
Trace["arckit.traceability<br/>[DATE]<br/>Traceability Matrix"] --> Analyze
Analyze["arckit.analyze<br/>[DATE]<br/>Quality Analysis"] --> End
End([Project Complete<br/>[END_DATE]])
style Start fill:#e1f5e1
style End fill:#e1f5e1
```
**Visualization 3: Timeline Table**
Create a detailed table with all events:
| # | Date | Days from Start | Event Type | Command | Artifact | Description |
|---|------|-----------------|------------|---------|----------|-------------|
| 1 | [DATE] | 0 | Foundation | `$arckit-principles` | ARC-000-PRIN-v1.0.md | Established enterprise architecture principles |
| 2 | [DATE] | [DAYS] | Foundation | `$arckit-stakeholders` | ARC-{PROJECT_ID}-STKE-v1.0.md | Analyzed [N] stakeholders, [M] goals, [P] outcomes |
| ... | ... | ... | ... | ... | ... | ... |
**Visualization 4: Phase Duration Pie Chart**
Calculate percentage of time spent in each phase:
```mermaid
pie title Project Phase Time Distribution
"Foundation (Principles, Stakeholders, Risk)" : [PERCENTAGE]
"Business Case & Requirements" : [PERCENTAGE]
"Research & Strategic Planning" : [PERCENTAGE]
"Procurement & Vendor Selection" : [PERCENTAGE]
"Design & Review" : [PERCENTAGE]
"Delivery Planning" : [PERCENTAGE]
"Compliance & Security" : [PERCENTAGE]
"Governance & Traceability" : [PERCENTAGE]
```
### Step 7: Generate Additional Mermaid Diagrams
**Timeline Milestone Chart**:
```mermaid
timeline
title [PROJECT_NAME] Key Milestones
[START_DATE] : Project Initiated
: Architecture Principles Established
[DATE] : Stakeholder Analysis Complete
: [N] Stakeholders, [M] Goals
[DATE] : Business Case Approved
: SOBC (5-case model)
[... key milestones with dates ...]
[END_DATE] : Project Governance Complete
: Traceability Matrix Verified
```
**Traceability Chain Flowchart**:
```mermaid
flowchart TD
subgraph Foundation
Principles[Architecture<br/>Principles<br/>[N] principles]
Stakeholders[Stakeholder<br/>Analysis<br/>[M] stakeholders]
Risk[Risk<br/>Register<br/>[Q] risks]
end
subgraph Requirements
BR[Business<br/>Requirements<br/>[BR_COUNT] BR]
FR[Functional<br/>Requirements<br/>[FR_COUNT] FR]
NFR[Non-Functional<br/>Requirements<br/>[NFR_COUNT] NFR]
end
[... show full traceability flow ...]
style Principles fill:#fff4e6
style Requirements fill:#e1f5e1
```
**Governance Achievements Mind Map**:
```mermaid
mindmap
root((Project<br/>Achievements))
Foundation
Architecture Principles Established
[N] Stakeholders Engaged
[M] Risks Managed
Business Case
SOBC Approved
[NPV] NPV
Data Model GDPR Compliant
[... continue for all phases ...]
```
### Step 8: Write Design & Delivery Review Chapters
For **the 2 key chapters** in the template, write a comprehensive narrative using the data extracted:
**Chapter 6: Design Review - Validating the Solution**
- Timeline context: Dates, duration, percentage of project timeline
- What happened: Vendor designs underwent rigorous ArcKit governance reviews
- Key activities:
- High-Level Design Review (HLD): Assessment against principles, requirements, NFRs, risks
- Detailed Design Review (DLD): API specs, database schemas, security controls, performance
- Findings: Strengths, concerns, gaps for both HLD and DLD
- Verdict: APPROVED/APPROVED WITH CONDITIONS/REJECTED for each review
- Decision Points: HLD review decision, DLD review decision
- Traceability Chain: Principles → HLD, Requirements → HLD/DLD, Risk → DLD
- Artifacts created: ARC-*-HLDR-*.md, ARC-*-DLDR-*.md
**Chapter 7: Delivery Planning - From Requirements to Sprints**
- Timeline context: Dates, duration, percentage of project
- What happened: Translating approved designs into delivery plans
- Key activities:
- Product Backlog: Requirements → GDS user stories, MoSCoW prioritization, sprint planning
- ServiceNow Design: CMDB CIs, SLA definitions, incident/change management workflows
- Backlog Summary: Story count, sprint count, velocity assumptions
- Traceability Chain: Requirements → User Stories → Sprint Backlog, Components → CMDB CIs
- Artifacts created: ARC-*-BKLG-*.md, ARC-*-SNOW-*.md
### Step 9: Calculate Timeline Metrics
Create a comprehensive metrics table:
| Metric | Value | Analysis |
|--------|-------|----------|
| **Project Duration** | [TOTAL_DAYS] days ([TOTAL_WEEKS] weeks) | [Analysis: faster/slower than typical] |
| **Average Phase Duration** | [AVG_DAYS] days | [Comparison] |
| **Longest Phase** | [PHASE_NAME] ([DAYS] days) | [Why this took longest] |
| **Shortest Phase** | [PHASE_NAME] ([DAYS] days) | [Why this was fastest] |
| **Commands per Week** | [VELOCITY] | [Velocity analysis] |
| **Artifacts per Week** | [VELOCITY] | [Output rate] |
| **Time to First Artifact** | [DAYS] days | From start to ARC-000-PRIN-v1.0.md |
| **Time to Requirements** | [DAYS] days | Critical milestone |
| **Time to Vendor Selection** | [DAYS] days | Critical milestone |
| **Time to Design Review** | [DAYS] days | Critical milestone |
| **Compliance Time** | [DAYS] days ([PERCENTAGE]% of total) | Time on compliance |
### Step 10: Write Timeline Insights & Analysis
Write comprehensive analysis sections:
**Pacing Analysis**:
- Overall pacing assessment: Steady/Accelerated/Extended
- Phase-by-phase analysis
- Comparison to typical ArcKit projects
**Critical Path**:
- Identify the critical path through the project
- Show longest dependency chains
- Identify parallel workstreams that could have been done concurrently
**Timeline Deviations**:
- Expected vs actual durations (if project plan exists)
- Reasons for deviations
- Impact assessment
**Velocity Metrics**:
- Commands per week over time
- Peak velocity periods
- Slowest periods and reasons
**Lessons Learned**:
- What went well (timeline perspective)
- What could be improved
- Recommendations for future projects
### Step 11: Detect Version
Before generating the document ID, check if a previous version exists:
1. Look for existing `ARC-{PROJECT_ID}-STORY-v*.md` files in the project directory
2. **If no existing file**: Use VERSION="1.0"
3. **If existing file found**:
- Read the existing document to understand its scope
- Compare against current project artifacts and timeline
- **Minor increment** (e.g., 1.0 → 1.1): Scope unchanged — refreshed metrics, updated timeline, corrected details
- **Major increment** (e.g., 1.0 → 2.0): Scope materially changed — new project phases covered, fundamentally different achievements, significant new artifacts added
4. Use the determined version for document ID, filename, Document Control, and Revision History
5. For v1.1+/v2.0+: Add a Revision History entry describing what changed from the previous version
### Step 12: Construct Document Control Metadata
Construct document control fields:
- **Document ID**: `ARC-{PROJECT_ID}-STORY-v{VERSION}` (e.g., `ARC-001-STORY-v1.0`)
- **Date Created**: Current date in YYYY-MM-DD format
Document control fields:
- `{document_id}`: Generated doc ID (e.g., ARC-001-STORY-v1.0)
- `{version}`: v${VERSION}
- `{status}`: Final
- `{date_created}`: Today's date
- `{last_updated}`: Today's date
- `{project_id}`: From project directory name (e.g., 001)
### Step 13: Read Template and Populate
Read the story template:
**Read the template** (with user override support):
- **First**, check if `.arckit/templates/story-template.md` exists in the project root
- **If found**: Read the user's customized template (user override takes precedence)
- **If not found**: Read `.arckit/templates/story-template.md` (default)
> **Tip**: Users can customize templates with `$arckit-customize story`
**Populate ALL placeholders** in the template with real data:
**Square bracket placeholders** (manual placeholders in template):
- `[PROJECT_NAME]` → Actual project name
- `[START_DATE]` → Earliest date from timeline
- `[END_DATE]` → Latest date from timeline
- `[TOTAL_DAYS]` → Calculated duration
- `[TOTAL_WEEKS]` → Calculated duration in weeks
- `[ARTIFACT_COUNT]` → Count of artifacts found
- `[COMMAND_COUNT]` → Count of commands executed
- `[N]`, `[M]`, `[P]`, `[Q]` → Actual counts from artifact analysis
- `[BR_COUNT]`, `[FR_COUNT]`, `[NFR_COUNT]`, etc. → Actual requirement counts
- `[DATE]` → Actual dates from timeline
- `[DAYS]` → Actual day counts
- `[PERCENTAGE]` → Actual calculated percentages
- `[VENDOR_NAME]` → Actual vendor name if selected
- `[BUILD/BUY]` → Actual decision
- All other placeholders → Replace with actual data
**Curly brace placeholders** (document control):
- `{document_id}` → Generated document ID
- `{version}` → v1.0
- `{status}` → Final
- `{date_created}` → Today's date
- `{last_updated}` → Today's date
- `{project_id}` → Project ID
**CRITICAL**:
- Replace **EVERY** placeholder with real data
- If data is not available, use "Not available" or "N/A"
- Ensure all Mermaid diagrams have real dates and data
- Ensure all tables are complete with real counts
- Write full narrative paragraphs for each chapter with real project details
Before writing the file, read `.arckit/references/quality-checklist.md` and verify all **Common Checks** plus the **STORY** per-type checks pass. Fix any failures before proceeding.
### Step 14: Write ARC-{PROJECT_ID}-STORY-v${VERSION}.md Using Write Tool
**CRITICAL**: Use the **Write tool** to create the document. Do NOT output the full content in your response.
```text
Write tool:
- file_path: projects/[PROJECT_ID]-[PROJECT_NAME]/ARC-{PROJECT_ID}-STORY-v1.0.md
- content: [Full populated template with all placeholders replaced]
```
The document will be **2000-3000 lines** with:
- Complete document control
- Executive summary with metrics
- 4 timeline visualizations
- Timeline metrics table
- Milestone timeline
- 2 detailed narrative chapters (Design Review & Delivery Planning)
- Timeline insights & analysis
- Complete traceability chain with Mermaid diagrams
- Key outcomes & achievements
- 5 comprehensive appendices
### Step 15: Show Concise Summary to User
After writing the file, show the user a **concise summary** (NOT the full document):
```text
✅ Project story generated: projects/001-cabinet-office-genai/ARC-001-STORY-v1.0.md
📊 **Project Timeline Summary**
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
**Project**: Cabinet Office GenAI Chatbot Platform
**Duration**: 79 days (11 weeks) from 2024-01-15 to 2024-04-03
**Artifacts Created**: 23 artifacts
**Commands Executed**: 22 ArcKit commands
**Velocity**: 2.0 commands/week
📅 **Timeline Breakdown**
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Phase Duration % of Project
────────────────────────────────────────────────────────
Foundation 8 days 10%
Business Case & Requirements 12 days 15%
Research & Strategic Planning 15 days 19%
Procurement & Vendor Selection 14 days 18%
Design & Review 10 days 13%
Delivery Planning 8 days 10%
Compliance & Security 8 days 10%
Governance & Traceability 4 days 5%
🎯 **Key Achievements**
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
✅ Architecture Principles Established
✅ 8 Stakeholders Analyzed → 12 Goals → 15 Outcomes
✅ 35 Risks Identified (8 high, 15 medium, 12 low)
✅ Business Case: NPV £2.4M, ROI 187%, BCR 2.87
✅ 142 Requirements Defined (23 BR, 45 FR, 52 NFR, 12 INT, 10 DR)
✅ Data Model: 12 entities, GDPR compliant
✅ Build vs Buy: BUY decision (Azure OpenAI + GOV.UK services)
✅ Vendor Selected: Microsoft (92/100 score) via G-Cloud
✅ HLD + DLD Approved
✅ 67 User Stories → 12 Sprints (24 weeks delivery)
✅ TCoP: 13/13 points ✓
✅ Service Standard: 14/14 points (Ready for Beta)
✅ NCSC CAF: 14/14 principles ✓
✅ Traceability: 98% coverage ✓
📈 **Timeline Insights**
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
• Research phase (19% of project) was critical for build vs buy decision
• Wardley mapping enabled rapid vendor selection
• Parallel compliance work accelerated governance validation
• Peak velocity: Week 4 (requirements + data model + research)
• Critical path: Principles → Stakeholders → Requirements → Research → Vendor → Design Reviews
📄 **Document Contents**
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
The 2,400-line ARC-{PROJECT_ID}-STORY-v1.0.md includes:
✓ Executive summary with timeline snapshot
✓ 4 timeline visualizations (Gantt, flowchart, table, pie chart)
✓ Timeline metrics analysis
✓ Milestone timeline
✓ 2 detailed narrative chapters (Design Review & Delivery Planning)
✓ Timeline insights & lessons learned
✓ Complete traceability chain with Mermaid diagrams
✓ Governance achievements mind map
✓ 5 comprehensive appendices (artifact register, activity log, DSM, command reference, glossary)
🔗 **Traceability Verified**
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Stakeholders (8) → Goals (12) → Outcomes (15)
Goals → Business Reqs (23) → Functional Reqs (45)
Requirements (142) → User Stories (67) → Sprints (12)
Data Model (12 entities) → Data Reqs (10) → CMDB CIs (28)
Requirements → Architecture Components → Tests
Coverage: 98% ✓
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
The story demonstrates systematic architecture governance from stakeholder needs through to delivery plans, with full timeline visibility and end-to-end traceability.
```
**Adapt the summary** based on actual project data. Show real numbers, real dates, real achievements.
## Important Notes
1. **Prerequisites first**: Always check that architecture principles exist before generating a story. The principles command (`$arckit-principles`) is the foundation of the ArcKit governance framework and should be the FIRST command run in any project.
2. **Use Write tool**: The ARC-{PROJECT_ID}-STORY-v1.0.md will be 2000-3000 lines. You MUST use the Write tool to avoid exceeding token limits.
3. **Real data only**: Replace ALL placeholders with real data extracted from artifacts. No "[PLACEHOLDER]" should remain in the final document.
4. **Timeline emphasis**: The story is primarily about the timeline. Every chapter should have timeline context (dates, durations, pacing analysis).
5. **Git log preferred**: If available, use git log for most accurate timeline. Fall back to file modification dates if needed.
6. **Comprehensive analysis**: Don't just list what happened - analyze why, how it compares to typical projects, what lessons can be learned.
7. **Mermaid diagrams**: Generate at least 7-10 Mermaid diagrams (Gantt, flowchart, table, pie, timeline, traceability, mind map, DSM).
8. **Traceability**: Show complete end-to-end traceability chains with actual counts.
9. **Metrics**: Calculate real metrics (velocity, phase durations, percentages).
10. **Narrative**: Write engaging narrative chapters that tell the story of how the project evolved, not just a dry list of facts.
11. **Quality**: This is a showcase document. Make it comprehensive, accurate, and professionally written.
- **Markdown escaping**: When writing less-than or greater-than comparisons, always include a space after `<` or `>` (e.g., `< 3 seconds`, `> 99.9% uptime`) to prevent markdown renderers from interpreting them as HTML tags or emoji
## Example Usage
```bash
# Generate story for a specific project
$arckit-story Cabinet Office GenAI
# Generate story for project by number
$arckit-story 009
# Let user choose from list
$arckit-story
# Generate story for current directory
cd projects/009-cabinet-office-genai
$arckit-story .
```
## Success Criteria
- ✅ Prerequisites checked (architecture principles exist)
- ✅ ARC-{PROJECT_ID}-STORY-v1.0.md created in project directory
- ✅ All timeline data extracted from git log or file dates
- ✅ All placeholders replaced with real data
- ✅ 4 timeline visualizations generated
- ✅ 2 key narrative chapters written (Design Review, Delivery Planning)
- ✅ Timeline metrics calculated
- ✅ Timeline insights & lessons learned written
- ✅ Complete traceability chain documented
- ✅ All Mermaid diagrams generated with real data
- ✅ Comprehensive appendices included
- ✅ Document control metadata populated
- ✅ Concise summary shown to user
This command creates a comprehensive historical record and demonstration of the ArcKit governance framework in action, with timeline as a first-class feature throughout.