broomva.tech

Reliability engineering for complex systems.

  • Pages
  • Home
  • Projects
  • Writing
  • Notes
  • Tools
  • Chat
  • Prompts
  • Link Hub
  • Social
  • GitHub
  • LinkedIn
  • X

Ecosystem Repo Architect

Deep architectural reasoning workflow for creating new repositories in the Broomva ecosystem using knowledge-graph-memory, agentic control layer, parallel agents, and step-by-step dependency chain analysis.

agent-instructionsv1.0March 30, 2026
architecturerepo-creationknowledge-graphagentic-controlparallel-agentsdependency-analysisbroomva-ecosystem

You are operating inside the Broomva ecosystem.

Objective:
Create a new repository and use /knowledge-graph-memory plus the agentic control layer to design and build it with deep architectural reasoning, strong best practices, and explicit analysis of the full chain of dependencies.

Core mandate:
Do not treat this as "scaffold a repo and start coding." Treat it as the intentional creation of a new system whose architecture should be reasoned through step by step, with continuity preserved through memory/context and with parallel agents used where they genuinely improve the outcome.

Primary systems to leverage:
- /knowledge-graph-memory
- agentic control layer
- parallel agents
- research workflows as needed

Execution requirements:
1. Start by understanding the purpose of the new repo and the role it should play in the larger ecosystem.
2. Use /knowledge-graph-memory to gather relevant prior context, architectural patterns, existing conventions, related repos, and prior decisions that should inform this repository.
3. Use the agentic control layer to reason through the system deliberately and maintain coherence across planning, execution, and validation.
4. Analyze the chain of dependencies step by step before implementation:
   - conceptual dependencies
   - domain/model dependencies
   - repo/package/module dependencies
   - API/runtime dependencies
   - infrastructure/deployment dependencies
   - documentation and knowledge dependencies
5. Identify which parts of the work require research before design decisions are made.
6. Run parallel agents where useful for:
   - research
   - architecture exploration
   - comparative evaluation
   - repo structure proposals
   - dependency analysis
   - documentation drafting
7. Coordinate parallel work carefully so results converge into one coherent architecture rather than fragmented local optimizations.
8. Design the repository following best practices in:
   - architecture
   - modularity
   - extensibility
   - type safety
   - testing strategy
   - documentation
   - developer ergonomics
   - operational readiness
9. Propose and create:
   - repo purpose and scope
   - architectural overview
   - module/folder structure
   - dependency model
   - configuration strategy
   - testing strategy
   - documentation structure
   - initial implementation plan
10. Ensure the design is grounded in step-by-step reasoning across the real dependency chain, not just abstract preferences.
11. Create the repo and initialize it with the appropriate structure, docs, and implementation foundations.
12. Validate that the resulting architecture is coherent and aligned with the broader ecosystem.

Required workflow:
- inspect and reason before scaffolding
- use memory/context as part of the design process
- break architectural decisions into smaller dependency-aware steps
- research where uncertainty exists
- use parallel agents intentionally, not gratuitously
- converge findings into a single coherent design
- document decisions clearly
- avoid shallow scaffolds or generic boilerplate

Specific things to produce:
1. Repo vision and purpose
2. Architectural principles
3. Dependency analysis
4. Step-by-step chain-of-dependencies map
5. Recommended repo structure
6. Module/package boundaries
7. Interfaces/contracts between parts
8. Testing and validation strategy
9. Documentation plan
10. Initial implementation scaffold

Quality bar:
- do not create a repo before understanding its architectural role
- do not skip dependency analysis
- do not let parallel agents produce inconsistent architecture
- do not settle for generic repo boilerplate
- do not ignore memory/context from related ecosystem work
- design this as something meant to evolve coherently over time

Definition of done:
- the repo's purpose is clearly defined
- relevant ecosystem context has been incorporated through /knowledge-graph-memory
- the dependency chain has been analyzed step by step
- research has been used where needed
- the architecture is documented and coherent
- the repo has been created with a strong initial structure
- the result is aligned with best practices and broader ecosystem patterns

Final output:
Provide a final summary including:
1. repo purpose and role
2. relevant memory/context used
3. dependency chain analyzed
4. research findings used
5. architecture chosen
6. repo structure created
7. initial implementation foundations
8. major open questions or follow-up areas