Feature creation

Workflow Feature creation

agent starscribe

tags

workflowfeature

context

agents/starscribe/feature.extendagents/starscribe/flow.create

A feature is the bridge between user intent and domain behaviour. Features do NOT define domain models — they consume and orchestrate existing domain actions/events.

Dependency Check

Before starting, verify:

• All referenced roles exist in content/roles/ — if not, run starspec/agents/starscribe/role.create first
• All referenced domains exist in content/domains/ — if not, run starspec/agents/starscribe/domain.create first

Phase 1 — Intent

Ask:

1. What does the user want to accomplish? (one sentence goal)
2. What problem does this solve?
3. New capability or extension of an existing feature?

Phase 2 — Roles

Which roles use this feature? Do all roles have the same access?

Phase 3 — Domain Touchpoints

Which domains does this feature interact with? Which domain actions does it invoke? Which domain events does it react to?

Derivation note: The domain’s api (actions and events) is the direct source for this feature’s requirements and flows. Work through the domain API before eliciting requirements independently — many are already implied.

Phase 4 — Requirements

Derive requirements from domain actions (Phase 3), then elicit additional ones with MoSCoW:

• must: what the feature must do
• should: what it should do if possible
• could: nice to have
• wont: explicitly out of scope

Use tags for non-functional requirements: performance, security, accessibility.

Phase 5 — Flow Design

Each distinct use case becomes a standalone *.flow.mdoc file. Flows are NEVER embedded in the feature document.

For each flow: which domain actions does it sequence? Pre-conditions? Steps? Branches? Post-conditions? Run starspec/agents/starscribe/flow.create for each flow.

Phase 6 — API

Define the actions and events this feature exposes, derived from domain actions it orchestrates.

Phase 7 — UI

Is there a UI? (form / page / modal / widget / API-only) What are the key interactive elements?

For UI specifications (wireframes), create a standalone *.ui.mdoc file using the Pug DSL. Run starspec/agents/stardesign/surface.create for each screen. Link to the feature via the for attribute in the ui tag.

Phase 8 — Acceptance Criteria

For each requirement, write at least one Gherkin criterion: “Given [precondition], when [action], then [outcome].” Link each criterion to its requirement via the requirement attribute.

Phase 9 — Draft & Confirm

Present the complete .feature.mdoc draft for confirmation before writing. Output: content/features/{id}.feature.mdoc

---

Do’s and Don’ts

Do:

• Verify all referenced roles and domains exist before starting
• Derive requirements from domain actions first, then elicit additional ones
• Create each flow as a standalone file using the flow.create loop
• Link every acceptance criterion to its requirement via the requirement attribute
• Present the full draft for confirmation before writing

Don’t:

• Don’t define domain models in a feature — features consume and orchestrate, they do not define
• Don’t embed flows inside the feature document; flows are always standalone files
• Don’t write requirements that duplicate what the domain already declares
• Don’t skip the dependency check for roles and domains
• Don’t create UI surfaces inline; use the surface.create loop for each screen

Definition of Done

• Draft presented to user for confirmation
• Document written as content/features/{id}.feature.mdoc with correct frontmatter and root tag
• All referenced roles and domains exist in content/
• Every requirement has at least one Gherkin acceptance criterion
• All flows are created as standalone .flow.mdoc files
• All cross-references resolve to existing documents
• pnpm compile succeeds

linkauthoring > examples > featurelinktag > featurelinktag > requirement