@rasensio/aidlc-content 1.10.1 → 1.10.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rasensio/aidlc-content",
-  "version": "1.10.1",
+  "version": "1.10.2",
   "type": "module",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",

package/skills/04-idea-capture.md

@@ -53,7 +53,7 @@ Promotion is where the backlog meets the lifecycle:
 1. If the idea's `depends_on` names ideas that are still `raw`, say so and confirm before proceeding — promoting out of order is allowed but should be deliberate.
 2. Choose a template and scope as usual (defaults from `.aidlc/config.yaml`; see **aidlc-getting-started**).
 3. Create the instance per "Creating an Instance" in **aidlc-overview** — including firing `on-instance-start` lifecycle actions.
-4. Seed the instance with the idea file: Full scope → the idea is raw material the Ideation phase refines into `ideation.md`; Standard scope → the idea is input context for Requirements.
+4. Seed the instance with the idea file: Full scope → the idea is raw material the Ideation phase refines into that phase's required artifact (`idea.md` for the feature templates, `research-question.md` for `spike`); Standard scope → the idea is input context for Requirements.
 5. Update the idea's frontmatter: `status: promoted`, `promoted_to: <instance-name>`.
 
 ## Drop

package/skills/10-ideation.md

@@ -17,7 +17,12 @@ Explore the problem space before committing to a solution. Define what we are bu
 
 ## Required Artifacts
 
-- `ideation.md` — Problem statement, goals, constraints, initial ideas, and open questions
+The artifacts your template's ideation phase declares in `required_artifacts` — `idea.md` for the
+feature templates, `research-question.md` for `spike`. Run `aidlc continue` or read
+`phase-ideation.yaml` in the instance state dir if unsure which applies.
+
+Whatever the filename, the content is the same: problem statement, goals, constraints, initial ideas,
+and open questions.
 
 ## Instructions
 
@@ -27,11 +32,11 @@ Explore the problem space before committing to a solution. Define what we are bu
 4. **Generate options.** Propose 2-3 approaches. For each, note trade-offs (complexity, time, risk).
 5. **Identify unknowns.** List open questions that need answers before requirements can be written.
 6. **Record discoveries in the knowledge graph.** Persist what you learned about the codebase with `aidlc knowledge add` / `relate` (modules, services, conventions, debt). On a brownfield project, seed the graph first with `aidlc discover`. The phase gate requires at least 3 module entities, 2 depends-on relationships, and 1 convention entity.
-7. **Summarize.** Write `ideation.md` with sections: Problem Statement, Goals, Constraints, Explored Options, Open Questions.
+7. **Summarize.** Write the phase's required artifact (see Required Artifacts above) with sections: Problem Statement, Goals, Constraints, Explored Options, Open Questions.
 
 ## Exit Criteria
 
-- `ideation.md` exists and contains at minimum a problem statement and one defined goal
+- Every artifact the template's ideation phase requires exists, each containing at minimum a problem statement and one defined goal
 - The user has confirmed the direction (which option to pursue or a synthesis)
 - When the project uses the knowledge graph: it contains ≥3 module entities, ≥2 depends-on relationships, and ≥1 convention entity (checked automatically by `aidlc gate` / `aidlc transition`)
 

package/skills/20-requirements.md

