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.
More from tractorjuice/arc-kit
- architecture-workflowThis skill should be used when the user asks how to start an architecture project, which ArcKit commands to run and in what order, what workflow to follow, getting started, new project setup, guide me through, or what comes next.
- arckit-adrDocument architectural decisions with options analysis and traceability
- arckit-ai-playbookAssess UK Government AI Playbook compliance for responsible AI deployment
- arckit-analyzePerform comprehensive governance quality analysis across architecture artifacts (requirements, principles, designs, assessments)
- arckit-at-bvergg[COMMUNITY] Generate Austrian public procurement documentation aligned with Bundesvergabegesetz 2018 — Oberschwellen/Unterschwellen determination, ANKÖ publication, BVergGVS secondary rules, and BVwG review pathway
- arckit-at-dsgvo[COMMUNITY] Assess Austrian DSG / DSGVO obligations — Datenschutzbehörde patterns, §§12–13 DSG special provisions, image processing (§12 DSG), and Austrian enforcement practice
- arckit-at-nisg[COMMUNITY] Assess Austrian NISG obligations (BGBl. I Nr. 94/2025) — AT transposition of NIS2, BKA (GovCERT) / BMI (SPOC) reporting, KSÖ coordination, and Austrian sectoral rules for Essential/Important entities
- arckit-atrsGenerate Algorithmic Transparency Recording Standard (ATRS) record for AI/algorithmic tools
- arckit-aws-researchResearch AWS services and architecture patterns using AWS Knowledge MCP for authoritative guidance
- arckit-azure-researchResearch Azure services and architecture patterns using Microsoft Learn MCP for authoritative guidance