Agent skill

Product Implement

by tikalk in tikalk/adlc-team-skills

A skill your agent uses when accepted PDRs exist and PRD.md must be generated or updated.

MITAuto-check passedProduct & Project Management

Install Product Implement

skills CLI
$ npx skills add tikalk/adlc-team-skills --skill product-implement -a claude-code

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

GitHub CLI
$ gh skill install tikalk/adlc-team-skills product-implement --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/tikalk/adlc-team-skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/product/product-implement .claude/skills/product-implement && 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
product-implement
GitHub stars
141
Token cost
~3.7k tokens
SKILL.md length
1,085 words
Files
6 (incl. scripts)
Skills in repo
44
Repo updated
First seen
Licence
MIT

At a glance

A skill your agent uses when accepted PDRs exist and PRD.md must be generated or updated.

  • Works in 5 steps: Plan → Execute → Summarize → …
  • Accepted PDRs exist and PRD.md must be generated
  • SKILL.md covers What this skill does, When to use, When NOT to use and Pre-Flight Validation, plus 8 more sections
  • Runs Shell and PowerShell scripts from its folder

What it does

Product Implement is an agent skill from tikalk/adlc-team-skills. Use when accepted PDRs exist and PRD.md must be generated or updated.

Its SKILL.md is about 3.7k tokens, which your agent loads only when the skill is triggered. The skill folder holds 8 other files, including scripts (for example `scripts/bash/migrate-pdr-frontmatter.sh`, `scripts/bash/setup-product-implement.sh` and `scripts/bash/validate-pdr.sh`).

It sits in Product & Project Management, covering PRD writing. The repository describes itself as: Agent skills for the Agentic SDLC: team lifecycle (team-boot, team-learn, team-init, team-repair), software factory, evals, CDR lifecycle with confidence scoring, and… The licence is MIT.

When your agent uses it

  • Accepted PDRs exist and PRD.md must be generated
  • Tasks that involve PRD writing

Example prompts

  • “/product-implement”

Requirements

  • A Bash shell
  • PowerShell

Workflow steps

5 steps, taken from the step headings in SKILL.md.

  1. Plan
  2. Execute
  3. Summarize
  4. PDR Lifecycle Management (MANDATORY)
  5. Final Verification

What it can do on your machine

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

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Ships 5 files in scripts/ (Shell and PowerShell), which the agent can run.

    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

Product Implement loads about 3.7k tokens when it runs. Until then it costs about 22 tokens; SKILL.md has 1,085 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~22
When it runs · the whole SKILL.md, loaded when a task matches
~3.7k

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); the scripts in this folder are not scanned.

SKILL.md

The full file from tikalk/adlc-team-skills at commit 2dbed36, republished under its MIT licence (© tikalk). 1,085 words, ~3,688 tokens.

