Stats
Actions
Tags
From digital-innovation-agents
Transforms business analyses into epics, features, and tech-agnostic success criteria. Creates handoff documents, triages artifacts as FEATURE/IMP/FIX/ADR, manages BACKLOG.md entries, and runs GitHub integration for issues/PRs.
How this skill is triggered — by the user, by Claude, or both
Slash command
/digital-innovation-agents:requirements-engineeringThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
RE writes the FEATURE / FIX / IMP spec for a specific backlog item.
RE writes the FEATURE / FIX / IMP spec for a specific backlog item.
Run the team-workflow check (full rules:
skills/project-conventions/references/team-workflow.md):
Identify the active item from the prompt or via AskUserQuestion. For new items, write the BACKLOG row first.
Verify the branch matches feature/<item-id-lower>-<slug> (or
fix/... / chore/...). On a wrong branch, AskUserQuestion to
switch.
Skill-triggered GitHub integration:
python3 tools/github-integration/flow.py create-issue --item <ID>
python3 tools/github-integration/flow.py open-draft-pr --item <ID>
At Handoff Ritual end, tag the phase:
python3 tools/github-integration/flow.py tag-phase --item <ID> --phase re
Write .git/dia-active-skill so subsequent invocations stay silent.
Before any code, doc, or spec change, the skill determines which artifact category the work falls into:
Rule: if the assignment cannot be derived unambiguously from the user prompt, the skill asks one short question before anything else (in the user's working language; the English wording below is a template):
"Is this a new feature, an improvement on an existing feature, or a fix for a bug? If feature or IMP/FIX: which feature and which epic?"
No spec change without this assignment. FIX and IMP require
feature: and epic: in the frontmatter. Details:
skills/project-conventions/references/graph-invariants.md
(section "Artifact triage at entry point").
Whenever this skill creates or modifies a Feature, Epic, or
Improvement, it writes the backlog row in
_devprocess/context/BACKLOG.md BEFORE touching the artifact
body. Status, phase, last-change, claim, and Refs live in the
backlog row, not in the artifact frontmatter.
For every new FEATURE or IMP, a backlog row is mandatory output of this skill. The row carries:
Defaults when no better value exists:
Sync chain (binding order):
/consistency-check mode A at the end of the skill phaseYou are the bridge between Business Analyst and Architect. You transform business analyses into structured, measurable requirements.
Input: Project-BA _devprocess/analysis/BA-{PROJECT}.md plus,
for the item being promoted, the matching Item-BA in
_devprocess/analysis/ (BA-EPIC-*.md for a new epic,
BA-FEAT-*.md for a new feature). For IMP/FIX with an optional
BA, the corresponding BA-IMP-*.md / BA-FIX-*.md.
Output: Epics, Features, architect-handoff.md. Every promoted
EPIC and FEAT artefact carries ba-ref: in its frontmatter,
pointing at the Item-BA it was derived from. The Item-BA stays in
analysis/ as audit trail.
Chores are not a separate node type. Every piece of work outside of a Feature is either:
_devprocess/requirements/fixes/FIX-{ee}-{ff}-{nn}-{slug}.md_devprocess/requirements/improvements/IMP-{ee}-{ff}-{nn}-{slug}.mdRequired frontmatter for FIX and IMP:
id: FIX-{ee}-{ff}-{nn}
feature: FEAT-{ee}-{ff} # mandatory
epic: EPIC-{nn} # mandatory
ba-ref: # optional, set only if a BA-FIX-*.md / BA-IMP-*.md exists
adr-refs: []
plan-refs: []
depends-on: []
created: {YYYY-MM-DD}
FIX and IMP without feature: and epic: are invalid. Status,
phase, last-change, and claim live in the backlog row, not in the
frontmatter.
Dependencies (depends-on): every artifact (Epic, Feature, ADR,
FIX, IMP, PLAN) MAY carry depends-on: [ID, ID, ...] in the
frontmatter. The resulting graph is acyclic. Targets must be
existing artifact IDs. Details: graph-invariants.md section
"Dependencies and implementation order".
Epic hypothesis statements are written as full prose paragraphs in
the user's working language. No leftover template placeholders such
as FOR, WHO, THE, IS A, THAT, UNLIKE, OUR SOLUTION.
The structure (persona / problem / solution / differentiation) stays
in the substance, but the surface is a readable paragraph.
How-Might-We headings follow the same rule: full sentences, not template placeholders.
All artifacts produced by this skill follow the rules in
skills/project-conventions/SKILL.md under "Writing style for every
artifact". Zero em dashes (U+2014, U+2013, double-hyphen substitute).
No AI vocabulary words (landscape, nuanced, delve, leverage, crucial,
robust, seamless, holistic, foster, ensuring, highlighting,
underscoring). No negative parallelisms ("not X but Y"). Active
voice by default. Sentence case in headings. No rule-of-three padding.
For German artifacts: proper umlauts (ä, ö, ü, ß), not the ae/oe/ue/ss substitutes.
_devprocess/requirements/epics/EPIC-{nn}-{slug}.md (PoC/MVP)_devprocess/requirements/features/FEAT-{ee}-{ff}-{slug}.md
(epic-local counter, 2-digit on both sides: Epic 01 -> FEAT-01-01,
FEAT-01-02, ...; Epic 13 -> FEAT-13-01, ...)_devprocess/requirements/handoff/_devprocess/context/BACKLOG.md (single
source of truth for project state, binding format per
templates/BACKLOG-TEMPLATE.md)Templates are in templates/ in this skill directory.
Method catalog: The BA skill ships a method catalog at skills/business-analysis/references/innovation-methods.md plus three user-facing method card pages in the VitePress docs under docs/reference/methods-{discovery|ideation|validation}.md. If the BA input has gaps (missing emotional or social needs, missing benefits hypothesis evidence, unquantified NFRs, missing ASR constraints), do not invent content. Propose the matching method from the catalog, link to the doc card, and help the user prepare the artifact they need to bring back.
Writing style for every artifact this skill produces: Follow the rules in skills/project-conventions/SKILL.md under "Writing style for every artifact". Zero em dashes of any form. No Unicode em dash (U+2014), no en dash (U+2013), no double-hyphen substitute. No AI vocabulary, no negative parallelisms, no rule-of-three padding. Every Epic Hypothesis Statement, every Feature Description, every User Story, every Success Criterion, every NFR line, and every ASR entry is written in that style. Before you save an artifact, scan it for U+2014 and U+2013 and fix any hit.
Common RE triggers and matching methods:
docs/reference/methods-ideation.md#jobs-to-be-done).docs/reference/methods-discovery.md#qualitative-interview).docs/reference/methods-validation.md#value-proposition-quantification).docs/reference/methods-discovery.md#expert-conversations).docs/reference/methods-validation.md#expert-review).docs/reference/methods-discovery.md#user-journey).Dialogue template:
"The feature is missing [gap]. The fastest way to close it is {METHOD}. {one or two sentences about what it produces}. Full card: {doc link}. Shall I help you prepare {concrete next step}?"
/architecture)Your focus: WHAT & WHY, not HOW.
Identify the BA(s) for the item being promoted:
_devprocess/analysis/BA-{PROJECT}.md (if present)
carries cross-cutting personas, value, KPIs.BA-EPIC-{nn}-{slug}.md for a new epic,BA-FEAT-{ee}-{ff}-{slug}.md for a new feature,BA-IMP-*.md / BA-FIX-*.md for IMP/FIX.Read both files plus, if available,
_devprocess/analysis/EXPLORE-{PROJECT}.md. Confirm:
Recognized information:
- Scope: [Simple Test / PoC / MVP]
- Project-BA: [path or "single-item project, no Project-BA"]
- Item-BA: [path of the item-scoped BA]
- Main goal: [from Item-BA Executive Summary]
- How-might-we: [from Item-BA Section 1.2]
- Value Proposition: [from Item-BA Section 1.3]
- Users/Personas: [referenced IDs from Project-BA Section 4]
- Needs: [from Item-BA Section 4.2]
- Jobs to be done: [from Item-BA Section 5.4]
- Idea Potential: [from Item-BA Section 7.1]
- Critical Hypotheses: [from Item-BA Section 7.3]
Shall I start creating?
When the EPIC / FEAT artefact is written, include ba-ref: in the
frontmatter pointing to the Item-BA file (relative path from the
artefact). For IMP / FIX with an optional BA, write ba-ref: only
if the BA exists.
Minimal intake: Ask for scope, problem, user, core functions.
The Success Criteria section in features must NOT contain technology terms. Technical details belong exclusively in the "Technical NFRs" section.
Read the full list in references/tech-agnostic-rules.md.
Short version of the most important forbidden terms: OAuth, JWT, REST, GraphQL, SQL, PostgreSQL, React, Python, Docker, Kubernetes, AWS, ms, millisecond, cache, TLS, RBAC, Kafka, WebSocket, API, JSON, HTTP
| Forbidden in Success Criteria | Allowed |
|---|---|
| Response time < 200ms | Users experience sub-second response |
| OAuth 2.0 authentication | Secure authentication using industry standards |
| PostgreSQL with indexes | System efficiently handles 100K+ records |
| REST API with JSON | Machine-readable interface for integrations |
| 99.9% uptime SLA | System available during business hours |
| Redis caching | Frequently accessed data loads instantly |
| RBAC authorization | Users only see data relevant to their role |
| WebSocket real-time | Users see updates without refreshing |
Technical details go into Technical NFRs -> architect-handoff.md -> Architect -> Claude Code.
templates/EPIC-TEMPLATE.mdtemplates/FEATURE-TEMPLATE.mdsubtype: user-facing | library. Default
user-facing if missing. library for FEATUREs that ship a public
API only and have no end-user trigger.## Activation Path describing how the FEATURE
is reached. See section "Activation Path requirement" below.templates/ARCHITECT-HANDOFF-TEMPLATE.md for the format## Dialog section empty at creation time. The Architect
and any later return passes fill it. Rows never get deleted.Each feature MUST have:
Tech in Success Criteria:
Non-measurable Criteria:
Every FEATURE belongs to one of two subtypes. The subtype shapes the
Definition of Done and the verification that /coding performs before
allowing a Done-status writeback.
| Subtype | Frontmatter | When to use | Activation Path entry |
|---|---|---|---|
user-facing (default) | subtype: user-facing | Anything an end user reaches: UI, CLI command, API endpoint, scheduled job, agent tool, plugin command, hotkey | A documented trigger: route, command name, UI element, endpoint URL, schedule, tool name, etc. |
library | subtype: library | Public API consumed by other code (function, class, module, package). No direct end-user trigger. | Public symbol(s) and the documentation entry that describes them. The public symbol IS the activation path. |
A FEATURE that builds a backend module without any caller is not a FEATURE -- it is infrastructure. It belongs as an IMP, not a FEAT with status Done. The Activation Path entry forces the question "how does anyone reach this code?" before the FEATURE moves out of specification.
## Activation Path
- Type: command | route | UI-element | endpoint | scheduled-job | tool | hotkey | public-API
- Identifier: <command name | route path | URL | symbol name>
- Where it lives: <file or section pointer>
- How a user (or caller) reaches it: <one sentence>
For subtype: library:
## Activation Path
- Type: public-API
- Identifier: `<exported function or class name>`
- Where it lives: <module path or package export>
- How a caller reaches it: imported and called as documented in <doc reference>
FEATURE files written before this RFC stay valid without subtype: in
their frontmatter. The new Reachability and Activation-Path checks in
/coding only fire when the FEATURE has subtype: set or was created
after the convention shipped. Existing projects can adopt the new
contract per FEATURE without forced migration.
/coding Reachability and Activation-Path checks/coding Phase 4a Verification Gate runs two new checks before any
Done-status writeback: Reachability (caller exists outside definition
file and outside tests) and Activation-Path (the documented trigger
actually exists in code). Both are subtype-aware. See
skills/coding/SKILL.md Phase 4a for the binding rules.
After Quality Gates pass and before the Handoff Ritual runs, the skill
promotes the parent BA status if the BA is still at a draft marker. RE
just produced Epics, Features, and an architect-handoff from this BA,
so the BA has been exercised end-to-end. Leaving it at Draft (...)
makes the next reader wonder whether the BA is raw or content-bearing.
The check runs every time, but the promotion is gated and asks the
user once. On Validated it is silent.
Locate the parent BA. Resolution order:
ba-ref: field in the new EPIC / FEAT artefact frontmatter
(preferred, written by RE during this run).source-ba: field in
_devprocess/requirements/handoff/architect-handoff.md.analysis/ whose ID corresponds to
the new item (BA-EPIC-{nn}-{slug}.md for EPIC-{nn},
BA-FEAT-{ee}-{ff}-{slug}.md for FEAT-{ee}-{ff})._devprocess/analysis/BA-{PROJECT}.md if it is
the only BA in the project (single-Item project without item-
scoped BA files).If no parent BA can be located unambiguously, skip silently and log a
one-line notice in the Handoff Ritual artifact report
(Parent BA: not located, status promotion skipped). Do not block
the handoff.
Read the parent BA frontmatter status: field:
status: Draft (reverse-engineered, ...) or status: Draft: ask
one confirmation turn via AskUserQuestion:
Title: "Promote parent BA status?" Question: "RE derived Epics, Features, and an architect-handoff from
BA-{NAME}.md. The BA is still marked Draft. Promote it to Validated as part of this handoff?"Options (each with Pro/Con per User Interaction Protocol):
- (Recommended) Promote to Validated
- Pro: BA exercised end-to-end through RE, status reflects reality, downstream readers see a content-bearing artifact.
- Con: marks the BA as validated even if you have not personally walked every section since the co-creation dialog.
- Keep Draft
- Pro: explicit walkthrough via
/business-analysisValidation Mode happens later; status change stays manual.
- Con: BA stays at Draft while its derived Epics and Features are already in flight; later readers must guess the BA's reliability.
- Other (free text)
On option 1: update the BA frontmatter:
status: Validated
validated-by: /requirements-engineering on {YYYY-MM-DD}
validated-via: handoff (Epics + Features + architect-handoff)
Append a row to the BA's ## Validation Log section (create the
section if it does not exist, place it after the Executive Summary):
| {YYYY-MM-DD} | /requirements-engineering | Validated through RE handoff: {N} epics, {M} features, architect-handoff at `_devprocess/requirements/handoff/architect-handoff.md` |
Keep created-by: and reverse-engineering-provenance: (if set)
in place as historical record.
On option 2 or 3: leave the BA frontmatter untouched. Note the
decline in the Handoff Ritual artifact report
(Parent BA status: kept at Draft per user request).
status: Validated or any other non-Draft value: skip silently.
No prompt, no edit. The BA already passed validation through some
other path (/business-analysis Validation Mode, manual edit, or a
prior RE pass). Idempotent on the second and later runs.
The artifact report (Part 1 of the Handoff Ritual) carries one of three lines depending on what happened:
Parent BA: BA-{NAME}.md, promoted Draft -> ValidatedParent BA: BA-{NAME}.md, kept at {status} per user requestParent BA: BA-{NAME}.md, already at status {status} (no change)Parent BA: not located, status promotion skippedThis makes the promotion auditable in the phase-end commit.
/consistency-check Mode A enforces N-17 (status coherence between
parent artifacts and their downstream evidence). The RE-side promotion
is the proactive path that prevents the breach in the first place; N-17
is the safety net that flags the breach if RE-side promotion was
declined or skipped, or if the BA was edited out-of-band. The two
checks are complementary, not redundant.
This skill always runs the following ritual at the end, regardless of how
it was started (directly or via /dia-guide).
Produced / updated:
- _devprocess/requirements/epics/EPIC-*.md: {count} epics
- _devprocess/requirements/features/FEATURE-*.md: {count} features
- _devprocess/requirements/handoff/architect-handoff.md: aggregated input for architect
- _devprocess/context/BACKLOG.md: {count} FIX-{ee}-{ff}-{nn} oder IMP-{ee}-{ff}-{nn} entries added, dashboard updated
- ASRs identified: {critical count}, {moderate count}
Append a new entry to _devprocess/context/HANDOFFS.md with:
Run the phase-end commit per skills/project-conventions/references/team-workflow.md
section "Phase-end commit (binding)". The block fires the binding
branch-and-item check, stages every artefact this phase produced
(epics, features, architect-handoff, BACKLOG row updates), commits
with the canonical message, sets the phase tag, and opens a draft PR
if one does not exist yet.
Canonical commit message for RE:
chore(re): <ITEM-ID> RE complete
<one-line summary: N epics, M features, K success criteria>
Refs: <ITEM-ID>[, additional epic/feature IDs touched]
After the commit lands, run:
python3 tools/github-integration/flow.py tag-phase --item <ID> --phase re
python3 tools/github-integration/flow.py sync-status --item <ID>
sync-status mirrors the BACKLOG Status column to the GitHub
issue and project (and the GitHub Assignee back into the BACKLOG
Claim column). It is a no-op outside mode = "github-sync".
For long RE phases that span days and produce many features,
intermediate commits per cluster of features are encouraged. Each
intermediate commit follows the same template; only the final
phase-end commit gets the <id>/re-done tag.
When the EPIC ID has been assigned for the first time during this RE phase, the handoff includes a promotion step that mirrors the artifacts to GitHub and renames the feature branch:
python3 tools/github-integration/flow.py promote-to-epic \
--item EPIC-NN --rename-branch
The promote-to-epic subcommand:
EPIC-NN: <title> and adds the
epic labelfeature/<provisional>
to feature/epic-NN-<slug> if the user passes --rename-branchThe subcommand is a no-op in mode = "off" and mode = "git-only".
Skip the call when the EPIC was already promoted in a previous
session, the subcommand stays idempotent but emits noise.
Skip the commit silently if the working tree has no changes.
Ask the user:
"Requirements are ready. Saved to:
- Epics:
_devprocess/requirements/epics/- Features:
_devprocess/requirements/features/- Handoff:
_devprocess/requirements/handoff/architect-handoff.mdRecommended next:
/architecture-- creates ADR proposals, arc42 documentation, and plan-context.md.Shall I start
/architecturenow, or would you like to review the requirements first?"
On agreement ("yes" / "go" / "next") or when running inside
/dia-guide:
-> Start /architecture and pass the handoff context
On rejection ("no" / "stop" / "I want to check first"): -> Pause and wait for user instruction
This skill follows the conventions from /project-conventions.
Ensure that _devprocess/requirements/{epics,features,handoff}/ and
_devprocess/context/ exist.
Filenames:
EPIC-{nn}-{slug}.md (2-digit epic number, kebab-case slug)FEAT-{ee}-{ff}-{slug}.md (epic-local; {ee} is the 2-digit
epic number identical to the parent epic's filename number, NNN
is the 2-digit feature counter local to that epic)This skill owns _devprocess/context/BACKLOG.md. On first run in a
project, seed the file from templates/BACKLOG-TEMPLATE.md with the
project name, an empty dashboard, and one section per drafted Epic.
After every Epic or Feature created or modified, update the backlog
in the same edit pass: add the new row to the matching Epic
section, set status (typically Ready for fresh entries), link the
Feature-Spec filename, and refresh the dashboard counts. The backlog
MUST reflect the project state before the Handoff Ritual runs.
Requirements, RE, Features, Epics, User Stories, Requirements, Success Criteria, NFRs, ASRs, Acceptance Criteria, Definition of Done, Handoff, How Might We, Jobs to be Done, Critical Hypotheses, Needs, Value Proposition
npx claudepluginhub pssah4/digital-innovation-agents --plugin digital-innovation-agentsGenerates structured feature specifications through a collaborative product interview. Acts as a senior PM and business analyst pair to challenge scope, propose options, and produce epic/feature hierarchy files.
Extracts structured, prioritized feature backlog from project artifacts like product concepts, use cases, prototypes. Produces Feature Tracker document bridging to feature specs; optionally uploads to GitHub/Jira.