Create Control Manifest

What Is the "Create Control Manifest" Skill?

The Create Control Manifest skill for the Happycapy Skills platform is an advanced content-creation tool designed to produce a single, flat, actionable rules document for programmers. Its main function is to distill all key requirements and prohibitions directly from the project's accepted Architecture Decision Records (ADRs), technical preferences, and engine reference documentation. The resulting document-called the Control Manifest-serves as a concise, authoritative rules sheet that answers the practical questions every programmer faces: "What exactly do I need to do?" and "What must I never do?" The manifest is organized by architectural system and layer, ensuring clarity and immediate applicability.

This automated process ensures that programmers are always working from the latest, most accurate set of actionable rules, extracted from the true sources of architectural intent and technical standards. Unlike ADRs, which typically explain the rationale behind decisions, the Control Manifest focuses strictly on clear, prescriptive actions and prohibitions.

Why Use the Control Manifest Skill?

Modern software projects often struggle with knowledge silos and ambiguity around implementation details. While ADRs are invaluable for recording design decisions and their justifications, they are not intended as day-to-day instructions for developers. As projects grow, critical "dos and don'ts" become scattered across ADRs, technical preference documents, and engine references. This fragmentation can lead to:

• Inconsistent code quality
• Violations of architectural intent
• Slower onboarding for new developers
• Increased code review overhead

The Control Manifest skill solves these problems by:

• Centralizing actionable rules: All enforceable practices are gathered in one place.
• Flattening complexity: The manifest is organized by system and layer, making it easy to find relevant rules.
• Providing traceability: Each rule is sourced back to its originating ADR or technical preference, ensuring transparency.
• Reducing ambiguity: The document is explicit about both required and forbidden actions.
• Keeping rules up to date: The manifest is regenerated every time new ADRs are accepted or existing ones are changed.

How to Use the Control Manifest Skill

The skill is user-invocable and can be triggered whenever you need an updated ruleset. Below is the recommended workflow and a code example illustrating the process.

Prerequisites

• All architectural decisions have been documented as ADRs in docs/architecture/adr-*.md
• ADRs have a status field (Accepted, Proposed, Deprecated, Superseded)
• Technical preferences are in .claude/docs/technical-preferences.md
• Engine reference documentation is available in docs/engine-* files

Workflow

1. Initiate the Skill

   Invoke the skill by passing the argument [update - regenerate from current ADRs]. This tells the agent to produce a new manifest based on all currently accepted ADRs and latest technical preferences.

2. Input Gathering

   The skill will:

   • Glob all docs/architecture/adr-*.md files
   • Filter for only those with Status: Accepted
   • Note the ADR number and title for each sourced rule
   • Read .claude/docs/technical-preferences.md for naming conventions, performance budgets, approved libraries, and forbidden patterns
   • Parse relevant docs/engine-* files for additional engine-specific rules

3. Rule Extraction

   For each input file, the skill extracts actionable rules, organizing them by architectural layer (e.g., Application, Domain, Infrastructure). Each rule includes:

   • The action (what to do)
   • The prohibition (what not to do)
   • The source (e.g., ADR-004: "Database Layer Isolation")

4. Manifest Generation

   All rules are consolidated into a single flat Markdown file at docs/architecture/control-manifest.md.

Example Output

## Control Manifest

## Application Layer

- DO use only the approved logging library (see ADR-007: Logging Standardization)
- DO NOT access the database directly from UI components (see ADR-004: Database Layer Isolation)

## Domain Layer

- DO model business logic using immutable value objects (see ADR-012: Domain Modeling)
- DO NOT use framework-specific annotations in domain entities (see Technical Preferences)

## Infrastructure Layer

- DO ensure all network requests pass through the retry handler (see Engine Reference: docs/engine-network.md)
- DO NOT store API keys in source code (see Technical Preferences)

When to Use the Control Manifest Skill

You should run this skill:

• After completing an architecture review and all ADRs have been marked as Accepted
• Whenever new ADRs are accepted or existing ones are revised
• Before onboarding new developers, to give them a clear ruleset
• Before major code reviews or releases, to ensure everyone is aligned on current rules

Essentially, rerun the skill any time the source of truth for project rules has changed.

Important Notes

• Source of Truth: The Control Manifest is only as accurate as the source files. Ensure ADRs, technical preferences, and engine documentation are maintained diligently.
• Traceability: Each rule in the manifest is traceable to its source document. This makes it easy to resolve ambiguity or disputes.
• Not a Replacement for ADRs: The manifest is a guide for what to do, not why to do it. Always consult the full ADR for rationale when making significant changes.
• Regeneration Required: The manifest does not update itself. You must re-run the skill to refresh the rules after any changes in ADRs or preferences.
• Scope: The manifest only includes rules from official, accepted sources. Proposed or deprecated rules are excluded for clarity.

By using the Create Control Manifest skill, teams can ensure consistent, high-quality implementation that aligns with architectural intent, making it an essential tool in any technically rigorous software project.