Agent skill

Prd V06 Technical Specification

by mattgierhart in mattgierhart/PRD-driven-context-engineering

Define implementation contracts (APIs and data models) that developers will build against during PRD v0.6 Architecture.

MITAuto-check passedProduct & Project Management

Install Prd V06 Technical Specification

skills CLI
$ npx skills add mattgierhart/PRD-driven-context-engineering --skill prd-v06-technical-specification -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install mattgierhart/PRD-driven-context-engineering prd-v06-technical-specification --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/mattgierhart/PRD-driven-context-engineering.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/prd-v06-technical-specification .claude/skills/prd-v06-technical-specification && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
prd-v06-technical-specification
GitHub stars
180
Token cost
~3.4k tokens
SKILL.md length
843 words
Files
4 (incl. references, assets)
Skills in repo
45
Repo updated
First seen
Licence
MIT

At a glance

Define implementation contracts (APIs and data models) that developers will build against during PRD v0.6 Architecture.

  • Works in 7 steps: Pull ARC- decisions — System structure… → Pull TECH- Build items — What we're… → Pull UJ- journeys — User flows the API… → …
  • Requests to define APIs
  • SKILL.md covers Consumes, Produces, Specification Types and Specification Process, plus 9 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Prd V06 Technical Specification is an agent skill from mattgierhart/PRD-driven-context-engineering. Define implementation contracts (APIs and data models) that developers will build against during PRD v0.6 Architecture. Triggers on requests to define APIs, design database schema, create data models, or when user asks "define APIs", "data model", "database schema", "API contracts", "technical spec", "endpoint design", "schema design". Consumes ARC- (architecture), TECH- (Build items), UJ- (flows), SCR- (screens). Outputs API- entries for endpoints and DBT- entries for data models. Feeds v0.7 Build Execution.

Its SKILL.md is about 3.4k tokens, which your agent loads only when the skill is triggered. The skill folder holds 5 other files, including reference files and assets (for example `assets/api.md`, `assets/dbt.md` and `references/examples.md`).

It sits in Product & Project Management, covering Database schema design, PRD writing and Data pipelines and ETL. It works with dbt. The repository describes itself as: PRD-Led Context Engineering — Memory as Infrastructure. An ontology layer for product teams building products that solve real problems — with AI agents that remember. Gated PRD… The licence is MIT.

When your agent uses it

  • Requests to define APIs
  • Design database schema
  • Create data models
  • User asks define APIs

Example prompts

  • “define APIs”
  • “data model”
  • “database schema”
  • “/prd-v06-technical-specification”

Requirements

  • Pre-approved tools (allowed-tools): Read, Write, Edit, Glob, Grep

Workflow steps

7 steps, taken from the first numbered list in SKILL.md.

  1. Pull ARC- decisions — System structure and boundaries
  2. Pull TECH- Build items — What we're implementing
  3. Pull UJ- journeys — User flows the API must support
  4. Pull SCR- screens — UI data requirements
  5. Define API contracts for each endpoint
  6. Define data models for each entity
  7. Validate consistency

What it can do on your machine

Read from SKILL.md and the folder at commit 30ed1b0. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves these tools, so the agent can use them without asking each time:

    • Read
    • Write
    • Edit
    • Glob
    • Grep

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are markdown).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Prd V06 Technical Specification loads about 3.4k tokens when it runs, and up to ~5.4k if it reads all its reference files. Until then it costs about 137 tokens; SKILL.md has 843 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~137
When it runs · the whole SKILL.md, loaded when a task matches
~3.4k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~5.4k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from mattgierhart/PRD-driven-context-engineering at commit 30ed1b0, republished under its MIT licence (© mattgierhart). 843 words, ~3,357 tokens.

