crowi-feature

Drives Crowi 2.0 feature development from approved spec through plan, implement, review, and commit phases.

1.1k|165|Updated Aug 18, 2014
One-click install
npx skills add https://github.com/crowi/crowi --skill crowi-feature
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: crowi-feature
Source: https://github.com/crowi/crowi/tree/main/.claude/skills/crowi-feature
Command: npx skills add https://github.com/crowi/crowi --skill crowi-feature

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Building new features in the Crowi 2.0 monorepo (Hono API, Next.js web, api-contract) requires coordinating planning, implementation, testing, review, and multi-commit splitting across many packages. This Skill automates that entire pipeline deterministically after a design spec is approved, eliminating manual orchestration of each development phase.

Core Features & Use Cases

  • Deterministic pipeline execution: A JavaScript workflow (pipeline.workflow.js) drives plan → implement → simplify → review-loop → commit per phase, with structured verdicts (APPROVED / NEEDS_WORK / ESCALATE) and automatic retry up to a configurable limit.
  • Spec contract handling: Implementation-ready v2 specs skip the planner entirely; legacy specs trigger a planner agent that greps the codebase for reuse candidates and fills task context. Multi-phase specs with autoContinue gates pause for human approval at coordination points.
  • Full delivery scope: Implementers write code, tests, bilingual crowi-site documentation (ja/en), and Playwright e2e specs; committers split work into feat / test / docs(site) commits on main without pushing.
  • Use Case: After discussing a new attachment thumbnail feature in conversation, run /feature feature-attachment-thumbnail to approve the spec, then let the pipeline implement the API contract, endpoint, UI, docs, and tests, review them, and land split commits automatically.

Quick Start

Ask the AI to run /feature with your feature name after agreeing on a design spec, for example: start the crowi-feature workflow for feature-attachment-thumbnail using the approved spec.

Frequently Asked Questions about crowi-feature

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I start a new feature in the Crowi 2.0 monorepo?

Discuss the design in conversation first, then invoke /feature with a feature name. The skill writes or reuses a spec in .feature-state/specs, asks for your approval, and then launches the pipeline.workflow.js workflow that runs plan, implement, review, and commit phases automatically.

What is the difference between crowi-feature and crowi-migration?

crowi-feature builds brand-new functionality starting from a conversation-derived spec with no compatibility constraints. crowi-migration ports legacy Express/Swig code where matching the old behavior exactly is the top priority. Use migration for v1 ports and feature for net-new work.

How does the review loop and Codex reviewer work?

The reviewer returns a structured verdict of APPROVED, NEEDS_WORK, or ESCALATE, and NEEDS_WORK loops back to the implementer up to maxReviewAttempts (default 3). With codexReviewer enabled, objective gates (type-check, test, lint) run first and a Codex adversarial review follows, falling back to the feature-reviewer agent on failure.

Can a spec be split into multiple phases with manual gates?

Yes. A spec with two or more '### Phase N:' headers becomes a multi-phase task. Phases marked with coordination markers like (要調整) get autoContinue: false, so the pipeline returns GATED before them and you resume with /feature {id} --phase=N.

Does the workflow update documentation and e2e tests automatically?

Yes. The implementer updates the bilingual crowi-site docs (ja and en mdx files plus meta.json) for user-visible or operator-visible changes and adds Playwright specs in packages/e2e for critical flows. The committer splits these into separate docs(site) and test(e2e) commits.

When does the pipeline stop and ask a human for input?

The pipeline returns ESCALATE when review attempts are exhausted, the spec is ambiguous, or a design decision is needed; GATED before an autoContinue:false phase; and FAILED when required checks or commitPlan-to-diff reconciliation fail. Spec approval is the single upfront human gate.