architect-analyze
Use when validating generated or refined architecture artifacts, before feature development, during architecture review, or…
Use when product or feature work starts, or a PDR-worthy decision (scope, persona, monetization) emerges — injects the PDR index (docs/adlc/memory/pdr/, legacy .adlc/memory/pdr/ fallback) as session context and pairs the decision with capture via /product-specify; invoked from
$ npx -y skills add tikalk/adlc-team-skills --skill product-boot --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/product-bootContext preview
The summary Claude sees to decide when to auto-load this skill.
Use when product or feature work starts, or a PDR-worthy decision (scope, persona, monetization) emerges — injects the PDR index (docs/adlc/memory/pdr/, legacy .adlc/memory/pdr/ fallback) as session context and pairs the decision with capture via /product-specify; invoked from
name: product-boot description: Use when product or feature work starts, or a PDR-worthy decision (scope, persona, monetization) emerges — injects the PDR index (docs/adlc/memory/pdr/, legacy .adlc/memory/pdr/ fallback) as session context and pairs the decision with capture via /product-specify; invoked from team-boot's Class Boots catalog.
One of the five **class boots** surfaced by `team-boot`'s Class Boots catalog. `team-boot` injects the always-relevant team context (constitution, CDR index, skills registry) at session start; this skill loads the **product decision layer** on demand — the Accepted PDR index from project memory — and pairs it with decision capture so new product choices are recorded (`/product-specify`) rather than evaporating.
Reading decisions and recording decisions are one loop: existing PDRs inform the work; decisions made during the work flow back into the same record system.
Invoke at the START of a matching task — before planning the todo list and before implementation — so the PDR context informs planning. Never defer to session end.
Invoke when:
planning, GTM decisions).
definition, monetization, pricing, or target-market choices emerge.
`/product-roadmap` benefit from the loaded index).
From the current working directory (do NOT walk up parent directories):
1. Primary: `docs/adlc/memory/pdr/pdr.md` (generated by `/product-implement`; rows start with `| PDR`) 2. Fallback: `.adlc/memory/pdr/pdr.md` (legacy layout, legacy)
If neither exists but `docs/adlc/memory/pdr/PDR-*.md` or legacy `.adlc/memory/pdr/PDR-*.md` files do, synthesize a lean table from each file (ID from filename; Feature-Area/Status/Title from frontmatter or first heading). If the directory is empty or absent, report `0 PDRs` — never fabricate rows.
When no local memory index exists in the current working directory and the directory sits inside a workspace (detected via a `.gitmodules` marker in an ancestor), read the workspace root's `docs/adlc/memory/` index instead (the dual-read order applies: `docs/adlc/memory` first, legacy `.adlc/memory` fallback).
Check `.adlc/drafts/pdr/` for `PDR-*.md` files with `status: proposed` in frontmatter. These are draft PDRs pending clarification. Collect ID / Title / Type / Status / Date from each file. If the directory is empty or absent, report `0 pending drafts`.
If `team-boot` injected no team context this session (no Team Context & Decisions section in the first user message — unconfigured project or hook failure): say so in one line, emit the section heading with a `0 PDRs matched (no team context injected — run /team-setup)` source line, and continue the task on the directly-read PDR index. Never treat a missing injection as an empty record set. Recovery: run `/team-diagnose`.
Emit before the task answer:
## PDR Context | ID | Feature-Area | Status | Title | |--|--|--|--| | AI triage | triage | Accepted | AI triage scoring | _Searched N PDRs, K matched._ ## Drafts Pending Review | ID | Title | Type | Status | Date | |----|-------|------|--------|------| | (from .adlc/drafts/pdr/) | _N pending drafts — run /product-clarify to review._
also carries Category, Date, Owner — read the individual `PDR-*.md` when a task matches a row).
equal the table rows shown.** 0 rows matched → emit the section heading + the `_Searched N PDRs, K matched._` line only — no table. A 0-row table header collapses into unrendered single-line markdown; never emit one. Emit the section as markdown blocks — heading, table rows, and counts line each on their own lines.
| Trigger | Action | |---------|--------| | Feature scope change, in/out decisions | PDR → direct write to `.adlc/drafts/pdr/` | | Persona definition or revision | PDR → direct write to `.adlc/drafts/pdr/` | | Monetization, pricing, target-market choice | PDR → direct write to `.adlc/drafts/pdr/` | | PDR-class decision already in the ledger | verify capture happened; if not, re-surface |
Add/refresh rows in **Team Context & Decisions** (ID | Name | Type | Rel | Status | Clarify) for every PDR-class decision detected this session — including ones from before this boot was invoked. Mirror each decision as a task-list todo (draft → `/product-clarify` at session end); after code-modifying tasks, add a trailing todo to sweep Team Context & Decisions until _Unrecorded: 0 pending · Unclarified: 0 drafts_ (a draft leaves Unclarified only via its clarify skill or an explicit user handoff to a named clarify or execute skill). At session end, deliver the clarify prompt naming each captured PDR draft in `.adlc/drafts/pdr/` (ID + skill); if the user defers clarify, mark those rows handed off.
`_Searched 0 PDRs, 0 matched._` only — no table — and continue the user's task; never block.
(K = table rows).
Agent skills that give coding agents your team's context at session start, so they stop working like strangers.
Use when validating generated or refined architecture artifacts, before feature development, during architecture review, or…
Use when architecture work starts or a tech-stack or pattern decision emerges — injects the project ADR index…
Use when ADRs need review, gaps need filling, or ADR status must be approved as Accepted before architecture generation.
Use when accepted ADRs exist and AD.md must be produced or updated as unified architecture documentation.
Use when bootstrapping architecture documentation for a brownfield project by reverse-engineering ADRs from an existing codebase.
Use when you want guided trade-off analysis, multi-option comparison, or structured architectural decision facilitation before…