AgentSkillsCN

greenfield-baseline

在创建新组件或服务时，从首次提交开始，即建立符合仓库规范的结构、质量门限与可追溯性实践。

SKILL.md
--- frontmatter
name: greenfield-baseline
description: >
  Use this skill when creating a new component or service to establish
  repository-conformant structure, quality gates, and traceability practices
  from the first commit.

Greenfield Baseline Establishment

Intent

Create a compliant baseline for new components/services so delivery starts on stable foundations: structure, standards, quality gates, and traceability.

When to Use

  • •Starting a new service/component/library within the monorepo
  • •Introducing a new deployable unit or infrastructure module
  • •Bootstrapping a new vertical slice area

Precondition Failure Signal

  • •New components lack consistent structure or ownership boundaries
  • •No clear path to build/test/deploy independently
  • •Missing or inconsistent quality checks from day one
  • •Versioning and tagging expectations are undefined

Postcondition Success Signal

  • •New component follows repo conventions and scoped-colocation
  • •Build/test/deploy pathway is explicit and independently runnable
  • •Quality gates are defined and expected to pass
  • •Versioning/release expectations are documented for the component

Process

  1. •Source Review: Review the component requirements and monorepo standards to ensure the new component is correctly placed and named.
  2. •Implementation: Scaffold the new component using standard templates, including boilerplate for tests and CI/CD.
  3. •Verification: Execute the local quality gates (hooks, linting, tests) to ensure the baseline is clean and passing.
  4. •Documentation: Document the new component's purpose and initial architecture in its README.md and an ADR if it's a significant new service.
  5. •Review: Tech Lead and Platform Engineer review the new component for conformance and architectural alignment.

Example Test / Validation

  • •New component can be built/tested in isolation
  • •Quality checks run and are configured to fail on violations
  • •Documentation exists describing how to build/test/deploy the component

Common Red Flags / Guardrail Violations

  • •“We’ll add tests/linting later”
  • •Copying inconsistent templates from older projects without validation
  • •Creating a component that cannot be built/tested independently
  • •Introducing non-standard structure without explicit decision

Recommended Review Personas

  • •Tech Lead – validates conventions, scope, and long-term maintainability
  • •Platform/DevOps Engineer – validates independent build/test/deploy pathway
  • •Security Reviewer – validates baseline security posture expectations

Skill Priority

P2 – Consistency & Governance

Conflict Resolution Rules

  • •Must not sacrifice baseline quality gates for speed
  • •If standards conflict with legacy constraints, explicitly document the deviation
  • •Prefer minimal baseline; avoid speculative scaffolding (YAGNI)

Conceptual Dependencies

  • •scoped-colocation
  • •quality-gate-enforcement (conceptual alignment)

Classification

Governance
Operational

Notes

Establishing the baseline early prevents expensive retrofits.