artifact-metadata
Standardizes artifact metadata, history tracking, and status management for SDLC deliverables.
Install
mkdir -p .claude/skills/artifact-metadata && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/16263" && unzip -o skill.zip -d .claude/skills/artifact-metadata && rm skill.zipInstalls to .claude/skills/artifact-metadata
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Manage artifact metadata, versioning, ownership, and history tracking. Use when relevant to the task.Key capabilities
- →Locate or create metadata.json files alongside artifacts.
- →Update metadata fields such as version, status, owner, and timestamps.
- →Track history including version changes, review records, and approvals.
- →Validate relationships like parent/child links and requirement traceability.
- →Query metadata for information like ownership and status.
- →Apply semantic versioning to artifacts.
How it works
This skill checks for or creates a metadata.json file, updates specified fields, tracks history, and validates relationships based on a defined schema.
Inputs & outputs
When to use artifact-metadata
- →Updating document metadata
- →Tracking artifact versioning
- →Managing status of design deliverables
About this skill
artifact-metadata
Manage artifact metadata, versioning, ownership, and history tracking.
Triggers
- "update artifact metadata"
- "track artifact version"
- "artifact history"
- "who owns [artifact]"
- "artifact status"
- "version [artifact]"
Purpose
This skill provides consistent metadata management for all SDLC and marketing artifacts. It tracks ownership, versioning, review history, and status across the artifact lifecycle.
Behavior
When triggered, this skill:
-
Locates or creates metadata:
- Check for existing
metadata.jsonalongside artifact - Create new metadata if none exists
- Validate against metadata schema
- Check for existing
-
Updates metadata fields:
- Version (semantic versioning)
- Status (draft, review, baselined, deprecated)
- Owner (agent or user)
- Reviewers (list of reviewing agents)
- Timestamps (created, modified, baselined)
-
Tracks history:
- Version history with change summaries
- Review records with reviewer and outcome
- Approval records
-
Validates relationships:
- Parent/child artifact links
- Requirement traceability links
- Cross-references to related artifacts
Metadata Schema
{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"required": ["artifact_id", "name", "type", "version", "status", "owner"],
"properties": {
"artifact_id": {
"type": "string",
"description": "Unique identifier (e.g., SAD-001, UC-003)"
},
"name": {
"type": "string",
"description": "Human-readable artifact name"
},
"type": {
"type": "string",
"enum": ["requirements", "architecture", "test", "security", "deployment", "marketing", "report"]
},
"version": {
"type": "string",
"pattern": "^\\d+\\.\\d+\\.\\d+$",
"description": "Semantic version"
},
"status": {
"type": "string",
"enum": ["draft", "review", "approved", "baselined", "deprecated"]
},
"owner": {
"type": "string",
"description": "Primary owner (agent name or user)"
},
"created": {
"type": "string",
"format": "date-time"
},
"modified": {
"type": "string",
"format": "date-time"
},
"baselined": {
"type": "string",
"format": "date-time"
},
"reviewers": {
"type": "array",
"items": {"type": "string"}
},
"history": {
"type": "array",
"items": {
"type": "object",
"properties": {
"version": {"type": "string"},
"date": {"type": "string", "format": "date-time"},
"author": {"type": "string"},
"summary": {"type": "string"}
}
}
},
"reviews": {
"type": "array",
"items": {
"type": "object",
"properties": {
"reviewer": {"type": "string"},
"date": {"type": "string", "format": "date-time"},
"outcome": {"type": "string", "enum": ["approved", "conditional", "rejected"]},
"comments": {"type": "string"}
}
}
},
"traceability": {
"type": "object",
"properties": {
"requirements": {"type": "array", "items": {"type": "string"}},
"parent": {"type": "string"},
"children": {"type": "array", "items": {"type": "string"}}
}
},
"tags": {
"type": "array",
"items": {"type": "string"}
}
}
}
Usage Examples
Create New Metadata
User: "Create metadata for the SAD"
Skill creates:
.aiwg/architecture/sad/metadata.json
{
"artifact_id": "SAD-001",
"name": "Software Architecture Document",
"type": "architecture",
"version": "0.1.0",
"status": "draft",
"owner": "architecture-designer",
"created": "2025-12-08T14:30:00Z",
"modified": "2025-12-08T14:30:00Z",
"reviewers": [],
"history": [],
"reviews": []
}
Update Version After Changes
User: "Version the SAD to 1.0.0 with summary 'Initial baseline'"
Skill updates:
- version: "1.0.0"
- status: "baselined"
- baselined: "2025-12-08T16:45:00Z"
- history: [adds entry with version, date, summary]
Record Review
User: "Record security-architect review as approved"
Skill updates:
- reviews: [adds review record]
- reviewers: [adds "security-architect" if not present]
- modified: [updates timestamp]
Query Ownership
User: "Who owns the test plan?"
Skill responds:
"Test Plan (TP-001) is owned by test-architect.
Status: review
Version: 0.3.0
Last modified: 2025-12-07
Reviewers: security-auditor, requirements-analyst"
Status Lifecycle
draft → review → approved → baselined
↑ ↓
└── rejected (returns to draft)
baselined → deprecated (end of life)
Status Transitions
| From | To | Triggered By |
|---|---|---|
| draft | review | Submit for review |
| review | approved | All reviewers approve |
| review | draft | Any reviewer rejects |
| approved | baselined | Formal baseline action |
| baselined | deprecated | Superseded or retired |
Version Conventions
- 0.x.x: Draft versions (not baselined)
- 1.0.0: First baseline
- x.y.0: Minor changes (compatible)
- x.0.0: Major changes (may break traceability)
Auto-Version Rules
| Change Type | Version Bump |
|---|---|
| Typo fix | patch (0.0.x) |
| Section update | minor (0.x.0) |
| Structure change | major (x.0.0) |
| Initial baseline | 1.0.0 |
Artifact Type Conventions
| Type | ID Prefix | Location |
|---|---|---|
| requirements | UC-, REQ-, NFR- | .aiwg/requirements/ |
| architecture | SAD-, ADR-, API- | .aiwg/architecture/ |
| test | TP-, TC-, TS- | .aiwg/testing/ |
| security | TM-, SEC- | .aiwg/security/ |
| deployment | DP-, RN- | .aiwg/deployment/ |
| marketing | CB-, CA- | .aiwg/marketing/ |
| report | RPT- | .aiwg/reports/ |
CLI Usage
# Create metadata for artifact
python artifact_metadata.py --create --artifact ".aiwg/architecture/sad.md" --type architecture
# Update version
python artifact_metadata.py --version "1.0.0" --artifact ".aiwg/architecture/sad.md" --summary "Initial baseline"
# Record review
python artifact_metadata.py --review --artifact ".aiwg/architecture/sad.md" \
--reviewer "security-architect" --outcome "approved" --comments "LGTM"
# Query metadata
python artifact_metadata.py --query --artifact ".aiwg/architecture/sad.md"
# List all artifacts by status
python artifact_metadata.py --list --status "review"
# Validate all metadata
python artifact_metadata.py --validate-all
Integration
This skill integrates with:
artifact-orchestration: Sets initial metadata when creating artifactsgate-evaluation: Checks artifact status for gate criteriatraceability-check: Uses traceability links in metadatatemplate-engine: Copies metadata template on instantiation
Output Locations
- Metadata file:
{artifact-dir}/metadata.json - Alternatively:
{artifact-dir}/{artifact-name}.metadata.json - Index file:
.aiwg/reports/artifact-index.json
References
- Schema:
schemas/artifact-metadata.schema.json - Conventions: AIWG Artifact Naming Guide
When not to use it
- →Managing artifacts outside the defined types (requirements, architecture, test, security, deployment, marketing, report).
- →When metadata management is not relevant to the task.
- →When the task involves only content creation without metadata tracking.
Limitations
- →The skill validates against a specific metadata schema.
- →It uses predefined artifact types and ID prefixes.
- →Version conventions are semantic and follow specific rules.
How it compares
This workflow provides a structured, automated way to manage artifact metadata and history, unlike manual tracking which can be inconsistent.
Compared to similar skills
artifact-metadata side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| artifact-metadata (this skill) | 0 | 5mo | Review | Intermediate |
| session-handoff | 13 | 2mo | Review | Beginner |
| spec-to-backlog | 8 | 4mo | No flags | Intermediate |
| create-handoff | 3 | 6mo | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by diegosouzapw
View all by diegosouzapw →You might also like
session-handoff
davila7
Creates comprehensive handoff documents for seamless AI agent session transfers. Triggered when: (1) user requests handoff/memory/context save, (2) context window approaches capacity, (3) major task milestone completed, (4) work session ending, (5) user says 'save state', 'create handoff', 'I need to pause', 'context is getting full', (6) resuming work with 'load handoff', 'resume from', 'continue where we left off'. Proactively suggests handoffs after substantial work (multiple file edits, complex debugging, architecture decisions). Solves long-running agent context exhaustion by enabling fresh agents to continue with zero ambiguity.
spec-to-backlog
atlassian
Automatically convert Confluence specification documents into structured Jira backlogs with Epics and implementation tickets. When Claude needs to: (1) Create Jira tickets from a Confluence page, (2) Generate a backlog from a specification, (3) Break down a spec into implementation tasks, or (4) Convert requirements into Jira issues. Handles reading Confluence pages, analyzing specifications, creating Epics with proper structure, and generating detailed implementation tickets linked to the Epic.
create-handoff
parcadei
Create handoff document for transferring work to another session
moai-workflow-project
modu-ai
Integrated project management system with documentation, language initialization, and template optimization modules. Use when setting up projects, generating documentation, configuring multilingual support, or optimizing templates.
granola-core-workflow-b
jeremylongshore
Post-meeting note processing and sharing workflow with Granola. Use when reviewing meeting notes, sharing with team members, or processing action items after meetings. Trigger with phrases like "granola post meeting", "share granola notes", "granola follow up", "process meeting notes", "granola action items".
reporting
comeredon
Final pipeline execution report format. Defines the structure, agent registry, Mermaid gantt chart, and change summary. Used by AnalystAgent in Phase 6.