create-adsk
| # /design-architecture | ||
| Collaborate on a sized solution-architecture packet (brief, C4 views, ADRs, risks). | ||
| ## Skill | ||
| Read and follow **`skills/solution-architecture`**. Load references only as that skill directs. | ||
| ## Usage | ||
| ``` | ||
| /design-architecture | ||
| /design-architecture "B2B notifications service — Medium, unclear email/webhook integration" | ||
| ``` | ||
| ## Behavior | ||
| 1. Size the work (Small skip / Medium packet / Large / AI extensions). | ||
| 2. Draft the architecture brief; confirm top quality attributes and assumptions. | ||
| 3. Produce only the views required by size (logical first, vendor second). | ||
| 4. Record ADRs for irreversible choices and a lite risk register. | ||
| 5. Link artifacts from the living spec/plan; offer a lightweight review checklist. |
| # solution-architecture |
| # /draft-spec | ||
| Generate a specification from a feature idea. | ||
| Generate a specification from a feature idea (or a surgical bugfix). | ||
| ## Skill | ||
| Read and follow **`skills/spec-driven-workflow`** (especially `references/spec-writing-guide.md` and `references/artifact-homes.md`). For Cursor output homes, also follow `references/cursor-adapter.md`. | ||
| Read and follow **`skills/spec-driven-workflow`** (especially `references/spec-writing-guide.md` and `references/artifact-homes.md`). For Cursor output homes, also follow `references/cursor-adapter.md`. For non-trivial bugs, follow `references/bugfix-workflow.md`. | ||
@@ -13,2 +13,3 @@ ## Usage | ||
| /draft-spec "your feature idea or description" | ||
| /draft-spec "Bug: …" # use bugfix template when appropriate | ||
| ``` | ||
@@ -19,7 +20,8 @@ | ||
| 1. If the idea is vague: surface assumptions and reframe into success criteria (2–3 questions max). Do not silently invent requirements. | ||
| 2. Scan the codebase for related patterns. | ||
| 3. Write a testable spec (prefer `REQ-XXX` IDs + acceptance criteria + test strategy). Include Assumptions / Open Questions when anything is unresolved. | ||
| 4. **Resolve the spec path** via the skill (`artifact-homes.md`). As a Cursor `/` command, default to `.cursor/docs/specs/{feature-name}.md` unless the project already uses `docs/specs/` or the user passed `--out`. | ||
| 5. Pause for user review on medium+ work; then suggest `/plan-impl`, or `/implement-spec` for small changes. | ||
| 2. Choose entry mode: **Requirements-First** (default), **Design-First** when TECH/NFRs dominate, or **Bugfix** (Current / Expected / Unchanged) for non-trivial defects. | ||
| 3. Scan the codebase for related patterns. | ||
| 4. Write a testable spec (prefer `REQ-XXX` IDs + acceptance criteria + test strategy). Include Assumptions / Open Questions when anything is unresolved. | ||
| 5. **Resolve the spec path** via the skill (`artifact-homes.md`). As a Cursor `/` command, default to `.cursor/docs/specs/{feature-name}.md` unless the project already uses `docs/specs/` or the user passed `--out`. | ||
| 6. Pause for user review on medium+ work; then suggest a cross-requirement **analyze** pass (`references/analyze-requirements.md`) before `/plan-impl`, or `/implement-spec` for small changes. | ||
| Do not duplicate the full playbook here — the skill is the source of truth. |
@@ -17,4 +17,4 @@ # /implement-spec | ||
| 1. **Clear** (Medium+): confirm exploration is persisted in the living spec/plan; start this session lean — see skill gated procedure. | ||
| 2. Read the spec or plan; follow the plan step-by-step when present. | ||
| 1. **Clear** (Medium+): confirm exploration is persisted in the living spec/plan; start this session lean — see skill gated procedure. If the living spec changed after the plan was written, **resync** (`/plan-impl`) before coding. | ||
| 2. Read the spec or plan; follow the plan step-by-step when present. For bugfix specs, honor the Unchanged (KEEP) fence. | ||
| 3. Implement with tests mapped to requirements (or justify non-behavioral exceptions). | ||
@@ -21,0 +21,0 @@ 4. Update plan todo status as steps complete (Cursor Plan YAML `todos` and/or portable checklist — see `references/cursor-adapter.md` / `artifact-homes.md`). |
@@ -7,3 +7,3 @@ # /plan-impl | ||
| Read and follow **`skills/spec-driven-workflow`**. Resolve paths with `references/artifact-homes.md`. For Cursor plan files, follow `references/cursor-adapter.md` (YAML `todos` required). When the **engineering-methods** pack is installed, use upstream `writing-plans` for granular task style — see `docs/engineering-methods.md`. | ||
| Read and follow **`skills/spec-driven-workflow`**. Resolve paths with `references/artifact-homes.md`. For Cursor plan files, follow `references/cursor-adapter.md` (YAML `todos` required). When the **engineering-methods** pack is installed, use upstream `writing-plans` for granular task style — see `docs/engineering-methods.md`. Before planning Medium+, run or confirm the cross-requirement pass in `references/analyze-requirements.md`. | ||
@@ -19,8 +19,9 @@ ## Usage | ||
| 1. Read the spec; if open questions or unconfirmed assumptions remain, resolve those before planning. | ||
| 2. Break work into ordered, verifiable tasks (files, tests, risks). Prefer tasks that map to `REQ-XXX` and stay within a focused file set. Prefer splitting **build** from **verify/review** so QA can run in parallel with the next slice. | ||
| 3. **Tracer gate** (Large, and Medium when architecture/integration is ambiguous): include a thin vertical slice + one verify before multi-phase implement, or “N/A — architecture proven” with justification — see skill / `problem-size-guide.md`. | ||
| 4. **Resolve the plan path** via the skill. As a Cursor `/` command, default to `.cursor/plans/{feature-name}.plan.md` unless the project already uses `docs/plans/` or the user overrides the path. | ||
| 5. Write the plan with **trackable todos** (Cursor: non-empty frontmatter `todos`; never body-only REQ tables with empty Plan UI todos). | ||
| 6. Suggest `/implement-spec` only after the user approves the plan (medium+). | ||
| 2. **Analyze** (Medium+): cross-check REQs for conflicts, ambiguity, and gaps (`analyze-requirements.md`). Update the living spec if findings change REQs. If a plan already exists and REQs changed, treat this as a **resync** (replace stale todos). | ||
| 3. Break work into ordered, verifiable tasks (files, tests, risks). Prefer tasks that map to `REQ-XXX` and stay within a focused file set. Prefer splitting **build** from **verify/review** so QA can run in parallel with the next slice. For bugfix specs, map tasks/tests to both FIX and KEEP (Unchanged) items. | ||
| 4. **Tracer gate** (Large, and Medium when architecture/integration is ambiguous): include a thin vertical slice + one verify before multi-phase implement, or “N/A — architecture proven” with justification — see skill / `problem-size-guide.md`. | ||
| 5. **Resolve the plan path** via the skill. As a Cursor `/` command, default to `.cursor/plans/{feature-name}.plan.md` unless the project already uses `docs/plans/` or the user overrides the path. | ||
| 6. Write the plan with **trackable todos** (Cursor: non-empty frontmatter `todos`; never body-only REQ tables with empty Plan UI todos). | ||
| 7. Suggest `/implement-spec` only after the user approves the plan (medium+). | ||
| Keep this command thin — planning depth lives in the skill / recommended upstream. |
@@ -23,5 +23,6 @@ { | ||
| "delivery": { | ||
| "description": "SDD plus DevOps strategy and release automation.", | ||
| "description": "SDD plus solution architecture, DevOps strategy, and release automation.", | ||
| "skills": [ | ||
| "spec-driven-workflow", | ||
| "solution-architecture", | ||
| "devops-strategy-facilitator", | ||
@@ -37,2 +38,3 @@ "release-automation" | ||
| "spec-driven-workflow", | ||
| "solution-architecture", | ||
| "devops-strategy-facilitator", | ||
@@ -52,2 +54,3 @@ "release-automation", | ||
| "spec-driven-workflow", | ||
| "solution-architecture", | ||
| "devops-strategy-facilitator", | ||
@@ -54,0 +57,0 @@ "release-automation", |
+1
-1
| { | ||
| "name": "create-adsk", | ||
| "version": "0.3.5", | ||
| "version": "0.3.6", | ||
| "description": "Adopt the Agentic Development Starter Kit as a versioned profile (skills + Cursor wiring).", | ||
@@ -5,0 +5,0 @@ "type": "module", |
+3
-1
@@ -27,3 +27,3 @@  | ||
| | `core` | Spec-driven workflow + Cursor commands | | ||
| | `delivery` | Core + DevOps strategy + release automation | | ||
| | `delivery` | Core + solution architecture + DevOps strategy + release automation | | ||
| | `maintainer` | Delivery + skill/README/PR authoring + supply-chain gate + stock rules | | ||
@@ -59,2 +59,4 @@ | `skills-only` | All first-party skills; no `.cursor/` writes | | ||
| **Org rules:** put company policy in `.cursor/rules/org-*/` in the app — `update` does not overwrite those folders. Avoid `--force-rules` unless you intend to reset stock rules. Guide: [`docs/customizing-org-rules.md`](../../docs/customizing-org-rules.md). | ||
| ## Two tools | ||
@@ -61,0 +63,0 @@ |
Sorry, the diff of this file is not supported yet
URL strings
Supply chain riskPackage contains fragments of external URLs or IP addresses, which the package may be accessing at runtime.
URL strings
Supply chain riskPackage contains fragments of external URLs or IP addresses, which the package may be accessing at runtime.
120361
1.8%73
2.82%1431
0.21%97
2.11%