Automated summary
Bootstraps the `.adlc/` structure in a new repo or subdirectory, creating the context docs, templates, shell partials and workflow files needed for spec-driven development.
Strengths
- Creates a complete, opinionated tree in one pass (context, specs, bugs, knowledge, templates, partials, workflows)
- Pulls project context automatically from CLAUDE.md, README.md or package.json and asks for confirmation instead of interrogating blindly
- Copies ETHOS.md, templates, partials and workflows locally so the toolkit stays readable inside a git worktree where the sandbox blocks paths outside the cwd
- Detects an existing `.adlc/` and offers to reinitialize or fill in the gaps
Limitations
- Tightly coupled to the ADLC toolkit's own layout and to Claude Code's sandbox/worktree behavior, so it is not portable to other agents
- Assumes `~/.claude/skills` (templates, partials, workflows) exists so the copies can be made
- Produces documentation scaffolding only — it does not verify that the populated context is accurate or complete
Use it when starting a new repo or subdirectory that will follow the ADLC spec-driven workflow.
Avoid it when the project already has an established, up-to-date `.adlc/`, or when you are not using the ADLC toolkit.
Security analysis
CautionThe skill is a project scaffolder: it creates directories, copies templates/markdown, edits .gitignore, and chmods shell partials — all legitimate. The one notable risk is that it runs a shell script resolved from the working directory before falling back to the home toolkit, so a hostile repo could plant `.adlc/partials/ethos-include.sh` and get code executed. That plus general bash/file-write usage makes this 'caution' rather than 'safe', but nothing exfiltrates or destroys data.
- •Executes shell code from a path inside the target repo: `sh .adlc/partials/ethos-include.sh ... || sh ~/.claude/skills/...`. A repo that already contains a malicious `.adlc/partials/ethos-include.sh` would get arbitrary code executed when `/init` runs, since the local copy is tried first.
- •Uses `sh`, `cp`, `mkdir`, `chmod +x`, and mutates `.gitignore` in the user's working tree — powerful but standard scaffolding operations.
- •Copies and executes files from `~/.claude/skills/` (templates, partials, workflows) into the project; trust depends entirely on that external toolkit being legitimate.
- •No network calls, no exfiltration, no `curl|sh`, no destructive deletes, no obfuscated payloads observed.
Examples
/init/init packages/api/init .adlc already exists — show me what's there and add the missing templates and workflow filesname: init description: Bootstrap .adlc/ structure in a new repo or subdirectory argument-hint: Optional target directory (defaults to current directory)
/init — Bootstrap ADLC Structure
You are setting up the .adlc/ directory structure for spec-driven development.
Ethos
!sh .adlc/partials/ethos-include.sh 2>/dev/null || sh ~/.claude/skills/partials/ethos-include.sh
Input
Target: $ARGUMENTS
Instructions
Step 1: Determine Target Directory
- If given a path, use that as the target
- If no argument, use the current working directory
- Check if
.adlc/already exists — if so, report what's already there and ask if the user wants to reinitialize or fill gaps
Step 2: Gather Project Context
Ask the user for the following (skip any that are already known from existing files):
- Project name — What is this project called?
- What it does — One paragraph description
- Tech stack — Languages, frameworks, databases, cloud providers
- Project scope — What's in scope vs out of scope
- Key architectural patterns — Layered? Microservices? Monolith?
If a CLAUDE.md, README.md, or package.json exists, extract this info automatically and confirm with the user instead of asking.
Step 3: Create Directory Structure
.adlc/
ETHOS.md # Copy of ~/.claude/skills/ETHOS.md — ensures skills work inside git worktrees
context/
project-overview.md # What the project does, tech stack, scope
architecture.md # System diagram, layers, key patterns, ADRs
conventions.md # File organization, naming, testing, git conventions
taxonomy.md # Retrieval tag vocabulary (component/domain/stack/concerns)
specs/
.gitkeep
bugs/
.gitkeep
knowledge/
assumptions/
.gitkeep
lessons/
.gitkeep
templates/ # Copies of ~/.claude/skills/templates/*.md — ensures skills work inside git worktrees
assumption-template.md
bug-template.md
lesson-template.md
requirement-template.md
task-template.md
partials/ # Copies of ~/.claude/skills/partials/*.sh — shared shell snippets sourced by SKILL.md files
ethos-include.sh
workflows/ # Copies of ~/.claude/skills/workflows/ RUNTIME files only — Dynamic Workflow scripts used by the workflow engine
adlc-sprint.workflow.js # ONE self-contained file: meta first, schemas + pure helpers inlined behind // ==== BEGIN/END PURE ==== (runtime has no require)
README.md # NOTE: workflows/tests/ is intentionally NOT copied — those are toolkit-internal node:test files (CommonJS require) that break Jest in "type":"module" consumer repos (see Step 6)
Why the local copies of ETHOS.md, templates, partials, and workflows? Claude Code's sandbox blocks the Read tool from accessing paths outside the current working directory. When a skill runs inside a git worktree (e.g., .claude/worktrees/<name>/), ~/.claude/skills/ETHOS.md, ~/.claude/skills/templates/*.md, ~/.claude/skills/partials/*.sh, and ~/.claude/skills/workflows/* become unreadable by subagents and any tool that uses Read mid-skill. Keeping copies under .adlc/ makes the toolkit work identically in main checkouts and worktrees.
Step 4: Populate Context Files
project-overview.md — Based on user input or existing docs:
# {Project Name} — Project Overview
## What It Does
{description}
## Tech Stack
{tech stack table or list}
## Project Scope
{in scope / out of scope}
architecture.md — Initial structure:
# {Project Name} — Architecture
## System Diagram
{ASCII diagram of major components}
## Layers
{description of architectural layers}
## Key Patterns
{important patterns used in the codebase}
## ADRs
(Add architectural decision records here as decisions are made)
conventions.md — Based on project analysis:
# {Project Name} — Conventions
## File Organization
{directory structure}
## Naming
{naming conventions per language}
## Testing
{test framework, conventions, coverage requirements}
## Error Handling
{error handling patterns}
## Git Conventions
{branch naming, commit messages, PR process}
Step 5: Update .gitignore
Add the following entries to the project's .gitignore (create it if it doesn't exist):
# ADLC worktrees (used by /proceed for parallel session isolation)
.worktrees/
# Claude Code per-user permission overrides (team settings live in .claude/settings.json)
.claude/settings.local.json
# ADLC ID counters are global (~/.claude/.global-next-req, ~/.claude/.global-next-bug, ~/.claude/.global-next-lesson) — not per-project
# Legacy per-project counters (deprecated, no longer read/written — ignored if present)
.adlc/.next-bug
.adlc/.next-req
.adlc/.next-lesson
Step 6: Copy ETHOS.md and Templates Into the Project
Copy the canonical ETHOS.md and all templates from the toolkit into the project so skills keep working inside git worktrees (where Read is sandboxed to the worktree root).
# Verify source exists
if [ ! -f ~/.claude/skills/ETHOS.md ] || [ ! -d ~/.claude/skills/templates ] || [ ! -d ~/.claude/skills/partials ] || [ ! -d ~/.claude/skills/workflows ]; then
echo "ERROR: Toolkit not found at ~/.claude/skills/. Ensure ~/.claude/skills is symlinked to the adlc-toolkit repo."
exit 1
fi
# Copy ETHOS.md (overwrite — canonical is source of truth)
cp ~/.claude/skills/ETHOS.md .adlc/ETHOS.md
# Copy templates (overwrite — canonical is source of truth)
mkdir -p .adlc/templates
cp ~/.claude/skills/templates/*.md .adlc/templates/
# Copy partials (overwrite — canonical is source of truth). These are POSIX
# shell snippets sourced by SKILL.md files (e.g., ethos-include.sh).
mkdir -p .adlc/partials
cp ~/.claude/skills/partials/*.sh .adlc/partials/
chmod +x .adlc/partials/*.sh
# Copy workflows (overwrite — canonical is source of truth). These are the
# Dynamic Workflow scripts the workflow engine runs (e.g.,
# adlc-sprint.workflow.js — ONE self-contained file with schemas + pure helpers
# inlined, since the runtime has no require). Resolved via the two-level fallback
# (.adlc/workflows/... -> ~/.claude/skills/workflows/...) so the engine works
# inside git worktrees where Read is sandboxed to the worktree root.
#
# Copy ONLY the runtime files: the workflow script(s) and the top-level README.
# Do NOT copy workflows/tests/ — those are toolkit-internal `node:test` unit
# tests for the inlined PURE helpers (CommonJS `require('node:test')`). They have
# no purpose in a consumer repo, and shipping a `*.test.js` under .adlc/ is a
# trap: in any "type":"module" repo running Jest, the DEFAULT testMatch
# (**/?(*.)+(spec|test).[jt]s?(x)) discovers .adlc/workflows/tests/helpers.test.js,
# runs it as ESM, and fails it with "ReferenceError: require is not defined" —
# reddening `npm test` and any CI gate that runs it. The engine is ONE
# self-contained file (no require/import/fs), so globbing *.workflow.js captures
# everything the runtime ever resolves.
mkdir -p .adlc/workflows
cp ~/.claude/skills/workflows/*.workflow.js .adlc/workflows/
cp ~/.claude/skills/workflows/README.md .adlc/workflows/
# Idempotent cleanup: remove a stale tests/ dir left by an OLDER /init that did
# `cp -R` of the whole workflows tree. Heals already-initialized repos on re-run;
# safe no-op when absent. (Belt-and-suspenders to the explicit-file copy above.)
rm -rf .adlc/workflows/tests
# Clean up Finder-style duplicates if present. Matches:
# - .md files: "requirement-template 2.md"
# - non-.md files: "pipeline-state 2.json", ".next-bug 2"
# - directories: "knowledge 2", "specs 2"
# The `-depth` flag processes directory contents before the directory itself,
# so `rm -rf` on a "* 2" dir doesn't fail due to prior deletions.
find .adlc -depth \( -name "* 2" -o -name "* 2.*" \) -exec rm -rf {} + 2>/dev/null
# Advisory (Jest repos): the copy above ships NO test files under .adlc/, so the
# default Jest testMatch stays green with no config change. Only a repo with a
# custom BROAD testMatch (e.g. "**/*.js") would pick up .adlc/ — those repos
# should add "<rootDir>/.adlc/" to testPathIgnorePatterns. Purely informational;
# this does not edit package.json or any jest config.
if grep -q '"jest"' package.json 2>/dev/null || find . -maxdepth 1 -name 'jest.config.*' 2>/dev/null | grep -q .; then
echo "ADVISORY (Jest detected): .adlc/ contains no test files by design — default 'npm test' is unaffected. If you use a custom broad testMatch, add \"<rootDir>/.adlc/\" to testPathIgnorePatterns."
fi
If the user has previously made intentional customizations to their local .adlc/ETHOS.md, .adlc/templates/*.md, .adlc/partials/*.sh, or .adlc/workflows/adlc-sprint.workflow.js, confirm before overwriting. Use /template-drift to surface what differs (it also flags a stale .adlc/workflows/tests/ left by an older /init — the Jest landmine fixed above). Typical drift (stale copies) should be overwritten silently.
Vendored sync surfaces (drift-detection contract with /template-drift)
The four surfaces this step copies are the project's vendored sync surfaces — copied once at
init time, never auto-updated afterward. /template-drift is the tool that detects when a toolkit
update to any of them has not yet landed in this project. The two lists MUST stay in agreement:
every surface added here must get a matching check in /template-drift (see its
<!-- sync-surfaces: template-drift --> list). The toolkit's tools/lint-skills
sync-surface-parity check fails the build if they diverge.
ethos—cp ~/.claude/skills/ETHOS.md .adlc/ETHOS.mdtemplates—cp ~/.claude/skills/templates/*.md .adlc/templates/partials—cp ~/.claude/skills/partials/*.sh .adlc/partials/workflow-runtime—cp ~/.claude/skills/workflows/*.workflow.js+README.md→.adlc/workflows/
(Note: /template-drift checks one additional surface — workflow-test-landmine, a stale
*.test.js an older /init left under .adlc/. That is a drift symptom this step deliberately
does NOT copy, so it has no entry here; the parity check accounts for that asymmetry.)
Step 7: Scaffold Retrieval Taxonomy
Copy the canonical taxonomy template to .adlc/context/taxonomy.md so authors of new REQs, bugs, and lessons have a reference vocabulary for retrieval tags.
This step is idempotent — skip if the file already exists (preserve any project-local customizations).
# Verify source exists
if [ ! -f ~/.claude/skills/templates/taxonomy-template.md ]; then
echo "ERROR: Taxonomy template not found at ~/.claude/skills/templates/taxonomy-template.md. Ensure ~/.claude/skills is symlinked to the adlc-toolkit repo."
exit 1
fi
# Ensure destination directory exists (safe if Step 3 already created it)
mkdir -p .adlc/context
# Idempotent copy: only copy if destination does not already exist
if [ ! -f .adlc/context/taxonomy.md ]; then
cp ~/.claude/skills/templates/taxonomy-template.md .adlc/context/taxonomy.md
echo "Created .adlc/context/taxonomy.md from canonical template."
else
echo "Preserved existing .adlc/context/taxonomy.md (idempotent — not overwritten)."
fi
Advise the user: "Open .adlc/context/taxonomy.md and customize the example values for this codebase. Authors of new REQs, bugs, and lessons will reference this file when choosing tag values (component, domain, stack, concerns). The tags dimension stays free-form."
Step 8: Scaffold Claude Code Permissions Allowlist
Copy the canonical Claude Code settings template to .claude/settings.json so /proceed (and every other skill in this toolkit) can run end-to-end without prompting for permission on every routine git, gh, test, and agent-dispatch operation. This is the single biggest mitigation against per-phase gating in long-running pipelines.
This step is idempotent — skip if the file already exists (preserve any project-local customizations).
# Verify source exists
if [ ! -f ~/.claude/skills/templates/claude-settings-template.json ]; then
echo "ERROR: Settings template not found at ~/.claude/skills/templates/claude-settings-template.json. Ensure ~/.claude/skills is symlinked to the adlc-toolkit repo."
exit 1
fi
# Ensure destination directory exists
mkdir -p .claude
# Idempotent copy: only copy if destination does not already exist
if [ ! -f .claude/settings.json ]; then
cp ~/.claude/skills/templates/claude-settings-template.json .claude/settings.json
echo "Created .claude/settings.json from canonical template."
else
echo "Preserved existing .claude/settings.json (idempotent — not overwritten)."
fi
The template pre-approves the routine git, gh, npm, Read/Write/Edit, and agent-dispatch operations the ADLC pipeline fires. Destructive operations (rm -rf, git reset --hard, gh pr merge, ./deploy.sh, terraform apply/destroy, force-push to main) remain on the ask list so a human still confirms the one-way moves. Customize for project-specific commands (e.g., add Bash(cd app && ./deploy.sh:*) for iOS deploys) by editing .claude/settings.json directly.
Advise the user: ".claude/settings.json was scaffolded with a default allowlist. Commit this file — it is team-shared. Use .claude/settings.local.json (gitignored by Claude Code) for personal overrides."
Step 9: Scaffold Cross-Repo Config (Optional)
Ask the user: "Will this repo ever share features with other repos you also work on (e.g., an admin app + its API + an iOS app)? If yes, /proceed can coordinate REQs across them — this repo needs a .adlc/config.yml to list its siblings."
Conceptual note — explain if the user seems uncertain: "Primary" is per-REQ, not a fixed role. The current repo is primary for REQs that originate here (/proceed invoked from this repo). The siblings you list are other repos that might participate when a cross-repo REQ starts here. If you also originate REQs from one of those siblings, you'll run /init there too — each repo that hosts REQs gets its own .adlc/ and its own config.yml listing the others as siblings (mirror images of each other).
If the user confirms cross-repo and .adlc/config.yml does not already exist, copy the template:
# Verify source exists
if [ ! -f ~/.claude/skills/templates/config-template.yml ]; then
echo "ERROR: Config template not found at ~/.claude/skills/templates/config-template.yml."
exit 1
fi
if [ ! -f .adlc/config.yml ]; then
cp ~/.claude/skills/templates/config-template.yml .adlc/config.yml
echo "Created .adlc/config.yml from template — edit it to match your repo layout."
else
echo "Preserved existing .adlc/config.yml."
fi
Advise the user:
- "Edit
.adlc/config.yml. The entry for THIS repo should haveprimary: trueand nopath(path is implicit since it's this repo). Each sibling entry gets apath:(relative to this repo root, or absolute). Every sibling must already be cloned locally at that path." - "If you also run REQs from one of the siblings, run
/initthere too. That repo's config will mark itself as primary and list the others as siblings — the structure is symmetric." - "If this is a single-repo project (REQs only ever originate here and never touch other repos), skip this step. ADLC skills fall back to single-repo behavior when no config or no siblings are declared."
- "After editing, verify with
cat .adlc/config.ymland make sure each sibling path resolves:git -C <sibling-path> rev-parse --git-dir."
If the project is single-repo, skip the copy (no config file needed).
Step 10: Summary
- Display the created directory structure
- Explain the ADLC workflow:
/spec→/validate→/architect→/validate→ implement →/reflect→/review→/wrapup(or use/proceedto run the full pipeline automatically) - If cross-repo config was scaffolded, remind the user that
/proceedwill create worktrees in every touched sibling and open one PR per repo - Suggest adding ADLC skill references to the project's
CLAUDE.mdif one exists
From the file to a first result
The download contains exactly the content displayed on this page. This copy may differ from the latest version in the source repository.
View the source and supporting filesThis download contains SKILL.md only. Any scripts, references, templates and dependencies are not included. Get the required files from the source, preserving their directory structure, before continuing.
1. Download the file
Download SKILL.mdFrom the root of a test project, save the file as .skill-downloads/bootstrap-adlc-structure-ms47vpaz/SKILL.md, or use the command below. This folder is for inspecting the skill before installation.
Command for macOS/Linux or WSL: requires a POSIX shell and curl. On Windows without WSL, use the download button and create the folder manually.
mkdir -p '.skill-downloads/bootstrap-adlc-structure-ms47vpaz' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/bootstrap-adlc-structure-ms47vpaz/download' --output '.skill-downloads/bootstrap-adlc-structure-ms47vpaz/SKILL.md.part' && mv '.skill-downloads/bootstrap-adlc-structure-ms47vpaz/SKILL.md.part' '.skill-downloads/bootstrap-adlc-structure-ms47vpaz/SKILL.md'2. Check prerequisites
Read SKILL.md before using it. If it references scripts or external services, inspect them and prepare the required access in your test environment.
No recognized prerequisites section in this file. This does not mean it is self-contained: libraries, tools and access requirements may be mentioned elsewhere in the content or source repository.
The platforms on this page are catalog indications. The paths below follow tool documentation; they do not prove this skill has been run in those tools. No minimum tool version is confirmed for this listing.
3. Load the skill
After inspection, copy the complete folder into your project using one of the commands below, then open a new tool session. The command stops if a folder with the same name already exists: compare the files before replacing it.
Claude Code
test -f '.skill-downloads/bootstrap-adlc-structure-ms47vpaz/SKILL.md' && test -s '.skill-downloads/bootstrap-adlc-structure-ms47vpaz/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/init' && cp -R '.skill-downloads/bootstrap-adlc-structure-ms47vpaz' '.claude/skills/init'OpenSkills
OpenSkills must already be installed. The local install/read procedure is checked with OpenSkills 1.5.0, which requires Node.js ≥ 20.6.0. Catalog slugs are not resolved automatically.
Official OpenSkills installationopenskills install './.skill-downloads/bootstrap-adlc-structure-ms47vpaz'openskills read 'bootstrap-adlc-structure-ms47vpaz'Reading should display the installed file content and its base directory. It does not run the skill or install its dependencies.
For an agent that reads AGENTS.md, then sync the index. This command changes AGENTS.md: review the diff before using it.
openskills syncManual method or another tool: attach SKILL.md to a conversation, or open it in an agent that can read files. Include any required supporting resources. No universal folder is recognized by every tool.
4. Try a first task
Use a short, synthetic input: an API endpoint, a small document or an interface brief. In a new conversation, attach the file or give the agent its path, then adapt this request:
Read .skill-downloads/bootstrap-adlc-structure-ms47vpaz/SKILL.md and apply its instructions to this example: [describe a test input]. Identify any missing files, dependencies or access. Produce the result requested by the skill without inventing data or running unreviewed scripts.Expected result: output matching the skill instructions, or a precise list of missing prerequisites. A read confirmation alone does not validate a first use. If an external resource is unavailable, that path remains untested.
React Hook Form Best Practices
Development
Master React Hook Form: avoid anti-patterns, manage subscriptions, and handle reset, dirty state, and controlled inputs correctly.
Emotion to Mantine Migration
Development
Migrate Emotion styled-components to Mantine components with style props and CSS modules. Use when converting .styled.tsx files or removing @emotion imports.
Scope Creep Detector
Development
Analyzes git diffs against a stated intent to detect scope creep, unrelated files, broad PRs, and oversized changes, then suggests keep, split, or justify actions.