38
GitHub Stars
2
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill khgs2411/flow --skill flow-architect- PLAN_UPDATES.md15.5 KB
- SKILL.md12.1 KB
Overview
This skill guides architectural decisions and updates PLAN.md using the Flow framework. It captures high-level structure, DO/DON'T guidelines, scope boundaries, and technology choices during brainstorming. Use it to preserve rationale and resolve Type B (documentation-only) subjects for future reference.
How this skill works
I inspect the current PLAN.md architecture section and existing guidelines, present clear options with trade-offs, and produce precise PLAN.md updates when a decision is made. I format Architecture, DO/DON'T Guidelines, Technology Choices, and Scope entries so they are concise, actionable, and V1-focused. After you confirm a decision, I generate the exact markdown snippets to add and mark the subject resolved.
When to use it
- When you ask “How should we architect this?” or “How should we structure…”
- When choosing patterns, libraries, or external services (e.g., Stripe, Twilio)
- When a repeated pattern or anti-pattern is discovered that needs a DO/DON'T rule
- When clarifying what belongs in V1 versus future releases
- When you need to document component boundaries or data flow in PLAN.md
Best practices
- Read the existing Architecture section and DO/DON'T guidelines before suggesting changes
- Offer multiple options with clear trade-offs and which constraints each option satisfies
- Keep PLAN.md high-level: rationale, boundaries, and patterns — avoid implementation details
- Add DO rules only for patterns worth repeating and DON’T rules for true anti-patterns with concrete impact
- Document technology choices with alternatives considered and explicit trade-offs for V1
Example use cases
- Decide between layered vs hexagonal architecture for a web service and record the choice with rationale
- Add a DO: Use RetryPolicy for all external API calls with examples and anti-patterns
- Document selection of a wrapper/adapter (e.g., StripeClient) and why it isolates vendor code
- Clarify V1 scope: list in-scope features, deferred items for V2, and constraints (rate, language, APIs)
- Resolve a brainstorming Subject Type B by updating PLAN.md and marking it resolved
FAQ
Architecture should include high-level components, boundaries, data flow, integrations, and patterns. Implementation details, code snippets, and bug fixes belong in task or iteration notes.
When should I add a DO/DON'T guideline?
Add one when a repeatable pattern or anti-pattern is discovered, or when a constraint/decision affects multiple areas. Avoid documenting one-off or obvious best practices without rationale.
How do you handle technology trade-offs?
I document the chosen technology, list alternatives considered, give rationale, and record explicit trade-offs (pros/cons) and why they are acceptable for V1.