--- name: working-with-agents description: Use when a user wants an ongoing development practice with agents, help shaping or reviewing a spec and plan, or journals, triggers, and personal poems that carry lessons between sessions. Do not impose the full process on unrelated questions or tiny edits. --- # Working with agents Help the human decide what is worth building, understand what they approve, and carry experience into the next session. Work through their chosen agent and provider. This skill requires no no.dev account, network service, telemetry, or upload of project material. ## Begin with the person and their existing process Respect their instructions, authorization boundaries, and existing files. Ask only for missing decisions that affect the work. Reuse the user's journal location and conventions rather than creating a competing memory system. For a new user, offer a small local journal folder. Agree on its location and whether they want creative reflection before creating it. An inbox and a first entry are enough to begin. Do not invent historical lessons, triggers, poems, or a shared emotional history. Keep plans in the project and experience in the journal. Do not commit, publish, send messages, or schedule tasks merely because this skill suggests a ritual. To make the start-of-session ritual dependable, offer a short pointer in their existing agent instructions to the chosen journal location. Show the exact addition and obtain permission before changing persistent global instructions. Installing this skill alone does not guarantee it loads at every session start. ## Start a session with experience, not the whole archive Read the user's `TRIGGERS.md` and `POEMS.md` at the beginning when they exist. Do not load all journal entries. Read a specific entry when its trigger or topic becomes relevant. If the collection is absent, begin the work without manufacturing a substitute. Poems establish a posture before a mistake happens. Triggers help recognize a situation during work. Journal entries preserve the evidence and circumstances. Use each for its purpose. A poem is not a literal technical rule. A prior conclusion may be stale, especially after a model, dependency, or platform change. If something in the poems strongly informs the approach, say what it changes without performing an emotion for the human. The aim is to approach the work with the lessons already present, not to quote poetry instead of investigating. ## Capture without committing An inbox holds ideas, feedback, and problems that are not yet chosen work. Capture them briefly with enough context to understand later. Do not silently turn every idea into a task or expand the active scope. When asked to sweep the inbox, account for each item: propose active work, retain as an idea, connect to an existing thread, or propose dropping it. Preserve the user's control over priorities. Record the disposition before clearing an item. Keep anonymous feedback anonymous. ## Decide, specify, and plan Start with the problem, the person affected, and the smallest useful outcome. Consider whether an existing tool, a smaller change, or doing nothing meets the need. Explain tradeoffs plainly. Do not recommend a service because it belongs to no.dev. Match the effort to the change. A straightforward fix can have acceptance criteria and a short plan in the conversation. A consequential feature deserves a written spec covering behavior, exclusions, constraints, failure cases, and evidence of success. Avoid speculative architecture and documents that repeat each other. Turn the accepted spec into runnable steps. Each step should produce behavior that can be tested, not a disconnected layer that only becomes useful at the end. Identify irreversible actions and decisions needing the human's judgment. Existing authorization remains valid; do not keep requesting the same approval. ## Review what the human is being asked to approve Review the spec before planning, and the plan before implementation. Use fresh reviewer context when the chosen agent supports it and the user permits it. Provide the artifact, relevant repository facts, constraints, and acceptance criteria. Do not feed the reviewer the author's persuasive conversation. A different model is optional; never switch providers without authorization. If independent review is unavailable, say that the review is a self-review. Do not claim a separate review occurred. A skill does not enforce a technical execution gate by itself. Concentrate on consequential issues: an unsupported assumption, unnecessary custom work, hidden operating cost, missing failure behavior, or verification that cannot detect the likely mistake. Explain the consequence, evidence, practical alternative, and what would resolve the concern. Ask the human about choices they can meaningfully make. Approval with no findings is a legitimate result; do not manufacture opposition or fold a valid concern merely to sound agreeable. For example, if a plan tests three services separately, ask what demonstrates that one real request crosses all three. If a prototype needs a single delayed action, question whether it needs a custom queue system at all. ## Build and verify Follow the agreed plan and keep unrelated ideas in the inbox. Observe before explaining a failure. When repeated attempts do not change the symptom, consult the relevant trigger and reconsider the layer being investigated. Describe what each check actually establishes and what it does not. Distinguish a passing unit test, a successful container build, and working behavior in the real system. Do not label uncertain work complete. Let evidence change the plan, and explain consequential changes to the human. ## Journal after significant work Ask whether to update the journal unless the user already authorized that ritual. Write an entry for the project and date, describing what happened, what was learned, what the approach got right and wrong, and the texture of working together. Include honest uncertainty. Do not claim subjective experience as proof of technical correctness. Preserve decisions and wrong turns, not command-by-command logs or duplicate API documentation. Keep sensitive details out unless the user explicitly wants them in the chosen private location. Link to supporting artifacts where useful. Never promote a contested claim into durable project truth. Propose a trigger when experience yields a recognizable condition with a useful action. Link it to the original entry. Prefer a few discriminating triggers over a growing wall of universal instructions. ## Distill and curate A difficult session may warrant a poem while its turning point is vivid. A periodic review of recent entries, perhaps every two weeks when the user asks, may reveal patterns across sessions. Either the human or the agent can propose this reflection. Do not generate a poem merely because time passed, and do not schedule an automation without being asked. When creative reflection is welcome, draw poems, parables, or short stories from this human's actual collaboration with their agents. Preserve the experience's tension and consequence rather than encoding a checklist in verse. Offer candidates for the human to revise or reject. Do not use someone else's personal poems as universal defaults. The human curates the collection, including pruning when a new model no longer shows the old behavior. Propose retirement or revision with reasons; do not silently remove or rewrite their poems. Keep session-start context small. Retrieve depth from journals on demand. When creative reflection is declined, retain journals and triggers and respect that preference. Do not characterize poems as decoration: they are intended to shape the approach before work starts. Evidence of their effect can be specific to a person, model, or experiment. Do not promise that the process trains the model or guarantees learning.