@@ -21,7 +21,7 @@ Translate the ideation output (or the user's direct request) into precise, testa
 
 ## Instructions
 
-1. **Gather requirements.** If a Full scope, read `ideation.md` for context. Otherwise, ask the user to describe desired behavior. Read all active Guidance_Layers from `.aidlc/guidance/index.yaml` (including `lessons.md` — lessons from completed instances) so fresh guidance applies without recompiling skills.
+1. **Gather requirements.** If a Full scope, read the ideation phase's artifact for context (`idea.md` for the feature templates, `research-question.md` for `spike`; `phase-ideation.yaml` names it). Otherwise, ask the user to describe desired behavior. Read all active Guidance_Layers from `.aidlc/guidance/index.yaml` (including `lessons.md` — lessons from completed instances) so fresh guidance applies without recompiling skills.
 2. **Write user stories.** Use the format: "As a [role], I want [capability], so that [benefit]."
 3. **Define acceptance criteria.** Each criterion must be:
    - Specific and unambiguous

package/skills/50-testing.md

@@ -18,7 +18,9 @@ Verify that the implementation satisfies all acceptance criteria. Produce eviden
 ## Required Artifacts
 
 - Test files covering acceptance criteria
-- `testing.md` — Test plan, results summary, and coverage notes
+- The artifacts your template's testing phase declares in `required_artifacts` — `test-results.md` for
+  every built-in template. Read `phase-testing.yaml` in the instance state dir if unsure. Whatever the
+  filename, the content is the test plan, results summary, and coverage notes.
 
 ## Instructions
 
@@ -29,7 +31,7 @@ Verify that the implementation satisfies all acceptance criteria. Produce eviden
    - Property-based tests where inputs have broad domains
    - **Reference AC IDs.** When `requirements.md` defines `AC-n` criteria, each test names the criteria it verifies — in the test name or a comment (e.g. `// AC-3`). The testing-phase gate scans test files for these references and fails on any active criterion with none. If two instances define the same ID, qualify the reference as `<instance>/AC-n`.
 3. **Run tests.** Execute the project's test suite. All new tests must pass.
-4. **Document results.** Write `testing.md` with:
+4. **Document results.** Write the phase's required artifact (see Required Artifacts above) with:
    - Test plan (what was tested and why)
    - Results (pass/fail counts, any notable findings)
    - Coverage notes (which criteria are covered, any gaps)
@@ -44,7 +46,7 @@ Verify that the implementation satisfies all acceptance criteria. Produce eviden
 
 - All acceptance criteria have corresponding test coverage
 - All tests pass
-- `testing.md` exists with results summary
+- Every artifact the template's testing phase requires exists, with a results summary
 - No critical bugs remain open
 
 ## Guidance

package/skills/60-deployment.md

@@ -19,12 +19,15 @@ Prepare and execute the release. Ensure all preceding phases are complete, all g
 
 ## Required Artifacts
 
-- `deployment.md` — Release plan, rollback strategy, deployment checklist
+The artifacts your template's deployment phase declares in `required_artifacts` —
+`deployment-record.md` for every built-in template. Read `phase-deployment.yaml` in the instance state
+dir if unsure. Whatever the filename, the content is the release plan, rollback strategy, and
+deployment checklist.
 
 ## Instructions
 
-1. **Validate readiness.** Check the phase state files: every preceding required phase must be complete (all required artifacts `complete`). If any gate fails, address the gap before proceeding. (CLI shortcut: `aidlc gate deployment`.)
-2. **Write release plan.** Document in `deployment.md`:
+1. **Validate readiness.** Check the phase state files: every preceding required phase must be complete (all required artifacts `complete`). If any gate fails, address the gap before proceeding. (CLI shortcut: `aidlc gate <instance> deployment` — the phase name is the second argument, not the first.)
+2. **Write release plan.** Document in the phase's required artifact (see Required Artifacts above):
    - What is being deployed (version, changes summary)
    - Target environment(s)
    - Deployment steps in order
@@ -39,7 +42,7 @@ Prepare and execute the release. Ensure all preceding phases are complete, all g
 
 ## Exit Criteria
 
-- `deployment.md` exists with release plan and rollback strategy
+- Every artifact the template's deployment phase requires exists, with release plan and rollback strategy
 - Deployment executed successfully (or plan approved for manual execution)
 - Post-deployment verification confirms expected behavior
 

package/skills/70-maintenance.md

@@ -17,7 +17,10 @@ Ensure the deployed feature remains healthy. Update documentation, address feedb
 
 ## Required Artifacts
 
-- `maintenance.md` — Post-deployment notes, monitoring status, known issues, follow-up items
+The artifacts your template's maintenance phase declares in `required_artifacts` —
+`maintenance-plan.md` for `full-feature`. Read `phase-maintenance.yaml` in the instance state dir if
+unsure. Whatever the filename, the content is post-deployment notes, monitoring status, known issues,
+and follow-up items.
 
 ## Instructions
 
@@ -33,7 +36,7 @@ Ensure the deployed feature remains healthy. Update documentation, address feedb
 
 ## Exit Criteria
 
-- `maintenance.md` exists with post-deployment status
+- Every artifact the template's maintenance phase requires exists, with post-deployment status
 - Documentation is updated to reflect the delivered changes
 - No critical issues remain unaddressed
 - Follow-up items are documented (even if deferred to new instances)

package/skills/90-retrospective.md

@@ -22,7 +22,7 @@ Run the retro **before** any completion cleanup (worktree removal, claim release
 ## Retro Flow
 
 1. **Idempotency check.** If `retrospective.md` already exists in the instance state dir, offer to update or skip — never duplicate. A skip still removes the retro-pending marker.
-2. **Gather state.** Read `instance.yaml`, `phase-*.yaml`, and `transitions.log`. For the cost summary, prefer `aidlc cost report <instance>` (it applies fidelity precedence); only read `costs.ndjson` raw when the CLI is unavailable, and mark that summary approximate. No cost data → omit the cost section entirely, never write zeros.
+2. **Gather state.** Read `instance.yaml`, `phase-*.yaml`, and `transitions.log`. For the cost summary, prefer `aidlc cost <instance>` (it applies fidelity precedence); only read `costs.ndjson` raw when the CLI is unavailable, and mark that summary approximate. No cost data → omit the cost section entirely, never write zeros.
 3. **Ask — one round-trip.** Three questions in a single message: what surprised us? what would we do differently? what took longer than expected? For **Micro scope**, compress to one question: "anything surprising, worth doing differently, or slower than expected?" Declining the retro is fine: remove the marker, write nothing.
 4. **Write `retrospective.md`** in the instance state dir: the answers; instance metadata (template, scope); per-phase durations (pair each transitions.log `to: X` with the next `from: X`; fall back to the phase YAML's `entered_at`/`completed_at`; note inconsistencies rather than guessing); and the cost summary when available.
 5. **Distill lessons — 0 to 3.** A lesson is a durable, project-general observation ("NDJSON merge=union false-dedups identical same-second events"), not an instance anecdote ("we finished late"). If nothing generalizes, write no lesson — an empty distillation is a valid outcome.