Download SKILL.mdSave it as .claude/skills/prd-v06-technical-specification/SKILL.md (or your agent's skills folder). This skill also uses 3 other files; get the full folder from GitHub.
name
prd-v06-technical-specification
description
Define implementation contracts (APIs and data models) that developers will build against during PRD v0.6 Architecture. Triggers on requests to define APIs, design database schema, create data models, or when user asks "define APIs", "data model", "database schema", "API contracts", "technical spec", "endpoint design", "schema design". Consumes ARC- (architecture), TECH- (Build items), UJ- (flows), SCR- (screens). Outputs API- entries for endpoints and DBT- entries for data models. Feeds v0.7 Build Execution.
allowed-tools
Read, Write, Edit, Glob, Grep
context
fork

Technical Specification

Position in workflow: v0.6 Architecture Design → v0.6 Technical Specification → v0.7 Build Execution

Technical specification defines the contracts developers build against: API endpoints and data models. This is the bridge between architecture and implementation.

Consumes

This skill requires prior work from v0.3-v0.6:

  • ARC-* architecture decisions (from v0.6 Architecture Design) — System structure (monolith vs microservices) determines API organization; integration patterns guide webhook/adapter design
  • TECH-* Build items (from v0.5 Technical Stack Selection) — Technologies chosen define data model types (PostgreSQL requires relational schema; MongoDB requires document schema)
  • UJ-* user journeys (from v0.4 User Journey Mapping) — Journey steps determine API call sequences; value moments determine response contracts
  • SCR-* screen entries (from v0.4 Screen Flow Definition) — Screen data requirements determine API response shape; form submissions map to POST/PUT/PATCH endpoints
  • BR-* business rules (from v0.3 Commercial Model) — Business constraints enforced in API responses (rate limits, validation rules, field constraints)

This skill assumes v0.6 Architecture Design is complete with ARC- entries providing system structure.

Produces

This skill creates/updates:

  • API-* entries (API endpoint contracts) — REST/GraphQL endpoint specifications with request/response shapes, auth requirements, error codes, tied to UJ-/SCR- consumers and DBT- data sources
  • DBT-* entries (database schema contracts) — Data model specifications with fields, relationships, indexes, constraints, tied to API- accessors and BR- rules
  • Screen-to-API validation matrix — Verification showing every SCR-* has supporting API-* and every UJ-* step can be completed via API calls
  • API-to-Data validation matrix — Verification showing every API-* response field maps to DBT-* and every DBT-* is used by at least one API-*

All API- and DBT- entries are implementation contracts (not confidence-based). They are:

  • Derivable from upstream IDs (UJ-/SCR-/ARC-/BR-/TECH-)
  • Testable (API responses have concrete shape, DBT constraints are verifiable)
  • Complete enough for developers to implement without re-research

Example API- entry (from UJ- and SCR-):

markdown
API-001: Create Report
Method: POST
Path: /api/reports
Purpose: Create new report from selected data source and template (implements UJ-001 Step 1)
Auth: User

Journey: UJ-001 (Step 1 - Create Report)
Screen: SCR-002 (Report Builder)

Request:
  Body:
    {
      title: string (required) — Report name
      templateId: string (required) — Selected template (FEA-008)
      dataSourceId: string (required) — Connected data source (FEA-001)
      options: { dateRange: { start, end }, filters: [...] }
    }

Response:
  Success (201):
    {
      data: { id, title, status: "pending|generating|ready", createdAt }
    }
  Errors:
    - 400: Invalid input — Missing required field
    - 403: Forbidden — User doesn't own data source
    - 404: Not found — Template or data source not found
    - 429: Rate limit exceeded

Business Rules: BR-015 (max 100 reports per user)
Data: DBT-001 (reports table), DBT-002 (data_sources table)

Example DBT- entry (referenced by API- entries):

markdown
DBT-001: Reports
Purpose: Stores user-generated reports (entities created by API-001, updated by API-004)
Table: reports

Fields:
  - id: uuid — Primary key
  - user_id: uuid — Report owner (FK → users) [NOT NULL]
  - title: varchar(255) — Display name [NOT NULL]
  - status: enum('pending','generating','ready','failed') [NOT NULL]
  - created_at: timestamp [NOT NULL, DEFAULT now()]

Relationships:
  - belongs_to: users via user_id
  - belongs_to: templates via template_id

Indexes:
  - user_id — List reports by user (API-003)
  - (user_id, created_at DESC) — Recent reports (API-003)
  - status — Find pending reports (background job)

Constraints:
  - title: NOT NULL, length 1-255
  - status: valid enum only

Business Rules: BR-015 (max 100 per user — enforce in API-001)
APIs: API-001 (create), API-002 (get), API-003 (list), API-005 (delete)

Specification Types

TypeWhat It DefinesExample
API-Endpoint contractsPOST /users, GET /reports/:id
DBT-Data model/schemaUsers table, Reports table

Rule: Every API- should know which DBT- it reads/writes. Every DBT- should know which API- accesses it.

Specification Process

  1. Pull ARC- decisions — System structure and boundaries

  2. Pull TECH- Build items — What we're implementing

  3. Pull UJ- journeys — User flows the API must support

  4. Pull SCR- screens — UI data requirements

  5. Define API contracts for each endpoint:

    • What's the request/response shape?
    • What auth is required?
    • What errors can occur?
  6. Define data models for each entity:

    • What fields exist?
    • What relationships?
    • What constraints?
  7. Validate consistency:

    • Does every screen have APIs to fetch its data?
    • Does every API response map to DBT- fields?

API- Output Template

API-XXX: [Endpoint Name]
Method: [GET | POST | PUT | PATCH | DELETE]
Path: [/resource/{id}/action]
Purpose: [What this endpoint does]
Auth: [Public | User | Admin | Service]

Journey: [UJ-XXX that uses this]
Screen: [SCR-XXX that calls this]

Request:
  Headers:
    - Authorization: Bearer <token>
    - Content-Type: application/json
  Params:
    - id: string (required) — Resource identifier
  Query:
    - limit: number (optional, default 20) — Pagination limit
  Body:
    {
      field: type — Description
    }

Response:
  Success (200/201):
    {
      data: { ... }
    }
  Errors:
    - 400: Invalid input — [when this occurs]
    - 401: Unauthorized — [when this occurs]
    - 404: Not found — [when this occurs]
    - 500: Server error — [when this occurs]

Business Rules: [BR-XXX enforced here]
Data: [DBT-XXX entities accessed]
Rate Limit: [requests/minute if applicable]

Example API- entry:

API-001: Create Report
Method: POST
Path: /api/reports
Purpose: Create a new report from selected data source and template
Auth: User

Journey: UJ-001 (Step 1 - Create Report)
Screen: SCR-002 (Report Builder)

Request:
  Headers:
    - Authorization: Bearer <token>
    - Content-Type: application/json
  Body:
    {
      title: string (required) — Report name
      templateId: string (required) — Selected template
      dataSourceId: string (required) — Connected data source
      options: {
        dateRange: { start: ISO8601, end: ISO8601 }
        filters: [{ field: string, operator: string, value: any }]
      }
    }

Response:
  Success (201):
    {
      data: {
        id: string
        title: string
        status: "pending" | "generating" | "ready"
        createdAt: ISO8601
      }
    }
  Errors:
    - 400: Invalid input — Missing required field or invalid templateId
    - 401: Unauthorized — Invalid or expired token
    - 403: Forbidden — User doesn't own data source
    - 404: Not found — Template or data source not found
    - 429: Too many requests — Rate limit exceeded

Business Rules: BR-015 (max 100 reports per user)
Data: DBT-001 (reports), DBT-002 (data_sources)
Rate Limit: 10 requests/minute

DBT- Output Template

DBT-XXX: [Entity Name]
Purpose: [What this entity represents]
Table: [database_table_name]

Fields:
  - id: uuid — Primary key, auto-generated
  - [field_name]: [type] — Description [constraints]
  - created_at: timestamp — Record creation (auto)
  - updated_at: timestamp — Last modification (auto)

Relationships:
  - belongs_to: [DBT-YYY] via [foreign_key]
  - has_many: [DBT-ZZZ]

Indexes:
  - [field_name] — [Query pattern it supports]

Constraints:
  - [field]: [UNIQUE | NOT NULL | CHECK expression]

Business Rules: [BR-XXX that affect this entity]
APIs: [API-XXX that read/write this]

Example DBT- entry:

DBT-001: Reports
Purpose: Stores user-generated reports with configuration and status
Table: reports

Fields:
  - id: uuid — Primary key
  - user_id: uuid — Report owner (FK → users) [NOT NULL]
  - title: varchar(255) — Display name [NOT NULL]
  - template_id: uuid — Template used (FK → templates) [NOT NULL]
  - data_source_id: uuid — Data source (FK → data_sources) [NOT NULL]
  - status: enum('pending','generating','ready','failed') — Generation status [NOT NULL, DEFAULT 'pending']
  - options: jsonb — Report configuration (date range, filters) [DEFAULT '{}']
  - output_url: varchar(500) — Generated report file URL [NULL until ready]
  - created_at: timestamp — [NOT NULL, DEFAULT now()]
  - updated_at: timestamp — [NOT NULL, DEFAULT now()]

Relationships:
  - belongs_to: DBT-010 (users) via user_id
  - belongs_to: DBT-002 (templates) via template_id
  - belongs_to: DBT-003 (data_sources) via data_source_id

Indexes:
  - user_id — List reports by user
  - (user_id, created_at DESC) — List recent reports
  - status — Find pending reports for processing

Constraints:
  - title: NOT NULL, length 1-255
  - status: NOT NULL, valid enum value

Business Rules: BR-015 (max 100 reports per user — enforce in API)
APIs: API-001 (create), API-002 (get), API-003 (list), API-005 (delete)

API Design Principles

PrincipleGuidanceExample
Resource-orientedURLs are nouns, not verbs/reports not /createReport
Consistent namingPlural nouns, kebab-case/data-sources not /dataSource
StatelessNo server-side sessionsAuth via token, not cookie session
VersionedPrefix for breaking changes/v1/reports
Documented errorsClear codes and messages{ error: { code: "LIMIT_EXCEEDED", message: "..." } }
Show full SKILL.md (360 more words)Show less

Data Model Principles

PrincipleGuidanceExample
NormalizedAvoid redundancy (unless denormalized for performance)User name in users table, not duplicated
Audit trailcreated_at, updated_at on all tablesTrack when records change
Soft deletedeleted_at instead of hard delete (when needed)Recover deleted data
Foreign keysEnforce referential integrityuser_id → users.id
Index strategyIndex fields in WHERE and JOINFilter fields, FK columns

Validation Checklist

Use this to ensure spec completeness:

Screen-to-API Validation
  • Every SCR- screen has APIs to fetch its data
  • Every form submission maps to a POST/PUT/PATCH
  • Every list view has a paginated GET
Journey-to-API Validation
  • Every UJ- step that needs data has an API call
  • API sequence supports journey flow
  • Error states in journey have error responses
API-to-Data Validation
  • Every API- response field maps to DBT- fields
  • Every API- that writes data has a target DBT-
  • Business rules (BR-) enforced in API or DB constraint
Orphan Check
  • No API- without SCR-/UJ- consumer
  • No DBT- table unused by any API-
  • No dead code paths

Anti-Patterns to Avoid

Anti-PatternSignalFix
API/UI mismatchScreen needs data not in any APIAdd API- or modify existing
Schema sprawl50+ tables for MVPConsolidate; YAGNI applies
Missing constraintsNo validation, anything acceptedAdd BR- enforcement
N+1 queries baked inAPI design requires multiple calls for one viewAdd compound endpoints
No error handlingOnly happy path documentedDefine all error responses
Vague typesdata: anySpecify exact shape

Quality Gates

Before proceeding to Build Execution:

  • All SCR- screens have supporting API- endpoints
  • All UJ- journeys can be completed via API- calls
  • All API- responses map to DBT- fields
  • All BR- rules enforced in API- or DBT- constraints
  • No orphaned tables or endpoints
  • Error responses documented for all endpoints

Downstream Connections

API- and DBT- entries feed into:

ConsumerWhat It UsesExample
v0.7 Epic ScopingAPI- and DBT- define EPIC scopeEPIC-01 implements API-001–005
v0.7 Test PlanningAPI- defines test contractsTEST-001 validates API-001
v0.7 Implementation LoopAPI-/DBT- are implementation tasksCode implements API-001
API DocumentationAPI- becomes OpenAPI specSwagger from API- entries

Detailed References

  • API and data model examples: See references/examples.md
  • API- entry template: See assets/api.md
  • DBT- entry template: See assets/dbt.md

© mattgierhart, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 3 other files (references, assets) in .claude/skills/prd-v06-technical-specification of mattgierhart/PRD-driven-context-engineering.

  • SKILL.md
  • assets/api.md
  • assets/dbt.md
  • references/examples.md

Open the folder on GitHubat commit 30ed1b0

Compare with similar skills

Prd V06 Technical Specification next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Prd V06 Technical Specification compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Prd V06 Technical Specification this skillmattgierhart/PRD-driven-context-engineering180—~3.4kAutomated safety check: PassMIT
Erd Studio Setupliam-machine/erd-studio165—~8.6kAutomated safety check: PassCustom licence
Modelersidequery/sidemantic129—~4.2kAutomated safety check: PassApache-2.0
Analytics Engineerborghei/Claude-Skills891—~3.4kAutomated safety check: PassMIT
API Architectcuriositech/some_claude_skills244—~1.4kAutomated safety check: PassMIT
Tushare Plugin BuilderYourdaylight/stock_datasource189—~2.5kAutomated safety check: PassMIT

Similar skills

  • Erd Studio Setup

    liam-machine/erd-studio

    Friendly, step-by-step setup for ERD Studio in an existing dbt project, for people who may be new to dbt or data modelling.

    165 GitHub stars~8.6k tokensUpdated today
    Data & AnalyticsAuto-check passed
  • Modeler

    sidequery/sidemantic

    Build, validate, and manage semantic models using Sidemantic.

    129 GitHub stars~4.2k tokensUpdated 3 days ago
    DatabasesAuto-check passed
  • Analytics Engineer

    borghei/Claude-Skills

    Analytics engineering across data modeling, dbt, transformation, and semantic layers.

    891 GitHub stars~3.4k tokensUpdated 3 days ago
    Data & AnalyticsAuto-check passed
  • API Architect

    curiositech/some_claude_skills

    Expert API designer for REST, GraphQL, gRPC architectures. An agent skill from curiositech/some_claude_skills.

    244 GitHub stars~1.4k tokensUpdated 1 mo ago
    Backend & APIsAuto-check passed
  • Tushare Plugin Builder

    Yourdaylight/stock_datasource

    Turns a Tushare API doc URL into a full data plugin for the stock_datasource repo: extractor, ClickHouse schema, query service, config and curl examples.

    189 GitHub stars~2.5k tokensUpdated 1 mo ago
    Data & AnalyticsAuto-check passed
  • Snowflake Development

    sickn33/agentic-awesome-skills

    Comprehensive Snowflake development assistant covering SQL best practices, data pipeline design (Dynamic Tables, Streams, Tasks, Snowpipe), Cortex AI functions, Cortex Agents, Snowpark Python, dbt…

    47k GitHub starsUsed in 2 repos~2.1k tokens
    DatabasesAuto-check passed

More from mattgierhart/PRD-driven-context-engineering

All 45 skills in this repo
  • Ghm Gate Check

    mattgierhart/PRD-driven-context-engineering

    Validates gate criteria before PRD lifecycle advancement by delegating to the readiness scoring pipeline (scripts/readiness.py).

    180 GitHub stars~1.3k tokensUpdated 1 mo ago
    Auto-check: notes
  • Ghm Harvest

    mattgierhart/PRD-driven-context-engineering

    Extracts durable insights from temp/ files to SoT during EPIC Phase E.

    180 GitHub stars~1.1k tokensUpdated 1 mo ago
    Auto-check passed
  • Ghm Id Register

    mattgierhart/PRD-driven-context-engineering

    Validates and registers new SoT IDs with cross-reference integrity.

    180 GitHub stars~1.5k tokensUpdated 1 mo ago
    Auto-check passed
  • Ghm Sot Builder

    mattgierhart/PRD-driven-context-engineering

    Creates new Source of Truth (SoT) files when existing templates don't fit your needs.

    180 GitHub stars~2k tokensUpdated 1 mo ago
    Auto-check passed
  • Prd V01 Problem Framing

    mattgierhart/PRD-driven-context-engineering

    Transform vague product ideas into evidence-anchored problem statements for PRD v0.1 Spark.

    180 GitHub stars~1.7k tokensUpdated 1 mo ago
    Auto-check passed
  • Prd V01 User Value Articulation

    mattgierhart/PRD-driven-context-engineering

    Transform validated pain points into articulated user value statements for PRD v0.1 Spark.

    180 GitHub stars~1.6k tokensUpdated 1 mo ago
    Auto-check passed

Works with

Questions about Prd V06 Technical Specification

What does Prd V06 Technical Specification do?

Define implementation contracts (APIs and data models) that developers will build against during PRD v0.6 Architecture. Prd V06 Technical Specification is an agent skill from mattgierhart/PRD-driven-context-engineering.6 Architecture.

When should I use Prd V06 Technical Specification?

Prd V06 Technical Specification fits situations like: requests to define APIs; design database schema; create data models; user asks define APIs.

How do I install Prd V06 Technical Specification in Claude Code?

Run `npx skills add mattgierhart/PRD-driven-context-engineering --skill prd-v06-technical-specification -a claude-code`. Or copy the skill folder (.claude/skills/prd-v06-technical-specification in mattgierhart/PRD-driven-context-engineering) into .claude/skills/prd-v06-technical-specification in your project. Claude Code loads it when a task matches its description.

How do I install Prd V06 Technical Specification in Codex?

Run `npx skills add mattgierhart/PRD-driven-context-engineering --skill prd-v06-technical-specification -a codex`. Or copy the skill folder (.claude/skills/prd-v06-technical-specification in mattgierhart/PRD-driven-context-engineering) into .agents/skills/prd-v06-technical-specification in your project. Codex loads it when a task matches its description.

Can I use Prd V06 Technical Specification in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add mattgierhart/PRD-driven-context-engineering --skill prd-v06-technical-specification -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/prd-v06-technical-specification, .gemini/skills/prd-v06-technical-specification, .github/skills/prd-v06-technical-specification and .opencode/skills/prd-v06-technical-specification in your project.

What does Prd V06 Technical Specification need to run?

SKILL.md names no scripts, command-line tools or credentials: Prd V06 Technical Specification is instructions for the agent only. Its frontmatter pre-approves these tools: Read, Write, Edit, Glob, Grep.

Does Prd V06 Technical Specification access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Prd V06 Technical Specification safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Prd V06 Technical Specification use?

Prd V06 Technical Specification is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Prd V06 Technical Specification use?

About 3.4k tokens (SKILL.md is roughly 13k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 2k tokens, read only when the agent opens those files.

What are the alternatives to Prd V06 Technical Specification?

Skills that share tags, products or a category with Prd V06 Technical Specification: Erd Studio Setup (liam-machine/erd-studio, 165 stars), Modeler (sidequery/sidemantic, 129 stars), Analytics Engineer (borghei/Claude-Skills, 891 stars) and API Architect (curiositech/some_claude_skills, 244 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Prd V06 Technical Specification?

mattgierhart (a GitHub user) maintains it in mattgierhart/PRD-driven-context-engineering, which has 180 GitHub stars. The repository holds 45 skills in this directory. The repository was last updated on August 31, 2026.

Source: mattgierhart/PRD-driven-context-engineering on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.