Download SKILL.mdSave it as .claude/skills/product-implement/SKILL.md (or your agent's skills folder). This skill also uses 5 other files; get the full folder from GitHub.
name
product-implement
description
Use when accepted PDRs exist and PRD.md must be generated or updated.
disable-model-invocation
true

product-implement

What this skill does

Transforms accepted PDRs into a comprehensive, self-contained PRD.md using a three-phase DAG:

  1. Plan Agent: Analyze PDRs, detect feature-areas, generate customized DAG, get user approval
  2. Execute Agent: Generate sections per feature-area with mandatory checkpoint after Requirements
  3. Summarize Agent: Aggregate sections, resolve conflicts, produce unified PRD.md

Output:

  • docs/adlc/product/PRD.md — self-contained product requirements (ADR-401; legacy repo-root PRD.md stays read-compatible)
  • {REPO_ROOT}/.adlc/product/sections/{feature-area}/{section}.md — intermediate section files
  • Accepted PDRs moved to {REPO_ROOT}/docs/adlc/memory/pdr/ (ADR-401 canonical memory root)

When to use

  • After /product-clarify has approved PDRs
  • After /product-init to document existing product
  • PDR updates requiring PRD regeneration

When NOT to use

  • No Accepted PDRs (run /product-clarify first)
  • Minor PRD edits (edit PRD.md directly)

Pre-Flight Validation

Before starting, verify prerequisites:

  1. Check PDRs exist: {REPO_ROOT}/.adlc/drafts/pdr/PDR-*.md
  2. Check for Accepted PDRs: Count files with status "Accepted"
    • If zero: STOP and output:
      Cannot proceed: No Accepted PDRs found.
      Run /product-clarify to review and approve PDRs first.
    • If ≥1: Proceed

Three-Phase DAG Workflow

┌─────────────────────────────────────────────────────────┐
│ PHASE 1: PLAN (Plan Agent)                              │
│ Load PDRs → Detect Feature-Areas → Generate DAG → Approve│
└─────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────┐
│ PHASE 2: EXECUTE (Execute Agent)                        │
│ Overview → Problem → Goals → Metrics → Personas         │
│ → [REQUIREMENTS CHECKPOINT] ← MANDATORY USER APPROVAL   │
│ → NFRs → Out-of-Scope → Risks → Roadmap → PDR-Summary   │
└─────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────┐
│ PHASE 3: SUMMARIZE (Summarize Agent)                    │
│ Read sections → Detect conflicts → Resolve → PRD.md     │
└─────────────────────────────────────────────────────────┘

Execution Steps

Phase 1: Plan

Step 1.1: Load and Analyze PDRs

  1. Read all PDR-*.md files from .adlc/drafts/pdr/
  2. Filter to Accepted status only
  3. Parse feature-area from each PDR
  4. Group PDRs by feature-area

Step 1.2: Detect Feature-Area Characteristics

CharacteristicDetection PatternDAG Customization
B2B SaaSEnterprise, admin, SSOInclude compliance sections
Consumer AppMobile, freemium, socialSimplify requirements
PlatformAPI, integrations, developerExpand NFRs
MarketplaceMulti-sided, transactionAdd business model sections

Step 1.3: Generate Customized DAG

Default DAG (all 15 sections):

Document Information → Executive Summary → Overview → Problem
→ Market Opportunity → Goals → Metrics → Personas
→ [CHECKPOINT: Requirements]
→ NFRs → Out-of-Scope → Risks → Investment
→ Roadmap → Go-to-Market → PDR-Summary

Section numbering (fixed):

    1. Document Information
  • 1.5 Executive Summary
    1. Overview
    1. The Problem
  • 3.5 Market Opportunity
    1. Goals & Objectives
    1. Success Metrics
    1. Personas
    1. Functional Requirements
    1. Non-Functional Requirements
    1. Out of Scope
    1. Risks & Mitigation
  • 10.5 Investment & Resources
    1. Roadmap & Milestones
  • 11.5 Go-to-Market Strategy
    1. PDR Summary

Step 1.4: Present Plan for Approval

markdown
## DAG Execution Plan

**Feature-Areas detected**: 3
**Total sections**: 15

**Feature-Area: Core**
**PDRs**: PDR-001, PDR-005, PDR-008
**DAG**: Document Info → Executive Summary → Overview → Problem
→ Market Opportunity → Goals → Metrics → Personas
→ [Requirements Checkpoint] → NFRs → Out-of-Scope → Risks
→ Investment → Roadmap → GTM → PDR-Summary

**Approve this plan?** [Yes/Modify/Cancel]

Step 1.5: Write state.json

json
{
  "version": "1.0",
  "phase": "plan_approved",
  "feature_areas": [
    {
      "id": "core",
      "name": "Core",
      "pdrs": ["PDR-001", "PDR-005"],
      "dag": ["document-info", "executive-summary", "overview", "problem", ...],
      "progress": {}
    }
  ],
  "checkpoint": {
    "enabled": true,
    "after_section": "requirements",
    "status": "pending"
  }
}
Phase 2: Execute

For each section in the DAG:

  1. Check dependencies — ensure all prerequisites completed
  2. Load section template — ../templates/sections/{section}.md
  3. Generate content — fill template with PDR-derived content
  4. Write section file — .adlc/product/sections/{feature-area}/{section}.md
  5. Validate — run scripts/bash/validate-prd.sh {section}.md
  6. Update state.json — mark section as "completed"

Section template usage (MANDATORY):

  • Read template FIRST
  • Fill ALL [PLACEHOLDERS]
  • NEVER generate from scratch

In-section diagrams (MANDATORY):

  • Use ```mermaid code blocks
  • Use flowchart keyword (NOT deprecated graph)
  • ASCII box-drawing characters are PROHIBITED
  • Diagrams embedded in their home sections
SectionDiagram TypeSubsection
2. OverviewFeature Hierarchy (flowchart TD)2.4
2. OverviewArchitecture (flowchart TB)2.5
6. PersonasUser Journey (journey)6.4
7. RequirementsReq Dependencies (flowchart LR)7.4
7. RequirementsFeature Dependencies (flowchart LR)7.5
11. RoadmapGantt Chart (gantt)11.1

Requirements Checkpoint (MANDATORY):

After generating Requirements section:

markdown
## CHECKPOINT: Requirements Section Complete

The Requirements section has been generated.

**Why checkpoint here?** Requirements shapes:
- NFRs (how requirements are met)
- Out-of-Scope (what's NOT required)
- Risks (technical feasibility)
- Roadmap (priority and sequencing)

**Options**:
A) Approve — Continue to remaining sections
B) Modify — Edit requirements, then continue
C) Restart — Regenerate from Problem phase
D) Cancel — Stop execution
Phase 3: Summarize

Step 3.1: Read All Sections FROM DISK

CRITICAL: Read each section file from filesystem. Do NOT use content from memory.

  1. Scan .adlc/product/sections/ for all .md files
  2. Read each file
  3. Validate: ≥20 lines, proper headers

Step 3.2: Detect Cross-Feature-Area Conflicts

Conflict TypeDetectionResolution
Duplicate requirementsSame requirement, different wordingStandardize to PDR terminology
Priority mismatchSame feature, different priorityDefer to PDR
Metric inconsistencySame metric, different definitionUse PDR definition

Step 3.3: Aggregate into PRD.md

CRITICAL: PRD.md MUST be SELF-CONTAINED.

  • ALL diagrams embedded IN-SECTION
  • ZERO reader-facing links to .adlc/ paths
  • Use in-document anchors only: [Section 2.4](#24-feature-hierarchy)
  • PDR references as plain text: PDR-078 (NOT linked)

PRD structure (must match template):

markdown
# Product Requirements Document: [Product Name]

## 1. Document Information
[Quick Stats, revision history, approval]

## 1.5 Executive Summary
[Business case, ROI, recommendation]

## 2. Overview
[Product description, scope]
### 2.4 Feature Hierarchy [MERMAID flowchart TD]
### 2.5 Architecture Overview [MERMAID flowchart TB]

## 3. The Problem
[Problem statement, validation evidence]

## 3.5 Market Opportunity
[TAM/SAM/SOM, competitive landscape]

## 4. Goals & Objectives
[Primary, technical, business goals traced to PDRs]

## 5. Success Metrics
[Adoption, engagement, quality]
### 5.5 Business Outcome Metrics
### 5.6 Financial Metrics

## 6. Personas
[Primary, secondary, anti-personas]
### 6.4 User Journey [MERMAID journey]

## 7. Functional Requirements [CHECKPOINT]
[User stories, REQ-XXX IDs, priority matrix]
### 7.4 Requirement Dependencies [MERMAID flowchart LR]
### 7.5 Feature Dependencies [MERMAID flowchart LR]

## 8. Non-Functional Requirements
[Performance, security, reliability, scalability]

## 9. Out of Scope
[Feature, technical, market exclusions]

## 10. Risks & Mitigation
[Risk summary, technical, market, operational]
### 10.4 Business Risks

## 10.5 Investment & Resources
[Team, budget, ROI, go/no-go criteria]

## 11. Roadmap & Milestones
### 11.1 Roadmap Overview [MERMAID gantt]
[Milestone details with demo sentences]

### 11.2 Milestone Gates & Progress
[Per milestone: done-means definition, feature rollup, gate table, issue/evidence status — sourced from milestone PDRs]

## 11.5 Go-to-Market Strategy
[Launch phases, pricing, messaging]

## 12. PDR Summary
[Key decisions, constitution alignment — NO external links]
Phase 4: PDR Lifecycle Management (MANDATORY)

Requires: the product-clarify skill (provides pdr-lib.sh): adlc-cli skills add tikalk/adlc-team-skills --skill product-clarify

Step 4.1: Move Accepted PDRs to Memory (atomic — script-driven)

Source the PDR lifecycle library and call move_pdr for each Accepted PDR. This performs an atomic mv (no copy-then-delete duplication risk) and regenerates both scopes' indexes automatically.

bash
source "{REPO_ROOT}/.agents/skills/product-clarify/scripts/bash/pdr-lib.sh"
# Or on Windows: . "{REPO_ROOT}/.agents/skills/product-clarify/scripts/powershell/pdr-lib.ps1"

for pdr_id in <list of Accepted PDR IDs>; do
  move_pdr "$pdr_id" drafts memory
done
  • PDRs with status "Accepted" are moved (not copied) from .adlc/drafts/pdr/ to docs/adlc/memory/pdr/.
  • Do NOT change status to "Completed" — keep status as "Accepted" so the index header ("Accepted PDRs only") remains truthful.
  • Proposed/Discovered PDRs remain in drafts (not moved).
  • Both drafts/pdr/pdr.md and memory/pdr/pdr.md indexes are regenerated by move_pdr.

Step 4.2: Generate Memory PDR Index (MANDATORY — script-driven)

The move_pdr call in Step 4.1 already regenerates the memory index. To manually regenerate (e.g., after bulk edits to PDR files):

bash
source "{REPO_ROOT}/.agents/skills/product-clarify/scripts/bash/pdr-lib.sh"
generate_pdr_index memory

This writes {REPO_ROOT}/docs/adlc/memory/pdr/pdr.md using a frontmatter-primary + heading-fallback parser that handles both ## (H2 legacy) and ### (H3 current) metadata. Blank cells trigger a stderr warning and defaults are applied — no silent blank rows.

The generated index has this format:

markdown
# Product Decision Records (Memory)

> Auto-generated by /product-implement. Accepted PDRs only.
> Source: docs/adlc/memory/pdr/PDR-*.md

## PDR Index

| ID | Feature-Area | Category | Status | Date | Owner | Title |
|----|--------------|----------|--------|------|-------|-------|
| PDR-001 | control-plane | Governance | Accepted | 2026-08-04 | User/AI collaboration | Lit Factory Operating Model |

This index is consumed by team-boot for session-start injection (similar to how CDR.md is used for team-level context).

Step 4.3: Update state.json

json
{
  "phase": "completed",
  "pdr_lifecycle": {
    "pdrs_promoted": [N],
    "memory_pdr_moved": true,
    "drafts_retained": true,
    "drafts_reason": "Proposed/Discovered PDRs remain",
    "memory_index_generated": true
  }
}
Show full SKILL.md (346 more words)Show less
Phase 5: Final Verification

Before marking complete, verify ALL checks:

#CheckExpected
1Section files on diskN files in .adlc/product/sections/
2PRD.md existsYes
3PRD.md content size>200 lines
4PRD.md has all sectionsSections 1-12 + sub-sections
5PRD.md is self-contained0 .adlc/ links
6Diagrams embedded≥4 mermaid blocks
7Memory PDRs writtendocs/adlc/memory/pdr/PDR-*.md exist
8Memory PDR index generateddocs/adlc/memory/pdr/pdr.md exists with correct table
9state.json consistentAll sections "completed"

Gate Rule: If ANY check fails → do NOT mark as completed. Report failures.

PDR Traceability Rules

  • Every section must reference source PDRs with ID
  • Every requirement (REQ-XXX) must trace to a PDR
  • No content without PDR backing
  • PDRs are source of truth for conflict resolution

Configuration

  • PDR_DRAFTS_DIR — {REPO_ROOT}/.adlc/drafts/pdr
  • PDR_MEMORY_DIR — {REPO_ROOT}/docs/adlc/memory/pdr
  • PRD_FILE — {REPO_ROOT}/docs/adlc/product/PRD.md
  • SECTIONS_DIR — {REPO_ROOT}/.adlc/product/sections
  • STATE_FILE — {REPO_ROOT}/.adlc/product/state.json

12-Factor Alignment

  • Factor III (Mission Definition): Compiles mission decisions into actionable requirements
  • Factor IV (Structured Planning): DAG orchestration separates planning from execution
  • Factor IX (Traceability): Every PRD element traces back to a PDR

Common Rationalizations

RationalizationReality
"I'll skip the checkpoint and just generate everything."Requirements shapes NFRs, Out-of-Scope, Risks, and Roadmap. Skipping the checkpoint risks cascading errors.
"The PRD can reference section files."PRD.md MUST be self-contained. External references break when section files are moved or deleted.
"I don't need to move PDRs to memory."Without promotion, drafts and memory diverge. The next clarify session sees stale data.

Red Flags

  • Generating PRD from non-Accepted PDRs — implement skips Proposed/Discovered; the PRD will be incomplete.
  • Writing PRD.md directly from PDRs — content MUST come from section files to ensure validation passed.
  • Missing the Requirements checkpoint — this is the cornerstone section; errors here cascade.
  • Leaving .adlc/ links in PRD.md — breaks self-containment; readers cannot follow internal paths.

Verification

  • Pre-flight: ≥1 Accepted PDR exists
  • Plan approved by user
  • state.json written with DAG
  • Each section file ≥20 lines
  • validate-prd.sh passes for each section
  • Requirements checkpoint approved by user
  • PRD.md >200 lines with all 15 sections
  • Zero .adlc/ links in PRD.md
  • ≥4 Mermaid diagrams embedded in-section
  • All requirements trace to PDRs
  • Accepted PDRs moved to docs/adlc/memory/pdr/
  • Final completion verification: all 8 checks pass

© tikalk, 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 5 other files (scripts) in skills/product/product-implement of tikalk/adlc-team-skills.

  • SKILL.md
  • scripts/bash/migrate-pdr-frontmatter.sh
  • scripts/bash/setup-product-implement.sh
  • scripts/bash/validate-pdr.sh
  • scripts/bash/validate-prd.sh
  • scripts/powershell/setup-product-implement.ps1

Open the folder on GitHubat commit 2dbed36

Compare with similar skills

Product Implement 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.

Product Implement compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Product Implement this skilltikalk/adlc-team-skills141—~3.7kAutomated safety check: PassMIT
CCPM Project Managementautomazeio/ccpm8.4k—~1.1kAutomated safety check: PassMIT
Ralph Tui Create Beadssubsy/ralph-tui2.5k1 repos~2.6kAutomated safety check: PassMIT
Trellis Brainstormanjiemo/SunnyBeach1787 repos~4kAutomated safety check: PassApache-2.0
Adversarial Speczscole/adversarial-spec5561 repos~8.3kAutomated safety check: NotesMIT
Ralph Tui Create Beads Rustsubsy/ralph-tui2.5k1 repos~2.8kAutomated safety check: PassMIT

Similar skills

  • Runs a spec-driven workflow from PRD to epic to GitHub issues to parallel agents, with status, standup and blocked-work reports from bundled scripts.

    8.4k GitHub stars~1.1k tokensUpdated 6 mo ago
    Product & Project ManagementAuto-check passed
  • Ralph Tui Create Beads

    subsy/ralph-tui

    Convert PRDs to beads for ralph-tui execution. An agent skill from subsy/ralph-tui.

    2.5k GitHub starsUsed in 1 repo~2.6k tokens
    Product & Project ManagementAuto-check passed
  • Trellis Brainstorm

    anjiemo/SunnyBeach

    Guides collaborative requirements discovery before implementation.

    178 GitHub starsUsed in 7 repos~4k tokens
    Product & Project ManagementAuto-check passed
  • Adversarial Spec

    zscole/adversarial-spec

    Iteratively refine a product spec by debating with multiple LLMs (GPT, Gemini, Grok, etc.) until all models agree.

    556 GitHub starsUsed in 1 repo~8.3k tokens
    Product & Project ManagementAuto-check: notes
  • Convert PRDs to beads for ralph-tui execution using beads-rust (br CLI).

    2.5k GitHub starsUsed in 1 repo~2.8k tokens
    Product & Project ManagementAuto-check passed
  • To Issues

    ywwynm/EverythingDone

    Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices.

    144 GitHub starsUsed in 12 repos~893 tokens
    Product & Project ManagementAuto-check passed

More from tikalk/adlc-team-skills

All 44 skills in this repo
  • Team Boot

    tikalk/adlc-team-skills

    A skill your agent uses when a session starts or resumes after compaction (auto via the sessionstart and sessioncompact event hooks) and the team AI directives context — constitution, CDR index…

    141 GitHub stars~2.2k tokensUpdated yesterday
    Auto-check passed
  • Architect Clarify

    tikalk/adlc-team-skills

    A skill your agent uses when ADRs need review, gaps need filling, or ADR status must be approved as Accepted before architecture generation.

    141 GitHub stars~4.7k tokensUpdated yesterday
    Auto-check passed
  • Change Clarify

    tikalk/adlc-team-skills

    A skill your agent uses when reviewing, accepting, rejecting, or deferring ChDRs mined by change-init, validating inferred decisions against their git and issue evidence before promotion to project…

    141 GitHub stars~2.9k tokensUpdated yesterday
    Auto-check passed
  • Change Init

    tikalk/adlc-team-skills

    A skill your agent uses when you want guided mining of git history, structured change-story clustering, or comprehensive rationale recovery before documenting.

    141 GitHub stars~3.5k tokensUpdated yesterday
    Auto-check passed
  • Change Publish

    tikalk/adlc-team-skills

    A skill your agent uses when accepted ChDRs are ready for promotion from drafts to project memory at docs/adlc/memory/chdr/ and the boot-facing chdr.md index needs regenerating.

    141 GitHub stars~2k tokensUpdated yesterday
    Auto-check passed
  • Evals Analyze

    tikalk/adlc-team-skills

    A skill your agent uses when evaluation results need triage and loop-closing — spec failures route to deterministic checks or context rules, generalization failures to the evaluator backlog.

    141 GitHub stars~1.2k tokensUpdated yesterday
    Auto-check passed

Questions about Product Implement

What does Product Implement do?

A skill your agent uses when accepted PDRs exist and PRD.md must be generated or updated. Product Implement is an agent skill from tikalk/adlc-team-skills.md must be generated or updated.

When should I use Product Implement?

Product Implement fits situations like: accepted PDRs exist and PRD.md must be generated; tasks that involve PRD writing.

How do I install Product Implement in Claude Code?

Run `npx skills add tikalk/adlc-team-skills --skill product-implement -a claude-code`. Or copy the skill folder (skills/product/product-implement in tikalk/adlc-team-skills) into .claude/skills/product-implement in your project. Claude Code loads it when a task matches its description.

How do I install Product Implement in Codex?

Run `npx skills add tikalk/adlc-team-skills --skill product-implement -a codex`. Or copy the skill folder (skills/product/product-implement in tikalk/adlc-team-skills) into .agents/skills/product-implement in your project. Codex loads it when a task matches its description.

Can I use Product Implement 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 tikalk/adlc-team-skills --skill product-implement -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/product-implement, .gemini/skills/product-implement, .github/skills/product-implement and .opencode/skills/product-implement in your project.

What does Product Implement need to run?

Going by SKILL.md and its folder, Product Implement needs a shell and PowerShell for the scripts in its folder. Our summary lists: A Bash shell; PowerShell.

Does Product Implement 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 Product Implement 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. The check reads SKILL.md only: the scripts in the folder are not scanned, so read them before running anything.

What licence does Product Implement use?

Product Implement 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 Product Implement use?

About 3.7k tokens (SKILL.md is roughly 15k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Product Implement?

Skills that share tags, products or a category with Product Implement: CCPM Project Management (automazeio/ccpm, 8.4k stars), Ralph Tui Create Beads (subsy/ralph-tui, 2.5k stars), Trellis Brainstorm (anjiemo/SunnyBeach, 178 stars) and Adversarial Spec (zscole/adversarial-spec, 556 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Product Implement?

tikalk (a GitHub organization) maintains it in tikalk/adlc-team-skills, which has 141 GitHub stars. The repository holds 44 skills in this directory. The repository was last updated on October 6, 2026.

Source: tikalk/adlc-team-skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.